Pulumi
宇野礼於Pulumiの公式チュートリアル
Azure用のデプロイをしたいのでそれをやる。
宇野礼於わかりやすく、すぐできた。
- ストレージアカウントの作成とキーの作成・アウトプット
- index.htmlを登録して静的サイトデプロイ
-
pulumi destroyでリソース削除 -
pulumi stack rmでスタック自体を削除
宇野礼於pulumi login すると、pulumiのクラウドコンソール上で状態管理・チェックができる。
料金はこれ https://www.pulumi.com/pricing/
無料版だと 500 free deployments minutes らしい。月間とも書いてないから、ここまで使ったもう使えないのか。
pulumi login --local にすると、クラウドコンソールで管理できないけど、上記のプランと関係なく単なるCLIツールとして無制限に利用できる（と思う）。
状態管理やログ関連のファイルはローカルに保存されるらしい。
それを閲覧・管理できる簡単なGUIコンソールをdockerとかで提供してくれたらいいのに。
宇野礼於- Pulumi IaC: インフラリソースの定義・CI/CD
- Pulumi ESC: Environments, Secrets, Configurationの略、IaCと一緒に使うこともできるし単体でも使える
宇野礼於Pulumiでlocation設定方法（azure-nativeの場合）：
# 設定できるロケーションの値は以下で確認
az account list-locations --output table
# 設定
pulumi config set azure-native:location japaneast
# 確認
pulumi config get azure-native:location
参考: https://www.pulumi.com/docs/iac/get-started/azure/create-project/
宇野礼於コンテナイメージをデプロイする場合、mac（M系）でやるときはCPUアーキテクチャの指定が必要。
こんな感じで指定できる。
custom_image = "node-app"
my_image = docker.Image(
custom_image,
image_name=registry.login_server.apply(
lambda login_server: f"{login_server}/{custom_image}:v1.0.0"
),
- build=docker.DockerBuildArgs(context=f"./{custom_image}"),
+ build=docker.DockerBuildArgs(
+ context=f"./{custom_image}",
+ platform="linux/amd64", # ← これを追加
+ ),
registry=docker.RegistryArgs(
server=registry.login_server, username=admin_username, password=admin_password
),
)
pulumi up の前に環境変数を指定（ export DOCKER_DEFAULT_PLATFORM=linux/amd64 ）するやり方もあるようだけどやってみたらできなかったので上記の方法が確実。
アーキテクチャ指定せずに pulumi up すると、以下のようなエラーが出る。
Type Name Status Info
+ pulumi:pulumi:Stack azure-py-containerapps-dev **creating failed** 1 error
+ ├─ azure-native:resources:ResourceGroup rg created (3s)
+ ├─ azure-native:operationalinsights:Workspace loganalytics created (10s)
+ ├─ azure-native:containerregistry:Registry registry created (9s)
+ ├─ docker:index:Image node-app created (20s) 1 message
+ ├─ azure-native:app:ManagedEnvironment env created (48s)
+ └─ azure-native:app:ContainerApp app **creating failed** 1 error
Diagnostics:
azure-native:app:ContainerApp (app):
error: 1 error occurred:
* Status=200 Code="ContainerAppOperationError" Message="Failed to provision revision for container app 'app5abc924d'. Error details: The following field(s) are either invalid or missing. Field 'template.containers.myapp.image' is invalid with details: 'Invalid value: "registry06567b5e.azurecr.io/node-app:v1.0.0": image OS/Arc must be linux/amd64 but found linux/arm64';.."
pulumi:pulumi:Stack (azure-py-containerapps-dev):
error: update failed
docker:index:Image (node-app):
Building your image for linux/arm64 architecture.
To ensure you are building for the correct platform, consider explicitly setting the platform field on ImageBuildOptions.
Pulumiのディレクトリ構造ベストプラクティス
結論としては、まずはモノリシックからかな。いきなりマイクロスタックにすると、どの粒度で分けるべきか判断が難しいから、必要に応じて徐々にが良さそう。
以下詳細。
モノリシック or マイクロスタック
typescriptとgoの場合: Organizing Pulumi projects & stacks
| 観点 | モノリシックスタック | マイクロスタック |
|---|---|---|
| 概要 | すべてのリソースを1つのスタックで管理 | リソースごとにスタックを分割して管理 |
| 利点 | - 単一のスタックで管理が簡単 - リソース間の参照が容易 |
- 再利用性が高い - 並列デプロイが可能 - 小さな変更の影響範囲が限定的 |
| 欠点 | - 変更が全体に波及するリスク - デプロイに時間がかかる |
- スタック間の依存関係が複雑化しやすい - 参照のための外部出力共有が必要 |
| スケーラビリティ | 限定的（大規模になると管理が困難） | 高い（チームごと・機能ごとに分割できる） |
| 適用例 | 小規模プロジェクトやシンプルな構成のアプリ | 大規模システム、チーム開発、マルチサービス構成 |
仮想ユースケースでの例
IaC Best Practices: Structuring Pulumi Projects
こちらもだいたい同じことを言っている。
単一プロジェクト vs 複数プロジェクト（Pulumi構成のベストプラクティス）
| 観点 | 単一プロジェクト構成 | 複数プロジェクト構成 |
|---|---|---|
| 定義 | 全てのスタックを1つのPulumiプロジェクト内で管理 | スタックごとに異なるPulumiプロジェクトで管理 |
| メリット | - 管理が簡単 - セットアップが素早い |
- モジュール化しやすい - チームでの分担が容易 |
| デメリット | - 拡張性に欠ける - 大規模になると複雑化 |
- 設定・統合が面倒 - 初期の構成が複雑 |
| 適した規模 | 小〜中規模 | 中〜大規模 |
| デプロイ時間 | 比較的速い | 並列化・分割できるがプロジェクト数に依存 |
| チームのコラボレーション | 難しい（変更が集中） | 容易（責務を分割可能） |
| CI/CD統合 | シンプル（1つのCIパイプライン） | より柔軟（プロジェクトごとのパイプライン） |
| 再利用性 | 低い（内部での共通コードの共有が難しい） | 高い（コンポーネント再利用がしやすい） |