Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=47 kaojiri
January 15, 2018

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

2018/01/12、JAWSUG-TOHOKU@仙台での発表資料です。
OpsJAWSとのコラボで実現しました。

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=128

kaojiri

January 15, 2018
Tweet

Transcript

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

  2. Agenda 1. 手軽さ <> 統制 2. 組織の壁 3. 解決策 4.

    ポイント 5. 結果
  3. 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
  4. 2. 組織の壁 (顧客)構成管理はどうしてる?効率化・自動化してるのか? (私) はい。Infrastructure As Codeってやつです (顧客)パラメーターシートを見せろ (私) プロビジョンコードに対するinputファイル(JSON)があるので、

    それで管理してます (顧客)俺はプログラムは読めん。JSON?なんだそれ? パラメーターシートはないんか? (私) …… (顧客)プログラムのinputと環境が一致してるのは当然だ。 パラメーターシートとの整合性を取りなさい (私) ……
  5. 3. 解決策 ~ツール作成~ • 所定のルールに則ったJSONを入力とし、以下を自動生成 • terraformプロビジョンコード • awspecテストコード •

    EXCELパラメーターシート
  6. 3. 解決策 ~ツールイメージ~ JSON .tf _spec.rb .xlsx プロビジョン後に リソースIDに変換

  7. 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する形も多かったりもする
  8. 4. ポイント • 全ての変更をJSONで行い、ツール経由で生成・更新する • EXCELはViewerとしてのみ利用し、編集させない

  9. 5. 結果 • 全ての成果物と実環境の整合性が保たれるようになった • 各自が見たい成果物で状況確認可能に • 自分たちで好きにできるならJSONが正でよいが、コードという単語にアレルギーを もつ顧客が多い(主観) •

    たしかにViewerとしてのEXCELは秀逸 • 顧客も納得 • エンジニアのエゴを貫き、組織に対して波風立てるより、 うまく乗り越えられる部分は、乗り越え方が後々よい関係が築ける
  10. Let’s share the tips later!!