2018/01/12、JAWSUG-TOHOKU@仙台での発表資料です。 OpsJAWSとのコラボで実現しました。
組織を意識したAWS構成管理プロセスを考える2018/01/12@JAWS-UG TOHOKU
View Slide
Agenda1. 手軽さ <> 統制2. 組織の壁3. 解決策4. ポイント5. 結果
1. 手軽さ <> 統制• AWSは簡単に構築・修正できる反面、暗黙知が埋没しやすい• ちょっとした修正をしたっきり、誰にも共有してない etc…• このSecurity groupのルールって何?なんで必要なんだっけ?• Infrastructure As CodeとGit flowで解決• SIerにおけるDevOpsの現状 @OPSJAWS #7 2016/07/29https://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!!