dockerとdev ops
Post on 14-Apr-2017
174 Views
Preview:
TRANSCRIPT
自己紹介
• 前川博志 a.k.a @Posaune
• もともと老舗メーカでWindowプログラマ⇒ ギルドワークス株式会社所属ALMエンジニア
• Microsoft MVP for Visual Studio ALM
ALM #とは
• Application Lifecycle Management
• アプリケーションの一生を面倒見るお仕事
• どういう課題から、どういう要求が生まれて、それをどう実現し、どう確認し、どう運用し、どう役目を終わらせるか。
• (個人的解釈です)
ALMエンジニアとしての最近
• ギルドワークスの現場コーチ
• 飛び込みCIエンジニアとして主にiOS周りのビルド環境を整備
• CI Serviceにゾッコン中
http://www.slideshare.net/Posaune/jenkinsci-50411288
世は正に大Docker時代!
• Docker コマンドを、今から覚えましょう!
• あらゆるものをコンテナに!軽量コンテナは正義!最高!
• 既存の環境をDockerに乗せさえすれば、インフラの問題は全て解決!
Docker前に知っておきたいこと
• Docker自体は非常に強力なツール
• Dockerを入れることを目的にしても、 充分楽しいし、効果があるように見える
• でも、それだけでは、あまりにもったいないくらい、強力なツール
Dockerを語る、その前に
• Docker単体では、ただのおもしろVM構成ツール(言い過ぎ)
• Dockerを使う文脈は?といわれると、 やっぱりDevOpsですよね!
• というわけで、Dockerを使ってあれやこれやする、DevOpsとはなんなのか見ていきましょう。
ではDevOpsって?
DevOps(デブオプス[1])は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。
Wikipedia先生曰く…
DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、Flickrのエンジニアにより始めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでリリースが可能になる」という発表とともにDevOpsという単語が用いられた。
DevOpsを語る、その前に
• 素早いデプロイを行う、その背景は何なんでしょう?
• それを理解するためには、さらにもう一歩ソフトウェア開発の上流へ踏み込む必要がります。
• さらに、遡上していきますよ。
DepOps本:The Phenix Project
• DevOps版 『The Goal』と言った感じ
• DevOpsだけでなく、更に外側まで視野を広げている。TOC や リーンの考え方もある。
TOC(制約条件の理論)
• ビジネス上、かならず一つ以上の「制約条件
= ボトルネック」となるプロセスが存在する
• 制約条件を強化する・改善する以外の全ての取り組みは、本質的にムダ
• 制約条件を発見し、それを徹底的に活用することで、ビジネスを成功に導く
リーン生産とリーンソフトウェア開発
• リーン生産 ≒ トヨタ生産方式
• ジャストインタイム・ムダを無くす・カイゼンなどのエッセンスを盛り込んだプロダクト生産方式
• それをソフトウェアに取り込んだのがリーンソフトウェア開発
• 多くのアジャイル系開発手法が強い影響を受けている
参考)トヨタ生産方式
• 全員が読むべき、とは思わないけれど、リーン面白い!と思ったなら是非。
• かなりソフトウェア的な脳内変換は必要ですが、トヨタ生産方式とは何を目指しているのかが、よく分かります
• 古典に外れなし。ただし、誤読し易い。
リーンソフトウェア開発
• リーン生産方式の考え方をソフトウェア開発に応用
• 7つの価値:- 無駄をなくす- 品質を作りこむ- 知識を作り出す- 決定を遅らせる
- 速く提供する- 人を尊重する- 全体を最適化する
余分な機能のムダ
• 使われない機能は、どれだけバグがなくても、ムダでしかない
• 余分な仕事、も含む。
• んじゃあ、余分な機能って、どうやって見つけますか?
• 実は作らないと分からない。だから、大きな機能を作ってはいけない。
再学習のムダ
• 覚えたことを、もう一度学習するムダ
• え?じゃあ覚えたこと忘れちゃいけない!よしめちゃくちゃ分厚い仕様書を・・・
• ではなく。なぜ「覚えた」のか。覚えるのではなく、それを「仕組み」にすべき。
タスク切り替えのムダ
• マルチタスクは非常に効率が落ちます
• 何故マルチタスクになるのか?
• それは、複数の仕事を同時に進めているから。
• 何で複数の仕事を同時に進められるの? ⇒ 仕事のどこかに待ちがある
遅れのムダ
• 仕事の遅れではなく、フィードバックの遅れのムダ
• 機能に対するレビューが遅れたり、不具合検知と修正の間が遅れたり、アクション間の遅れが生じるムダ
• フィードバックサイクルを短く、機能単位を小さく、イテレーティブに、が重要となる
欠陥のムダ
• 欠陥がある機能は、当然ムダ。
• 欠陥を0にすることは不可能。最終製品に欠陥が残ってしまうのが問題。
• 品質を作りこむ、という姿勢が重要。
• 特にテストは、自動手動問わず、可能な限り早期に行う。
一番大切なこと
• 世の中にはムダが溢れている
• 開発プロセスで、一番「ムダ」が貯まっているところが、ボトルネックとなる
• ボトルネックを適切に発見し、そのムダを取り除くことで劇的な改善が得られる
これまでのまとめ
• Docker ⇒ DevOps って、何のためにするの?
• というわけで、Phenixから、TOCとリーンについて、さっと解説しました。
• キーワードは、「ムダ」と「ボトルネック」
• ボトルネックを見つけ、そのムダを取り除いていく、そのためのツールとして DevOpsがある
バリューストリームとDevOps
要求ヒアリング 要件リスト入り 要件定義 設計
実装 テスト ステージングデプロイ
受け入れテスト リリースデプロイ リリース!!
3時間 2週間待ち 1週間 1ヶ月
1ヶ月1ヶ月 4時間
1週間 4時間
バリューストリームとDevOps
要求ヒアリング 要件リスト入り 要件定義 設計
実装 テスト ステージングデプロイ
受け入れテスト リリースデプロイ リリース!!
3時間 2週間待ち 1週間 1ヶ月
1ヶ月 1ヶ月 4時間
1週間 4時間
DevOpsが変えない世界
• DevOpsで、いくら1日に10回でも100回でもビルドしても、届けるべき価値がなければ意味が無い
• DevOpsが絡む場所がボトルネックになっていることもあれば、そうでないこともある
• DevOpsだけでは、世界は変わらない!
必要な作戦は?
• DevOpsできることによって、他の工程にもインパクトを与える
• 例えば・・・・- 自動テスト導入でテスト工程を極限まで削る- すばやいフィードバックで要求側を刺激していく- Fail-Safeな変更を実現し、変更のインパクトを小さくする
Dockerとは
• コンテナ技術をベースとした、仮想化技術
• 他のVM系技術と比べ、非常に軽く立ち上がる
• Dockerfileによる構成管理や、各種ホスティングサービスにより、事実上の標準ツールに
• Windowsでも!もうすぐ!
Docker is NOT a new tech !!
• もともとLinuxには、コンテナ化技術は早い段階から組み込まれていた(LXC)
• Dockerのコア技術自体は目新しいものではない(なのでコアなLinuxプログラマーからは叩かれることも)
• では、なんでこんなに流行ってるの?
DockerをDockerたらしめる物
• Dockerfile / Dockerhub による、git ライクなマシン構成管理- プログラムを書くかのように、マシンが作成でき、変更をキャプチャでき、Pushできる
• Dockerhubの仕組みを活用した、フルマネージドのインフラサービス群
- AWS ECS, Docker tutum, Azure Container Service(new!!)
Dockerが実現している世界
• 設定系が非常にプログラマブル(に見える)
• 常に1から構築なので、もはや冪等性いらない
• 母艦としてサーバを幾つか提供すれば、 後は立ちあげたいサービス構成を記述するだけで立ち上がる
• 更新がとても早く、小さくできる。
Dockerがバリューストリームに与えるインパクト• 開発 / ステージング / 本番で、ほとんど同じモノ = コンテナが使用できる⇒ 再学習 / 引き継ぎ のムダがなくなる
• 小さな変更であれば、変更の部分適用ができる⇒本番で変更部分が落ちても、他のコンテナで補完できる。過度なテストを削れる。
Dockerでバリューストリームにインパクトを与えるために• まずはInfra as Code / Config as Code を徹底し、「同じモノ」を定義する
• 全体に影響を与えないような「小さな変更」を積み重ねられるようにする
• 小さな変更による失敗を、大きなエラーにしない
Infra as Code, Config as Code
• Dockerは、Ched / Ansible に比べてコード化は容易。なぜなら冪等性を確保する必要が無いから。
• マシンの構築手順を、素直にコード化すればよい。シェルでいい(もちろんAnsibleとか使ってもいい)
• マシン間のネットワーク等も、簡便にコード化できる(Docker Compose)
失敗をエラーにしない• 巨大な1マシンを作らない(Dockerではつくりづらい)
• 複数のマシンに処理を分散し、変更を一部にのみ適用できるようにする
SV1 SV2 SV3 SV4
LB
CL10回
リトライするよー
SV4
変更サイズを小さくする
• 「失敗をエラーにしない」レベルの変更に、変更サイズを小さくしないと、この話は始まらない
• 一ヶ月分の変更をブルーグリーンとか無理w
• そもそも1日10回デプロイするんだから、1日10個の新機能ができるサイズ感にしないとね!
Dockerで変わること
• システム構成含めたコード化が可能になる。冪等性考えなくていいので、楽。
• うまく組めば、失敗してもダウンタイムなしにできる
• VMとしての起動は、非常に楽になる
• 各クラウドベンダーからの強力サポート
Dockerで変わらないこと
• いくらリリース周りが楽になったとしても、 要件のボリュームは勝手には変わらない
• スケールアウト前提の環境に、Dockerにしたからといって勝手に変わるわけではない
• あなたが変えないと、あなたのプロセスは変わらない
Dockerであなたが変えること
• Docker Readyな、Dockerを活用できるインフラ構成に!
• 1日に10回のリリースが必要とされるような 開発プロセスに!
• フィードバックループを素早く回して、DevOps
がボトルネック外のムダな改善にならないように!
top related