HashiCorpの考えるMicroservicesとNomad,Otto
•
49 likes•10,273 views
次世代クラウド勉強会 テーマ：【Docker、DevOpsを取り巻くマイクロサービスのコンセプト】 http://connpass.com/event/20426/
![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
これでテスト用の環境が、すぐ
立ち上がります。](https://image.slidesharecdn.com/microserviceshashicorpnomadandottodistribution-151009130526-lva1-app6891/85/HashiCorp-Microservices-Nomad-Otto-27-320.jpg?cb=1444396113)
![# 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 設定ファイルのサンプルです。
ここでリソースやジョブを定義](https://image.slidesharecdn.com/microserviceshashicorpnomadandottodistribution-151009130526-lva1-app6891/85/HashiCorp-Microservices-Nomad-Otto-29-320.jpg?cb=1444396113)
![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
コマンドを実行すると、勝手に
コンテナを起動してくれます。](https://image.slidesharecdn.com/microserviceshashicorpnomadandottodistribution-151009130526-lva1-app6891/85/HashiCorp-Microservices-Nomad-Otto-30-320.jpg?cb=1444396113)
HashiCorpの考えるMicroservicesとNomad,Otto
- 1. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 HashiCorp の考える Microservices と Nomad,Otto @zembutsu #ms_study 次世代クラウド勉強会 Docker、DevOpsを取り巻く マイクロサービスのコンセプト Oct 9, 2015
- 2. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 HashiCorp の考える Microservices と Nomad,Otto 今日の内容 ‣ HashiCorpとは？ ‣ NomadはDockerスケジューラ ‣ OttoはVagrantの後継ソフト HashiCorpについてと、先週に 発表されたNomadとOttoの概要 そして使い方をご紹介。 @zembutsu #ms_study 次世代クラウド勉強会 Docker、DevOpsを取り巻く マイクロサービスのコンセプト Oct 9, 2015
- 3. 3 自己紹介 ‣ @zembutsu a.k.a. 前佛雅人 - Technology Evangelist; Creationline, Inc. – 1.5 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: 4774174416 ISBN-10: 4844338145 ISBN-10: 4798139785
- 11. 11 HashiCorp “Powering the software-managed datacenter.” ‣ 2012年設立 Mitchell Hashimoto氏が2010年に開発・発表したVagrantが前身 ‣ データセンタ管理に革命をもたらす目的 仮想・物理・コンテナ・クラウド等を組みあわせる状況、その時に生まれる溝を埋めるものを提供 ‣ オープンソースで開発過程が公開 設立以後も、コードが公開されているだけでなく、GitHub・IRC で誰でも意見表明できる HashiCorp(ハシコープ)という 会社名です。コードはすべてが オープンに公開されています。
- 12. 12 ‣ 技術ありきではなく、どのように実現するか？ 最も簡単にするためのワークフローを考え、そこに対応するツールが無ければ作るという設計思想 ‣ 単純・モジュール型・組みあわせ可能 Unix哲学と同様、全体の問題を解決するのではなく、個々の要素（コンポーネント）に分解 ‣ コードで管理・弾力的システム・実用主義 システムや基盤に対するバージョン管理や自動化によって、システムにとっても人にとっても利点となる The Tao of HashiCorp ※参考：The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3 http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/ 彼らは問題を解決するために 各種のツールを作っています。
- 16. vagrant up packerbuild terraform apply 従来はAtlasが各サービスを結 びつける役割でしたが
- 17. otto dev otto build otto deploy Ottoは開発者視点で全ツールを とりまとめる役割。
- 18. オープン ソース Web インター フェース セキュリ ティ CLI 共同作業 管理機能コア機能 Git GitHub Otto Atlas こんな役割分担。
- 20. Nomad 分散スケジューラ Distributed Scheduler デプロイを簡単に Easily Deploy Applications ジョブの詳細設計 Job Specification あらゆるリソース管理とスケ ジュールを処理するもの。
- 21. コンテナ化 Containerized 仮想化 Virtualized スタンドアローン Standalone Docker Qemu / KVM Java Jar バイナリの実行 Nomad対応環境 Docker以外の環境も同じように 管理できるのが特徴です。
- 22. Nomad アプリのデプロイ Application Deployment Dockerコンテナ対応 Docker 柔軟なワークロード Flexible Workloads リソースを最大限に集約 Bin Packing HCLによるジョブ定義 HCL Job Specifications
- 23. 23 ‣ マイクロサービスのプラットフォーム MicroservicesやSOAはアプリケーションの設計が複雑化しているが、その基盤としてNomadを使う ‣ パブリック・クラウドへのデプロイ マルチリージョン＆マルチデータセンタ機能により、複数のクラウド環境、物理環境を併用できる ‣ ECサイト 長期間稼働するウェブサービスやバッチ処理のバックエンドにおいて、 あらゆるワークロードをクラスタで共有するので、稼働率の向上やコスト削減につながる 使用例の一部 様々なパブリック・クラウドや 物理環境も問わず一括管理。
- 24. 24 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 ざっくり比較（もしかしたら 変な所があるかも…）
- 25. サーバ (リーダー) サーバ (フォロワー) サーバ (フォロワー) クライアント クライアント クライアント RPC RPC RPC レプリケーション レプリケーション 転送 転送 基本はConsulと同じように、 サーバ・クライアント型です。
- 26. 26 ‣ セットアップ 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 使うのは非常にシンプルです。 このバイナリ1個を準備します。
- 27. 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 これでテスト用の環境が、すぐ 立ち上がります。
- 28. 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 状態確認のIDですが、エージェ ントごとにUUIDが割り当てられ ます。Serf・Consul風のメンバ 管理コマンドです。
- 29. # 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 設定ファイルのサンプルです。 ここでリソースやジョブを定義
- 30. 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 コマンドを実行すると、勝手に コンテナを起動してくれます。
- 31. 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 こちらは状態確認コマンド。
- 32. 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 スケールするのも簡単。 コンテナが３つになりました。
- 33. 33 ‣ リソース管理とスケジュールを簡単に行える 'nomad' コマンドを使うだけで、複雑になりがちな分散環境における任意のリソースを管理 ‣ 環境に依存しない 特定のクラウド・仮想化システムによる制限を受けないし、併用して使い分けられる ‣ クライアント・サーバ型のアーキテクチャ 基本になっている技術は、Serf の Gossip プロトコル、Consul の Raft プロトコルと同じ ‣ Dockerコンテナを始めとして様々なジョブを処理 対応環境はDocker、仮想化、通常のバイナリに対応している Nomad まとめ
- 36. Otto Vagrant後継ソフト The Successor to Vagrant Vagrantから学んだ多くの知見 それを反映したのが Otto HashiCorpがVagrantから学んだ 知見を入れ込んだソフトという 位置づけです。
- 37. Otto 開発環境は類似 Development environments are similar 開発者はデプロイしたい Developers want to deploy マイクロサービスは未来 Microservices are the future Atlasとは逆に、開発者向けに アプローチしているツールです。
- 38. vagrant up packerbuild terraform apply これまでは各ツールを別々に ダウンロードして使い分ける 必用がありました。
- 39. otto dev otto build otto deploy Ottoは「otto」コマンドで各 ツールを抽象化して扱います。
- 40. 40 Ottoの主な機能 ‣ 開発環境の自動構築 ( otto dev, otto build ) アプリケーションの種類に応じて、依存関係のあるパッケージやサービスを自動的に構築する ‣ デプロイ ( otto deploy ) クラウド環境だけでなく、リモートでの環境構築やアプリケーションのデプロイを単一コマンドで実行可能 ‣ HashiCorpのツールと連携 ‣ 環境をコードで管理 Appfile ( Vagrantfile に相当するようなもの ) 開発向け環境の良いところ取り
- 41. 41 application { name = "my-app" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/postgresql" } } customization "ruby" { ruby_version = "2.1" } Appfile これがVagrantfileにかわり アプリケーションの状態を 管理するものになります。
- 42. 42 ‣ otto dev ( vagrant up 相当 ) otto dev ssh otto dev address otto dev destroy ‣ otto infra ( terraform apply 相当 ) ‣ otto build ( packer build 相当 ) ‣ otto deploy コマンド実行例 「vagrant up」のかわりに 「otto dev ～」を実行します。
- 43. 43 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 HashiCorpの他のツール同様に コマンド１つを実行するだけ。
- 44. $ 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. チュートリアルが機能を試す のに非常に分かりやすいです。
- 45. $ 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 こちらは状態確認するコマンド
- 46. $ 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. 「aws」環境上に、セキュリ ティ・グループなどインフラに 関連する情報を読み込みます。
- 47. $ 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. こちらはデプロイに向けて マシン・イメージの自動構築。 後ろでpackerを使っています。
- 50. 50 Ottoの現状とこれから ‣ デプロイ先のインフラは拡大予定 現状（バージョン 0.1 ）では Amazon Web Services の環境のみ ‣ Vaultと連携予定 シークレットの自動的な保管や管理 ‣ Atlasとも機能統合予定 現在の開発者向けから、運用担当向けの監視やアプリケーションのメンテナンスもできるように ‣ 構成管理ツールとの棲み分けは？ 個人的な疑問
- 51. 51 Vagrantの今後 ‣ 今後も開発継続 機能改善もバージョンアップもあり ‣ Ottoと並列に開発が進む Vagrantはマシンレベルの開発環境、Ottoはアプリレベルでの開発環境という位置付け ‣ Ottoの開発環境はVagrantと連携 https://ottoproject.io/intro/vagrant-successor.html ottoは必用があれば内部的に Vagrantを呼び出しており、 ローカルの開発にVagrantを使 うのであれば、これまでも、こ れからも変わりません。
- 52. 52 Ottoまとめ ‣ Otto は Vagrant の後継ソフトウェアの位置付け ただし、必ずしも Otto に移行を促すものではない ‣ 開発ツールでもあり、デプロイツールでもある 「otto」コマンドを使い、複数の環境を使い分ける事ができる ‣ Appflie で環境や依存関係を管理 ‣ Dockerに対応している Microservices 向けの複雑な環境も、Otto を使えば簡単に開発・デプロイ・運用可能になる デプロイのために、Nomadとも 連携しています。
- 54. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 HashiCorp の考える Microservices と Nomad,Otto 今日の内容 ‣ HashiCorpとは？ ‣ NomadはDockerスケジューラ ‣ OttoはVagrantの後継ソフト どれも使うのはとても簡単です。 興味があれば使ってみてはいか がでしょうか。
- 55. 背景画像CREDIT:videodoctor / PIXTA(ピクスタ) https://pixta.jp/@prof306848 HashiCorp の考える Microservices と Nomad,Otto この中で、 気になる所はありますか？(Q&A) Q「Ottoが対応しているのはAWSだけ？」 →現時点ではAWSですが、今後は様々な環境への対応が 発表されています。 Q「弊社環境をOttoに対応したい」 →AWSやDigitalOceanの対応が早いのは、HashiCorp 自身が使っているからです。GitHubでIssueを挙げるの が一番の近道だと思います。 Q「OttoがあればVagrantは不要？」 →いいえ、Ottoはローカル開発環境にVagrantを内部的に 呼び出しています。
- 56. 56 ‣ 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/ (日本語参考) 参考情報