Kubernetes アプリケーションのための Azure コンテナ―技術資産を準備する
この記事では、Azure Marketplace で Kubernetes アプリケーションのためのコンテナー オファーを作成するのに役立つ技術リソースとレコメンデーションを示します。
Kubernetes アプリケーションベースのコンテナー オファーに必要な技術資産の包括的な例については、「Kubernetes 用の Azure Marketplace コンテナー オファーのサンプル」を参照してください。
技術的な知識の基礎
こうした資産の設計と構築､テストには時間がかかり､Azure プラットフォームとその構築に使用する技術に関する知識が必要です。
エンジニアリング チームには､ソリューションのドメインだけでなく､Microsoft の次の技術に関する知識も必要です。
- Azure Services に関する基本知識
- Azure アプリケーションそのものとそのアーキテクチャを設計する方法
- Azure Resource Manager に関する実用的な知識
- JSON に関する実用的な知識
- Helm に関する実用的な知識
- createUiDefinition に関する実用的な知識
- Azure Resource Manager (ARM) テンプレートに関する実用的な知識
前提条件
アプリケーションは Helm グラフベースである必要があります。
Helm チャートにはアーカイブ ファイル
.tgz含めないようにする必要があります。すべてのファイルをアンパックする必要があります。複数のグラフがある場合は、メインの Helm チャート以外のサブグラフとして他の Helm グラフを含めることができます。
すべての画像参照とダイジェストの詳細がグラフに含まれている必要があります。 実行時に他のグラフや画像をダウンロードすることはできません。
アクティブな発行テナント、または発行テナントとパートナー センター アカウントへのアクセス権が必要です。
上記のアクティブな発行テナントに属する Azure Container Registry (ACR) を作成しておく必要があります。 クラウド ネイティブ アプリケーション バンドル (CNAB) をアップロードします。 詳細については、「 Azure Container Registry の作成」を参照してください。
最新バージョンの Azure CLI をインストールします。
アプリケーションは、Linux 環境にデプロイできる必要があります。
イメージには脆弱性が含まれている必要があります。 脆弱性スキャンの要件を指定するガイダンスについては、「 コンテナー認定のトラブルシューティングを参照してください。 脆弱性のスキャンの詳細については、「Microsoft Defender 脆弱性の管理を使用した Azure の信頼性評価」を参照してください。
パッケージ 化ツールを手動で実行する場合は、Docker にローカル コンピューターをインストールする必要があります。 詳細については、 Windows または Linux の Docker ドキュメントの WSL 2 バックエンド セクションを参照してください。 これは Linux/Windows AMD64 マシンでのみサポートされます。
制限事項
- コンテナー Marketplace では、Linux プラットフォーム ベースの AMD64 イメージのみがサポートされます。
- Container Marketplace オファーでは、 管理された AKS および Arc 対応 Kubernetes へのデプロイがサポートされています。 1 つのオファーでターゲットにできるのは、マネージド AKS または Arc 対応 Kubernetes の 1 つのクラスターの種類のみです。
- Arc 対応 Kubernetes クラスターのオファーでは、定義済みの課金モデルのみがサポートされます。 課金モデルの詳細については、「 Azure Container プランを計画する」を参照してください。
- 単一コンテナーはサポートされていません。
- リンクされた Azure Resource Manager テンプレートはサポートされていません。
公開の概要
Azure Marketplace で Kubernetes アプリケーションベースのコンテナー オファーを発行する最初の手順は、アプリケーションをクラウド ネイティブ アプリケーション バンドル (CNAB) としてパッケージすることです。 アプリケーションの成果物で構成される CNAB は、最初にプライベート Azure Container Registry (ACR) に発行され、後で Microsoft 所有のパブリック ACR にプッシュされ、パートナー センターで参照する 1 つの成果物として使用されます。
そこから、イメージが安全であることを確認するために脆弱性スキャンが行なわれます。 最後に、Kubernetes アプリケーションは、Azure Kubernetes Service (AKS) クラスターの拡張機能の種類として登録されます。
オファーが発行されると、アプリケーションは AKS 機能の クラスター拡張機能を利用して、AKS クラスター内でアプリケーションのライフサイクルを管理します。
Azure Container Registry へのアクセスを許可する
公開プロセスの一環として、Microsoft は CNAB を ACR から Microsoft 所有の Azure Marketplace 固有の ACR に深くコピーします。 イメージは、すべてのユーザーがアクセスできるパブリック レジストリにアップロードされます。 この手順では、Microsoft にレジストリへのアクセス権を付与する必要があります。 ACR は、パートナー センター アカウントにリンクされているのと同じ Microsoft Entra テナント内にある必要があります。
Microsoft には、32597670-3e15-4def-8851-614ff48c1efaのidでこのプロセスを処理するファースト パーティ 製アプリケーションがあります。 開始するには、アプリケーションに基づいてサービス プリンシパルを作成します。
Note
ご利用のアカウントにサービス プリンシパルを作成するためのアクセス許可がない場合は、az ad sp create から "この操作を完了するのに十分な特権がありません" というエラー メッセージが返されます。 サービス プリンシパルを作成するには、Microsoft Entra 管理者に問い合わせてください。
az login
アプリケーションのサービス プリンシパルが既に存在するかどうかを確認します。
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
前のコマンドで結果が返されない場合は、新しいサービス プリンシパルを作成します。
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
次の手順で使用するサービス プリンシパルの ID をメモしておきます。
次に、レジストリの完全な ID を取得します。
az acr show --name <registry-name> --query "id" --output tsv
出力は次のようになります。
...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
次に、先ほど取得した値を使用してレジストリからプルする機能をサービス プリンシパルに付与するロールの割り当てを作成します。
Azure ロールを割り当てるには、以下が必要です。
Microsoft.Authorization/roleAssignments/writeアクセス許可 (ユーザー アクセス管理者や所有者など)
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
最後に、Azure Container Registry の作成に使用したのと同じサブスクリプションに Microsoft.PartnerCenterIngestion リソース プロバイダーを登録します。
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
登録を監視し、完了したことを確認してから続行します。
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
パッケージ形式の要件を満たすために成果物を収集する
各 CNAB は、次の成果物で構成されます。
- Helm チャート
- CreateUiDefinition
- ARM テンプレート
- マニフェスト ファイル:
Helm グラフをアップデートする
Helm グラフが次の規則に準拠していることを確認します。
すべての画像名と参照はパラメーター化され、
values.yamlで global.azure.images 参照として表されます。 Helm チャート テンプレート ファイルdeployment.yamlを更新して、これらの画像をポイントします。 これにより、イメージ ブロックを更新して Azure Marketplace の ACR イメージを参照できるようになります。
複数のグラフがある場合は、メインの Helm チャート以外のサブグラフとして他の Helm グラフを含めることができます。 依存するすべての Helm チャートのイメージ参照は更新が必要であり、メイン チャートの
values.yamlに含まれるイメージを指す必要があります。画像を参照する場合は、タグまたはダイジェストを利用できます。 ただし、イメージは、Microsoft 所有の Azure Container Registry (ACR) を指すために内部的にタグが変更されることに注意することが重要です。 タグを更新するときは、新しいバージョンの CNAB を Azure Marketplace に送信する必要があります。 これは、変更を顧客のデプロイに反映できるようにするためです。
使用可能な課金モデル
使用可能なすべての課金モデルについては、Azure Kubernetes Applications の ライセンス オプションを参照してください。
課金モデルに基づいて更新を行う
利用可能な課金モデルを確認した後ユース ケースに適した課金モデルを 1 つ選択し、次の手順を完了します。
次の手順を実行して、 Per core、 Per pod、 Per ノード 課金モデルに識別子を追加します。
workload yaml ファイル内のポッド スペックに
azure-extensions-usage-release-identifier課金識別子ラベルを追加します。ワークロードがデプロイ、レプリカセット、ステートフルセット、デーモンセットの仕様として指定されている場合は、このラベルを .spec.template.metadata.labels の下に追加します。
ワークロードがポッド スペックとして直接指定されている場合は、 .metadata.labels の下にこのラベルを追加します。
perCore課金モデルの場合は、コンテナー リソース マニフェストに
resources:requestsフィールド含めることでCPU 要求を指定します。 この手順は、 perCore 課金モデルにのみ必要です。
デプロイ時に、クラスター拡張機能機能によって課金識別子の値が拡張機能インスタンス名に置き換えられます。
Azure Voting App をデプロイするように構成された例については、以下を参照してください。
カスタム メーター課金モデルの場合は、Helm テンプレートの values.yaml ファイルに以下に示すフィールドを追加します。
- clientId は global.azure.identity の下に追加する必要があります
- planId キーは global.azure.marketplace に追加する必要があります。 planId
- resourceId は global.azure.extension.resrouceId の下に追加する必要があります
デプロイ時に、クラスター拡張機能機能によってこれらのフィールドが適切な値に置き換えられます。 例については、 Azure Vote Custom Meters ベースのアプリを参照してください。
Helm グラフを検証する
Helm グラフが有効であることを確認するには、ローカル クラスターにインストールできることをテストします。 特定のテンプレート生成エラーを検出するために helm install --generate-name --dry-run --debug を使用することもできます。
createUiDefinition を作成してテストする
createUiDefinition は、アプリケーションのデプロイ時に Azure portal のユーザー インターフェイス要素を定義する JSON ファイルです。 詳細については、以下を参照してください:
または、新規または既存のクラスター選択の入力データを要求しアプリケーションにパラメーターを渡す UI 定義の例を参照してください。
アプリケーション用の createUiDefinition.json ファイルを作成したら、ユーザー エクスペリエンスをテストする必要があります。 テストを簡略化するには、ファイルの内容を sandbox 環境にコピーします。 サンドボックスでは、最新の全画面表示ポータル エクスペリエンスでユーザー インターフェイスが表示されます。 サンドボックスは、ユーザー インターフェイスをプレビューするのにお勧めの方法です。
Azure Resource Manager (ARM) テンプレートを作成する
ARM テンプレートは、デプロイする Azure リソースを定義します。 既定では、Azure Marketplace アプリケーションのクラスター拡張機能リソースをデプロイします。 必要に応じて、AKS クラスターのデプロイを選択できます。
現在、以下のリソースの種類のみを許可しています。
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
たとえば、前にリンクされたサンプル UI 定義から結果を取得しアプリケーションにパラメーターを渡すために設計された、この サンプル ARM テンプレートを参照してください。
ユーザー パラメーター フロー
作成およびパッケージ化する成果物全体でユーザー パラメーターがどのように流れるかを理解することが重要です。 Azure Voting App の例では、createUiDefinition.json ファイルを使用して UI を作成するときに、パラメーターが最初に定義されます。
パラメーターは、 outputs セクションを使用してエクスポートされます。
そこから、値は Azure Resource Manager テンプレートに渡され、デプロイ時に Helm チャートに反映されます。
![この記事でリンクされている Azure Resource Manager テンプレートの例のスクリーンショット。[configurationSettings] の下に、アプリケーション タイトル、'value1'、および 'value2' のパラメーターが示されています。](../media/marketplace-offers/azure-container/user-param-arm.png)
最後に、次に示すように、値は values.yaml を介して Helm チャートに渡されます。
Note
この例では、extensionResourceName もパラメーター化され、クラスター拡張機能リソースに渡されます。 同様に、マイナー バージョンの場合の自動アップグレードを有効にするなど、他の拡張機能のプロパティをパラメーター化することもできます。 クラスター拡張機能のプロパティの詳細については、省略可能なパラメーターに関する記事を参照してください。
マニフェスト ファイルの作成
パッケージ マニフェストは、パッケージとそのコンテンツを記述し、依存する成果物をどこに配置するかをパッケージ ツールに指示する yaml ファイルです。
マニフェストで使用されるフィールドは次のとおりです。
| Name | データの種類 | 説明 |
|---|---|---|
| applicationName | String | アプリケーションの名前 |
| publisher | String | パブリッシャーの名前 |
| description | String | パッケージの簡単な説明 |
| version | #.#.# 形式の文字列 |
アプリケーション パッケージのバージョンを記述するバージョン文字列。内部のバイナリのバージョンと一致する場合と一致しない場合があります。 |
| helmChart | String | この manifest.yaml から相対的に Helm グラフを見つけることができるローカル ディレクトリ |
| clusterARMTemplate | String | 制限フィールドの要件を満たす AKS クラスターを記述する ARM テンプレートがあるローカル パス |
| uiDefinition | String | Azure portal の作成エクスペリエンスを記述する JSON ファイルがあるローカル パス |
| registryServer | String | 最終的な CNAB バンドルをプッシュする必要がある ACR |
| extensionRegistrationParameters | コレクション | 拡張機能の登録パラメーターの仕様。 少なくとも defaultScope をパラメーターとして含めます。 |
| defaultScope | String | 拡張機能のインストールの既定のスコープ。 指定できる値は cluster または namespace です。 cluster スコープが設定されている場合、クラスターごとに許可される拡張機能インスタンスは 1 つだけです。 namespace スコープが選択されている場合、名前空間ごとに許可されるインスタンスは 1 つだけです。 Kubernetes クラスターには複数の名前空間を含めることができるので、複数の拡張機能のインスタンスが存在できます。 |
| namespace | String | (省略可能)拡張機能がインストールする名前空間を指定します。 このプロパティは、defaultScope が cluster に設定されている場合は必須です。 名前空間の名前付けの制限については、「名前空間と DNS」を参照してください。 |
| supportedClusterTypes | コレクション | (省略可能)アプリケーションでサポートされるクラスターの種類を指定します。 使用できる型は、"managedClusters"、"connectedClusters" です。 "managedClusters" は、Azure Kubernetes Service (AKS) クラスターを指します。 "connectedClusters" は、Azure Arc 対応 Kubernetes クラスターを指します。 supportedClusterTypes が指定されていない場合、'managedClusters' のすべてのディストリビューションが既定でサポートされます。 supportedClusterTypes が指定されていて、特定の最上位レベルのクラスターの種類が指定されていない場合、そのクラスターの種類のすべてのディストリビューションと Kubernetes バージョンはサポートされていないものとして扱われます。 クラスターの種類ごとに、次のプロパティを持つ 1 つ以上のディストリビューションの一覧を指定します。 -流通 - distributionSupported - unsupportedVersions |
| distribution | リスト | クラスターの種類に対応するディストリビューションの配列。 特定のディストリビューションの名前を指定します。 すべてのディストリビューションがサポートされていることを示すには、値を ["All"] に設定します。 |
| distributionSupported | Boolean | 指定したディストリビューションがサポートされているかどうかを表すブール値。 false の場合、UnsupportedVersions を指定するとエラーが発生します。 |
| unsupportedVersions | リスト | サポートされていない指定されたディストリビューションのバージョンの一覧。 サポートされている演算子: - "=" 特定のバージョンはサポートされていません。 たとえば、"=1.2.12" とします。 - ">" 指定されたバージョンより大きいすべてのバージョンはサポートされていません。 たとえば、">1.1.13" - "<" 指定されたバージョンより小さいすべてのバージョンはサポートされていません。 たとえば、"<1.3.14" - "..."範囲内のすべてのバージョンはサポートされていません。 たとえば、"1.1.2....1.1.15" (右側の値が含まれており、左側の値は除外されます) |
投票アプリケーション用に構成されたサンプルについては、次の「マニフェスト ファイルの例」を参照してください。
アプリケーションの構造
アプリケーションの Helm グラフの横に createUiDefinition、ARM テンプレート、マニフェスト ファイルを配置します。
適切に構造化されたディレクトリの例については、 Azure Vote のサンプルを参照してください。
Azure Arc 対応 Kubernetes クラスターをサポートする投票アプリケーションのサンプルについては、 ConnectedCluster のみのサンプル を参照してください。
Azure Kubernetes Service (AKS) クラスターと Azure Arc 対応 Kubernetes クラスターをサポートする投票アプリケーションのサンプルについては、「 Connected と Managed Cluster のサンプルを参照してください。
アプリケーションを検証するために Azure Arc 対応 Kubernetes クラスターを設定する方法の詳細については、「 Quickstart: 既存の Kubernetes クラスターを Azure Arc に接続する」を参照してください。
コンテナー パッケージ ツールを使用する
必要なすべての成果物を追加したら、パッケージ ツール container-package-app を実行して成果物を検証し、パッケージをビルドして、パッケージを Azure Container Registry にアップロードします。
PDB は新しい形式であり、学習曲線があるため、パッケージ化ツールを正常に実行するために必要なブートストラップ環境とツールを使用して、 container-package-app 用の Docker イメージを作成しました。
パッケージ ツールを使用するには、2 つのオプションがあります。 手動で使用することも、デプロイ パイプラインに統合することもできます。
パッケージ ツールを手動で実行する
パッケージ ツールの最新の画像は、mcr.microsoft.com/container-package-app:latest からプルできます.
次の Docker コマンドは、最新のパッケージ ツールの画像をプルし、ディレクトリもマウントします。
~\<path-to-content>がパッケージ化する内容を含むディレクトリであると仮定すると、次の docker コマンドはコンテナー内の/dataに~/<path-to-content>マウントします。 必ず ~/<path-to-content> を独自のアプリケーションの場所に置き換えてください。
docker pull mcr.microsoft.com/container-package-app:latest
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest
container-package-app コンテナー シェルで、次のコマンドを実行します。 必ず <registry-name> を ACR の名前に置き換えてください。
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
ACR を認証するには、2 つのオプションがあります。 1 つのオプションは、前に示したように az login を使用することです。2 つ目のオプションは、 docker login 'yourACRname'.azurecr.ioを実行して docker を使用することです。 ユーザー名とパスワードを入力して (ユーザー名は ACR 名にする必要があり、パスワードは Azure portal で生成されたキーです)、実行します。
docker login <yourACRname.azurecr.io>
次に、 cpa verify を実行して成果物を反復処理し、それらを 1 つずつ検証し、エラーに対処します。 CNAB をパッケージ化して Azure Container Registry にアップロードする準備ができたら、 cpa buildbundle を実行します。 cpa buildbundle コマンドは、検証プロセスを実行し、パッケージをビルドして、パッケージを Azure Container Registry にアップロードします。
cpa verify
cpa buildbundle
Note
既存のタグを上書きする場合にのみ cpa buildbundle --force を使用します。 この CNAB を Azure Marketplace オファーに既にアタッチしている場合は、代わりにマニフェスト ファイルのバージョンをインクリメントします。
Azure パイプラインに統合する
container-package-appを Azure Pipeline に統合する方法の例については、Azure Pipeline の例を参照してください。