目次
はじめに
私のCI/CDパイプラインは、Pulumiを使ってGoogle CloudにデプロイするマルチステージのGitHub Actionsワークフローで、完璧に見えました。Google CloudとAWSへの認証、pulumi upの実行、そしてSlack通知の送信まで、すべてが正常に実行されていました。すべてがグリーン（成功）でした。しかし、アプリケーションは更新されていませんでした。原因は、Docker認証のためのたった一行の欠落でした。この記事では、この静かで重大な問題を発見し、修正する方法を紹介します。
セットアップ： “完璧な”デプロイワークフロー
このワークフローは堅牢に設計されていました。Workload Identity Federationを利用してGoogle Cloudに安全に認証し、pulumi upを実行し、デプロイ前にはコミットSHAの検証まで行っていました。以下は、私のGitHub Actionsファイルから抜粋したセットアップの概要です。
問題の症状と根本原因
不可解だったのは、pulumi upコマンドが成功を報告していたことです。Pulumiは新しいイメージタグをデプロイしていると認識していました。しかし、その裏でdocker pushがPulumiプロセス内で静かに失敗していたため、実際には古い既存のイメージを再デプロイしていただけでした。
解決の鍵：欠けていた認証ステップ
根本的な原因は、GitHub ActionsのランナーはGoogle Cloudの一般的なAPI呼び出しに対して認証されていた（google-github-actions/authのおかげで）ものの、Dockerクライアント自体は認証されていなかったことでした。そのため、Google Artifact Registryにプッシュするための認証情報がなかったのです。
修正は、Google Cloudのメイン認証の直後に配置する、たった一つのシンプルなステップでした。
追加した認証ステップ:
このコマンドは、（すでに認証済みの）gcloud CLIを使用してDockerクライアントを設定します。これを追加することで、Pulumiが内部でdocker pushを呼び出す際に認証が機能し、新しいイメージがプッシュされ、デプロイが正しく成功するようになります。
結論：すべてのツールを認証せよ
私の重要な学びはシンプルでした。CI/CDランナーを認証することと、それが使用するツールを認証することは同じではない、ということです。
- ランナーの認証:
google-github-actions/authのようなアクションを使い、ワークフローに全般的なクラウドアクセス権を付与する。 - クライアントの認証: Docker（
gcloud auth configure-docker）、Terraformなどの特定のクライアントツールに対して、認証情報を明示的に設定する。
見かけ上の『成功』と、実際の『反映』が一致しないケースが存在します。デプロイの信頼性を高め、成功を本物にするために、あなたのツールチェーン内のすべてのツールが必要な認証情報を持っていることを確認してください。
