Azure 上の Red Hat Enterprise Linux におけるプラットフォーム自動化に関する考慮事項

[アーティクル]
08/05/2024

この記事では、Azure 上の Red Hat Enterprise Linux (RHEL) の自動化を管理する方法について説明します。一貫性のある安定した環境を実現するために使用できる、Azure エコシステム内のさまざまなツールに関する設計上の考慮事項、推奨事項、オプションについて説明します。この記事では、さまざまなお客様のシナリオ、ビジネス要件、運用プラクティス、技術的成熟度に合わせて調整されたガイダンスを提供します。

概要

Azure ランディングゾーンの RHEL を自動化する場合は、Red Hat インフラストラクチャ標準 (RH-IS) および関連する Red Hat インフラストラクチャ標準導入モデル (RH-ISAM) を使用して、Azure ランディングゾーンのライフサイクル管理を調整します。ソリューションの信頼できる基盤を提供するようにシステムを標準化します。 RH-IS は、ソフトウェアコンポーネントと構成の既定のセットから成る標準の運用環境を定義しています。これらのコンポーネントと構成は、RH-ISAM (DevOps または Git 運用原則、Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、Azure CLI、Azure PowerShell のセット) を通じてシステムに適用できます。

さまざまな操作を自動化できます。たとえば、自動化を使用して以下ができます。

コンポーネントのプロビジョニング。
システムの管理。
プラットフォームの機能強化。
インフラストラクチャ運用の組み込み。
アプリケーションおよびワークロードのライフサイクルの構成。

これらの操作は Infrastructure as Code (IaC) と Configuration as Code として実装できます。エラーを減らし、信頼性を高めるために、構成を定義し、テストします。大規模な移行の速度を向上させるために、プロビジョニングを自動化します。自動化された構成により、構成のドリフトが減り、確実にシステムが正しく機能するようになります。

設計上の考慮事項

Red Hat Identity Management (IdM) は、RHEL システムの ID ストア、認証ポリシー、承認ポリシーを管理するために使用できる、一元化された統合プラットフォームとなります。ハイブリッドシナリオでは、既存の Red Hat IdM インフラストラクチャを仮想プライベートネットワークまたは Azure ExpressRoute により拡張できます。この構成により、オンプレミス環境が Azure 内の RHEL ランディングゾーンに接続されます。ハイブリッドクラウド ID シナリオをサポートするために、オンプレミス環境を Azure に拡張して、ワークロードを Microsoft Entra と統合できるようにします。詳細については、Microsoft Entra 認証に関するページを参照してください。

代替の ID 管理ソリューションとして、RHEL を参加させて Windows Server Active Directory との外部信頼を作成するか、既存の Windows Server Active Directory フォレストに直接参加させることができます。詳細については、「RHEL システムを Windows Server Active Directory と直接統合する」を参照してください。

Red Hat Satellite は、マネージド RHEL システムに配信される 1 つのコンテンツソースです。 Satellite には、Red Hat のパッケージとパッチだけでなく、Microsoft 以外からのパッケージとアプリケーション開発チームが開発するカスタムパッケージが含まれています。 Satellite は、セキュリティやパフォーマンスのリスクを特定するために構成の予測分析を行う Red Hat Insights へのゲートウェイとして機能します。事前構成済みの RHEL 従量課金制イメージをデプロイする場合は、Red Hat Update Infrastructure for Azure を利用できます。これは、従量課金制イメージに組み込まれている更新ツールです。

Red Hat Ansible Automation Platform に関する設計上の考慮事項

Red Hat Ansible Automation Platform (AAP) は技術的なワークフローと定期的なタスクの標準化に役立ちます。 AAP を使用して、ワークフローのオーケストレーション、新しいシステムのプロビジョニングプロセスの作成、定期的な運用タスクの作成を行うことができます。複雑さを軽減するために、1 つの共通の自動化プラットフォームと言語を使用します。完全自動化ワークフローにより、アプリケーションのイノベーションが加速され、オンプレミス環境とクラウド環境にまたがる大規模なワークロード移行が簡素化されます。

プラットフォーム自動化戦略としての RHEL の利点は次のとおりです。

新しいシステムの大規模な完全自動プロビジョニングにより、大規模な移行の速度が向上します。
物理システムと仮想システムにわたって、テスト済みシステムの構成とアプリケーションのインストールの均一性が向上します。
パッチ管理をすぐに利用できるため、継続的な更新が可能です。
新しいアプリケーションとワークロードをデリバリーするためのプラットフォームが標準化され簡素化されます。スタッフはイノベーションを拡大するための追加の時間を確保できます。

以下を実装できます。

オンプレミスインフラストラクチャ、クラウドインフラストラクチャ、またはその両方を使用したセルフマネージド AAP インスタンス。 RHEL デプロイまたは Red Hat OpenShift Container Platform デプロイを使用できます。
パブリッククラウド内のセルフマネージド AAP インスタンス。
パブリッククラウド内のマネージド AAP インスタンス。

オンプレミスまたはクラウドでのセルフマネージド Red Hat AAP

Microsoft Azure 上の Red Hat AAP をオンプレミス、クラウド、またはハイブリッドインフラストラクチャに自己管理モードでデプロイすると、次の利点が得られます。

アーキテクチャとスケール: 自動化プラットフォームをサポートするのに最適なアーキテクチャを決定します。 RHEL インフラストラクチャまたは OpenShift オペレーターデプロイに基づいたアーキテクチャを選択できます。フリートのサイズと要件に基づいて、コントローラー、実行ノード、プライベート自動化ハブのインスタンス数とインスタンスサイズを選択します。アーキテクチャ、設計、構成、スケールの詳細については、Red Hat AAP 計画ガイドを参照してください。
Azure 構成: 組織の Azure の設計と構成に合わせて自動化アーキテクチャを最適化します。
自動化メッシュのサポート: AAP 自動化メッシュ機能により、既存のネットワークを使用してピアツーピア接続を確立するハイブリッドクラウドノードにわたって自動化ワークロードを分散します。セキュリティ設計基準とネットワークトポロジに基づいて、ホップノードをデプロイします。
自動化ハブアーキテクチャ: スケールとプライベート自動化ハブインスタンスの配置に合わせて自動化ハブアーキテクチャを最適化します。自動化実行リソースに近接する実行環境ソースへの自動化コンテンツの安全な配信とアクセスを強化するように、構成を最適化します。自動化コンシューマーによってアクセス可能な Ansible コンテンツのコレクションとバージョンを選択できます。

マネージドまたはセルフマネージド Red Hat AAP on Azure

Microsoft Azure 上の Red Hat AAP はマネージドアプリケーションまたはセルフマネージドアプリケーションとして利用でき、次の利点があります。

使いやすさによる迅速な投資収益率 (ROI): Azure Marketplace から直接 AAP on Azure をデプロイできます。このマネージドソリューションは、デプロイ直後にアクティブになり、数分で Azure リソースの管理の自動化を開始できます。 Red Hat がインフラストラクチャを管理するため、企業にとって重要な他のシステムについて自由に検討できます。
合理的な統合: AAP on Azure は Azure サービスと統合されています。 Microsoft と Red Hat が Azure 用の Ansible コレクションを開発し、セキュリティテストを行ったため、最小限の設定で最大限のサポートを得られます。 AAP on Azure をハイブリッドクラウド自動化戦略の一環として使用して、ハイブリッドクラウド、モノのインターネット、エッジデプロイにわたって管理と自動化を統合します。
既存のコミット済み Azure 支出: Microsoft との既存のコミット済み支出を使用して AAP on Azure を購入できます。コミット済み支出を使用すると、組織全体のチームがコンポーネントをシームレスにデプロイ、構成、自動化できます。請求の統合とは、単一の請求書で全コストを可視化できるということです。
クラウドを超えた自動化: AAP on Azure を使用すると、Microsoft Azure クラウドにアプリケーションをデプロイし、インフラストラクチャ全体に拡張できます。 Azure 環境とハイブリッドクラウド環境にわたってアプリケーションをデプロイ、実行、スケールします。
サポート: Red Hat と Microsoft は提携して AAP on Azure を構築して、一貫したセキュリティ重視の運用を実現しています。 Red Hat がアプリケーションを管理、サービス提供、サポートするため、IT チームは自動化戦略のデリバリーに専念できます。

マネージドモードに関するその他の考慮事項

AAP on Azure は、マネージドアプリケーションになるように、マネージドモードでインストールできます。 Red Hat が、基盤となる Azure リソースとその上で実行されるソフトウェアの両方を管理します。そのインフラストラクチャは Azure テナントで実行されます。

マネージドアプリケーションリソースグループはテナント内の他のリソースグループとは別のものです。 Red Hat は、マネージドアプリケーションリソースグループにのみアクセスでき、他のテナントリソースを表示することはできません。

詳細については、「Azure マネージドアプリケーションの概要」を参照してください。

マネージドモードの AAP on Azure では、次のリソースグループが使用されます。

テナント内の新規または既存のリソースグループ。このリソースグループには、AAP on Azure マネージドアプリケーションデプロイを参照する 1 つのリソースが含まれています。 Red Hat はマネージドアプリにアクセスして、サポート、メンテナンス、アップグレードを行うことができます。ただし、Red Hat はリソースグループを管理しません。
AAP on Azure を運用するために必要なインフラストラクチャのほとんどを含む、マルチテナントマネージドリソースグループ (MRG)。 Red Hat テナントとお客様のテナントは、このマルチテナントリソースグループを共有します。 Red Hat は完全な管理制御権を持ちます。お客様はリソースグループへの読み取り専用アクセス権を持ちます。
Azure Kubernetes Service (AKS) ノードプールリソースグループ (NPRG)。 Microsoft は AKS デプロイに NPRG を必要とします。 NPRG には、AKS が機能するために使用するリソースが含まれています。このリソースグループは、デプロイ時に作成されます。 Red Hat はこのリソースグループを管理しません。詳細については、Microsoft AKS のドキュメントを参照してください。

マネージドモードの AAP on Azure では、次の要素も考慮してください。

AAP on Azure をインストールする際、デプロイをパブリックにするかプライベートにするかを選択します。これは、ユーザーが AAP ユーザーインターフェイスにアクセスする方法に影響します。
パブリックデプロイとプライベートデプロイのどちらを選択しても、自動化するリソースを含むプライベートネットワークへの AAP からのアウトバウンド通信用にネットワークピアリングを構成する必要があります。 AAP on Azure からプライベート Azure 仮想ネットワークへのネットワークピアリング、さらに、Azure とのトランジットルーティングが存在するオンプレミスネットワークまたはマルチクラウドネットワークへのネットワークピアリングを構成できます。

セルフマネージドモードに関するその他の考慮事項

セルフマネージドモードの AAP on Azure にはマネージド AAP と同様の多くの利点があります。ただし、マネージドモードが AKS クラスター内で実行される場合、セルフマネージドモードの自動化プラットフォームリソースは仮想マシン (VM) ベースになります。

セルフマネージドモードの AAP on Azure では、次の要素を考慮してください。

Event-Driven Ansible は Azure 上のセルフマネージド製品に含まれています。イベントドリブン自動化は、手動タスクを削減し、イノベーションに重点を置いた効率的な IT 環境を提供するのに役立ちます。 Event-Driven Ansible は、イベントを処理し、適切な応答を決定し、イベントを修復するための自動化されたアクションを実行します。
サブスクリプションは 100 アクティブマネージドノード単位で利用できます。パブリックオファーまたはプライベートオファーで使用できます。
セルフマネージドモードの AAP on Azure を支える VM リソースは、Azure Marketplace イメージのみで構成することも、Azure Marketplace イメージとカスタマーマネージドイメージの組み合わせで構成することもできます。

設計の推奨事項

Azure ランディングゾーンの RHEL プラットフォームを運用する際は、Red Hat 認定コンテンツと、Red Hat 自動化ハブからの検証済みコンテンツコレクションを使用します。次のコレクションは自動化フレームワークで重要な役割を果たします。

redhat.rhel_idm
- IdM プライマリ VM を構成する。
- IdM レプリカを構成する。
- RHEL クライアントを IdM と統合して構成する。
redhat.satellite、redhat.satellite_operations、redhat.rhel_system_roles
- Satellite と Capsule をデプロイする。
- Satellite のオブジェクトと設定を作成して構成する。
- RHEL システムをプロビジョニングして構成する。
ansible.*、ansible.controller、infra.controller_configuration
- AAP を構成します。
- AAP ジョブテンプレートと設定を作成して構成する。

Azure 用の Ansible コレクションには、次のような Azure リソースタイプを照会、管理、自動化するために使用できる 250 を超えるモジュールが含まれています。

AKS。
アプリケーションセキュリティグループ。
Azure Container Registry。
Azure データベースサービス。
Azure Key Vault。
Azure SQL データベース。
Azure Virtual Machines。
Microsoft Entra ID。
ネットワーク。
Storage]\(次へ: ストレージ\) を選択します。

コアプラットフォームインフラストラクチャのデプロイ

コアプラットフォームインフラストラクチャを効果的にデプロイし、Azure ランディングゾーンモデルの RHEL プラットフォームをサポートするための、概念とプロセスを定義します。

詳細については、以下を参照してください:

プラットフォーム自動化の考慮事項に関する Azure ランディングゾーン設計ガイダンス。
開発ライフサイクル。自動化を使用したランディングゾーンの作成に関する主な設計上の考慮事項と推奨事項について説明します。このガイダンスでは、リポジトリ、ブランチ、自動ビルド、デプロイ、ロールバック戦略について説明します。
IaC。 IaC を通じて Azure ランディングゾーンを実装することの利点について説明します。コード構造、ツール、テクノロジに関連する考慮事項について説明します。
環境。複数の環境を使用して、より高速かつ頻繁にコードをビルド、テスト、リリースする方法について説明します。このアプローチにより、デプロイを可能なかぎり単純にできます。
テスト駆動開発。単体テストを使用して、新しい機能の品質を向上させ、Azure ランディングゾーンコードベースを改良する方法について説明します。

前のセクションで必要なソースコード管理ツールを導入し、ソースコード管理プロセスを定義したら、自動化を実装できます。 IaC または Configuration as Code として付属の Ansible 自動化コードを開発して、コアインフラストラクチャをデプロイし、Azure ランディングゾーンモデルの RHEL プラットフォームをサポートします。グリーンフィールドデプロイの場合、完全な環境実装のために次のタスクを自動化できます。ブラウンフィールドデプロイの場合、ユースケースに必要なタスクのみを自動化できます。

Azure リソースグループを作成する。
仮想ネットワークを作成する。
サブネットを作成する。
ネットワークセキュリティグループを作成する。
自動化された Red Hat Image Builder を通じて Azure 用の RHEL 8.x および 9.x ゴールデンイメージを作成する。
IdM プライマリ VM を作成する (事前 Satellite プロビジョニング)。 Configuration as Code を通じて IdM プライマリ VM を構成する。
Satellite VM を作成する (事前 Satellite プロビジョニング)。 Configuration as Code を通じて Satellite を構成する。
Capsule VM を作成する (Satellite プロビジョニング)。 Configuration as Code を通じて Capsule を構成する。
IdM レプリカ VM を作成する (Satellite プロビジョニング)。 Configuration as Code を通じて IdM レプリカを構成する。
AAP インフラストラクチャを作成する (Satellite プロビジョニング)。これには以下が含まれます。
- 自動化コントローラー VM。
- 実行ノード VM。
- ホップノード VM (オプション)。
- 自動化ハブ VM。
- Event-Driven Ansible VM (有効な場合)。
- Azure Database for PostgreSQL サーバー、さらにコントローラー、ハブ、Event-Driven Ansible コンポーネントに必要なデータベース。高可用性またはディザスターリカバリー Azure Database for PostgreSQL 構成には、レプリケーション、ログ配布、または Crunchy Postgres を介した追加の自動化が必要です。
ロードバランサー (アプリケーションゲートウェイ) を作成する。
- Capsule VM のフロントエンド
- AAP コントローラー VM のフロントエンド
- 自動化ハブ VM のフロントエンド
アプリケーションセキュリティグループを作成する
- IdM インフラストラクチャ
- AAP インフラストラクチャ
- Satellite または Capsule インフラストラクチャ

RHEL システムのライフサイクル管理

コアプラットフォームインフラストラクチャが整ったら、RHEL アプリケーションとワークロードのライフサイクルの自動化を実装できます。次のワークフローは、開発ライフサイクルパイプラインの自動化実装の例を示しています。

エラータフィルターの終了日を更新し、Satellite でコンテンツを公開します。
コンテンツビュー (CV) と複合コンテンツビュー (CCV) を開発環境に昇格させます。
Satellite ホストグループから RHEL 開発テストシステムをデプロイします。 Red Hat Image Builder を通じて自動生成された Azure 用の RHEL 8.x および 9.x ゴールデンイメージは、Satellite 内で Azure コンピューティングリソースとして定義されます。
アプリケーション通信パスに基づいて Azure ネットワークセキュリティグループを更新または作成します。
Azure アプリケーションセキュリティグループを更新または作成して、多層アプリケーションスタックに複数層セキュリティを追加します。
RHEL 開発システムを更新し、Satellite 開発 CV または CCV から目的のアプリケーションをデプロイして構成します。
- シンプルなアプリケーションスタックの場合は、1 つの RHEL インスタンスにデプロイします。
- 多層アプリケーションスタックの場合は、複数の RHEL インスタンスにデプロイします。
- アプリケーションスタックを構成します。
アプリケーションテストフレームワークを実行します。
- テストに失敗した場合は、OnCall 自動化管理者に通知して、トラブルシューティングと分析の支援を依頼します。自動化ワークフローを終了します。 RHEL テストシステムは事後分析のためにデプロイされたままになります。
- テストに成功した場合は、手順を続行します。
CV と CCV を品質保証 (QA) 環境に昇格させます。
RHEL 開発テストシステムを破棄します。

ライフサイクルパイプラインの後続のステージは開発ライフサイクルステージとは少し異なります。開発ステージのみで、初期コンテンツの公開、さらに初期 CV と CCV の開発環境への昇格が使用されます。次の例では、非開発ライフサイクルパイプライン (QA、運用前、運用パイプラインなど) の自動化ワークフローを説明しています。

Satellite ホストグループから RHEL QA テストシステムをデプロイします。 Red Hat Image Builder を通じて自動生成された Azure 用の RHEL 8.x および 9.x ゴールデンイメージは、Satellite 内で Azure コンピューティングリソースとして定義されます。
アプリケーション通信パスに基づいて Azure ネットワークセキュリティグループを更新または作成します。
Azure アプリケーションセキュリティグループを更新または作成して、多層アプリケーションスタックに複数層セキュリティを追加します。
RHEL QA システムを更新し、Satellite QA CV または CCV から目的のアプリケーションをデプロイして構成します。
- シンプルなアプリケーションスタックの場合は、1 つの RHEL インスタンスにデプロイします。
- 多層アプリケーションスタックの場合は、複数の RHEL インスタンスにデプロイします。
- アプリケーションスタックを構成します。
アプリケーションテストフレームワークを実行します。
- テストに失敗した場合は、OnCall 自動化管理者に通知して、トラブルシューティングと分析の支援を依頼します。自動化ワークフローを終了します。 RHEL テストシステムは事後分析のためにデプロイされたままになります。
- テストに成功した場合は、手順を続行します。
CV と CCV を運用環境に昇格させます。
RHEL QA テストシステムを破棄します。

Azure ネイティブツールに関するその他の設計上の考慮事項

Azure Automation

頻繁に実行され、時間がかかり、エラーが発生しやすい管理タスクを自動化するには、Azure Automation のプロセス自動化機能を使用できます。この機能を利用して、ビジネスの価値を高める作業に集中できます。プロセス自動化により、エラーが減り、効率が高まるため、運用コストの削減に役立ちます。詳細については、「Automation の概要」を参照してください。

プロセス自動化は、エンドツーエンドプロセスのデプロイ、構成、管理に必要な Azure サービスと、Red Hat などのパートナーシステムの統合をサポートします。この機能を使用して、グラフィカルな PowerShell と Python の Runbook を作成することもできます。

Runbook は、リソースの管理、VM の起動と停止、Azure 内外でのメンテナンスタスクの処理など、さまざまな自動化タスクに使用できます。詳細については、「Azure Automation アカウント認証の概要」と「Azure Automation の Runbook」を参照してください。

次の表に、サポートされている Runbook のタイプについて説明します。

Runbook の種類	説明
PowerShell	Windows PowerShell スクリプトに基づくテキスト形式の Runbook です。サポートされているバージョンは PowerShell 7.2 (GA) と PowerShell 5.1 (GA) です。 PowerShell の親製品では、PowerShell 7.1 はサポートされなくなりました。長期サポートバージョンの PowerShell 7.2 で Runbook を作成することをお勧めします。
PowerShell ワークフロー	Windows PowerShell ワークフロースクリプトに基づくテキスト形式の Runbook です。
Python	Python スクリプトに基づくテキスト形式の Runbook です。サポートされているバージョンは Python 3.8 (GA) と Python 3.10 (プレビュー) です。 Python の親製品では、Python 2.7 はサポートされなくなりました。長期サポートバージョンで Runbook を作成することをお勧めします。
グラフィカル	Windows PowerShell に基づき、Azure portal のグラフィカルエディターで完全に作成および編集されるグラフィカル Runbook です。
グラフィカル PowerShell ワークフロー	Windows PowerShell ワークフローに基づき、Azure portal のグラフィカルエディターで完全に作成および編集されるグラフィカル Runbook です。

Webhook を使用すると、Azure Logic Apps、Azure Functions、IT サービスマネジメント製品やサービス、DevOps、または監視システムを通じて自動化をトリガーすることで、要求を満たし、継続的なデリバリーと運用を実現できます。

Azure Arc はクラウドコンピューティングにおける大きな進歩であり、Azure の機能をオンプレミス、マルチクラウド、エッジ環境に拡張する統合管理プラットフォームとして機能します。 Azure Arc は、VM 拡張フレームワークを通じて Azure Automation サービスと統合され、ハイブリッド Runbook ワーカーロールのデプロイ、更新管理、変更履歴、インベントリ機能へのオンボードを簡素化します。

詳細については、「既存の Linux サーバーを Azure Arc に接続する」を参照してください。

ARM テンプレート

ARM テンプレートを使用した IaC により、Azure リソースをデプロイおよび管理するための一貫した宣言的な手法を利用できるようになります。 ARM テンプレートを使用して、アプリケーションに必要なインフラストラクチャを JSON 形式で定義します。 ARM テンプレートはべき等です。つまり、同じテンプレートを何度でもデプロイし、同じリソースの種類を同じ状態で作成できます。

詳細については、ARM テンプレートのドキュメントを参照してください。

JSON 例

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}

Bicep ドメイン固有言語を使用して、JSON 構文の複雑さを軽減し、Azure を初めて使用するユーザーの学習曲線を最小限に抑えることができます。 Bicep は JSON 形式の ARM テンプレートを簡略化したものですが、ARM テンプレートの機能をすべて維持しながら、よりわかりやすい記述が可能です。デプロイ時に、Bicep コマンドラインインターフェイスは Bicep ファイルを JSON 形式の ARM テンプレートに変換します。

このセクションの例は、Bicep ファイルとそれに相当する JSON テンプレートの違いを示しています。どちらの例でも、ストレージアカウントをデプロイします。

Bicep の例

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
}

Azure DevOps

Azure DevOps は、クラウドとオンプレミスの両環境にプロジェクト管理、継続的インテグレーションと継続的デリバリー (CI/CD) サービス、ソースコードリポジトリを提供する、開発ツールの包括的なセットです。これらの機能を Azure Test Plans、Azure Artifacts、Logic Apps、Azure Functions と組み合わせることで、最新のソフトウェアプロジェクトのシームレスなコラボレーション、開発、デリバリーを促進できます。

Azure Boards

Azure Boards は、クラウドソフトウェア開発とプロジェクト管理のためのアジャイル手法をサポートしています。詳細については、Azure Boards のドキュメントおよび「Azure Boards の構成とカスタマイズ」を参照してください。

Azure Boards を最大限に活用するには、チームがツールと機能 (Scrum、Kanban、Scrumban など) をどのように使用しているか、さらに構成とカスタマイズへのそれらの依存関係を理解することが重要です。

次の表は、プロジェクトを構造化する際に考慮すべき主要な項目をまとめたものです。

プロジェクトレベル	チームレベル
定義するチームの数	製品バックログを使用して作業を計画および優先順位付けする方法
ポートフォリオ管理ビューをサポートする区分パスの構成方法	バグを要件として追跡するか、タスクとして追跡するか、バグをまったく使用しないか
フィールドのカスタマイズ	タスクを使って時間とキャパシティを追跡するかどうか
カスタム作業項目の種類	ポートフォリオバックログレベルを使用する方法
ポートフォリオバックログのカスタマイズ	ポートフォリオバックログレベルを使用する方法
ワークフローのカスタマイズ	進捗、ステータス、リスクを上級管理職に通知する方法

Azure Pipelines

Azure Pipelines は、一貫性のある高品質なコードを即座に利用可能にするプロジェクトビルドを自動化する迅速で簡単かつ安全な方法を提供します。

Azure Pipelines:

あらゆる言語またはプラットフォームで動作します。
さまざまな種類のターゲットに同時にデプロイできます。
Azure のデプロイと統合できます。
Windows、Linux、または Mac マシンで構築します。
GitHub と統合されます。
オープンソースプロジェクトを使用できます。

詳細については、「Azure Pipelines のドキュメント」を参照してください。

組織のニーズに応じて、Azure Pipelines の 4 つのコアアーキテクチャのいずれかを選択できます。

Azure Repos

Azure Repos は、Git バージョン管理と一元化されたバージョン管理の 2 種類のバージョン管理を提供します。

コードにアクセスするには、開発環境を Azure Repos に接続します。以下を通じてコードを共有します。

詳細については、Azure Repos Git のドキュメントおよび Team Foundation バージョン管理のドキュメントを参照してください。

リリースパイプラインと Azure Artifacts ソースを使用する

開発者は、Azure Artifacts を使用して、フィードやパブリックレジストリ (PyPI、Maven Central、NuGet.org など) からさまざまな種類のパッケージを公開および使用できます。Azure Artifacts を Azure Pipelines と共に使用して、ビルドおよびパイプラインアーティファクトを公開したり、パッケージをデプロイしたり、パイプラインのさまざまなステージにわたってファイルを統合してアプリケーションをビルド、テスト、デプロイしたりできます。

詳細については、以下を参照してください:

Azure Policy を Azure DevOps と統合する

Azure Policy は、Azure 環境内のリソースに直接適用されますが、その原則とガバナンスは Azure DevOps のプラクティスに間接的に影響を与える可能性があります。たとえば、Azure Policy は以下に影響を与える可能性があります。

CI/CD パイプラインのコンプライアンス: パイプラインにコンプライアンスチェックを統合できます。たとえば、Azure DevOps を通じてデプロイするインフラストラクチャが、Azure Policy で定義したポリシーに準拠していることを確認します。
環境の一貫性: Azure Policy を使用して特定の構成やリソースタイプを適用し、Azure DevOps を通じてデプロイする環境の一貫性を確保しながら、コンプライアンスを遵守します。
セキュリティとガバナンス: ポリシーは、Azure DevOps Projects が管理するリソースにセキュリティ基準とガバナンスプラクティスを適用できます。この規制により、開発ライフサイクルに組織および規制基準への準拠が含まれるようになります。

Azure Policy を Azure DevOps と効果的に統合するために、Azure Policy のコンプライアンスデータと監査機能を使用して、DevOps のプラクティスに情報を追加できます。 Azure Policy を通じて適用する組織のポリシーに合わせて、パイプラインや IaC 定義を調整します。

この統合により、Azure DevOps を通じてデプロイおよび管理するリソースが常に会社のガバナンス標準に準拠しているようになります。このアプローチを使用して、Azure 環境全体でセキュリティ、一貫性、コスト管理を向上させます。

次の方法で共有

Azure 上の Red Hat Enterprise Linux におけるプラットフォーム自動化に関する考慮事項

概要

設計上の考慮事項

Red Hat Ansible Automation Platform に関する設計上の考慮事項

オンプレミスまたはクラウドでのセルフマネージド Red Hat AAP

マネージドまたはセルフマネージド Red Hat AAP on Azure

マネージドモードに関するその他の考慮事項

セルフマネージドモードに関するその他の考慮事項

設計の推奨事項

コアプラットフォームインフラストラクチャのデプロイ

RHEL システムのライフサイクル管理

Azure ネイティブツールに関するその他の設計上の考慮事項

Azure Automation

ARM テンプレート

JSON 例

Bicep の例

Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

リリースパイプラインと Azure Artifacts ソースを使用する

Azure Policy を Azure DevOps と統合する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure 上の Red Hat Enterprise Linux におけるプラットフォーム自動化に関する考慮事項

概要

設計上の考慮事項

Red Hat Ansible Automation Platform に関する設計上の考慮事項

オンプレミスまたはクラウドでのセルフマネージド Red Hat AAP

マネージドまたはセルフマネージド Red Hat AAP on Azure

マネージド モードに関するその他の考慮事項

セルフマネージド モードに関するその他の考慮事項

設計の推奨事項

コア プラットフォーム インフラストラクチャのデプロイ

RHEL システムのライフサイクル管理

Azure ネイティブ ツールに関するその他の設計上の考慮事項

Azure Automation

ARM テンプレート

JSON 例

Bicep の例

Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

リリースパイプラインと Azure Artifacts ソースを使用する

Azure Policy を Azure DevOps と統合する

次のステップ

フィードバック

その他のリソース

マネージドモードに関するその他の考慮事項

セルフマネージドモードに関するその他の考慮事項

コアプラットフォームインフラストラクチャのデプロイ

Azure ネイティブツールに関するその他の設計上の考慮事項