今回話すこと
- AWS, GCP, Azureなどクラウドインフラサービスを対象としたInfrastructure as Codeの概要
今回話さないこと
- ChefやAnsibleのようなMutable Infrastructure用ツール(Dockerがある今、利用拡大することないでしょ？)
- Docker周り
IaCツール/サービス
AWS CloudFormation
- JSON / YAML
- IaCの雄
- AWSに住んでいるならこれだけでもそう困らない
- AWSの様々なサービスがこれを使うので避けては通れない
- sam
- beanstalk
- beanstalkのように、独自設定を書いていたら結局実装はCloudFormation Stackできた、というパターンは多い
- 個人的な所感
- 表面から70%ぐらいの用途ではとても快適
- さらに20%ぐらいの用途では結構CloudFormationを理解する必要がある
- そこから5%ぐらいの用途ではCloudFormationに機能が足りずまっとうに使えない
- 奥底、5%ぐらいの用途はまずいコーナーケースでとんでもなく苦労する(削除周りとか)
Google Cloud Deployment Manager
- YAML(jinja)
- CloudFormationのGCP版らしい
- 個人的に使ったことはない
- 影薄い(GCP基盤の会社でも使っているところを聞いたことがない)
Azure Resource Manager
- なんも知らん
Terraform
- HCL (alt-JSON)
- IaCといえばこれ、という評価も
- CFnやCDMと似ているが、プラグインによりクロスクラウドな設定ができる
- 以下あるシステムで設定しているSaaSの一覧
- AWS
- GCP
- DataDog
- PagerDuty
- GitHub
- Kubernetes
- MySQL
- どんだけやんちゃをしてもstateファイルをいじればどうとでもなるし、自分でProvider実装すればこれまたなんとでもなる。OSSなのでツール自体にもプラグインにもPRを送れる。パッチを当ててとりあえず手元でだけ修正して動かすこともできる。自由度の鬼
- 個人的な所感
- 表面から30%ぐらいはそこそこ快適
- そこから20%ぐらいでクソやばい問題にぶち当たる(applyの同時実行とか、手動変更後のapplyとか)
- そこから30%ぐらいでstate mv, importなどで大抵のことができるようになる
- さらに10%ぐらいで手動state編集など事実上出来ないことがなくなる
- 最後10%、自分でproviderを書き始める
ちなみに
サードパーティサービスはある日突然公式にはしご外されることがあるので(e.g. Travis CI)、僕は多少不便でもオフィシャルのソリューション使っておけ派です。
が、Terraformとserverless frameworkはそれぞれAWS公式の競合があるにも関わらずAWS DevOps Professional / Solution Architect Professionalの試験に出てきたので、少なくとも直近潰されるようなことはないのかなと思っています。
Pulumi(プルミ)
- JavaScript, TypeScript, Python, Go
- 2018年ぐらい、Next Terraformとして鳴り物入りで登場
- 結局その後ほとんど見ない
- 個人利用以外は有償
- Cloudサービス前提
- 個人的な所感
- ビジネスモデルに無理を感じる
- TerraformがOSSコミッターの力を借りてかつ一番メンテナンス状態の良いAWS providerでさえあのクオリティなのに、1私企業が様々なクラウドサービスの機能を社内エンジニアリングリソースのみで迅速にキャッチアップしていくのはどう考えても無理。品質かサポート範囲のどちらかが犠牲になる
AWS Cloud Development Kit
- TypeScript、JavaScript、Python、Java、C#/.NET
- Pulumiと同じ系統
- 最終的にCloudFormationへコンパイルされる
- 個人的な所感
- 2016年頃、CloudFormationの柔軟性のなさに嫌気が差してkumogata/kumogataというツールを使い倒していた。これはCloudFormationをRuby DSLで書くというもので、僕にはCDKはkumogataのAWSオフィシャル版に見える
- 楽しそうだが、コンパイル結果がCloudFormationなので結局AWS外を定義できない。またCloudFormationの知識も必要になる。欠点が多い
Kubernetes Service Catalog
- YAML
- Kubernetesを使ってAWSなどクラウドインフラリソースを管理する仕組み
- 野心的で未来を感じるが、クラウド間の移行もしやすくなるためかawsが対応に全然乗り気ではなさそう
- 個人的な所感
- Kubernetesは明らかに確定した未来なので、これが将来普及する可能性も高い
- 実用段階になるまで注視したい
- あるいは実用状態になる前に別のソリューションが出てくる可能性もある
番外: Kubernetes
- YAML
- Operatorと呼ばれるプラグインを通じて外部のクラウドインフラリソースを部分的に操作できるる
- ELB
- Route53
- 前述の通り、さらにそれを汎用化したService Catalogはまだ未成熟
まとめ
- 2021/09現在、とりあえずTerraformやっておけばOK
- AWSが主戦場のエンジニアはCloudFormationも必須。CFnが最低限使えないエンジニアは使えるAWSサービスが限定される
蛇足
2015 - 2021年、Infrastructure as Codeは明らかに
- 宣言的なリソース定義
- それを処理してよしなに実態リソースを作るプラグイン
- 宣言的なリソース定義をコンパイルするツール
へ向かっている(参考: Infrastructure as Dataとは何か | Taichi Nakashima)
| ツール | リソース定義 | プラグイン | コンパイル前 |
|---|---|---|---|
| Kubernetes | YAML manifest | Operator | Kpt, Kustomize, Jsonnet, cue, ... |
| Terraform | HCL | Provider | Terraform自体 + HCL |
Terraformがイケていないところを一つ上げるとすれば、リソース定義とそのコンパイルツールがTerraformという一つのツールで賄っていること。これによりコンパイル手段の多様性が失われ、同時にTerraformの実装が複雑になる要因にもなっている。
Terraformの後継が出るとしたら、ここを解決するものではないかと思う