Azure Container Registry タスクを使用してコンテナー イメージのビルドと保守管理を自動化する
コンテナーは、アプリケーションと開発者の依存関係をインフラストラクチャおよび操作の要件から分離することで、新たなレベルの仮想化を提供します。 コンテナーのライフサイクルを通してこのアプリケーション仮想化を管理し修正プログラムを適用する方法に対処することはやはり必要です。
Azure Container Registry タスクは、以下を行う機能のスイートです。
- Linux、Windows、ARM などのプラットフォーム用のクラウドベースのコンテナー イメージ ビルドを提供します。
- オンデマンド コンテナー イメージ ビルドを使用して、アプリケーション開発サイクルの初期部分をクラウドに拡張します。
- ソース コードの更新、コンテナーの基本イメージの更新、またはタイマーによってトリガーされる自動化されたビルドを有効にします。
たとえば、基本イメージへの更新のトリガーを使用して、Docker コンテナー用の OS とフレームワークの修正プログラムの適用を自動化できます。 これらのトリガーは、不変コンテナーの原則に従いながら、セキュリティで保護された環境を維持するのに役立ちます。
重要
Azure Container Registry タスクの実行は、Azure の無料クレジットから一時停止されます。 この一時停止は、既存のタスクの実行に影響する可能性があります。 問題が発生した場合は、当社のチームが追加のガイダンスを提供できるようにサポート ケースを開いてください。
警告
コマンド ラインまたは URI の一部として指定した情報は、Azure Container Registry (ACR) 診断トレースの一部としてログに記録される可能性があることに注意してください。 これには、資格情報、GitHub の個人用アクセス トークン、セキュリティで保護されたその他の情報などの機密データが含まれます。 注意し、潜在的なセキュリティ リスクを防いでください。診断ログの対象となるコマンド ラインまたは URI に機密性の高い詳細を含めないようにすることが重要です。
一般的なシナリオ
Azure Container Registry タスクでは、コンテナー イメージやその他の成果物をビルドし、保守管理するためのシナリオをいくつかサポートしています。 この記事では、クイック タスク、自動的にトリガーされるタスク、マルチステップ タスクについて説明します。
各タスクには、ソース コード コンテキストが関連付けられます。これは、コンテナー イメージまたはその他の成果物のビルドに使用されるソース ファイルの場所です。 見本のコンテキストには、Git リポジトリとローカル ファイル システムが含まれます。
タスクでは、Run 変数を活用することもできます。そのため、タスクの定義を再利用したり、イメージや成果物のタグを標準化したりできます。
クイック タスク
"内部ループ" 開発サイクルは、コードの記述、ビルド、およびソース管理にコミットする前のアプリケーションのテストの反復的なプロセスです。 実のところ、これはコンテナー ライフサイクル管理の開始点です。
Azure Container Registry タスクの "クイック タスク" 機能は、コンテナー イメージのビルドを Azure にオフロードすることで、統合された開発環境を提供できます。 ローカル Docker エンジンをインストールすることなく、Azure 内で 1 つのコンテナー イメージをオンデマンドでビルドし、コンテナー レジストリにプッシュできます。 クラウドでの docker build や docker push を思い浮かべてください。 クイック タスクを使用すると、コードをコミットする前に、自動化されたビルド定義を検証し、潜在的な問題を知ることができます。
使い慣れた docker build 形式を使用すると、Azure CLI の az acr build コマンドは、コンテキストを受け取ります。 その後、コマンドはコンテキストを Azure Container Registry に送信し、(既定では) 完了時にビルドされたイメージをそのレジストリにプッシュします。
Azure Container Registry タスクは、コンテナー ライフサイクル プリミティブとして設計されています。 たとえば、Azure Container Registry タスクを継続的インテグレーションと継続的デリバリー (CI/CD) ソリューションに統合できます。 az login をサービス プリンシパルで実行する場合、CI/CD ソリューションは az acr build コマンドを発行してイメージ ビルドを開始できます。
クイック タスクを使用する方法については、Azure Container Registry タスクを使用してコンテナー イメージをビルドおよびデプロイするためのクイックスタートとチュートリアルを参照してください。
ヒント
Dockerfile を使用せずにソース コードから直接、イメージをビルドしてプッシュする場合、az acr pack build コマンド (プレビュー) が Azure Container Registry に用意されています。 このツールでは、Cloud Native Buildpacks を使用して、アプリケーション ソース コードからイメージをビルドし、プッシュします。
自動的にトリガーされたタスク
イメージをビルドする目的で 1 つまたは複数の "トリガー" を有効にします。
ソース コードの更新でタスクをトリガーする
GitHub または Azure DevOps の公開または非公開 Git リポジトリに対して、コードがコミットされたとき、または pull request が作成または更新されたときに、コンテナー イメージのビルドまたはマルチステップ タスクをトリガーできます。 たとえば、Azure CLI コマンドの az acr task create でビルド タスクを構成し、その際、Git リポジトリと任意でブランチと Dockerfile を指定します。 チームがリポジトリ内のコードを更新すると、Azure Container Registry タスクで作成された Webhook が、リポジトリで定義されているコンテナー イメージのビルドをトリガーします。
Azure Container Registry タスクでは、Git リポジトリをタスクのコンテキストとして設定すると、次のトリガーがサポートされます。
| トリガー | 既定で有効 |
|---|---|
| Commit | はい |
| Pull request | いいえ |
Note
現在、GitHub Enterprise リポジトリにおける commit や pull request トリガーは、Azure Container Registry タスクではサポートされません。
ソース コードのコミット時にビルドをトリガーする方法については、Azure Container Registry タスクを使用したコンテナー イメージのビルドの自動化に関するページを参照してください。
個人用アクセス トークン
ソース コード更新のトリガーを構成するには、公開または非公開 GitHub または Azure DevOps リポジトリに Webhook を設定する個人用アクセス トークンをタスクに与える必要があります。 個人用アクセス トークンに必要なスコープは次のとおりです。
| リポジトリの種類 | GitHub | Azure DevOps |
|---|---|---|
| Public Repo | repo:status public_repo |
コード (読み取り) |
| プライベート リポジトリ | repo (フル コントロール) | コード (読み取り) |
個人用アクセス トークンを作成するには、GitHub または Azure DevOps のドキュメントを参照してください。
OS とフレームワークの修正プログラムの適用を自動化する
Azure Container Registry タスクがコンテナー ビルド ワークフローを強化する能力は、"基本イメージ" に対する更新を検出する機能に由来します。 基本イメージは、ほとんどのコンテナー イメージの機能です。 1 つ以上のアプリケーション イメージの基になる親イメージです。 通常、基本イメージにはオペレーティング システムが含まれ、場合によってはアプリケーション フレームワークが含まれます。
アプリケーション イメージをビルドするときに基本イメージ上の依存関係を追跡するように Azure Container Registry タスクを設定できます。 更新された基本イメージがレジストリにプッシュされると、または基本イメージが Docker Hub などの公開リポジトリで更新されると、Azure Container Registry タスクではそれに基づいてすべてのアプリケーション イメージを自動的にビルドできます。 Azure Container Registry タスクは、更新された基本イメージを参照するすべてのアプリケーション イメージを手動で追跡し更新するために通常は必要となる時間と労力を、この自動検出とリビルドによって削減します。
詳細については、Azure Container Registry タスクの基本イメージの更新に関する記事および「チュートリアル:Azure コンテナー レジストリで基本イメージの更新時にコンテナー イメージ ビルドを自動化する」を参照してください。
タスクのスケジュール設定
タスクの作成時または更新時に 1 つまたは複数の "タイマー トリガー" を設定して、タスクをスケジュール設定できます。 タスクのスケジュール設定は、決まったスケジュールでコンテナー ワークロードを実行する場合やレジストリに定期的にプッシュされるイメージで保守管理操作やテストを実行する場合に役立ちます。 詳細については、定義したスケジュールでの Azure Container Registry タスクの実行に関する記事を参照してください。
複数ステップのタスク:
複数のステップから成る複数コンテナー ベースのワークフローを使用して、Azure Container Registry タスクの単一イメージのビルドおよびプッシュ機能を拡張します。
複数ステップのタスクでは、クラウドでのコンテナー イメージのビルド、テスト、および修正プログラムの適用のために、ステップベースでタスクの定義と実行を行うことができます。 YAML ファイルに定義されているタスク手順では、コンテナー イメージまたはその他の成果物に対する個別のビルド/プッシュ操作が指定されます。 各ステップで実行環境としてコンテナーを使用するように、1 つまたは複数のコンテナーの実行を定義することもできます。
たとえば、以下のステップを自動化するマルチ ステップ タスクを作成できます。
- Web アプリケーション イメージをビルドします。
- Web アプリケーション コンテナーを実行します。
- Web アプリケーションのテスト イメージをビルドします。
- 実行中のアプリケーション コンテナーに対するテストを実行する Web アプリケーション テスト コンテナーを実行します。
- テストに成功した場合は Helm グラフのアーカイブ パッケージをビルドします。
- 新しい Helm グラフのアーカイブ パッケージを使用して
helm upgradeタスクを実行します。
マルチ ステップ タスクを使用すると、イメージのビルド、実行、およびテストを、ステップ間の依存関係がサポートされる、よりコンポーザブルなステップに分割できます。 Azure Container Registry タスクでマルチ ステップ タスクを使用すると、イメージのビルド、テスト、OS やフレームワークへの修正プログラム適用のワークフローをより細かく制御できます。
Azure Container Registry タスクでの複数ステップのビルド、テスト、および修正プログラムの適用タスクの実行の詳細。
コンテキストの場所
次の表は、Azure Container Registry タスクでサポートされているコンテキストの場所の例を示しています。
| コンテキストの場所 | 説明 | 例 |
|---|---|---|
| ローカル ファイル システム | ローカル ファイル システム上のディレクトリ内のファイル。 | /home/user/projects/myapp |
| GitHub メイン ブランチ | 公開または非公開 GitHub リポジトリのメイン (または他の既定) ブランチ内のファイル。 | https://github.com/gituser/myapp-repo.git |
| GitHub ブランチ | 公開または非公開 GitHub リポジトリの特定のブランチ。 | https://github.com/gituser/myapp-repo.git#mybranch |
| GitHub のサブフォルダー | 公開または非公開 GitHub リポジトリのサブフォルダー内のファイル。 例では、ブランチとサブフォルダーの指定の組み合わせが示されています。 | https://github.com/gituser/myapp-repo.git#mybranch:myfolder |
| GitHub コミット | 公開または非公開 GitHub リポジトリの特定のコミット。 例では、コミット ハッシュ (SHA) とサブフォルダーの指定の組み合わせが示されています。 | https://github.com/gituser/myapp-repo.git#git-commit-hash:myfolder |
| Azure DevOps サブフォルダー | 公開または非公開 Azure リポジトリのサブフォルダー内のファイル。 例では、ブランチとサブフォルダーの指定の組み合わせが示されています。 | https://dev.azure.com/user/myproject/_git/myapp-repo#mybranch:myfolder |
| リモート tarball | リモート Web サーバー上の圧縮されたアーカイブ内のファイル。 | http://remoteserver/myapp.tar.gz |
| コンテナー レジストリの成果物 | コンテナー レジストリ リポジトリ内の OCI 成果物ファイル。 | oci://myregistry.azurecr.io/myartifact:mytag |
Note
ソース コードの更新によってトリガーされたタスクのコンテキストとして Git リポジトリを使用する場合は、個人用アクセス トークンを提供する必要があります。
イメージのプラットフォーム
既定では、Azure Container Registry タスクによって Linux OS と AMD64 アーキテクチャ用のイメージがビルドされます。 他のアーキテクチャ用の Windows イメージまたは Linux イメージを構築するための --platform タグを指定します。 OS と、必要に応じて "OS/アーキテクチャ" 形式 (--platform Linux/arm など) でサポートされているアーキテクチャを指定します。 ARM アーキテクチャの場合は、必要に応じて、"OS/アーキテクチャ/バリアント" 形式でバリアントを指定します (例: --platform Linux/arm64/v8)。
| OS | Architecture |
|---|---|
| Linux | AMD64 ARM ARM64 386 |
| Windows | AMD64 |
タスクの出力
それぞれのタスク実行で、タスク ステップが正常に実行されたかどうかを判別するために検査できるログ出力が生成されます。 タスクを手動でトリガーすると、タスク実行のログ出力がコンソールにストリーミングされ、後で取得できるように格納されます。 (ソース コードのコミットや基本イメージの更新などによって) タスクが自動的にトリガーされる場合、タスク ログは格納されるだけです。 実行ログは Azure portal で表示するか、az acr task logs コマンドを使用します。
関連するコンテンツ
クラウドでコンテナー イメージのビルドと保守管理を自動化する準備ができたら、「チュートリアル: Azure Container Registry タスクを使用して、クラウドでコンテナー イメージをビルドしてデプロイする」を参照してください。
必要に応じて、Visual Studio Code について、Docker 拡張機能と Azure Account 拡張機能の詳細を確認してください。 これらの拡張機能を使用して、コンテナー レジストリからイメージをプルしたり、コンテナー レジストリにイメージをプッシュしたり、Azure Container Registry タスクをすべて Visual Studio Code 内で実行したりできます。