ぼくの考えた最強のiaC

Transcript

1. ぼくの考えた最強のIaC 2026/3/27
2. お前誰だよ Otazoman 1975年生まれ がっつり氷河期世代の文系卒です 趣味：惰眠をむさぼること 妙なこだわりですが、理系の修士卒ではなくエンジニアの 定義から外れていて、おこがましくてエンジニアは名乗れ ないです。 AWSのインフラ構築メインにT社様案件に関わってました。 ダメダメなインフラおじさんです(本日最終出社ですw)。 X:うひーマン(@norikoni)
3. ▪本日お話しすること 自分で体験したIaCの話(あまり役に立たない) ▪本日お話しないこと IaCベストプラクティスとか最先端ななんか役に立ちそうなこと
4. 皆さん、クラウドでのインフラ設定ってどうしてますか？
5. 当然、GUIっすか・・・(石器時代) GUIでちまちま操作して設定 ・手順書見ながら操作 ・GUI変わったら泣きそう
6. まぁCLIっしょ(土器時代) CLIで操作して設定 ・コマンドライン操作 ・イケてる感じ醸し出せる
7. いやいやShell芸っすよ(鉄器時代) ShellでCLIを組み合わせる ・コマンド一撃でリソース作成 ・CSV定義の設定ファイル外出しも可能
8. 今までのやりかたまとめ Shell芸最強 GUI操作 CLI操作 Shell芸 メリット ・操作が簡単 ・習得が早い ・追加リソース不要 ・詳細設定が簡単 ・再現性あり ・デバッグできる ・条件分岐できる ・複数リソース作成時に強み ・マルチクラウドも構築可能 デメリット ・詳細設定が煩雑 ・誤操作による設定ミス ・デバッグできない ・コマンド理解が必要 ・学習コストがかかる ・大規模環境には不向き ・属人性が強くなりがち ・追加環境とShellが必要 ・複雑性が増す 評価 素人みたいにみられる ややかっこよく見える 職人みたくみられる
9. 今までのやり方の問題点 •UI変わったら手順書作り直し発生 •手で設定したらミスがついて回る •コマンドだけ見ても何してるか判別しにくい モダンではないので、巷のキラキラエンジニアの受けが悪い •なんでShell？ってDisられる
10. そこで救世主IaCの登場
11. IaCって何それおいしいの？ IaCとは Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタ ルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プ ロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理シ ステムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定 義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられ ている[1]。 WikiPedia よ り 転 載 WikiPediaより転載 コードにインフラの構成記述しとけば、それを元に設定できる。 コード変更すればインフラの構成も変更できる。 コマンド一発滅びの呪文を使える。
12. 導入すればモダンなインフラ環境が実現できます クラウドリソースをコードで管理 CI/CD パイプライン コードを修正しGitHubへPush GitHubへのPushをトリガーにCI/CD インフラ自動構築
13. ちょっとだけIaCの説明
14. IaCの種類 宣言型 中間型 プログラミング型 YAMLとかJSONとかで設定内容を 記述してコマンドラインでテンプ レートファイルを読み込んでリ ソースを構築する. テンプレートファイルを修正して 流しなおせば構成の変更も可能 専用ツールをインストールし、 DSL(ドメイン固有言語)でインフ ラのリソースを記述してDeployし てインフラを構築する。一応、繰 り返しや条件分岐できる。 プログラミング言語を使用して、 リソースをプログラムの様に記述 できる。内部で宣言型とか中間型 のスタックに置き換える形式のも のが多い。 対応言語は TypeScript/Python/C#/Javaの ケースが大半だが専用ツールの installがnpmってケースが多く、 TypeScriptが中心で他の言語使っ てる事例は少ない。 ・AWS Cloud Formation ・Azure ARM Template ・Google Deployment Manager ・ちょっと特殊 ・Crossplane ・Ansible ・Terraform ・Open Tofu ・Azure Bicep ・AWS CDK ・CDK for Terraform(CDKTF) ・Plumi
15. AWS Cloud Formation ・スタック単位でリソースを管理して、よしなにしてくれる ・テンプレートはYAMLもしくはJSONで記述 ・AWS CloudFormation デザイナーでグラフィカルに管理できる ・SAMとかServerless Framework、AWS-CDKも行きつく先はコレ 宣言型 Azure ARM Template ・リソースをグループ単位で管理して、よしなにしてくれる ・テンプレートはJSONで記述する ・手動作成したリソースからテンプレート出力できる Google Deployment manager ・リソース単位でテンプレートファイルを記述する ・JSON, YAML, Python, Jinja2というフォーマットで柔軟な管理ができる ・2026年3月末でサービス終了、もはや使う理由はない (ファイル分割とかきれいにできたので結構好きだったが残念)
16. 中間型 Terraform ・Hashi Corp製(IBMに買収されちゃった)、IaC界隈で圧倒的なシェア(62%) ・幅広いサービスを統一した形式(HCL)で記述できる ・条件分岐とか繰り返しとかいろいろできるけどトリッキーになる Open Tofu ・Terraformのライセンス変更によってフォークしたOSS ・Terraformとほぼ同じ特徴、利用者そんなに多くない ・バージョンが進むとterraform互換が怪しくなりそう Azure Bicep ・記述方法はTerraformに似てる ・Azureのリソースしか作成できない ・なんか色々とイケてなく見えてアレな感じ(MSなので・・・)
17. プログラミング型 AWS CDK ・AWS謹製なので当然、AWSのみでしか使用できない ・結構、頻繁に更新されている ・L3コンストラクタを使えば少ない記述量でリソースを表現できる CDK for Terraform (CDKTF) ・Hashi Corp製のCDKでいろんなサービスで使用できるようになってる ・Terraformからインポートエクスポートできたりする ・開発止まってるけど大丈夫か(大丈夫ではなかった) Plumi ・スタック作るタイプと違って純粋にプログラムでリソースを操作できる ・なんか巷では評価は高いみたいだが触っていないのでよくわからない ・採用が少なくマイナーすぎて知見が少ない
18. IaCの3タイプ比較 宣言型 中間型 プログラミング型 使用言語 JSON/YAML等 DSL TypeScript,Python,Java,C# 学習コスト JSON/YAMLの構文のみ。 直感的に理解しやすい。 HCL等の独自DSLの学習が必要 言語仕様 + 中間スタック仕様+ ク ラス設計の理解が必要。 抽象化 リソース定義が冗長にな りがち。 モジュールによる再利用が可能。ロ ジック記述するとトリッキーになっ て可読性が落ちる。 クラス継承、ループ、関数化によ り高度に抽象化可能。 マルチクラウド もともと想定されていな い 単一ツールで多数のプロバイダを統 合管理可能。BicepはAzure特化 Pulumi、CDKTFは対応。CDKは AWS特化 状態管理 ユーザ側で意識する必要 がない tfstateファイルの安全な管理 （S3+Lock等）が必須。 CDKはAWS依存、それ以外はス テートファイルの管理が必要 総評 クラウド単体なら一番簡 単に管理できる。小規模 であればこれがおススメ ちょっと込み入った構成やマルチク ラウド管理ならこちらがおススメ アプリケーションと同じような感 覚で管理できる。テストとかしっ かりやりたい場合はこちらがおス スメ
19. そしてようやく本題
20. 何がしたいのか コンテナ+RDBMS構成でVPN接続したマルチクラウドのAPIバックエンド構成作りたい。 (現在も継続中) Virtual private cloud (VPC) VNet Cloud Run Cloud SQL Cloud Load Balancing Applicationg ateway Container Apps Virtual NetworkGateway AWS Site-to-Site VPN Cloud VPN Flexible Database Amazon ECS Amazon RDS Elastic Load Balancing
21. 最初にマルチクラウドでVPN始めてみました CLIコマンド組み合わせてVPN 接続するところからスタート いきなりTerraformに進化
22. Terraformで作業しててモヤモヤ ・ベタ書き ↓ ・モジュール化して分割 ↓ 可変値は変数化してvariables.tfに切り出し ・追加要件 ・開発モードは非HAのVPN構成にしたい ・コンテナとかDBとかはフラグ制御したい ・接続するクラウドを制御したい などなど Terraformでやると複雑になりそう・・・ あとテスト何とかしたい なんか管理しやすい手立てないかな
23. そこで採用したのが CDK for Terraform (CDKTF) マルチクラウド扱える!! スナップショットテスト記述できる!! Terraformと親和性高い!! 早速、TerraformのHCLをちまちまTypeScriptに変換
24. が、現実はそう甘くない Constructs記述 オーケストレータ記述 スナップショットテスト なぜか実際にリソース作成し てテスト ・リソースが正しくできるかはやはり手動テストしないと不明 ・コンパイル通ってもリソース作ると謎のエラー ・AzureのVPNリソースが作成完了までに1時間 ・Azureマジでデプロイ遅い、殺意が芽生えました ・GoogleもDestroy時に意味不明のエラー ・バグらしくIssueで上げられてるが修正見通しなし、手作業 ・プロパティ名がterraformと違って混乱・・・ ・おまけにGoogle・AzureはMySQL8.4、Postgre18まだ、未対応・・・ ・なんで・・・意味不明
25. ・Windows UpdateのテロのせいでDISKが吹っ飛ぶ(MSマジかよ・・・) ・バックアップとGitHubからデータ復元して作業再開 正直、この時は心折れました 極めつけは・・・・ 3ヶ月分程度の作業がすべてパー
26. リカバリーの過程で ・スナップショットテストの威力をかみしめる ・復旧後テストの動作は担保!! ・スナップショットテストﾈ申
27. そんなCDKTFとの日々が・・・
28. いきなりのお別れ 2025年12月10日、突如GitHubのアーカイブとサービス終了、事前告知なし
29. 移行をどうするか・・ ・せっかく3クラウド分のDB作成のところまで進んだのに、、、、 ・移行するには ①HCL変換してterraformへ戻る ②Plumiへ・・・(が、インポートできるのはHCL) どっちにしてもHCLにしないといけない CDKTF is Dead: What Now? cdktf synth --hcl
30. そして救世主cdktn爆誕
31. なんとコミュニティの方々が・・・ Xユーザーのk.gotoさん: 「CDKTF (CDK for Terraform) がコミュニティ駆動の継 続版として CDK Terrain (cdktn) という 名前に変わり、Open Construct Foundation (OCF) によって開発が引き継 がれるそうです。 https://t.co/tRheplfY8N」 / X
32. GitHub覗きに行きました open-constructs/cdk-terrain: Define infrastructure resources using programming constructs and provision them using OpenTofu/Terraform リリースされてる じゃないですか!!! (2月4日のことでしたね・・・)
33. そして移行(1時間ほどで終了) Migrating to CDKTN - CDK Terrain (CDKTN) ・作業用Dockerコンテナ修正 ・cdktnインストール ・tenvいれてterraformとOpen tofu入れる ・コマンドにシンボリックリンク張る ・新コンテナ立上 ・ソースコード修正 ・importしているライブラリの[cdktf]を[cdktn]に書替 ・package.json書替 ・npm installで依存パッケージインストールしなおし ・最後にスナップショットテスト(npm run test)走らせて ・テストはすべてGreen ・コマンドはcdktfと変わらない!!!!
34. 無事に移行完了、cdktnとの新生活スタート
35. 学んだこと ・買収されるといきなりサービス終了される場合もあるので要注意 ・IaCはテストコード書くこと非常に重要 ・環境はコンテナで作成してコードはGitHubで管理が必須 ・OSSのコミュニティの人達はﾈ申 ・この先どうなるかは分からないです。なんせメジャーじゃないので・・・
36. 実務において ・マネコンでリソースを触る人が多いので人類にIaCは早すぎる ・IaCは状態管理が命なので全部コード管理する覚悟がないと破綻する ・ちょっとした修正でDeploy走らせるのはコストが大きく面倒 ・設計書のないコードが残されると技術負債化しがち(そうなると本末転倒) きちんと調整せずにIaCを導入すると廃墟化する ・インフラ設定はGitHub管理できていないことが多くて履歴管理ツライ
37. そういう意味で行くとShell芸は ・マネコンでリソースを触られてもびくともしない ・状態管理していないけどコードでインフラ管理できる ・ちょっとした修正はCLIなので柔軟、修正コストはIaCよりやや小さい ・Shell職人がいれば何とかなる(どれだけいるかは謎だがIaCできる人より多そう) もしかしたらShell芸こそ最強のIaCかもしれない ・GitHubなくても頑張ればEXCELで履歴管理できる(やりたくないけど)
38. ちなみに同じ内容で、はやりの生成AI にスライド作ってって依頼したら Genspark 爆速で作成してくれました。そして自 分が作ったのより有益でした。
39. ご清聴ありがとうございました