こんにちは！インフラストラクチャの世界へようこそ。
日々、クラウドの構成管理やデプロイに奔走していると、こんな恐怖を感じたことはありませんか？
「気づいたらPulumiのプロバイダバージョンが何世代も古くなっている……」
「メジャーアップデートを当てたら、突然本番環境のインフラが破壊的な変更でエラーを吐いた……」
手動でバージョン追従を行うのは、暗闇の中で地雷原を歩くようなものです。そこで今回は、「Dependabot / Renovate」と「Pulumiの自動テスト」を組み合わせ、安全かつ完全に自動でプロバイダやランタイムを最新に保つOpsワークフローの極意を伝授します。
これをマスターすれば、バージョンアップの恐怖から解放され、毎日のインフラ運用が劇的に楽になりますよ。さあ、一緒に深淵を覗いてみましょう！
—
1. Pulumiのバージョン管理における「2つの罠」
まず、Pulumiを使ったIaC（Infrastructure as Code）特有の構造を理解しましょう。Pulumiのプロジェクトは、主に以下の3つの要素で構成されています。
1. 言語ランタイム: TypeScript/Node.js、Python、Go、C#など。
2. Pulumi SDK (Core): `pulumi` パッケージ自体。
3. クラウドプロバイダ SDK: `@pulumi/aws` や `pulumi_gcp` など。
これらはそれぞれ独立してバージョンを持っています。「プロバイダだけを上げたら、ランタイムの依存関係とコンフリクトを起こした」「マイナーバージョンならまだしも、メジャーバージョンアップでリソースのプロパティ名が変わってしまった」といった事故が後を絶ちません。
だからこそ、「安全に自動検知し、テストを通過したプルリクエストだけをマージする仕組み」が不可欠なのです。
—
2. ツール選定：Renovateによる全方位自動追従
依存関係の自動更新ツールといえばDependabotが有名ですが、Pulumi環境において真価を発揮するのはRenovateです。Node.jsの`package.json`、Pythonの`requirements.txt`、あるいはDockerイメージまで、複数の言語やマニフェストが混在しがちなPulumiプロジェクトを、一元的に、かつ柔軟なスケジュールで統御できるからです。
究極の `renovate.json` 設定
プロジェクトのルートに配置する、現場で即座に使える設定ファイルを見てみましょう。
{
“$schema”: “https://docs.renovatebot.com/renovate-schema.json”,
“extends”: [
“config:base”,
“schedule:weekly”,
“:dependencyDashboard”
],
“packageRules”: [
{
“matchUpdateTypes”: [“minor”, “patch”],
“automerge”: true,
“automergeType”: “branch”
},
{
“matchPackagePatterns”: [“^@pulumi/”],
“groupName”: “pulumi-providers”
}
],
“labels”: [“dependencies”, “pulumi”],
“commitMessagePrefix”: “chore(deps):”
}
ここがポイント：
- `schedule:weekly`: 毎日PRが作られて通知地獄になるのを防ぎ、週に一度まとめて安全に処理します。
- `matchUpdateTypes`: `minor` / `patch`: 破壊的変更が含まれないマイナー・パッチ更新は自動マージ（`automerge`）させ、運用の手間を極限まで削ります。
- `matchPackagePatterns: [“^@pulumi/”]`: 散らばりがちなPulumiのプロバイダ群を一つのPRにグループ化し、CIの実行回数を最適化します。
—
3. 破壊的変更（Breaking Changes）に備えるマイナー＆メジャー戦略
では、自動マージされない「メジャーバージョンアップ（例: AWSプロバイダの v5 から v6 への移行など）」はどう扱えばいいのでしょうか？ ここにプロのエンジニアとしての腕の見せ所があります。
メジャーアップデートのPRが作成されたら、必ず「Pulumi Preview」と「自動テスト（Unit/Integration）」の防壁を潜り抜けさせます。
GitHub Actionsによる安全検証ワークフロー
依存関係が更新された際、単にビルドが通るだけでなく、「実際にクラウド側のAPIと通信し、既存リソースに予期せぬ差分（Diff）が発生しないか」を検証するワークフローを組みます。
`.github/workflows/pulumi-verify.yml`:
name: Pulumi Safety Verification
on:
pull_request:
branches: [ main ]
jobs:
preview:
name: Pulumi Preview & Test
runs-on: ubuntu-latest
steps:
- name: Checkout Repo
uses: actions/checkout@v4
- name: Setup Node.js (ランタイムのバージョンを合わせる)
uses: actions/setup-node@v4
with:
node-version: ’20.x’
cache: ‘npm’
- name: Install Dependencies
run: npm ci
- name: Setup Pulumi
uses: pulumi/action-updatestack@v2
with:
pulumi-version: ‘^3.0.0’
- name: Configure AWS Credentials (OIDC推奨)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsPulumiRole
aws-region: ap-northeast-1
- name: Run Pulumi Preview
uses: pulumi/actions@v5
with:
command: preview
stack: production
comment: true
env:
PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
このワークフローがPRのコメント欄に「どのような差分（Diff）が生じるか」を自動投稿してくれます。エンジニアは、メジャーバージョンのPRが来たらこのDiffを目視確認するだけで、破壊的変更を事前に検知できるのです。
—
4. テスト駆動型インフラ：Unit Testでコードの破綻を防ぐ
さらに踏み込んで、Pulumiの強力な機能である「モックテスト（Unit Testing）」を導入しましょう。プロバイダのバージョンアップによって予期せぬプロパティの型変更などが起きた際、クラウドに接続する前のコードレベルで検知できます。
TypeScriptでのテスト例 (`index.test.ts`):
import as pulumi from “@pulumi/pulumi”;
// Pulumiのランタイムをモック化する
pulumi.runtime.setMocks({
newResource:- (args: pulumi.runtime.MockResourceArgs): { id: string, state: Record
return {
id: `${args.name}-id`,
state: args.inputs,
};
},
call: (args: pulumi.runtime.MockCallArgs) => {
return args.inputs;
},
});
describe(“Infrastructure Unit Tests”, () => {
it(“S3 bucket must have encryption enabled”, async () => {
// メインのインフラ定義をインポート
const infra = await import(“./index”);
// バケットのプロパティを検証（バージョンアップによる設定漏れを防ぐ）
// ※実際のコードの構造に合わせてアテストを記述
expect(infra.bucketId).toBeDefined();
});
});
このユニットテストをCI（GitHub Actions）のパイプラインに組み込んでおけば、依存関係の更新によってコードの整合性が崩れた瞬間にビルドが落ちるため、バグを含んだコードがマージされることは物理的に不可能になります。
—
5. まとめ：おそるるなかれ、自動化された未来へ
いかがでしょうか？
1. Renovateでマイナー/パッチを自動追従しつつ、プロバイダの更新をグルーピング。
2. メジャーバージョンや変更時は GitHub Actions + Pulumi Preview で差分を視覚的にチェック。
3. ユニットテストでコードレベルの整合性を担保。
このOpsワークフローを一度構築してしまえば、あなたは古いバージョンの呪縛から解放され、つねに最新かつ安全なクラウドインフラの恩恵を受け続けることができます。
「インフラの面倒なメンテナンスはツールと仕組みに任せ、自分たちは新しい価値を創造するコードを書くことに集中する」——これこそが、SREが目指すべき理想郷です。
ぜひ、あなたのプロジェクトにも導入してみてください。あなたのインフラ運用ライフが劇的に快適になることを、心から応援しています！