「ArgoCDを使用して、マルチ環境でのイメージプロモーションの課題を解決する」

Using ArgoCD to solve multi-environment image promotion challenges.

クラウド環境を設計する際には、複数のアカウントを設定することが推奨されることがよくあります。このアプローチはリソースの独立性、隔離性、セキュリティの向上、アクセスおよび請求の境界を提供しますが、その一方で独自の問題もあります。そのような課題の1つは、異なる環境間でアプリケーションを効率的に促進および追跡することです。

GitOpsアプローチとArgoCDやKustomizeなどのツールを使用することで、トラッキングとプロモーションを簡素化することができます。しかし、イメージのプロモーションはしばしば見落とされます。多くの企業が共有イメージレジストリを採用していますが、使用されないバージョンで膨れ上がることがよくあります。

この記事では、イメージのプロモーションの問題と、GitOpsの原則に従いながら採用された革新的な解決策について調査した最近の取り組みを探ってみます。

課題

最近、コスト効率性、より優れたガバナンス、シームレスなライフサイクル管理のために、共有ECRレジストリを使用している企業が、独立したECRレジストリに移行することを検討していました。

• 「失敗、試行、そして成功：負の二項分布の解説」
• 「コンシューマハードウェア上でPythonコーディングのためにLlama2を微調整する方法」
• 分類器のアンサンブル：投票分類器

以下は、インフラストラクチャとパイプラインの現状を見てみましょう：

• 各環境には、専用のAWSアカウントがあり、それぞれ独自のクラスタとArgoCDインストールがあります。
• Kustomizeを使用して、異なる環境間の設定の違いを管理しています。

├── infra  │   ├── charts/  └── overlays      ├── dev      │   ├── patch-image.yaml      └── production          ├── patch-image.yaml          └── patch-replicas.yaml

• Jenkinsは、開発環境で新しいイメージを継続的にビルドするために使用されています。

ただし、これらのツールのいずれも、ECRレジストリ間でイメージのプロモーションをサポートしていないため、革新的な解決策の探求が行われました。

考慮事項：

• 選択的なプロモーション：企業のアプリケーション環境は、複数のモジュールとチームで構成され、異なるタイムラインを持っています。したがって、各リリースで選択されたモジュールのイメージのプロモーションをサポートする必要があります。
• 最適化されたストレージ：プロダクションなどの環境では、プロモーションされたイメージバージョンのみを保存する必要があり、ごちゃごちゃを減らし、リソースの使用を最適化する必要があります。
• イメージのタグとダイジェストの複製：ECRレジストリ間でイメージのタグとダイジェストを複製することは、セキュリティとトレース性にとって重要です。

潜在的な解決策

最初に、2つの潜在的な解決策が提案されました：

1. ECRクロスアカウントレプリケーション： AWSのECRは、2つのアカウント間でイメージのレプリケーションをネイティブにサポートしています。ただし、現時点では、どの基準に基づいてレプリケートするイメージをフィルタリングする方法はありません。代わりに、AWSはタグの命名規則に基づいてイメージの選択的なレプリケーションをイベントベースのデザインで推奨しています。ただし、どのバージョンがプロモーションされるかわからないため、プロモーション前に追加のリタギングのステップが必要です。
2. Jenkinsプロモーションパイプライン：イメージのタグを解析し、プログラム的にそれらを複製するJenkinsパイプライン。

どちらのオプションも有効ですが、プロモーションプロセスに追加の複雑さを導入します。また、Kustomizeのオーバーレイが更新される前にイメージがプロモーションされることを確認する必要があります。

勝利の戦略：ArgoCD PreSync Job

このシナリオでは、クライアントは既にアプリケーションの変更を継続的にデプロイするためにArgoCDを使用していました。そのため、ArgoCDにイメージの配信の責任も割り当てることにしました。

ArgoCDは、デプロイや同期プロセスの前後にカスタムスクリプトを実行することができるフックをサポートしています。

1. ECRリポジトリの権限：Dockerイメージのクロスアカウントプルアクセスを認可する

ArgoCDがソースECRからイメージをプルできるようにするには、リポジトリにリソースベースのポリシーを追加する必要があります。

// cross-account-ecr-read-policy.json
{  
  "Version": "2012-10-17",  
  "Statement": [
    {
      "Sid": "AllowPull",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::{DESTINATION_ACCOUNT}:root" // 宛先アカウントに置き換えてください
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ]
    }
  ]
}

ECRリポジトリにポリシーを適用します：

aws ecr set-repository-policy --repository-name example --policy-text "file://cross-account-ecr-read-policy.json"
// 複数のリポジトリの場合：
aws ecr describe-repositories --query "repositories[].[repositoryName]" | xargs -I {} aws ecr set-repository-policy --repository-name {} --policy-text "file://cross-account-ecr-read-policy.json"

2. PreSyncフックジョブ：アカウント間でイメージをコピーする

• タグとダイジェストを変更せずにイメージをコピーするために、Craneを使用します。
• PreSyncフックジョブは、他のアプリケーションマニフェストとともにgitに格納され、ArgoCDによって監視されます。ArgoCDは同期変更の前にジョブを実行します。
• ソースアカウントは、イメージをプルする開発またはDevOpsアカウントです。
• 宛先アカウントは、イメージをコピーするプロダクションまたはターゲット環境です。

// Helmテンプレートの例
apiVersion: batch/v1
kind: Job
metadata:
  generateName: argo-presync-promote-image-
  annotations:
    argocd.argoproj.io/hook: PreSync
spec:
  template:
    spec:
      volumes:
        - name: creds
          emptyDir: {}
      initContainers:
        - name: aws-creds
          image: public.ecr.aws/aws-cli/aws-cli
          command:
            - sh
            - -c
            - |
              aws ecr get-login-password > /creds/ecr
          volumeMounts:
            - name: creds
              mountPath: /creds
      containers:
        // 簡潔さのため、すべてのHelm値がルートにあると仮定しています
        - name: promote-image
          image: gcr.io/go-containerregistry/crane:debug
          command:
            - sh
            - -c
            - |
              // 両方のECRレジストリにログインする
              cat /creds/ecr | crane auth login {{.Values.sourceAccount}}.dkr.ecr.us-east-1.amazonaws.com -u AWS --password-stdin
              cat /creds/ecr | crane auth login {{.Values.destinationAccount}}.dkr.ecr.us-east-1.amazonaws.com -u AWS --password-stdin
              // ソースアカウントから宛先アカウントにイメージをコピーする
              crane copy {{.Values.image | replace .Values.destinationAccount .Values.sourceAccount}} {{.Values.image}}
          volumeMounts:
            - name: creds
              mountPath: /creds
      restartPolicy: Never
  backoffLimit: 2

結論

結論として、プリシンクフックを使用してチームは必要に応じてイメージをプロモーションすることができました。これにより、プロダクションのプロモーションはKustomizeのオーバーレイを更新する単一のステップとなりました。

採用した他のオプションについてもお聞かせいただければ幸いです。たとえば、Kubernetes Dynamic Admission Controlを使用して不足しているイメージを必要に応じてインターセプトしてプルする別のアプローチを使用することもできます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!