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

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

kaojiri
January 15, 2018

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

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

kaojiri

January 15, 2018
Tweet

More Decks by kaojiri

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. Let’s share the tips later!!

    View Slide