組織を意識した AWS構成管理プロセスを考える_20180112

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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する形も多かったりもする

View Slide

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

View Slide

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

View Slide

Let’s share the tips later!!

View Slide

組織を意識したAWS構成管理プロセスを考える_20180112

組織を意識した AWS構成管理プロセスを考える_20180112

kaojiri

More Decks by kaojiri

Other Decks in Technology

Featured

Transcript