Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
組織を意識したAWS構成管理プロセスを考える_20180112
Search
kaojiri
January 15, 2018
Technology
0
800
組織を意識した AWS構成管理プロセスを考える_20180112
2018/01/12、JAWSUG-TOHOKU@仙台での発表資料です。
OpsJAWSとのコラボで実現しました。
kaojiri
January 15, 2018
Tweet
Share
More Decks by kaojiri
See All by kaojiri
コンテナ監視って何見るの?~初心者編~
kaojiri
8
5.8k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
1.1k
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
79
JAWS-UG_SAITAMA_20190420
kaojiri
1
200
OpsJAWS-JAWSUG-KANAZAWA_20181123
kaojiri
1
300
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.7k
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.9k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.2k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
3k
Other Decks in Technology
See All in Technology
ゼロからはじめる採用広報
yutadayo
3
980
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
970
品質と速度の両立:生成AI時代の品質保証アプローチ
odasho
1
390
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
420
データ基盤からデータベースまで?広がるユースケースのDatabricksについて教えるよ!
akuwano
3
130
American airlines ®️ USA Contact Numbers: Complete 2025 Support Guide
airhelpsupport
0
390
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
3
7.4k
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
120
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
6
13k
OSSのSNSツール「Misskey」をさわってみよう(右下ワイプで私のOSCの20年を振り返ります) / 20250705-osc2025-do
akkiesoft
0
170
Claude Code に プロジェクト管理やらせたみた
unson
6
4.5k
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
180
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Building an army of robots
kneath
306
45k
The Invisible Side of Design
smashingmag
301
51k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Music & Morning Musume
bryan
46
6.6k
How to Ace a Technical Interview
jacobian
278
23k
We Have a Design System, Now What?
morganepeng
53
7.7k
Producing Creativity
orderedlist
PRO
346
40k
Code Reviewing Like a Champion
maltzj
524
40k
A designer walks into a library…
pauljervisheath
207
24k
Documentation Writing (for coders)
carmenintech
72
4.9k
Transcript
組織を意識した 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!!