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 チャート以外のサブグラフとして他の 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 イメージのみがサポートされます。
- マネージド AKS のみ。
- 単一コンテナーはサポートされていません。
- リンクされた 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 には、このプロセスを処理するファースト パーティアプリケーションがありますid32597670-3e15-4def-8851-614ff48c1efa。 開始するには、アプリケーションに基づいてサービス プリンシパルを作成します。
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/ffffffff-ff6d-ff22-77ff-ffffffffffff/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 グラフを含めることができます。 次に、メイン グラフに含まれるイメージを指すように、各依存イメージ参照を更新します
values.yaml。画像を参照する場合は、タグまたはダイジェストを利用できます。 ただし、イメージは、Microsoft 所有の Azure Container Registry (ACR) を指すために内部的にタグが変更されることに注意することが重要です。 タグを更新するときは、新しいバージョンの CNAB を Azure Marketplace に送信する必要があります。 これは、変更を顧客のデプロイに反映できるようにするためです。
使用可能な課金モデル
使用可能なすべての課金モデルについては、Azure Kubernetes アプリケーションのライセンス オプションを参照してください。
課金モデルに基づいて更新を行う
使用可能な課金モデルを確認したら、ユース ケースに適したモデルを 1 つ選択し、次の手順を実行します。
コアごと、ポッドごと、ノードごとの課金モデルに識別子を追加するには、次の手順を実行します。
ワークロード 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 ベースのアプリを参照してください。
テスト パラメーター ファイルを作成する
テスト パラメーター ファイルは、リソースを Azure にデプロイするために ARM テンプレートと組み合わせて使用される JSON です。 マネージド クラスター (AKS) にデプロイできるアプリケーションまたは拡張機能の場合は、デプロイの検証にパラメーター ファイルを指定する必要があります。 テスト パラメーター ファイルには、テストデプロイを成功させる値を含める必要があります。
テスト パラメーター ファイルのサンプルを次に示します。
テスト パラメーター ファイルが作成されたら、それをマニフェスト ファイルに追加します。
Note
テスト パラメーター ファイルがアプリケーションに適用できない場合 (たとえば、アプリケーションで API キーやアプリケーションが接続されたクラスターにデプロイされるようにシークレットをデプロイする必要がある場合)、デプロイ テストをスキップできるように skipdeployment フラグが提供されます。
Helm グラフを検証する
Helm グラフが有効であることを確認するには、ローカル クラスターにインストールできることをテストします。 特定のテンプレート生成エラーを検出するために helm install --generate-name --dry-run --debug を使用することもできます。
createUiDefinition を作成してテストする
createUiDefinition は、アプリケーションのデプロイ時に Azure portal のユーザー インターフェイス要素を定義する JSON ファイルです。 詳細については、以下を参照してください:
アプリケーション用の createUiDefinition.json ファイルを作成したら、ユーザー エクスペリエンスをテストする必要があります。 テストを簡略化するには、ファイルの内容をサンドボックス環境にコピーします。 サンドボックスは、現在の全画面表示ポータル エクスペリエンスでユーザー インターフェイスを表示します。 サンドボックスは、ユーザー インターフェイスをプレビューするのにお勧めの方法です。
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 チャートに反映されます。
最後に、次に示すように、値が Helm チャート values.yaml に渡されます。
Note
この例では、extensionResourceName もパラメーター化され、クラスター拡張機能リソースに渡されます。 同様に、マイナー バージョンの場合の自動アップグレードを有効にするなど、他の拡張機能のプロパティをパラメーター化することもできます。 クラスター拡張機能のプロパティの詳細については、省略可能なパラメーターに関する記事を参照してください。
マニフェスト ファイルの作成
パッケージ マニフェストは、パッケージとそのコンテンツを記述し、依存する成果物をどこに配置するかをパッケージ ツールに指示する yaml ファイルです。
マニフェストで使用されるフィールドは次のとおりです。
| 名前 | データ型 | 説明 |
|---|---|---|
| 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 クラスターをサポートする投票アプリケーションのサンプルについては、「接続済みクラスターとマネージド クラスターのサンプル」を参照してください。
アプリケーションを検証するために Azure Arc 対応 Kubernetes クラスターを設定する方法の詳細については、「クイック スタート: 既存の Kubernetes クラスターを Azure Arc に接続する」を参照してください。
コンテナー パッケージ ツールを使用する
必要なすべての成果物を追加したら、パッケージ ツール container-package-app を実行します。
PDB は新しい形式であり、学習曲線があるため、パッケージ化ツールを正常に実行するために必要なブートストラップ環境とツールを備えた Docker イメージ container-package-app を作成しました。
パッケージ ツールを使用するには、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 を使用して実行 docker login 'yourACRname'.azurecr.ioすることです。 ユーザー名とパスワードを入力して (ユーザー名は ACR 名にする必要があり、パスワードは Azure portal で生成されたキーです)、実行します。
docker login <yourACRname.azurecr.io>
次に、cpa verify を実行して成果物を反復処理し、それらを 1 つずつ検証します。 エラーに対処し、CNAB をパッケージして Azure Container Registry にアップロードする準備ができたら cpa buildbundle を実行します。 このコマンドでは cpa buildbundle 、ビルド前に検証プロセスも実行されます
cpa verify
cpa buildbundle
Note
既存のタグを上書きする場合にのみ cpa buildbundle --force を使用します。 この CNAB を Azure Marketplace オファーに既にアタッチしている場合は、代わりにマニフェスト ファイルのバージョンをインクリメントします。
Azure パイプラインに統合する
Azure Pipeline に統合 container-package-app する方法の例については、Azure Pipeline の例を 参照してください。
トラブルシューティング
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示