オライリーの「Infrastructure as Code」を読んで思ったことや自分的メモをまとめておく．太字は自分の感想， 斜字体は本からの引用 ，そのほかは本の要約など．

ツールの要件

• 他のツールを連携しやすいこと
  • コマンドライン引数や環境変数などでの入力，パースしやすい結果出力
  • 設定の外在化
• 自動実行しやすいこと
  • 冪等性など
  • 失敗したらわかる
• 周辺のツールとの連携しやすさは意識して考慮に入れてなかった
• 考え方はすごくよくわかる．UNIX哲学に通じている

構成レジストリ

• コンフィグ定義ツールが提供するもの(Chef Server, Ansible Towerなど)
• Zookeeper/Consul/etcd
• プログラムによるレジストリエントリの追加，更新，削除をサポートしていること
• こういうのほしいと前から思っていたけどどうやって実装すればいいか，定義ツールとどう連携させればいいかイメージついてない

軽い構成レジストリ

• S3やVCS上のファイル
  • HTTP等で配布．こうすることで可用性，スケーリングしやすい．管理が単純
  • 頻繁に更新されて複雑になる部分は分割やシャーディングで対応する
• こうした場合，例えばAnsibleへはどうやって渡せばいいんだろうか
  • ansible-playbook実行前にyaml組んでvar_fileなどに渡す
    • ダイナミックインベントリみたいなことはできなさそう．一回ファイルに吐き出す必要がある？
  • json組み立ててansible-playbookの--extra-varsオプションに渡す
  • Ansible TowerのAPIでも渡せるかも
• Consumer Driven Contract Testing
  • Itamaeのnode.validate!はまさにこれだと思う¹
  • こんな記事出てきた Consumer-Driven Contracts: A Service Evolution Pattern
  • Pactのようなツールで容易に書けそう

CMDB

• CMDBとInfrastructure as Codeは構成管理に対するアプローチが正反対．両者を同一視してはならない
  • ただしすべてを自動化するならInfrastructure as CodeはCMDBを兼ねることができる．またはInfrastructure as CodeがCMDBも管理することができる
  • ハードウェアも含めてすべてを自動化はけっこうハードル高そう

その他

• インフラを完全に管理，自動化するために，やり方を変えるだけでなく自動化しやすいようにタスクそのものを見直すメンタルを忘れてはいけない

以上

参考文献

1. Kief Morris, Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス, 長尾高弘訳, オライリー・ジャパン, 2017

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス amazon.co.jp