Dockerイメージ更新の自動化:Argo CD Image Updaterガイド

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

GitOpsのループを完結させる

GitOpsは「信頼できる唯一の情報源(Single Source of Truth)」を約束しますが、現実はイメージタグの更新という面倒な手動ステップが伴うことがよくあります。新しいDockerイメージをビルドしてECRやDocker Hubにプッシュした後、values.yamlファイルをわざわざ手動で編集していませんか?これはヒューマンエラーを招きやすい繰り返しの作業です。20以上のマイクロサービスを抱えるペースの速い環境では、この手動パッチ作業だけでDevOpsエンジニアの週に4〜5時間が奪われてしまうこともあります。

Argo CD Image Updaterは、コンテナレジストリを監視し、タグの変更をGitに自動で書き戻すことでこの問題を解決します。これにより、CIパイプラインとGitOpsリポジトリの間の溝が埋まります。開発者がビルドのたびに細かなコミットをする代わりに、コントローラーがその重労働を肩代わりしてくれます。

コントローラーの仕組み

Image Updaterは、Argo CDのコンパニオンツールのようなものだと考えてください。独立したデプロイメントとして動作し、Harbor、GCR、AWS ECRなどのレジストリをポーリングして、新しいイメージバージョンが存在するかを確認します。設定した条件に一致するものを検出すると、更新をトリガーします。

更新戦略

「新しい」の定義は、以下の戦略から選択できます:

  • SemVer: 本番環境のゴールドスタンダードです。セマンティックバージョニングの規則に従います。例えば、現在のタグが1.2.0であれば、1.2.1は自動取得しますが、破壊的変更を含む2.0.0は無視します。
  • Latest: 最も新しいビルドタイムスタンプを持つイメージを選択します。latestdevelopといったタグが頻繁に上書きされる開発環境に便利です。
  • Alphabetical: タグをアルファベット順にソートし、リストの最後にあるものを選択します。

書き戻し(Write-back)手法

更新をどのように適用するかは、監査証跡(Audit Trail)において非常に重要です:

  1. Imperative (Argo CD API): ツールがArgo CDに対し、内部状態のパラメータを上書きするよう指示します。変更はGitには現れません。高速ですが、リポジトリで変更履歴を確認できなくなります。
  2. Git Write-back: 推奨されるアプローチです。ツールがリポジトリをクローンし、新しいタグでコミットを作成してプッシュします。Gitの履歴が、本番環境で何が動作しているかの決定的な記録として残ります。

設定のステップバイステップ

すでにArgo CDが動作していることを前提とします。Image Updaterをインストールし、Git write-back手法を使ってサンプルアプリを追跡するように設定します。

1. インストール

公式のマニフェストを使用してコントローラーをデプロイします。安定版を取得するには、次のコマンドを実行します:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml

argocd名前空間でPodが実行されているか確認して、インストールを検証します。30秒ほどで準備が整うはずです。

2. Gitアクセスの許可

ツールが変更をコミットするためには、パーソナルアクセストークン(PAT)が必要です。これらの認証情報を安全に保存するために、Kubernetes Secretを作成します:

kubectl create secret generic git-creds \
  --from-literal=username=devops-bot \
  --from-literal=password=ghp_your_secret_token_here \
  -n argocd

3. アプリケーションアノテーションの追加

Image Updaterはオプトイン方式です。特定のアノテーションが付与されたアプリケーションのみを監視します。これらのアノテーションは、どのイメージを追跡し、どの戦略を使用するかをツールに伝えます。

以下は、SemVerでWebアプリを追跡するApplicationマニフェストのスニペットです:

apiVersion: argocd.io/v1alpha1
kind: Application
metadata:
  name: inventory-api
  namespace: argocd
  annotations:
    # inventoryイメージを追跡
    argocd-image-updater.argoproj.io/image-list: my-app=docker.io/org/inventory:~
    # SemVer戦略を使用
    argocd-image-updater.argoproj.io/my-app.update-strategy: semver
    # Git write-back手法を使用
    argocd-image-updater.argoproj.io/write-back-method: git
    # Git認証情報のSecretを参照
    argocd-image-updater.argoproj.io/write-back-repository: [email protected]:org/infra-repo.git
spec:
  source:
    repoURL: https://github.com/org/infra-repo.git
    targetRevision: HEAD
    path: apps/inventory

イメージリスト内の~記号は短縮記法です。これは、1.1.5から1.1.9への更新のように、現在のマイナーバージョンの範囲内に留まるようアップデーターに指示します。

プライベートレジストリへの接続

パブリックレジストリはそのまま動作しますが、プライベートなものは認証が必要です。argocd-image-updater-config ConfigMapでグローバルに認証情報を定義するか、特定のアプリケーション用にSecretを使用します:

argocd-image-updater.argoproj.io/my-app.pull-secret: secret:argocd/registry-creds

トラブルシューティングとベストプラクティス

タグが更新されない場合は、推測に頼らずすぐにログを確認しましょう。kubectl logs -n argocd deployment/argocd-image-updaterを実行して、401 Unauthorizedエラーやレート制限の問題が発生していないか確認してください。

  • レート制限に注意: Docker Hubには厳しいプル制限があります。ブロックされないよう、ConfigMapでポーリング間隔を5分または10分に設定してください。
  • ブランチ保護: Gitトークンにブランチ保護をバイパスする権限があることを確認してください。mainブランチで署名済みコミットやPRের承認が必要な場合、ツールはプッシュに失敗します。
  • オーバーライドファイル: Git write-backを使用すると、.argocd-source-<appname>.yamlという名前のファイルが作成されます。ここにツールがオーバーライド設定を保存します。このファイルはリポジトリ内に保持してください。

最後に

イメージ更新の自動化は、ほとんどのGitOpsワークフローにおける最後の手動の障壁を取り除きます。これにより、人の手を介さずにクラスターをレジストリと同期させることができます。まずは1つのステージング環境 service をSemVer戦略に移行することから始めてみてください。自動化の安定性が確認できたら、本番環境のマイクロサービス全体に展開し、真の継続的デリバリーを実現しましょう。

Share: