Mais conteúdo relacionado
OpsJAWS#5 背伸びをしないAWS構成管理 2016/04/20
- 3. よくあるケース:クラウド採用したけど…
• やってはみたものの、しばらく経つと…
• 今本当にこのパラメーターで動いてる?
• ルール決めたつもりだけど、いつの間にか誰かが設定変更してる 等…
• いざ何かやろうとしたときにリスクを積んじゃう → 高コスト体質…
• 故に気が乗らない…(今動いているものを変えて何かあったら…)
• 体制・文化の問題
• (開発)インフラよりの設定変える必要があるけど、リリース後は触れない…
• (運用)APへの影響が分からないから…
• カイゼンへの障壁
• いわゆる”保守”の品質(効率性・安全性)が上がらない
• 運用と保守の違い
• 運用:日々システムを動かすこと、現行維持、改善の根拠となる情報収集 → いわゆる現状維持
• 保守:より良いサービスを提供し信頼を担保し続けるための活動 → いわゆるカイゼン
- 6. AWS Config を使ってみる
• AWS-Config snapshotで全体構成の管理
• 定期的にsnapshotを取得しておく
• jsonのままだとお客さんや運用は見ないので、EXCEL化する
確認
顧客
顧客環境
AWS Config
AWS Config
Snapshot
(json)
Excel生成
AWS構成
パラメーターシート
Lambda function
Snapshot
取得
本番環境
複製環境
+
Ops
複製
- 7. AWS Config snapshot活用のPoint
• 差分が取れるようにするには最初も大事
• ソースコード化はやっておく。もちろんバージョン管理も
• 前述のEXCELのフォーマットにパラメーターを埋めてプロビジョン
• rspecやserverspec、awspecでテスト
• 何がうれしいか?
• 今の状態が”見える”
• 当初構築した環境との違いが”見える”
• 維持したいVerとの差。Rspec/serverspec定期実行で自動検知もできる
• 環境複製、復旧する際に必要な最新パラメーターが常に信頼できる
• AWSのサービスが使える → 安全!!!
• 残念なところ
• 対応リソースが少ない…
- 8. まとめ
• 安全性を高めるところから始める
• DevOpsへの道はインフラコード化&Ver管理から ※所説あります
• インフラリソースをバージョン管理できるのはクラウドのメリット
• AWS-Config snapshotを使えば、全体構成をjsonで取得可能
• AWSは始めやすい!!
• エンジニアレベルで始めてから組織を巻き込んでいくアプローチ
• Tips集めて実績つくる
• ここで認めてもらえると、体制や文化的な改革も軌道に乗せやすい
• DevOps(右上)への道が開ける!!!
+