組織を意識した AWS構成管理プロセスを考える 2018/01/12 ＠JAWS-UG TOHOKU 

Agenda 1. 手軽さ <> 統制 2. 組織の壁 3. 解決策 4. ポイント 5. 結果 

1. 手軽さ <> 統制 • AWSは簡単に構築・修正できる反面、暗黙知が埋没しやすい • ちょっとした修正をしたっきり、誰にも共有してない etc… • このSecurity groupのルールって何？なんで必要なんだっけ？ • Infrastructure As CodeとGit flowで解決 • SIerにおけるDevOpsの現状 @OPSJAWS #7 2016/07/29 https://speakerdeck.com/kaojiri/opsjaws-number-7-20160729-sierniokerudevopsfalsexian-zhuang-terraformwoshi- tutaawskai-fa 

2. 組織の壁 （顧客）構成管理はどうしてる？効率化・自動化してるのか？ （私） はい。Infrastructure As Codeってやつです （顧客）パラメーターシートを見せろ （私） プロビジョンコードに対するinputファイル(JSON)があるので、 それで管理してます （顧客）俺はプログラムは読めん。JSON？なんだそれ？ パラメーターシートはないんか？ （私） …… （顧客）プログラムのinputと環境が一致してるのは当然だ。 パラメーターシートとの整合性を取りなさい （私） …… 

3. 解決策 ～ツール作成～ • 所定のルールに則ったJSONを入力とし、以下を自動生成 • terraformプロビジョンコード • awspecテストコード • EXCELパラメーターシート 

3. 解決策 ～ツールイメージ～ JSON .tf _spec.rb .xlsx プロビジョン後に リソースIDに変換 

3. 解決策 ～採用技術根拠を少し～ • Why Golang • クロスコンパイル環境が提供されている • Artifactは1バイナリ―ファイルなので、利用開始までのハードルが低い • Why JSON • JSONは構造が規定されているので、EXCELのように行や列の使い方などのルールを設ける必要がな く、作業の標準化が可能 ※ EXCELフォーマットのバリデーションチェックに忙殺されたくなかったのが本音 • Why terraform • スタックテンプレート(.tf)を複数分割してもパラメーターの受け渡しが可能 • Dry run(plan)や差分実行がやりやすい • plan結果もgit flowでレビュー可能 • Why awspec • スモールスタートする際に極力イチからつくるのは避けたかったから • ぶっちゃけ、未対応リソースやプロパティがあったりして、awspecではカバーしきれない部分あり、 aws sdk for rubyでdescribeする形も多かったりもする 

4. ポイント • 全ての変更をJSONで行い、ツール経由で生成・更新する • EXCELはViewerとしてのみ利用し、編集させない 

5. 結果 • 全ての成果物と実環境の整合性が保たれるようになった • 各自が見たい成果物で状況確認可能に • 自分たちで好きにできるならJSONが正でよいが、コードという単語にアレルギーを もつ顧客が多い（主観） • たしかにViewerとしてのEXCELは秀逸 • 顧客も納得 • エンジニアのエゴを貫き、組織に対して波風立てるより、 うまく乗り越えられる部分は、乗り越え方が後々よい関係が築ける 

Let’s share the tips later!!