Azure ContainerRegistryを理解する

devopsビルドパイプラインの最後に到達すると、一連のアーティファクト(バイナリ、構成ファイル、Webページ、さらには仮想マシンやコンテナー)が残ります。これらは、最新のアプリケーションを構築するために連携するコンポーネントです。これらのコンポーネントをできるだけ多くコンテナにラップすることは非常に理にかなっており、より単純なデプロイメントモデルを提供します。しかし、それは新しい一連の質問を残します。これらのコンテナーをどのように管理し、グローバル規模のクラウドアプリケーション全体にどのようにデプロイするのでしょうか。

GitHubなどのサービスは、オープンスタンダードとオープンソースコードを使用して、ビルドアーティファクトのプライベートレジストリとパブリックレジストリを提供します。Azureは、Open Container Initiativeに準拠した、独自のコンテナーレジストリの基盤としてオープンソースのDocker Registry 2.0を使用して、同じことを行いました。コンテナ専用ではありません。Kubernetesベースのクラウドネイティブアプリケーションの重要性が増しているため、OCI準拠のすべてのビルドアーティファクトのワンストップリポジトリとなることを目的としています。これにはHelmチャートが含まれるようになったため、アプリケーションのデプロイハブとしてAzureのContainer Registry(ACR)を使用し、Kubernetesインスタンスへの配信にHelm3.0を使用できます。

ACR入門

Azure Container Registryなどのツールは、プライベートレジストリとして最もよく考えられています。レジストリにアクセスできるのはあなたとあなたのチームとサービスだけであり、コンテナーを使用するAzureサービスへの配信を自動化します。 Azure DevOpsやJenkinsなどの使い慣れたツールは、レジストリをビルドエンドポイントとして使用するように構成できるため、プルリクエストをAzure上のコンテナーにマージして、デプロイする準備ができています。

マイクロソフトは現在、ACRの3つのバージョン(ベーシック、スタンダード、プレミアム)を3つの異なる価格で提供しています。これらはすべてWebフックで動作し、認証にAzure Active Directoryを使用し、画像を削除する機能を備えています。 Basicの容量は最小です。 Premiumには、リージョン間のレプリケーションのサポートが含まれ、イメージ署名のサポートが追加されています。 100GBのストレージ、60MBpsのダウンロード帯域幅を提供し、最大10個のWebフックをサポートするStandardを使用する可能性が最も高いです。料金はレジストリごとに1日あたりで、追加のネットワークコストと、新しいコンテナイメージを構築する際のCPU使用率に別途料金がかかります。

Azure CLIまたはポータルを使用すると、新しいコンテナーレジストリの作成は比較的簡単です。ACRインスタンスはリソースグループに関連付けられているため、Azureで実行するアプリケーションごとに個別のレジストリを作成できます。レジストリが作成されると、ログインサーバーのURLが提供されます。これは、devopsツールまたは開発者のデスクトップDockerインスタンスと統合するためのエンドポイントです。

ACRレジストリとの相互作用

Azure CLIのacrコマンドは、レジストリを操作するためのおそらく最も便利な方法です。ログインすると、コンテナイメージのプッシュを開始できます。デスクトップから始めて、その仕組みを理解し、ローカルのDockerイメージにACRログインサーバー名をタグ付けしてdocker pushから、コマンドを使用してイメージをACRレジストリに送信し、適切なリポジトリを自動的に作成することをお勧めします。 Azureで。イメージがACRリポジトリに配置されたら、コマンドラインツールを使用してファイルを一覧表示し、ファイルを削除し、Dockerコマンドを使用してファイルを実行します。

ACRを自動化すると、ACRタスクを使用してワークロードを大幅に削減できます。タスクは、Azure CLIスクリプトのセットであったものを、一般的な操作を管理する単純なワークフローにまとめます。たとえば、ビルドパイプラインまたは継続的インテグレーション/継続的デリバリー(CI / CD)システムで変更が発生したときに、新しいイメージのビルドを自動化する一連のトリガーを提供します。

1つのオプションであるクイックタスクは、ファイルのセットをコンテナーにビルドするために使用されるすべてのステージを1つのコマンドにラップします。必要なのは、ファイルと既存のACRレジストリおよびDockerfileを含む作業ディレクトリだけです。1つのコマンドでこれらのファイルを取得し、Dockerfileを使用してイメージを作成し、ACRリポジトリに自動的に保存します。別の簡単なタスクは、選択したホストでイメージを実行します。

それらを組み合わせると、コンテナイメージをテストするための基本的なツールセットができます。より複雑なデプロイには、より複雑なスクリプトが必要になります。たとえば、AKSを使用してマネージドKubernetesインスタンスにコンテナをデプロイします。または、プロセス全体を自動化して、GitHubリポジトリでデプロイブランチの変更を監視するタスクを作成したり、プルリクエストをブランチにマージしたりコミットしたりするときに新しいイメージを構築することもできます。

ACRでのコンテナの保護

ACRを使用することにはセキュリティ上の利点があります。最新のアプリケーションを構築する人が直面する大きな問題の1つは、依存関係ツリーを理解して管理することです。新しいバージョンのキーライブラリまたは難読化されたコンポーネントが安全に使用できるかどうかをどのようにして知ることができますか?コンテナーを信頼できる必要があります。ACRには、信頼できるコードを常にデプロイするための2つの方法があります。

まず、署名されたコンテナイメージを提供するため、Kubernetesクラスタは、実行中のコードがビルドシステムからレジストリにプッシュしたコードであることを確認できます。署名されたイメージにより、展開中にコンテナの内容が改ざんされていないことが保証されます。次に、ACRはAzureのセキュリティセンターと統合できます。これにより、レジストリに保存されているイメージをスキャンして、コードやベースイメージの脆弱性だけでなく、イメージファイルに含まれている、またはイメージファイルから参照されている依存関係もチェックできます。 Qualysのスキャナーを使用すると、セキュリティセンターのレポートは、修正の推奨事項とともに脆弱性を特定するのに役立ちます。

コンテナ以外にもACRインスタンスを使い始めると、物事は面白くなります。OCIは、Kubernetesアプリケーションデプロイメントの事実上のツールであるHelmを使用して、レジストリ標準をアーティファクトに開放し始めました。これは、最新リリースで使用されています。業界ではレジストリとリポジトリが急増しており、特にそれらがすべて同じクラウドネイティブアプリケーションの一部である場合は、すべてのアプリケーションコンポーネントに対して1つを標準化することは理にかなっています。

ACRは、OCI Registry As Storage(ORAS)をサポートするようになりました。ORASツールを使用すると、同じACRリポジトリからすべてのアーティファクトをプッシュおよびプルできます。開発者のマシンにORASをインストールするか、ビルドパイプラインにサポートを追加します。プッシュ権限を持つAzureActive Directoryサービスプリンシパルを使用してレジストリにサインインしたら、ORASコマンドラインツールを使用して、新しいアーティファクトをレジストリにプッシュします。

Azure CLIでコマンドラインツールを使用すると、必要に応じて呼び出すことができるスクリプトとして、選択したビルドツールにORASプッシュをビルドする柔軟性が得られます。同じコマンドラインツールでアーティファクトをプルでき、それをデプロイメントスクリプトに組み込むことができるため、アプリケーションを構成するすべてのコンポーネントは、新しいビルドがACRリポジトリにプッシュされたときに自動的にデプロイできます。

プライベートコードにはプライベートリポジトリが必要であり、コンテナーやその他のビルドアーティファクトをAzureに保持すると、それらが必要な場所に配置されます。完全なdevopsビルドプロセスは、人間の介入なしにコードコミットからアプリケーションの実行に移行する必要があります。これにより、Azure Container Registryやそれに関連するタスク自動化などのツールが、Azureを対象とするパイプラインの必須コンポーネントになります。コードは自動的に保存され、グローバル規模で展開されるだけでなく、変更があるたびにセキュリティリスクがスキャンされます。