ACR タスクでコンテナーイメージのビルドとメンテナンスを自動化する

[アーティクル]
01/24/2024

コンテナーは、アプリケーションと開発者の依存関係をインフラストラクチャおよび操作の要件から分離する新たなレベルの仮想化を提供します。ただし、コンテナーのライフサイクルを通してこのアプリケーション仮想化を管理し修正プログラムを適用する方法に対処することはやはり必要です。

ACR タスクとは

ACR タスクは、Azure Container Registry 内の一連の機能です。 Linux、Windows、ARM などのプラットフォーム用のクラウドベースのコンテナーイメージのビルド機能があり、Docker コンテナーの OS とフレームワークのパッチ適用を自動化できます。 ACR タスクでは、オンデマンドのコンテナーイメージのビルドによって "内部ループ" 型の開発サイクルをクラウドに拡張するだけでなく、ソースコードの更新、コンテナーの基本イメージの更新、またはタイマーによってトリガーされるビルドの自動化を有効にすることもできます。たとえば、基本イメージの更新のトリガーを使用することで、OS とアプリケーションフレームワークの修正プログラム適用のワークフローを自動化したり、不変のコンテナーの原則に従いながら、セキュリティで保護された環境を維持したりできます。

[! IMPORTANT] ACR は、Azure の無料クレジットからの ACR タスクの実行を一時的に停止しています。これは、既存のタスクの実行に影響する可能性があります。問題が発生した場合は、当社のチームが追加のガイダンスを提供できるようにサポートケースを開いてください。既存のお客様はこの一時停止による影響を受けないことにご注意ください。一時停止が解除されたら常に、こちらのドキュメントを更新してお知らせします。

[! 警告] コマンドラインで、または URI の一部として提供される情報は、Azure Container Registry (ACR) 診断トレースの一部としてログに記録される可能性があることにご注意ください。これには、資格情報、GitHub の個人用アクセストークン、セキュリティで保護されたその他の情報などの機密データが含まれます。注意し、潜在的なセキュリティリスクを防いでください。診断ログの対象となるコマンドラインまたは URI に機密性の高い詳細を含めないようにすることが重要です。

一般的なシナリオ

ACR タスクでは、コンテナーイメージやその他の成果物をビルドし、保守管理するためのシナリオをいくつかサポートしています。詳細については、この記事の次のセクションを参照してください。

クイックタスク - ローカル Docker エンジンをインストールすることなく、Azure で 1 つのコンテナーイメージをオンデマンドでビルドし、コンテナーレジストリにプッシュします。クラウドでの docker build や docker push を思い浮かべてください。
自動的にトリガーされたタスク - イメージをビルドする目的で 1 つまたは複数のトリガーを有効にします。
マルチステップタスク - 複数のステップから成る複数コンテナーベースのワークフローを持つ、ACR タスクの単一イメージのビルドおよびプッシュ機能を拡張します。

各 ACR タスクには、ソースコードコンテキストが関連付けられます - コンテナーイメージまたはその他の成果物のビルドに使用される一連のソースファイルの場所。見本のコンテキストには、Git リポジトリまたはローカルファイルシステムが含まれます。

タスクでは、Run 変数を活用することもできます。そのため、タスクの定義を再利用したり、イメージや成果物のタグを標準化したりできます。

クイックタスク

内部ループ型の開発サイクルは、コードの記述、ビルド、およびアプリケーションのテストの反復プロセスであり、実のところ、コンテナーのライフサイクル管理の開始点となります。

ACR タスクのクイックタスク機能は、コードの 1 行目をコミットする前でさえ、コンテナーイメージのビルドを Azure にオフロードすることで、統合された開発環境を提供できます。クイックタスクを使用すると、コードをコミットする前に、自動化されたビルド定義を検証し、潜在的な問題を知ることができます。

よく知られている docker build 形式を使用して、Azure CLI の az acr build コマンドはコンテキスト (ビルド対象の一連のファイル) を取得して ACR タスクに送信し、既定では、完了時にビルド済みのイメージをそのレジストリにプッシュします。

概要については、Azure Container Registry でのコンテナーイメージのビルドと実行のクイックスタートを参照してください。

ACR タスクは、コンテナーライフサイクルプリミティブとして設計されています。たとえば、ACR タスクを CI/CD ソリューションに統合します。 az login をサービスプリンシパルで実行することにより、CI/CD ソリューションは az acr build コマンドを発行してイメージビルドを開始できます。

クイックタスクを使用する方法については、Azure Container Registry タスクを使用してクラウドでコンテナーイメージをビルドすることに関する ACR タスクの最初のチュートリアルを参照してください。

ヒント

Dockerfile を使用せずにソースコードから直接、イメージをビルドしてプッシュする場合、az acr pack build コマンド (プレビュー) が Azure Container Registry に用意されています。このツールでは、Cloud Native Buildpacks を使用し、アプリケーションソースコードからイメージをビルドし、プッシュします。

ソースコードの更新でタスクをトリガーする

GitHub または Azure DevOps の公開または非公開 Git リポジトリに対して、コードがコミットされたとき、またはプルリクエストが作成または更新されたときに、コンテナーイメージのビルドまたはマルチステップタスクをトリガーします。たとえば、Azure CLI コマンドの az acr task create でビルドタスクを構成し、その際、Git リポジトリと任意でブランチと Dockerfile を指定します。チームがリポジトリのコードを更新すると、ACR タスクで作成された Webhook が、リポジトリで定義されているコンテナーイメージのビルドをトリガーします。

ACR タスクでは、Git リポジトリをタスクのコンテキストとして設定すると、次のトリガーがサポートされます。

トリガー	既定で有効
Commit	はい
Pull request	いいえ

注意

現在、GitHub Enterprise リポジトリにおける commit や pull request トリガーは、ACR タスクではサポートされません。

ソースコードのコミット時にビルドをトリガーする方法については、Azure Container Registry タスクを使用してコンテナーイメージのビルドを自動化することに関する ACR タスクの 2 つ目のチュートリアルを参照してください。

個人用アクセストークン

ソースコード更新トリガーを構成するには、公開または非公開 GitHub または Azure DevOps リポジトリに Webhook を設定するアクセストークン (PAT) をタスクに与える必要があります。 PAT に必要なスコープは次のとおりです。

リポジトリの種類	GitHub	DevOps
Public Repo	repo:status public_repo	コード (読み取り)
プライベートリポジトリ	repo (フルコントロール)	コード (読み取り)

PAT を作成するには、GitHub または Azure DevOps のドキュメントを参照してください。

OS とフレームワークの修正プログラムの適用を自動化する

ACR タスクがコンテナービルドワークフローを真に強化する能力は、基本イメージに対する更新を検出する機能に由来します。ほとんどのコンテナーイメージの機能である基本イメージは、1 つ以上のアプリケーションイメージの基になる親イメージです。通常、基本イメージにはオペレーティングシステムが含まれ、場合によってはアプリケーションフレームワークが含まれます。

アプリケーションイメージをビルドするときに基本イメージ上の依存関係を追跡するように ACR タスクを設定できます。更新された基本イメージがレジストリにプッシュされると、または基本イメージが Docker Hub などのパブリックリポジトリで更新されると、ACR タスクではそれに基づいてすべてのアプリケーションイメージを自動的にビルドできます。 ACR タスクはこの自動検出とリビルドによって、更新された基本イメージを参照しているすべてのアプリケーションイメージを手動で追跡し、更新するために通常は必要となる時間と労力を削減しています。

詳細については、ACR タスクの基本イメージの更新トリガーに関する記事を参照してください。また、「Azure コンテナーレジストリ内の基本イメージの更新時のコンテナーイメージビルドの自動化」のチュートリアルで、基本イメージがコンテナーレジストリにプッシュされたときにイメージビルドをトリガーする方法を学習します

タスクのスケジュール設定

任意で、タスクの作成時または更新時に 1 つまたは複数の "タイマートリガー" を設定し、タスクをスケジュール設定します。タスクのスケジュール設定は、決まったスケジュールでコンテナーワークロードを実行する場合やレジストリに定期的にプッシュされるイメージで保守管理操作やテストを実行する場合に役立ちます。詳細については、「定義したスケジュールで ACR タスクを実行する」を参照してください。

複数ステップのタスク

複数ステップのタスクでは、クラウドでのコンテナーイメージのビルド、テスト、および修正プログラムの適用のために、ステップベースでタスクの定義と実行を行うことができます。 YAML ファイルに定義されているタスク手順では、コンテナーイメージまたはその他の成果物に対する個別のビルド/プッシュ操作が指定されます。各ステップで実行環境としてコンテナーを使用するように、1 つまたは複数のコンテナーの実行を定義することもできます。

たとえば、以下を自動化するマルチステップタスクを作成できます。

Web アプリケーションイメージをビルドする
Web アプリケーションコンテナーを実行する
Web アプリケーションのテストイメージをビルドする
実行中のアプリケーションコンテナーに対するテストを実行する Web アプリケーションテストコンテナーを実行する
テストに成功した場合は Helm グラフのアーカイブパッケージをビルドする
新しい Helm グラフのアーカイブパッケージを使用して helm upgrade を実行する

マルチステップタスクを使用すると、イメージのビルド、実行、およびテストを、ステップ間の依存関係がサポートされる、よりコンポーザブルなステップに分割できます。 ACR タスクでマルチステップタスクを使用すると、イメージのビルド、テスト、OS やフレームワークへの修正プログラム適用のワークフローをより細かく制御できます。

マルチステップタスクについては、ACR タスクでビルド、テスト、および修正プログラムの適用を行うマルチステップタスクを実行することに関するページを参照してください。

コンテキストの場所

次の表は、ACR タスクでサポートされているコンテキストの場所の例を示しています。

コンテキストの場所	説明	例
ローカルファイルシステム	ローカルファイルシステム上のディレクトリ内のファイル。	`/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 リポジトリを使用する場合は、個人用アクセストークン (PAT) を提供する必要があります。

イメージのプラットフォーム

既定では、ACR タスクによって 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 コマンドを使用します。

タスクログの表示と管理の詳細を確認してください。

次のステップ

クラウドでコンテナーイメージのビルドと保守管理を自動化する準備ができたら、ACR タスクのチュートリアルシリーズをご覧ください。

Azure コンテナーレジストリを操作するには、必要に応じて Visual Studio Code 用の Docker 拡張機能と Azure アカウント拡張機能をインストールします。 Azure コンテナーレジストリとの間でイメージをプルおよびプッシュしたり、ACR タスクを実行したりします。すべて Visual Studio Code 内で実行します。

ACR タスクでコンテナー イメージのビルドとメンテナンスを自動化する