マイクロサービス時代の生存戦略 with HashiCorp
•
29 likes•5,773 views
発表資料 2015年11月27日(金) #devopsjp DevOps/マイクロサービスセミナー ～導入事例から考える、マイクロ サービスを実現するコンセプトと技術～ 会場：マイクロソフト@品川 http://connpass.com/event/22027/
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to マイクロサービス時代の生存戦略 with HashiCorp
Similar to マイクロサービス時代の生存戦略 with HashiCorp (20)
More from Masahito Zembutsu
More from Masahito Zembutsu (20)
マイクロサービス時代の生存戦略 with HashiCorp
- 1. @zembutsu Nov 27, 2015 Our Survival Strategies, Microservices, and HashiCorp DevOps/マイクロサービスセミナー ～導入事例から考える、マイクロ サービスを実現する コンセプトと技術～ at マイクロソフト@品川
- 2. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 @zembutsu Nov 27, 2015 Our Survival Strategies, Microservices, and HashiCorp 今日の内容 ‣ 1. 生存戦略――Microserviceの課題 ‣ 2. "技術"ではなく、"ワークフロー"が真の課題 ‣ 3. HashiCorpは何を解決するのか？ ‣ ツール概要 ‣ Nomad は Docker 等のスケジューラ ‣ Otto は Vagrant の後継ソフト
- 3. 3 自己紹介 ‣ @zembutsu a.k.a. 前佛雅人 - Technology Evangelist; Creationline, Inc. – 2 yrs - Data Center Operations Engineer – 15+ yrs 興味関心：運用監視自動化、趣味でOSSやクラウド系の検証・情報発信 - SlideShare http://slideshare.net/zembutsu - Blog http://pocketstudio.jp/log3 書籍・記事 - Serf/Consulで管理を自動化！ (Gihyo.jp) http://gihyo.jp/admin/feature/01/serf-consul - HashiCorpのツール群からみる インフラ構築運用の未来 (Think IT) http://thinkit.co.jp/book/2015/03/05/5700 Why am I here? +MasahitoZembutsu ISBN-10: 4844339265 ISBN-10: 4774174416 ISBN-10: 4798139785 役職的にはテクノロジー・エバン ジェリストではありますが、基本 となったのは、データセンタでの 運用経験だと思っています。
- 4. Software Design 12 月号 第一特集 「Docker自由自在」に 寄稿の機会をいただきました。 最近、こんな所で寄稿の機会を いただきました。もしDockerに ご興味をお持ちであれば、コン パクトに情報をまとめますので、 是非どうぞ！
- 8. 当然、コンテナも炎上し…
- 14. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 @zembutsu Nov 27, 2015 Our Survival Strategies, Microservices, and HashiCorp 今日の内容 ‣ 1. 生存戦略――Microserviceの課題 ‣ 2. "技術"ではなく"ワークフロー"が真の課題 ‣ 3. HashiCorpは何を解決するのか？ ‣ ツール概要 ‣ Nomad は Docker 等のスケジューラ ‣ Otto は Vagrant の後継ソフト さて、改めて今日の内容です。
- 15. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 @zembutsu Nov 27, 2015 Our Survival Strategies, Microservices, and HashiCorp 生存戦略 せ い ぞ ん せ ん り ゃ く
- 16. 生存 戦略 せ い ぞ ん せ ん り ゃ く 生物が生命を持ち続けること。 Life 一般的には特定の目標を達成するために、 長期的視野と複合思考で力や資源を総合 的に運用する技術・科学である Strategy
- 17. 生存 戦略 せ い ぞ ん せ ん り ゃ く 生物が生命を持ち続けること。 Life 一般的には特定の目標を達成するために、 長期的視野と複合思考で力や資源を総合 的に運用する技術・科学である Strategy
- 18. 生存
- 19. 生存 戦略 M i c ro s e r v i c e s マイクロサービス HashiCorp
- 20. Survive ■□□
- 24. 水 金 地 月 火 木 土 天 冥 海 Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune 例えば、何を連想されますか？
- 25. 水 金 地 月 火 木 土 天 冥 海 Mercury Venus Earth Moon Mars Jupiter Saturn Uranus Pluto Neptune コンピュータ資源が 貴重だった時代 コンピュータ資源が 空気のような時代 物理サーバ PC 仮想サーバ クラウド コンテナ ← New! IoTデバイス ← New! ホスト名
- 31. Microservices
- 33. たったひとつの冴えたやりかた The Only Neat Things to Do
- 34. たったひとつの冴えたやりかた The Only Neat Things to Do そんなの、有りえません。
- 36. 人でスケールする時代の終焉
- 39. モンキーレンチ Adjustable wrench めがねレンチ box-end wrench ラチェットレンチ Ratchet wrench スパナ Open-end wrench コンビネーションレンチ chrome-vanadium wrench
- 41. たとえば
- 52. 生存 戦略 M i c ro s e r v i c e s マイクロサービス HashiCorp
- 53. 目標 まず、目標があって、
- 58. 生存 戦略 M i c ro s e r v i c e s マイクロサービス HashiCorp
- 60. HashiCorp ■■□
- 61. 61 HashiCorp “Powering the software-managed datacenter.” ‣ 2012年設立 Mitchell Hashimoto氏が2010年に開発・発表したVagrantが前身 ‣ データセンタ管理に革命をもたらす目的 仮想・物理・コンテナ・クラウド等を組みあわせる状況、その時に生まれる溝を埋めるものを提供 ‣ オープンソースで開発過程が公開 設立以後も、コードが公開されているだけでなく、GitHub・IRC で誰でも意見表明できる
- 62. 62 ‣ 技術ありきではなく、どのように実現するか？ 最も簡単にするためのワークフローを考え、そこに対応するツールが無ければ作るという設計思想 ‣ 単純・モジュール型・組みあわせ可能 Unix哲学と同様、全体の問題を解決するのではなく、個々の要素（コンポーネント）に分解 ‣ コードで管理・弾力的システム・実用主義 システムや基盤に対するバージョン管理や自動化によって、システムにとっても人にとっても利点となる The Tao of HashiCorp ※参考：The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/
- 64. 「品質」＝「速さ」×「正確さ」
- 68. vagrant up packerbuild terraform apply
- 69. otto dev otto build otto deploy
- 70. オープン ソース Web インター フェース セキュリ ティ CLI 共同作業 管理機能コア機能 Git GitHub Otto Atlas
- 72. Nomad 分散スケジューラ Distributed Scheduler デプロイを簡単に Easily Deploy Applications ジョブの詳細設計 Job Specification
- 73. コンテナ化 Containerized 仮想化 Virtualized スタンドアローン Standalone Docker Qemu / KVM Java Jar バイナリの実行 Nomad対応環境
- 74. Nomad アプリのデプロイ Application Deployment Dockerコンテナ対応 Docker 柔軟なワークロード Flexible Workloads リソースを最大限に集約 Bin Packing HCLによるジョブ定義 HCL Job Specifications
- 75. 75 ‣ マイクロサービスのプラットフォーム MicroservicesやSOAはアプリケーションの設計が複雑化しているが、その基盤としてNomadを使う ‣ パブリック・クラウドへのデプロイ マルチリージョン＆マルチデータセンタ機能により、複数のクラウド環境、物理環境を併用できる ‣ ECサイト 長期間稼働するウェブサービスやバッチ処理のバックエンドにおいて、 あらゆるワークロードをクラスタで共有するので、稼働率の向上やコスト削減につながる 使用例の一部
- 76. 76 Nomad Amazon ECS Dockre Swarm HTCondor Kubernetes Mesos with Aurora,Marathon Terraform Hadoop YARN ツールの役割 クラスタ管理とスケ ジューラ EC2に対応したクラス タ・マネージャ Dockerコンテナ向け のクラスタリング・ソ リューション グリッド/コンピュー ティング環境における バッチ処理 Dockerを基盤とした クラスタ管理、スケ ジューリング、サービ ス・ディスカバリ、管 理、シークレット管理 リソースマネージャと、 フレームワークと組み あわせたスケジューリ ングやジョブ管理 インフラ環境の自動 的な構築・変更と、 バージョン管理 リソース管理とジョブ スケジューリング クラスタ管理対象 あらゆる環境 AWSのみ Docker コンテナのみ あらゆる環境 Docker コンテナ あらゆる環境 あらゆる環境 あらゆる環境 対応環境 パブリッククラウド ○ △ ○ ○ ○ ○ ○ ○ プライベートクラウド ○ × ○ ○ ○ ○ ○ ○ 仮想化環境 ○ × ○ ○ ○ ○ ○ ○ 物理サーバ ○ × ○ ○ ○ ○ ○ ○ リソース管理 ○ ○ ○ × ○ ○ △ ○ ジョブの抽象化 ○ ○ × ○ ○ ○ × ○ アプリケーションの実行 ○ ○ ○ × ○ ○ × △ 可用性 ○ ○ △ × ○ ○ △ ○ スケーラビリティ ○ ○ ○ ○ ○ × ○ ○ マルチ・データセンタ ○ × × × × × ○ × Nomad vs. スケジューラ 参考：Nomad vs. Other Software - Nomad by HashiCorp https://nomadproject.io/intro/vs/index.html
- 77. サーバ (リーダー) サーバ (フォロワー) サーバ (フォロワー) クライアント クライアント クライアント RPC RPC RPC レプリケーション レプリケーション 転送 転送
- 78. 78 ‣ セットアップ Nomad の使い方 $ cd /tmp $ wget -O nomad.zip https://dl.bintray.com/mitchellh/nomad/nomad_0.1.2_linux_amd64.zip $ unzip nomad.zip $ sudo mv nomad /usr/bin/nomad $ sudo chmod 755 /usr/bin/nomad $ sudo mkdir /etc/nomad.d $ sudo 757 /etc/nomad.d
- 79. zem@dev:~$ sudo nomad agent -dev ==> Starting Nomad agent... ==> Nomad agent configuration: Atlas: <disabled> Client: true Log Level: DEBUG Region: global (DC: dc1) Server: true ==> Nomad agent started! Log data will stream in below: 2015/10/08 23:02:28 [INFO] serf: EventMemberJoin: dev.docker.jp.global 127.0.0.1 2015/10/08 23:02:28 [INFO] nomad: starting 1 scheduling worker(s) for [service batch _core] 2015/10/08 23:02:28 [INFO] raft: Node at 127.0.0.1:4647 [Follower] entering Follower state
- 80. zem@dev:~$ nomad node-status ID DC Name Class Drain Status 2b4b3259-f143-2abf-46d4-62905268263e dc1 dev.docker.jp <none> false ready zem@dev:~$ nomad server-members Name Addr Port Status Proto Build DC Region dev.docker.jp.global 127.0.0.1 4648 alive 2 0.1.2 dc1 global
- 81. # There can only be a single job definition per file. # Create a job with ID and Name 'example' job "example" { # Run the job in the global region, which is the default. # region = "global" # Specify the datacenters within the region this job can run in. datacenters = ["dc1"] # Service type jobs optimize for long-lived services. This is # the default but we can change to batch for short-lived tasks. # type = "service" # Priority controls our access to resources and scheduling priority. # This can be 1 to 100, inclusively, and defaults to 50. # priority = 50 # Restrict our job to only linux. We can specify multiple # constraints as needed. constraint { attribute = "$attr.kernel.name" value = "linux" } # Configure the job to do rolling updates update { # Stagger updates every 10 seconds stagger = "10s" # Update a single task at a time max_parallel = 1 } # Create a 'cache' group. Each task in the group will be # scheduled onto the same machine. group "cache" { # Control the number of instances of this groups. # Defaults to 1 # count = 1 # Define a task to run task "redis" { # Use Docker to run the task. driver = "docker" # Configure Docker driver with the image config { image = "redis:latest" } # We must specify the resources required for # this task to ensure it runs on a machine with # enough capacity. resources { cpu = 500 # 500 Mhz memory = 256 # 256MB network { mbits = 10 dynamic_ports = ["6379"] } } } } } zem@dev:~$ nomad init Example job file written to example.nomad
- 83. zem@dev:~$ nomad run example.nomad ==> Monitoring evaluation "88fc77ac-d878-b27f-925c-c0e131658ac6" Evaluation triggered by job "example" Allocation "1170083d-dd2c-92ec-1e29-44f25eb3de75" created: node "2b4b3259-f143-2abf-46d4-629 05268263e", group "cache" Evaluation status changed: "pending" -> "complete" ==> Evaluation "88fc77ac-d878-b27f-925c-c0e131658ac6" finished with status "complete" 2015/10/08 23:59:57 [DEBUG] driver.docker: docker pull redis:latest succeeded 2015/10/08 23:59:57 [DEBUG] driver.docker: using image 2f2578ff984f013c9a5d6cbb6fe061ed3f73… 2015/10/08 23:59:57 [INFO] driver.docker: identified image redis:latest as 2f2578ff984f013c… 2015/10/08 23:59:57 [DEBUG] driver.docker: using 268435456 bytes memory for redis:latest 2015/10/08 23:59:57 [DEBUG] driver.docker: using 500 cpu shares for redis:latest 2015/10/08 23:59:57 [WARN] driver.docker: no mode specified for networking, defaulting to bridge 2015/10/08 23:59:57 [DEBUG] driver.docker: using bridge as network mode 2015/10/08 23:59:57 [DEBUG] driver.docker: allocated port 128.199.223.107:44054 -> 6379 (mapped) 2015/10/08 23:59:57 [INFO] driver.docker: created container ca2c4efd37e4c5dee82da48fce248e… 2015/10/08 23:59:57 [INFO] driver.docker: started container ca2c4efd37e4c5dee82da48fce248e… zem@dev:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ca2c4efd37e4 redis:latest "/entrypoint.sh redis" 49 seconds ago Up 49 seconds 128.199.223.107:44054->6379/tcp desperate_mayer
- 84. zem@dev:~$ nomad status example ID = example Name = example Type = service Priority = 50 Datacenters = dc1 Status = <none> ==> Evaluations ID Priority TriggeredBy Status 88fc77ac-d878-b27f-925c-c0e131658ac6 50 job-register complete ==> Allocations ID EvalID NodeID TaskGroup Desired Status 1170083d-dd2c-92ec-1e29-44f25eb3de75 88fc77ac-d878-b27f-925c-c0e131658ac6 2b4b3259-f143-2abf- 46 d4-62905268263e cache run running
- 85. zem@dev:~$ nomad run example.nomad ==> Monitoring evaluation "8a72b095-79fc-f521-acea-463fd049d36c" Evaluation triggered by job "example" Allocation "5f4dfa20-ed30-18fb-9a18-300a374f2eac" created: node "2b4b3259-f143-2abf-46d4- 62905268263e", group "cache" Allocation "fa612324-877a-c589-4c03-87b393a7e721" created: node "2b4b3259-f143-2abf-46d4- 62905268263e", group "cache" Allocation "1170083d-dd2c-92ec-1e29-44f25eb3de75" modified: node "2b4b3259-f143-2abf-46d4- 62905268263e", group "cache" Evaluation status changed: "pending" -> "complete" ==> Evaluation "8a72b095-79fc-f521-acea-463fd049d36c" finished with status "complete" zem@dev:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 376c15af6b8f redis:latest "/entrypoint.sh redis" 1 seconds ago Up Less than a second 128.199.223.107:58268->6379/tcp prickly_visvesvaraya 2a78baaa8ec7 redis:latest "/entrypoint.sh redis" 1 seconds ago Up Less than a second 128.199.223.107:29865->6379/tcp mad_fermi ca2c4efd37e4 redis:latest "/entrypoint.sh redis" 5 minutes ago Up 5 minutes 128.199.223.107:44054->6379/tcp desperate_mayer
- 86. 86 ‣ リソース管理とスケジュールを簡単に行える 'nomad' コマンドを使うだけで、複雑になりがちな分散環境における任意のリソースを管理 ‣ 環境に依存しない 特定のクラウド・仮想化システムによる制限を受けないし、併用して使い分けられる ‣ クライアント・サーバ型のアーキテクチャ 基本になっている技術は、Serf の Gossip プロトコル、Consul の Raft プロトコルと同じ ‣ Dockerコンテナを始めとして様々なジョブを処理 対応環境はDocker、仮想化、通常のバイナリに対応している Nomad まとめ
- 88. Otto
- 89. Otto Vagrant後継ソフト The Successor to Vagrant Vagrantから学んだ多くの知見 それを反映したのが Otto
- 90. Otto 開発環境は類似 Development environments are similar 開発者はデプロイしたい Developers want to deploy マイクロサービスは未来 Microservices are the future
- 91. vagrant up packerbuild terraform apply
- 92. otto dev otto build otto deploy
- 93. otto dev otto infra otto deployotto build otto Compile Appfile
- 94. 94 Ottoの主な機能 ‣ 開発環境の自動構築 ( otto dev, otto build ) アプリケーションの種類に応じて、依存関係のあるパッケージやサービスを自動的に構築する ‣ デプロイ ( otto deploy ) クラウド環境だけでなく、リモートでの環境構築やアプリケーションのデプロイを単一コマンドで実行可能 ‣ HashiCorpのツールと連携 ‣ 環境をコードで管理 Appfile ( Vagrantfile に相当するようなもの )
- 95. 95 application { name = "my-app" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/postgresql" } } customization "ruby" { ruby_version = "2.1" } Appfile
- 96. 96 ‣ otto dev ( vagrant up 相当 ) otto dev ssh otto dev address otto dev destroy ‣ otto infra ( terraform apply 相当 ) ‣ otto build ( packer build 相当 ) ‣ otto deploy コマンド実行例
- 97. 97 Ottoを使うには ‣ 対応OS Windows, Mac OS X, Linux ‣ ダウンロード https://ottoproject.io/downloads.html ‣ チュートリアル https://ottoproject.io/intro/getting-started/install.html $ cd /tmp $ wget -O otto.zip https://dl.bintray.com/mitchellh/otto/otto_0.1.1_linux_amd64.zip $ unzip otto.zip $ sudo mv otto /usr/bin/ $ sudo chmod 755 /usr/bin/otto $ otto -v Otto v0.1.1
- 98. $ git clone https://github.com/hashicorp/otto-getting-started.git $ cd otto-getting-started $ otto compile ==> Loading Appfile... ==> No Appfile found! Detecting project information... No Appfile was found. If there is no Appfile, Otto will do its best to detect the type of application this is and set reasonable defaults. This is a good way to get started with Otto, but over time we recommend writing a real Appfile since this will allow more complex customizations, the ability to reference dependencies, versioning, and more. （省略） ==> Compiling main application... ==> Compilation success! This means that Otto is now ready to start a development environment, deploy this application, build the supporting infastructure, and more. See the help for more information. Supporting files to enable Otto to manage your application from development to deployment have been placed in the output directory. These files can be manually inspected to determine what Otto will do.
- 99. $ git clone https://github.com/hashicorp/otto-getting-started.git $ cd otto-getting-started $ otto compile ==> Loading Appfile... ==> No Appfile found! Detecting project information... No Appfile was found. If there is no Appfile, Otto will do its best to detect the type of application this is and set reasonable defaults. This is a good way to get started with Otto, but over time we recommend writing a real Appfile since this will allow more complex customizations, the ability to reference dependencies, versioning, and more. （省略） ==> Compiling main application... ==> Compilation success! This means that Otto is now ready to start a development environment, deploy this application, build the supporting infastructure, and more. See the help for more information. Supporting files to enable Otto to manage your application from development to deployment have been placed in the output directory. These files can be manually inspected to determine what Otto will do.
- 100. $ otto status ==> App Info Application: otto-getting-started (ruby) Project: otto-getting-started Infrastructure: aws (simple) ==> Component Status Dev environment: NOT CREATED Infra: READY Build: NOT BUILT Deploy: NOT DEPLOYED
- 101. $ otto infra ==> Detecting infrastructure credentials for: otto-getting-started (aws) Cached and encrypted infrastructure credentials found. Otto will now ask you for the password to decrypt these credentials. … ==> otto: Deleting temporary security group... ==> otto: Deleting temporary keypair... Build 'otto' finished. ==> Builds finished. The artifacts of successful builds are: --> otto: AMIs were created: us-east-1: ami-27185642 ==> Storing build data in directory... ==> Build success! The build was completed successfully and stored within the directory service, meaning other members of your team don't need to rebuild this same version and can deploy it immediately.
- 102. $ otto build … ==> otto: Deleting temporary security group... ==> otto: Deleting temporary keypair... Build 'otto' finished. ==> Builds finished. The artifacts of successful builds are: --> otto: AMIs were created: us-east-1: ami-27185642 ==> Storing build data in directory... ==> Build success! The build was completed successfully and stored within the directory service, meaning other members of your team don't need to rebuild this same version and can deploy it immediately.
- 103. $ otto build … ==> otto: Deleting temporary security group... ==> otto: Deleting temporary keypair... Build 'otto' finished. ==> Builds finished. The artifacts of successful builds are: --> otto: AMIs were created: us-east-1: ami-27185642 ==> Storing build data in directory... ==> Build success! The build was completed successfully and stored within the directory service, meaning other members of your team don't need to rebuild this same version and can deploy it immediately.
- 104. $ otto deploy
- 106. 106 Ottoの現状とこれから ‣ デプロイ先のインフラは拡大予定 現状（バージョン 0.1 ）では Amazon Web Services の環境のみ ‣ Vaultと連携予定 シークレットの自動的な保管や管理 ‣ Atlasとも機能統合予定 現在の開発者向けから、運用担当向けの監視やアプリケーションのメンテナンスもできるように ‣ 構成管理ツールとの棲み分けは？ 個人的な疑問
- 107. 107 Vagrantの今後 ‣ 今後も開発継続 機能改善もバージョンアップもあり ‣ Ottoと並列に開発が進む Vagrantはマシンレベルの開発環境、Ottoはアプリレベルでの開発環境という位置付け ‣ Ottoの開発環境はVagrantと連携 https://ottoproject.io/intro/vagrant-successor.html
- 108. 108 Ottoまとめ ‣ Otto は Vagrant の後継ソフトウェアの位置付け ただし、必ずしも Otto に移行を促すものではない ‣ 開発ツールでもあり、デプロイツールでもある 「otto」コマンドを使い、複数の環境を使い分ける事ができる ‣ Appflie で環境や依存関係を管理 ‣ Dockerに対応している Microservices 向けの複雑な環境も、Otto を使えば簡単に開発・デプロイ・運用可能になる
- 109. Wrap Up □□□
- 110. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 @zembutsu Nov 27, 2015 Our Survival Strategies, Microservices, and HashiCorp 今日のまとめ ‣ マイクロサービス時代の生存戦略 ‣ 「ペット」から「家畜」の時代 ‣ 「自由」のための「選択肢」 ‣ 「技術」ではなく、「業務手順」 ‣ HashiCorpは何を解決するのか？ ‣ マイクロサービスやDockerだけでなく、既存環境も管理 ‣ Nomad は Docker にも対応したスケジューラ ‣ Otto は マイクロサービスにも対応した Vagrant の後継開発・デプロイ用ツール
- 116. システムありきの仕組みに サヨナラを
- 117. 皆さんと一緒に 悩みながらも 進みたい
- 119. One more thing...
- 121. 121 ‣ Nomad https://nomadproject.io/ ‣ Otto https://ottoproject.io/ ‣ blog記事 Nomad • https://hashicorp.com/blog/nomad.html • http://pocketstudio.jp/log3/2015/09/29/nomad-ja/ (日本語参考） Otto • https://hashicorp.com/blog/otto.html • http://pocketstudio.jp/log3/2015/09/30/otto-ja/ (日本語参考) 参考情報