Azure Red Hat OpenShift (ARO)

Microsoft Azure Red Hat OpenShift サービスを使用すると、フルマネージドの OpenShift クラスターをデプロイできます。 Azure Red Hat OpenShift は Kubernetes を拡張します。 Kubernetes を使用して運用環境でコンテナーを実行するには、他のツールとリソースが必要です。これには、多くの場合、イメージレジストリ、ストレージ管理、ネットワークソリューション、および一緒にバージョン管理とテストを行う必要があるログ記録および監視ツールを調整する必要があります。コンテナーベースのアプリケーションを構築するには、さらにミドルウェア、フレームワーク、データベース、CI/CD ツールとの統合作業も必要です。 Azure Red Hat OpenShift は、これらすべての項目を 1 つのプラットフォームに結合し、IT チームに運用を容易にしながら、アプリケーションチームに実行する必要のあるものを提供します。

az aro validte

az aro validate は az CLI 2.52.0 で追加された Command で、ARO Cluster 作成の前提条件を検証します。

September 05, 2023 Version 2.52.0

ARO

az aro create: Add new --outbound-type parameter, allowing users to select "Loadbalancer" (default) or "UserDefinedRouting"
az aro create: Perform pre-flight validation of prerequisite permissions before creation
az aro validate: New command to perform explicit validation of prerequisite permissions

az aro validate --master-subnet
                --name
                --resource-group
                --worker-subnet
                [--assign-cluster-identity --mi-user-assigned]
                [--assign-platform-wi --assign-platform-workload-identity]
                [--client-id]
                [--client-secret]
                [--cluster-resource-group]
                [--disk-encryption-set]
                [--enable-managed-identity --enable-mi {false, true}]
                [--location]
                [--pod-cidr]
                [--service-cidr]
                [--version]
                [--vnet]
                [--vnet-resource-group]

Google Code Wiki

Google Code Wiki は Google が 2025年11月に公開した AI 駆動のコードドキュメント自動生成プラットフォームで、当記事執筆時点で Public Preview です。
Gemini（Google の最新 AI）とコード解析技術を組み合わせ、リポジトリ全体をスキャンして“常に最新の Wiki 形式ドキュメント”を自動生成・更新します。

az aro validate with Google Code Wiki

az aro validate を実際に使用してみると、az aro create の全ての前提条件を検証している訳ではない事が分かります。これは、az aro validate が正常終了しても az aro create が失敗する可能性がある事を意味しており、az aro validate に指定可能な Option からも推測できる事ですが、具体的にどこまでの範囲を検証しているのか、Google Code Wiki で確認してみました。

Google Code Wiki は一般的な AI 同様に、回答が常に正確であるとは限りません。Chat 画面下部にも、以下が表示されます。

Gemini can make mistakes, so double-check it.

Access Google Code Wiki

Google Code Wiki 画面上で az cli の検索結果から、azure-cli Repository を選択します。

下記右側にある GitHub アイコンをクリックすると、Code Wiki が学習した GitHub Repository が表示されます。

Chat Q&A

azure/azure-cli 画面から、az aro validate について確認してみます。
まずは、基本的な情報を確認してみました。

Q

あなたは Gemini ですか？

A

こんにちは！私は、Azure CLI コードリポジトリに関する情報を提供するお手伝いをしています。

あなたの質問は、リポジトリとは直接関係がないようです。Azure CLI について何か知りたいことがあれば、遠慮なく質問してくださいね。

Q

この Code Wiki の学習データを教えてください。

A

Code Wiki は、azure/azure-cli リポジトリの概要を提供しており、Azure コマンドラインインターフェース（CLI）の管理に関する情報を含んでいます。この情報源は、CLI のアーキテクチャ、拡張機能の管理、開発プロセス、およびリリースワークフローを理解するための学習データとして利用できます。

具体的には、以下の内容を学習データとして利用できます。

概要: 
Azure CLI の目的と機能、Azure リソースを管理するためのコマンドラインエクスペリエンスを提供すること (azure/azure-cli Overview)。

アーキテクチャ:
コマンドのロードと実行フロー、引数解析、実行、検証 (Command Loading and Execution Flow)。
Atomic Azure CLI (AAZ) フレームワーク、REST API 仕様からコマンドを生成する方法 (Atomic Azure CLI (AAZ) Framework)。
認証メカニズム、ログインフローの種類、トークンと資格情報の永続化 (Authentication and Credential Management)。
クラウド設定とユーザープロファイルの管理、異なる Azure 環境での対話 (Cloud Configuration and Profile Management)。

拡張機能の開発と管理:
Azure CLI 拡張機能の作成、テスト、公開方法 (Azure CLI Extension Authoring and Publishing)。
拡張機能のメタデータとバージョン管理、互換性の確保とリリースステータスの管理 (Azure CLI Extension Metadata and Versioning)。
互換性を維持するための変更分類ルール (Azure CLI Breaking Change Rules)。

開発とリリースプロセス:
コンテナ化された開発環境 (Containerized Development Environment)。
SDK の最適化、コマンドのイントロスペクション、自動テストを含む開発ツール (CLI Automation and Tooling)。
ビルドパイプライン、リリースノートの生成、各種プラットフォーム向けパッケージの構築 (Build and Release Processes)。
継続的インテグレーション (CI) プロセス、ビルド、テスト、ドキュメント生成の自動化 (Continuous Integration (CI) Processes)。
テストフレームワーク、シナリオベースのテスト、HTTP 記録と再生、リソースライフサイクル管理、機密データのサニタイズ (Testing Framework)。
Visual Studio Code でのデバッグ方法 (Debugging the Azure CLI)。

テレメトリーシステム: 
使用状況データとエラーを Application Insights に送信するシステム、非同期処理によるユーザーエクスペリエンスへの影響の最小化 (Telemetry System)。

Q

学習データの URL を教えてください。

A

Azure CLI リポジトリの学習データとして提供できるドキュメントは以下の URL でアクセスできます。

azure/azure-cli リポジトリの概要: azure/azure-cli Overview
貢献ガイドラインとプロジェクトガバナンス: Contribution Guidelines and Project Governance
Git Hook の管理と適用: Git Hook Management and Enforcement
コミュニティアイデア提出プロセス: Community Idea Submission Process
開発環境のセットアップ: Development Environment Setup
コンテナ化された開発環境: Containerized Development Environment
CLI のコアアーキテクチャ: Core CLI Architecture
コマンドのロードと実行フロー: Command Loading and Execution Flow
Atomic Azure CLI (AAZ) フレームワーク: Atomic Azure CLI (AAZ) Framework
認証と資格情報管理: Authentication and Credential Management
クラウド設定とプロファイル管理: Cloud Configuration and Profile Management
テレメトリーシステム: Telemetry System
非同期テレメトリーアップロードメカニズム: Asynchronous Telemetry Upload Mechanism
テレメトリーデータ管理と提出コンポーネント: Telemetry Data Management and Submission Components
テレメトリーのロギングと設定: Telemetry Logging and Configuration
テレメトリー分析のための Kusto クエリの例: Kusto Query Examples for Telemetry Analysis

これらの URL は、提供されたコンテキスト内の各セクションへのアンカーリンクです。

Q

以下の GitHub Repository を使用していますね。回答に Branch/Tag を指定する事はできますか？
https://github.com/azure/azure-cli

A

はい、回答の中でGitHubリポジトリの特定のブランチやタグを指定することは可能です。

提供されたスクリプトである scripts/ci/update_docs.sh や scripts/ci/version.sh では、git clone や git checkout コマンドを使用して特定のブランチ（例: main, release, cli-release-notes-${CLI_VERSION} など）を操作していることが確認できます。

したがって、これらのスクリプトや同様のGit操作が可能な環境を想定している場合、ブランチやタグを指定して特定のバージョンのコードベースを参照したり、それに基づいた情報を提供したりすることができます。

Q

以下の az CLI を使用しますので、これに該当する Branch/Tag での回答をお願いします。

$ az version
{
  "azure-cli": "2.84.0",
  "azure-cli-core": "2.84.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "aro": "1.0.12",
    "resource-graph": "2.1.1"
  }
}

A

azure-cli: 2.84.0

azure/azure-cli リポジトリでは、azure-cli のバージョンは __version__ 変数で定義されています (例: src/azure-cli-core/azure/cli/core/__init__.py)。提供された az version の出力が 2.84.0 であるため、azure-cli リポジトリの main ブランチに直接対応する特定のタグは 2.84.0 です。

extensions: 拡張機能は通常、コア CLI とは独立してバージョン管理されます (例: Azure CLI Extension Metadata and Versioning)。提供されたバージョン aro: 1.0.12、resource-graph: 2.1.1 は、各拡張機能の独自のタグに対応します。これらの拡張機能のバージョンは、コア CLI のリポジトリには直接含まれていませんが、拡張機能がそれぞれ独自の GitHub リポジトリでリリースされるときにタグ付けされます。

次に、az aro validate の質問をしてみます。

Q

az aro validate の機能と検証可能な範囲を教えてください。

A

az aro validate コマンドは、Azure Red Hat OpenShift クラスターの作成に必要な権限を検証する機能を提供します。

このコマンドは、主に以下の範囲を検証します。

    仮想ネットワークの権限: 
    仮想ネットワークに対する適切な権限（Microsoft.Network/virtualNetworks/join/action、read、write、Microsoft.Network/virtualNetworks/subnets/join/action、read、write）があることを確認します。これは、src/azure-cli/azure/cli/command_modules/aro/_dynamic_validators.py の dyn_validate_vnet 関数で実行されます。
    
    サブネットとルートテーブルの権限: 
    サブネットに関連付けられたルートテーブルに適切な権限（Microsoft.Network/routeTables/join/action、read、write）があることを検証します。また、--enable-preconfigured-nsg フラグが有効でない限り、サブネットにネットワークセキュリティグループが割り当てられていないことも確認します。これは、src/azure-cli/azure/cli/command_modules/aro/_dynamic_validators.py の dyn_validate_subnet_and_route_tables 関数で実行されます。
    
    CIDR 範囲の重複: 
    マスターサブネット、ワーカーサブネット、Pod CIDR、サービス CIDR の各範囲が重複していないことを検証します。また、Pod CIDR がマスターノードに必要な十分なアドレスを確保しているかどうかも確認します。これは、src/azure-cli/azure/cli/command_modules/aro/_dynamic_validators.py の dyn_validate_cidr_ranges 関数で実行されます。
    
    リソース権限: 
    クラスターの作成に必要なリソース（ネットワークリソースやディスク暗号化リソースなど）に対するサービスプリンシパルまたはマネージドIDの権限（Network Contributor や Reader ロールなど）を検証します。このプロセスは、dyn_validate_resource_permissions 関数で行われます。
    
    OpenShift バージョン: 
    指定された OpenShift バージョンが有効であることを確認します。これは、src/azure-cli/azure/cli/command_modules/aro/_dynamic_validators.py の dyn_validate_version 関数で実行されます。

Q

az aro create で ARO クラスターを作成する前提条件を検証するのですね？

A

はい、その通りです。az aro validate コマンドは、az aro create で Azure Red Hat OpenShift クラスターを作成する際の前提条件を検証するために設計されています。

Q

az aro create には、az aro validate で検証する範囲外の前提条件も多く指定可能です。それらは、検証対象外なのでしょうか？

A

はい、その可能性は十分にあります。az aro validate コマンドが検証する範囲は、OpenShift クラスターの作成における特定の重要な前提条件に焦点を当てています。これは主に、リソースの権限、ネットワーク構成、および特定の OpenShift バージョンの可用性など、クラスターのデプロイが成功するために最低限必要となる環境設定です。

しかし、az aro create コマンドは、非常に多くのオプションパラメータを持ち、クラスターのサイズ、VMの種類、アドオン、認証設定など、広範な設定が可能です。これらの設定の多くは、個々のパラメータの有効性や組み合わせの妥当性を CLI の引数バリデータや内部ロジックでチェックしますが、必ずしも az aro validate が行うような「環境全体に対する事前検証」の対象ではありません。

例えば、az aro create には以下のようなパラメータがあります。

    --worker-vm-size や --master-vm-size: 仮想マシンのサイズを指定しますが、これが現在のサブスクリプションで利用可能か、または十分なクォータがあるかといった環境依存のチェックは、az aro validate の主要な対象ではありません。
    --disk-encryption-set: ディスク暗号化セットを指定した場合、それが有効なリソースであるかの確認は行われますが、その設定が全体として推奨されるセキュリティプラクティスに沿っているか、あるいはパフォーマンスに影響を与えないかといった深いレベルの検証は、通常 az aro validate の範疇外です。
    --pull-secret: プルシークレットのフォーマットの妥当性は検証されますが、そのシークレットが実際にアクセス権を持つレジストリを指しているかといった外部サービスとの連携検証は、デプロイ時に発生する可能性があります。

Q

つまり、az aro validate で問題が無かったとしても、az aro create が失敗する可能性はあるということですね？

A

はい、その通りです。az aro validate で問題がなかったとしても、az aro create が失敗する可能性は十分にあります。

az aro validate コマンドは、主にクラスター作成の基本的な環境設定や権限など、デプロイが開始される前に確認すべき「最低限の要件」に焦点を当てて検証を行います。

しかし、az aro create コマンドには、より詳細なリソース設定、VMサイズ、クォータ、ネットワーク構成の複雑な相互作用など、az aro validate の範囲外の多くのオプションがあります。例えば、特定のVM SKUがリージョンで利用できない、サブスクリプションのクォータが不足している、あるいは指定されたカスタムスクリプトにエラーがあるといったケースは、az aro validate では検出されず、実際の az aro create の実行時にAzure API側で検証され、失敗する可能性があります。

次に、az aro validate 内部処理フロー図の作成を依頼してみました。

Q

az aro validate を実行してから、該当関数までの内部処理フロー図を作成してください。

最後に az aro create 実行時の Error Message を解析してみました。

Q

az aro validate で以下のようなエラーが表示されました。どの関数で処理されたものでしょうか。

Error Message

ERROR: The following errors are fatal and will block cluster creation:
+---------------+----------------+------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Type          | Name           | Severity   | Description                                                                                                                                                   |
+===============+================+============+===============================================================================================================================================================+
| master_subnet | master-subnet1 | Error      | A Network Security Group "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/aro-private-testfor-validate-                                    |
|               |                |            | rg/providers/Microsoft.Network/networkSecurityGroups/aro-private-testfor-dbwoeq-nsg" is already assigned to this subnet. Ensure there are no Network Security |
|               |                |            | Groups assigned to cluster subnets before cluster creation                                                                                                    |
+---------------+----------------+------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+
| worker_subnet | worker-subnet1 | Error      | A Network Security Group "/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/aro-private-testfor-validate-                                    |
|               |                |            | rg/providers/Microsoft.Network/networkSecurityGroups/aro-private-testfor-dbwoeq-nsg" is already assigned to this subnet. Ensure there are no Network Security |
|               |                |            | Groups assigned to cluster subnets before cluster creation                                                                                                    |
+---------------+----------------+------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------+

A

提示されたエラーメッセージは、マスターサブネット (master_subnet) とワーカーサブネット (worker_subnet) にネットワークセキュリティグループ (NSG) が割り当てられていることを示しています。Azure Red Hat OpenShift クラスターの作成では、サブネットにNSGが割り当てられていないことが前提条件となります（--enable-preconfigured-nsg フラグが有効でない限り）。

この検証処理は、src/azure-cli/azure/cli/command_modules/aro/_dynamic_validators.py 内の dyn_validate_subnet_and_route_tables 関数で処理されています。

この関数は、サブネットに関連付けられたルートテーブルの権限を検証するだけでなく、「--enable-preconfigured-nsg フラグが有効でない限り、サブネットにネットワークセキュリティグループが割り当てられていないこと」も確認します。この条件に違反した場合に、提示されたようなエラーが出力されます。