DockerとDevOps -変わること、変わらないこと-@Posaue from .reviewrc （おいしが）

自己紹介

• 前川博志 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を、、、1. 使ってる

2. 触ったことある3. 聞いたことある

4. 聞いたこともない

世は正に大Docker時代！

• Docker コマンドを、今から覚えましょう！

• あらゆるものをコンテナに！軽量コンテナは正義！最高！

• 既存の環境をDockerに乗せさえすれば、インフラの問題は全て解決！

ではなく

Docker前に知っておきたいこと

• Docker自体は非常に強力なツール

• Dockerを入れることを目的にしても、 充分楽しいし、効果があるように見える

• でも、それだけでは、あまりにもったいないくらい、強力なツール

Docker に至るまでの道を一度遡ってみましょう

Agenda: Dockerの遡上• 1. Dockerを語る、その前に

• 2. 改めて、DevOpsとは？

• 3. さて、Dockerとは

• 4. Dockerで変わること・変わらないこと

1. Dockerを語る、その前に

Dockerを語る、その前に

• Docker単体では、ただのおもしろVM構成ツール（言い過ぎ）

• Dockerを使う文脈は？といわれると、 やっぱりDevOpsですよね！

• というわけで、Dockerを使ってあれやこれやする、DevOpsとはなんなのか見ていきましょう。

ではDevOpsって？

DevOps（デブオプス[1]）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。

Wikipedia先生曰く…

DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、Flickrのエンジニアにより始めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでリリースが可能になる」という発表とともにDevOpsという単語が用いられた。

DevOpsとは！

• 開発と運用が協力して！！

• １日１０回以上のデプロイを実現することである！！

• 高頻度のデプロイ！！それが正義！！

なんのために？？？

DevOpsを語る、その前に

• 素早いデプロイを行う、その背景は何なんでしょう？

• それを理解するためには、さらにもう一歩ソフトウェア開発の上流へ踏み込む必要がります。

• さらに、遡上していきますよ。

DepOps本：The Phenix Project

• DevOps版 『The Goal』と言った感じ

• DevOpsだけでなく、更に外側まで視野を広げている。TOC や リーンの考え方もある。

The Goal

• 制約理論（TOC）を分かりやすく物語で語ったビジネス書

• 3ヶ月で工場を立て直す、というサクセスストーリー

TOC（制約条件の理論）

• ビジネス上、かならず一つ以上の「制約条件

= ボトルネック」となるプロセスが存在する

• 制約条件を強化する・改善する以外の全ての取り組みは、本質的にムダ

• 制約条件を発見し、それを徹底的に活用することで、ビジネスを成功に導く

リーン生産とリーンソフトウェア開発

• リーン生産 ≒ トヨタ生産方式

• ジャストインタイム・ムダを無くす・カイゼンなどのエッセンスを盛り込んだプロダクト生産方式

• それをソフトウェアに取り込んだのがリーンソフトウェア開発

• 多くのアジャイル系開発手法が強い影響を受けている

参考）トヨタ生産方式

• 全員が読むべき、とは思わないけれど、リーン面白い！と思ったなら是非。

• かなりソフトウェア的な脳内変換は必要ですが、トヨタ生産方式とは何を目指しているのかが、よく分かります

• 古典に外れなし。ただし、誤読し易い。

リーンソフトウェア開発

• リーン生産方式の考え方をソフトウェア開発に応用

• 7つの価値：- 無駄をなくす- 品質を作りこむ- 知識を作り出す- 決定を遅らせる

- 速く提供する- 人を尊重する- 全体を最適化する

リーンソフトウェア開発 7つのムダ• 未完成な作業のムダ

• 余分な機能のムダ

• 再学習のムダ

• 引き継ぎのムダ

• タスク切り替えのムダ

• 遅れのムダ

• 欠陥のムダ

未完成な作業のムダ

• 「仕掛中」の仕事

• 大量の作業が、宙ぶらりんになっていません？

• コードは、サーバにデプロイされないと、何の価値にもならない。価値が無いことの判断もできない。

余分な機能のムダ

• 使われない機能は、どれだけバグがなくても、ムダでしかない

• 余分な仕事、も含む。

• んじゃあ、余分な機能って、どうやって見つけますか？

• 実は作らないと分からない。だから、大きな機能を作ってはいけない。

再学習のムダ

• 覚えたことを、もう一度学習するムダ

• え？じゃあ覚えたこと忘れちゃいけない！よしめちゃくちゃ分厚い仕様書を・・・

• ではなく。なぜ「覚えた」のか。覚えるのではなく、それを「仕組み」にすべき。

引き継ぎのムダ

• 仕事に対して、「引き継ぎ」が存在することのムダ

• よし、手順書を整備するぞ！！…という話でなく

• 引き継がなくても良いプロセス、設計、仕組みを考える

タスク切り替えのムダ

• マルチタスクは非常に効率が落ちます

• 何故マルチタスクになるのか？

• それは、複数の仕事を同時に進めているから。

• 何で複数の仕事を同時に進められるの？ ⇒ 仕事のどこかに待ちがある

遅れのムダ

• 仕事の遅れではなく、フィードバックの遅れのムダ

• 機能に対するレビューが遅れたり、不具合検知と修正の間が遅れたり、アクション間の遅れが生じるムダ

• フィードバックサイクルを短く、機能単位を小さく、イテレーティブに、が重要となる

欠陥のムダ

• 欠陥がある機能は、当然ムダ。

• 欠陥を0にすることは不可能。最終製品に欠陥が残ってしまうのが問題。

• 品質を作りこむ、という姿勢が重要。

• 特にテストは、自動手動問わず、可能な限り早期に行う。

一番大切なこと

• 世の中にはムダが溢れている

• 開発プロセスで、一番「ムダ」が貯まっているところが、ボトルネックとなる

• ボトルネックを適切に発見し、そのムダを取り除くことで劇的な改善が得られる

バリューストリームマップ

• ソフトウェアの「価値」を届けるまでの流れを記述する方法

• 要求が発生してから、価値を届けるまでにある「ムダ」を発見する

バリューストリームの例

要求ヒアリング 要件リスト入り 要件定義 設計

実装 テスト ステージングデプロイ

受け入れテスト リリースデプロイ リリース！！

ちょっと休憩

これまでのまとめ

• Docker ⇒ DevOps って、何のためにするの？

• というわけで、Phenixから、TOCとリーンについて、さっと解説しました。

• キーワードは、「ムダ」と「ボトルネック」

• ボトルネックを見つけ、そのムダを取り除いていく、そのためのツールとして DevOpsがある

2. では改めて、DevOpsとは

バリューストリームとDevOps

要求ヒアリング 要件リスト入り 要件定義 設計

実装 テスト ステージングデプロイ

受け入れテスト リリースデプロイ リリース！！

３時間 ２週間待ち １週間 １ヶ月

１ヶ月１ヶ月 ４時間

１週間 ４時間

DevOpsが変える世界

• 実装したプログラムが、より早く使えるようになる

• 運用に乗っているプログラムの変更が、気軽に、容易になる

• そう、プログラムさえ完成できれば！

バリューストリームとDevOps

要求ヒアリング 要件リスト入り 要件定義 設計

実装 テスト ステージングデプロイ

受け入れテスト リリースデプロイ リリース！！

３時間 ２週間待ち １週間 １ヶ月

１ヶ月 １ヶ月 ４時間

１週間 ４時間

DevOpsが変えない世界

• DevOpsで、いくら１日に１０回でも１００回でもビルドしても、届けるべき価値がなければ意味が無い

• DevOpsが絡む場所がボトルネックになっていることもあれば、そうでないこともある

• DevOpsだけでは、世界は変わらない！

必要な作戦は？

• DevOpsできることによって、他の工程にもインパクトを与える

• 例えば・・・・- 自動テスト導入でテスト工程を極限まで削る- すばやいフィードバックで要求側を刺激していく- Fail-Safeな変更を実現し、変更のインパクトを小さくする

3. さて、Dockerとは

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が実現している世界

• 設定系が非常にプログラマブル（に見える）

• 常に１から構築なので、もはや冪等性いらない

• 母艦としてサーバを幾つか提供すれば、 後は立ちあげたいサービス構成を記述するだけで立ち上がる

• 更新がとても早く、小さくできる。

4. Dockerで変わること・変わらないこと

Dockerがバリューストリームに与えるインパクト• 開発 / ステージング / 本番で、ほとんど同じモノ = コンテナが使用できる⇒ 再学習 / 引き継ぎ のムダがなくなる

• 小さな変更であれば、変更の部分適用ができる⇒本番で変更部分が落ちても、他のコンテナで補完できる。過度なテストを削れる。

Dockerでバリューストリームにインパクトを与えるために• まずはInfra as Code / Config as Code を徹底し、「同じモノ」を定義する

• 全体に影響を与えないような「小さな変更」を積み重ねられるようにする

• 小さな変更による失敗を、大きなエラーにしない

Infra as Code, Config as Code

• Dockerは、Ched / Ansible に比べてコード化は容易。なぜなら冪等性を確保する必要が無いから。

• マシンの構築手順を、素直にコード化すればよい。シェルでいい（もちろんAnsibleとか使ってもいい）

• マシン間のネットワーク等も、簡便にコード化できる（Docker Compose）

失敗をエラーにしない• 巨大な１マシンを作らない（Dockerではつくりづらい）

• 複数のマシンに処理を分散し、変更を一部にのみ適用できるようにする

SV1 SV2 SV3 SV4

LB

CL10回

リトライするよー

SV4

変更サイズを小さくする

• 「失敗をエラーにしない」レベルの変更に、変更サイズを小さくしないと、この話は始まらない

• 一ヶ月分の変更をブルーグリーンとか無理ｗ

• そもそも1日10回デプロイするんだから、1日10個の新機能ができるサイズ感にしないとね！

バリューストリームを高速で駆け抜ける

要求ヒアリング 要件リスト入り 要件定義 設計

実装 テスト ステージングデプロイ

受け入れテスト リリースデプロイ リリース！！

まとめ

Dockerで変わること

• システム構成含めたコード化が可能になる。冪等性考えなくていいので、楽。

• うまく組めば、失敗してもダウンタイムなしにできる

• VMとしての起動は、非常に楽になる

• 各クラウドベンダーからの強力サポート

Dockerで変わらないこと

• いくらリリース周りが楽になったとしても、 要件のボリュームは勝手には変わらない

• スケールアウト前提の環境に、Dockerにしたからといって勝手に変わるわけではない

• あなたが変えないと、あなたのプロセスは変わらない

Dockerであなたが変えること

• Docker Readyな、Dockerを活用できるインフラ構成に！

• 1日に10回のリリースが必要とされるような 開発プロセスに！

• フィードバックループを素早く回して、DevOps

がボトルネック外のムダな改善にならないように！

Enjoy dev,ops, and everything!!