こんにちは。インフラの自動化という荒野を旅するエンジニアの皆さん。
今日は、IaC（Infrastructure as Code）の「その先」にある、Pulumi Automation APIという魔法の杖についてお話しします。
TerraformやPulumiのCLIを叩く日々も悪くありませんが、本番環境で「手動でコマンドを打つ」という行為は、実は一番のヒューマンエラーの温床です。そこで登場するのがAutomation API。これを使えば、インフラ構築ロジックそのものを、あなたのアプリケーションの一部として組み込めるようになります。
今日は、この「エンジニアの究極の武器」の基礎を、一緒に紐解いていきましょう。
—
1. Automation API とは何か？：インフラの「関数化」
通常、PulumiはCLI経由で実行されますよね。しかし、Automation APIを使うと、プログラムの中で直接 `up` や `destroy` を呼び出せます。
最大のメリットは「インフラのセルフサービス化」です。
例えば、社内のエンジニアが「AWS環境が欲しい」と言ったとき、専用のポータルサイトに入力フォームを作り、ボタンを押せば裏側でPulumiが動いて安全に環境が払い出される。そんなシステムが作れるのです。
- ユースケース:
- 開発環境の動的払い出しポータル
- SaaS製品のテナントごとの環境分離（マルチテナント管理）
- CI/CDパイプラインを自作し、より柔軟なデプロイ制御を行う
—
2. 準備：まずはここから
まずは環境を整えましょう。今回は扱いやすさと拡張性を考え、Node.js (TypeScript) で進めます。
インストール
適当なディレクトリで以下を実行してください。
mkdir pulumi-automation-app && cd pulumi-automation-app
npm init -y
npm install @pulumi/pulumi @pulumi/aws
npm install –save-dev typescript @types/node
npx tsc –init
—
3. HelloWorld: プログラムでインフラを動かす
ここが今日一番の肝です。「CLIを使わずに、コードだけでインフラをデプロイする」という体験をしてみましょう。
`index.ts` を以下の内容で作成してください。
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
import { InlineProgramArgs, LocalWorkspace } from “@pulumi/pulumi/automation”;
// 1. Pulumiのデプロイ内容をプログラムとして定義
const program = async () => {
// S3バケットを1つ作るという単純な構成
const bucket = new aws.s3.Bucket(“my-automation-bucket”);
return { bucketName: bucket.id };
};
async function run() {
// 2. ワークスペースの作成（Pulumiプロジェクトをメモリ上に仮想展開するイメージ）
const args: InlineProgramArgs = {
stackName: “dev”,
projectName: “inline-infra”,
program: program,
};
const stack = await LocalWorkspace.createOrSelectStack(args);
console.log(“デプロイを開始します…”);
// 3. プログラムからデプロイを実行（CLIの ‘pulumi up’ 相当）
const upRes = await stack.up({ onOutput: console.log });
console.log(`成功！ バケット名: ${upRes.outputs.bucketName.value}`);
}
run().catch(console.error);
なぜこれが凄いのか？
- 状態管理の隠蔽: `pulumi up` を叩く必要はありません。このスクリプトを動かすだけで、いつでも同じ環境が再現されます。
- 冪等性の担保: 何度実行しても、既に存在していれば何も起きず、差分があれば修正されます。これが「インフラ管理の安定」を生む秘訣です。
—
4. 運用コスト削減とガバナンス強化の秘訣
Automation APIを導入すると、単なる便利さを超えた「ガバナンス」が手に入ります。
1. 認可の統合: AWSのIAM権限を直接エンジニアに渡す必要はありません。「Webポータルを通した依頼のみ許可する」というフローを組むことで、セキュリティリスクを大幅に下げられます。
2. コストの可視化: デプロイ時にタグ付けを強制するロジックをプログラム内に記述すれば、「誰が、何のために作ったリソースか分からない」という悲劇を未然に防げます。
3. 環境のクリーンアップ: 「使っていない環境を夜間に自動削除する」といったロジックも、プログラムなら数行の cron 定義で実装可能です。
—
最後に：先輩エンジニアからのアドバイス
Automation APIは強力ですが、まずは「小さな部品」から自動化することをおすすめします。最初から巨大なポータルを作ろうとせず、まずは「特定のS3バケットを作るだけのAPI」を社内のサーバーで動かしてみてください。
その成功体験こそが、あなたのインフラエンジニアとしてのキャリアを大きく飛躍させるはずです。
「インフラをコードで書く」から、「インフラをプログラムで操る」世界へ。
この壁を越えると、あなたは単なるインフラ担当ではなく、「インフラの自律化をデザインするエンジニア」になれますよ。
もし詰まったら、いつでも聞いてください。応援しています。