アクセスが制限されているECRに対して Azure Pipelinesからイメージを登録してみた 2023/8/23 半田 大樹

自己紹介 ⚫ 名前 半田 大樹(@hundyhundy) DP-900 ⚫ 業務 クラウド専業のSIerで、AWS上にあるデー タ分析基盤の構築・運用やAWS全般の技術 支援などを主に担当。 ⚫ 趣味 クラウド資格を取得すること。 近々AzureのAZ-500(セキュリティ)と Google CloudのProfessional Cloud Network Engineerを受験予定。

目次 • はじめに • 利用したサービス • 検証した構成 • 前提条件 • 実施内容 • 検証結果 • まとめ

はじめに • 本日の内容は記事として公開済みですので、詳細は以下をご確認ください https://zenn.dev/handy/articles/azure-pipeline-shagent-ec2-ecr

利用したサービス • Amazon ECR • Amazon EC2 • NAT Gateway • Azure Repos • Azure Pipelines

検証した構成

前提条件 以下の事前作業は完了している前提とする • PAT作成(Agent登録時に利用) • Azure DevOps Organization作成 • Azure DevOps プロジェクト作成 • Azure Reposリポジトリ作成 • Azure Pipelines用コード作成(https://github.com/handy- dd18/AzurePipeline-SHAgent-EC2-ECR) • EC2(Amazon Linux 2)・NATGW構築 • EC2へのgit/dockerのインストール • ECRリポジトリ作成 • ECRポリシー設定 青文字：Azure作業 橙文字：AWS作業

事前知識 https://learn.microsoft.com/ja-jp/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=browser Azure Pipelines エージェント • Azure Pipelinesを使用してビルド・デ プロイをするためには1つ以上のエー ジェントが必要になる • エージェントは大きく分けて2種類ある • MS管理Agent • Self-Hosted Agent • 明示的にエージェントを指定しない場 合はMS管理Agentが使用される • Self-Hosted AgentはAzure VM Scale Setを使用する方法と手動で サーバーにインストール方法の2つある • 今回はSelf-Hosted AgentをAmazon EC2にインストールして使用する Azure

事前知識 PAT(Personal Access Token) • エージェント登録用のコマンドを実行す る際にAzure DevOpsユーザーである ことを保証するためのトークン • トークンごとに有効期限やスコープを設 定することが可能 • MSアカウントやAzure AD(Entra ID)を 使用できない3rd Partyツールや環境か らAzure DevOpsに対しての認証を行 う • 今回は事前に作成したPATを使用して Self-hosted Agentの登録を行う Azure

事前知識 ECRポリシー • AWS上でコンテナイメージを管理する ECRリポジトリにはリソースベースポリ シーが設定できる • 今回は特定のIPアドレス(コンソールア クセス用)かVPC Endpoint以外からの アクセスを拒否するように設定している ※余談 右記例ではイメージスキャンのため Inspectorからのアクセスも許可している AWS

実施内容 1. エージェントプール作成 2. SHAgentインストールコマンド確認 3. EC2ログイン、SHAgentインストール・実行 4. エージェント登録確認 5. パイプライン作成 6. パイプライン実行 7. イメージPush確認(ECRリポジトリ) 青文字：Azure作業 橙文字：AWS作業

1．エージェントプール作成 Self-Hosted Agentはエージェントプールという論理的なグループで纏められる パイプライン実行時に呼び出されるbuild.ymlではこのプール名を指定する Azure

2．SHAgentインストールコマンド確認 Self-Hosted Agentはエージェントプールからダウンロードが可能で、インストー ル先のサーバーに合わせたインストールコマンドも提供されるようになっている Azure

3．EC2ログイン、SHAgentインストール・実行 対象のサーバでインストールコマンドを実行すると、エージェントのインストール とエージェントプールとの紐づけが行われる サーバにインストールされたrun.shスクリプトを実行すると、エージェントから Azureに対してポーリング接続が行われる(=Azureからのインバウンド通信が不要) AWS

4．エージェント登録確認 エージェントからAzureに正常に通信できるとエージェントプールにエージェント が登録される Azure

5．パイプライン作成 事前にイメージ作成に必要なDockerfileとbuild.ymlファイル、アプリソースは Azure ReposリポジトリにPush済みのため、それらを使用するようにPipelineを作 成する (修正後)azure-pipelines.yml Azure

5．パイプライン作成 build.ymlではDockerのBuildとECRへのPushを行うタスクを指定する ECRへのPushには事前に登録したIAMユーザーの認証情報を使用する build.yml パイプライン環境変数 IAMユーザー登録 Azure

6．パイプライン実行 作成したPipelineを指定して手動で実行する Azure

6．パイプライン実行 Pipeline画面とエージェント側のコンソールログから実行結果が確認できる Pipeline画面を見ると、「waiting on the agent to receive and acknowledge the request(エージェントがリクエストを受信して確認するのを待つ)」とあることから、エー ジェントがリクエストを確認するのを待っていることがわかる Pipeline画面 エージェント側コンソール(EC2) Azure

7．イメージPush確認(ECRリポジトリ) ECRリポジトリを見ると正常にイメージが登録されていることが確認できる AWS

まとめ この構成の嬉しい点 • ソースコード管理をAzureに集約することができる • AWS側でインバウンド通信の考慮が不要になる • ECRリポジトリへのアクセスがAWS内で完結する(Azureから直接接続しない) この構成のイマイチな点 • PATを使用するため、ユーザー側で定期ローテーション作業が必要になる • IAMユーザー管理が必要になる • EC2の管理が必要になる • エージェント用サーバがスケールしない(恐らくASとUserData使えば可能) • NAT Gatewayが必要なため、コスト的には割高になる AWS Azure

ご清聴ありがとうございました