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

OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=47 kaojiri
August 01, 2016

OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~

イチ個人の見解であり、所属会社や組織とは関係はありません。

C8b3d5eaa8c8a490a1530b9b5256a2a9?s=128

kaojiri

August 01, 2016
Tweet

Transcript

  1. SIerにおけるDevOpsの現状 ~Terraformを使ったAWS開発~ 2016/07/29 OpsJAWS #7

  2. Agenda 1. 私なりのDevOpsの理解 • DevOpsとは • エンタープライズでDevOpsって…みたいな話 2. Terraformを使ったAWSインフラ開発の紹介

  3. DevOpsとは? • 「開発チーム(Development)と運用チーム(Operations)がお互いに 協調し合うことで、開発・運用するソフトウェア/システムによってビジ ネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ 迅速にエンドユーザーに届け続ける」という概念 • Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割 は“システムの安定稼働”である。そのため、Devが新しい機能を追加した くても、Opsはシステムの安定稼働のために変更を加えたがらない、とい

    う対立構造が作られてしまっていた • 「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr(1日10回以上のデプロイ: Flickrにおける開 発と運用の協力)」
  4. SoE?? SoR?? • スタートアップ、Web系企業 • ビジネスの価値に直結するようなシステム、サイトがほとんど • 細かい機能追加・カイゼンがビジネスに直結していくので、そのサイ クルタイムを短縮することが至上命題 • エンタープライズ(≒基幹系)

    • もともと(事務的な)業務効率を上げるためであり、ビジネスに直結 するようなものではないという性質 • コストカット目的 • デジタル・トランスフォーメーション by 斎藤様
  5. エンタープライズでDevOps? • Web系が積極的に採用した“クラウド”が、エンタープライズへ 浸透していったことで、Web系からバズりだしたDevOpsもエ ンタープライズが興味を示し始めるようになった • 最初は単純移行した基幹システムも、クラウドの進化に合わせ て継続的な最適化が求められるように • Blackbeltでも紹介あり「失敗例を成功に変える

    AWSアンチパターン のご紹介 2016 」 http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-antipattern
  6. DevとOpsの分業制は悪か? • エンタープライズにおけるDevとOpsは別企業であることが多い • しっかりとしたインターフェースを持ち、統率されている分業制は、 それはそれでのDevOps • 安全性が保たれてさえいれば、自動化・効率化がKPIにならない場合 • 求められるサイクルタイムがそんなに早くない場合

    • システムの特性に合わせて、目的に合わせて選択していくべき
  7. • 先日お話させていただきました。※OpsJAWS Meetup#5 • 背伸びをしないAWS構成管理 • https://speakerdeck.com/kaojiri/opsjaws-number-5-20160420-bei-shen-biwosinaiawsgou-cheng-guan-li • ここでは稼働中の安全性を高めるアプローチを紹介 •

    作った環境をどう安全に可視化・維持するか、みたいな話 • 今回は、どうやって作ればいいか?みたいな話
  8. カイゼンの道筋(イメージ) CI/CD DevOps アジャイル (攻めのIT) 画面・手作業系 (とりあえずやってみた) 最初は ここ 理想

    現実路線 ビ ジ ネ ス ス ピ ー ド 安全性 前回 今回
  9. (今回)Devよりな話。安全性とちょっとだけスピードアップを意識 × Tfstate (Staging) Tfstate (Production) Staging Production plan plan

    pull/push pull/push apply + test *.tf , tfvars etc…
  10. Terraform • HashiCorp社が開発した、クラウドっぽい環境に対するオーケスト レーションツール • AWSの他にAzure等のクラウド、OpenStack、VMwareなど十数種 類の環境について統合的に記述可能 • AWSにはCloudFormationが用意されているが、下記点を評価して Terraformを採用

    • 各リソースのidを動的に解決し、さらに変数名で容易に参照出来るなど表現 力の高さ • いわゆるDryRunの機構が優れており、ミスに容易に気づける。多人数で一 つのインフラ環境を構築したり、更新したりする場合に特に安心感が高まる • シェルスクリプトによる運用フローのカスタマイズが容易 • コメントが書ける
  11. Staging Production レビュー Tfstate (Staging) Tfstate (Staging) Tfstate (Production) Pull/Push

    開発者による plan確認 CIによる plan結果 共有 apply+ テスト レビュー 開発者による plan確認 CIによる plan結果 共有 apply+ テスト Tfstate (Production) Pull/Push トピック ブランチ Staging ブランチ Master マージ リクエスト マージ リクエスト マージ マージ
  12. 工夫点 • 変数はtfvarsで • ステージング、本番は変数ファイルだけ入れ替えればOK • tfstateをS3に保管 • 複数人で同じ状態の構成を管理できるように •

    GitLabで管理する方法もあるが、特定のブランチを見続けるのは困難なため、あえてS3で • plan、applyはシェルスクリプトで • 上記stateファイルの自動取得、Up • GitLabにはapplyした後にマージ • Terraformのvalidateだけでは不十分だったり、実際にモノがないとテストできないため • ここをみれば全部書いてありますwww • http://made.livesense.co.jp/entry/2016/07/12/083000
  13. これから • AWS上でインフラを安全に開発して、少しだけ開発スピードを アップできる手法と、それらを維持・可視化するための手法が なんとなく見えてきたので、これらを融合するフローや組織・ 文化を浸透させる!!! • これができ始めると本当のDevOpsのスタート

  14. カイゼンの道筋(イメージ) CI/CD DevOps アジャイル (攻めのIT) 画面・手作業系 (とりあえずやってみた) 最初は ここ 理想

    現実路線 ビ ジ ネ ス ス ピ ー ド 安全性 前回 これから 今回
  15. まとめ • DevとOpsの対立構造を解決するのはツール“だけ“じゃない • エンタープライズにおけるDevOps採用は、求められるサイクルタ イムを鑑みて • とはいうものの、エンタープライズがクラウド浸透してきた以上、避けては 通れない道 •

    Terraformでインフラ周りのCIが可能 • 今後は技術的な話だけでなく、文化を醸成していきたい • 次回をお楽しみに
  16. Let’s share the tips later!!