木曜日に Codenize Meetup に参加してきた．Codenize.tools には様々なツールがあって，有名なものだと Roadworker（Route 53 の設定をコード化） / Piculet（セキュリティグループの設定をコード化） / Miam（IAM の設定をコード化）など．タイミング良く Roadworker と Piculet を検証していたので， 実際に運用で Codenize.tools を活用している現場の話を聞いてみたく，抽選も当たって参加できて良かった．
cloudinfra-audio に Codenize.tools 開発者の @sgwr_dts さんが出てて，Roadworker を作ることになった背景とか，裏話っぽいことが聞けるので良い！オススメ！
Infrastructure as Code とは何かそして何であるべきか
Recruit Technologies Open Lab 勉強会で知って，読もう読もうと思いながら積読したままになっている “ Infrastructure as Code 本” の紹介だった．来年3月頃には日本語訳で出版される予定があるらしく，頑張って読むか，日本語訳の出版を待つか，悩ましいところ．オライリーで関連する本だと “Effective DevOps 本” もあるし，"Site Reliability Engineering 本“ もあるし，読みたい本が多すぎる．
- ダイナミックインフラストラクチャにより顕在化した問題
- サーバスプロール
- 構成ドリフト
- スノーフレークサーバ
- 脆弱なインフラ
- オートメーション恐怖症
- システム疲労
「スノーフレークサーバ」と「オートメーション恐怖症」の話は凄く考えさせられた．「スノーフレークサーバ」とは他のサーバと構成／設定が異なるサーバのことで，一時的な障害対応や検証などにより，手動で適用されたまま戻し忘れた設定が残ってしまったり，適用後に Chef などのプロビジョニングツール側のメンテナンスを忘れてしまうなどの状況のことを言う．そうなってしまうと，いざ自動化するときに一部のサーバでエラーになったりして，さらにそのエラーが致命的だと障害になってしまうため，自動化することに不安を感じてしまう「オートメーション恐怖症」に繋がる．今の現場でも最近まで「スノーフレークサーバ」が大量にあって，同じロールなのに全然構成が違ったりもした．Chef 管理を徹底して，ロールを分割して，Serverspec でテストをして，フローを抜本的に見直したことで今はほぼ解消していて，安定的な運用ができている．
- Infrastructure as Code の原則
- 簡単に再現できるシステム
- 使い捨てにできるシステム
- 統一的なシステム
- 反復可能なシステム
- 変更しやすいデザイン
再現可能なことは本当に重要だと思う．Chef を書くときは常に冪等性を意識して，どんな状態でも同じ結果が得られるようにしているし，ビジネス要求の変化によって迅速にインフラ構成も変更する必要があるため，より重要な要素となる．他にも自動化だけではなく，システムを深く理解して継続的に変更を加えられるように「人間中心設計」を意識することも重要という話があった．
Hashをめぐる冒険
- Codenize.tools のポリシー
- ステートを持たない
- エクスポートできること
- 管理コンソールで設定したいこともある
- コード化の意義
- テキストで状態を管理する
- 冪等性
- 設定を動的に行う
- データ記述言語 DSL (JSON / YAML / TOML)
- 汎用言語 DSL (Ruby)
- CI ツライ
既に運用中のシステムに導入することを考えると，Codenize.tools にエクスポート機能（+ 冪等性）があるのは重要だと思う．ただ Roadworker の template 機能などは一度使ってしまうと，エクスポートできなくなるため，そこは運用フローもセットで考えて，適材適所に使うという感じになるなと思った．コード化に関しては，やはり表現力の高さと記述量の省略を考えて Ruby などの汎用言語が良いのではないかなと思っているし，だからこそ Codenize.tools が流行ってるんだと思う．
CI ツライのはよくわかる．最近 Roadworker にプルリクを送る前にローカルで RSpec を流したら，個人用ドメイン設定が全て消えて，焦った話も今となっては昔の話．モックも再現性の問題はあるだろうけど，AWS 側で何かしら用意してもらえると CI の幅も広がりそう．
Sustainable Operation
- 個人に依存するノウハウは基本的に受け継がれない
- コード化することによって，知識量の差があったとしても，似たように書けば適用できる
- 知識のグラデーションを許容する
- インフラエンジニアの仕事はオペレーションからフローの構築に移っていく
- 継続できる環境を作ることが重要
凄く良い話だった．インフラエンジニアの仕事を権威的に守るのではなく，コード化することによってインフラエンジニア以外にも理解できる形で共有して，継続的に変更ができることに価値があるという内容だった．そして今後のインフラエンジニアの強みは継続的なオペレーションを実現するフローの構築，そして自動化ツールなどに対する深い理解で，オペレーションを行うことではないんだなと感じた．
クラメソ流 Codenize Tools 活用術
- Piculet でエクスポートした後に Ruby スクリプトで IP アドレスを独自の名前（オフィスの拠点名など）に変換する運用をしている
- オペレーションチーム専用の社内試験がある
- フェーズ 3 で Piculet を使ったテストなどがある
どんな社内試験なんだろう！受けてみたいなーと思った．
あと Piculet でグループ名が ["111111111111", "sg-11111111"] のような形式になってしまうという話は僕も同じく経験した．そのときに調べた限りだと，IAM ポリシーで iam:GetUser を許可する場合と許可しない場合で形式が違ったので，許可するようにして回避した．
www.slideshare.net
kumogata-template の紹介
- Kumogata フルサポート
- DSL をさらに簡略化して書くことができる Gem
- 今後 Kumogata2 に切り替える
www.slideshare.net
Roadworkerではじめる大量DNS移行
- 事故を防ぐ Tips
- direnv を使ってクレデンシャルを管理する
- ドメインごとにディレクトリを分けることで -f オプションなど副作用のあるコマンドも安心感が得られる
terraform の運用で消耗してる話(そして codenize で助けて欲しい話)
- Terraform を運用していると予想外の変更が発生する場合がある
- リソースが再作成されてしまう
- 管理コンソールで一時的な変更をしたままにしてしまうと次の実行でその変更が消えてしまう
terraform planの結果を見極めることが重要
まぁ Terraform だけじゃなく CloudFormation も同様にそういう場面はあると思うし，例えば Piculet も管理コンソールから修正不可能な「グループ名」などを修正すると再生成になったりはする（インスタンスとの依存はチェックしてくれるけど）．ツールの挙動を深くまで理解してないと，使うの怖いよなぁ…という印象がある．発表者の恩田さんが書いた記事を読んだときに良い事例だなと思ったのと同時に，もし Terraform 使うなら既に Terraform の運用経験のある人がいてくれると安心感があるなーと思ったりしていた．
（資料はまだ公開されてなさそう）
まとめ
Codenize.tools だけではなく，実践的な Infrastructure as Code の話が聞けて良かった．積極的に導入していきたい．
