HashiCorp製品（Vagrant, Consul, Atlas, Otto）の活用による開発環境構築の自動化 / 2015-4Q Report

次世代システム研究室 2015 年 4Q の研究発表会にて発表しました。
HashiCorp の新ツール “Otto” に関する調査結果の紹介です。

Transcript

1. HashiCorp製品 （Vagrant, Consul, Atlas, Otto） の活用による 開発環境構築の自動化 GMOインターネット株式会社 次世代システム研究室 吉澤 政洋
2. 1 内容 1. 実サービスにおける開発環境構築の課題 2. Vagrant + Consul + Atlas による ローカル開発環境の構築自動化 3. 新プロダクト Otto の活用による 本番環境との設定共通化
3. 2 1. 実サービスにおける 開発環境構築の課題
4. 3 • 開発プロジェクトに人が増えると、必ず発生する作業 • OS • ミドルウェア • ドライバ • … • 開発したいアプリケーション 開発環境の構築
5. 4 • マシンを用意し、OS も開発環境に合わせる必要が… – 仮想マシン、コンテナの普及 – IaaS の普及 • システムが複雑だと、手順書を用意するのが大変で… – 構成管理ツールの普及 • 一般に、ローカル開発環境の構築は 容易になってきた 近年の状況
6. 5 サーバ 1 台なら容易 複数台のサーバ、 多種多様な構成要素から成る システムはどうか？
7. 6 具体例
8. 7 http://pr.gmopdmp.jp/
10. 9 • 目的に応じて、複数のミドルウェア、 Webフレームワークを使い分け • 構成要素については、すでに社外セミナにて 開発チームメンバが発表済み GMO プライベート DMP の構成要素
11. 10 参考：HBase × Impalaで作るアドテク「GMOプライベートDMP」 http://www.slideshare.net/michiokatano/hbase-meetup-tokyo-2015-summer-gmo
12. 11 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014
13. 12 多数のコンポーネント • Web Server – Nginx • Application Server – FuelPHP (PHP) – Play! Framework (Java) • Hadoop Cluster (CDH) – HDFS – HBase – Hive – Impala – Flume – ... • Database, Cache – MariaDB Galera Cluster – Memcached • Message Broker – RabbitMQ • Load Balancer – HAProxy + Our applications – Web applications – Worker processes – Batch processes
14. 13 この開発環境を ローカルマシン上に作るには？
15. 14 課題の整理
16. 15 • サービス間の依存関係の設定 • Hadoopクラスタの構築 開発環境構築の課題
17. 16 サービス間の依存関係の設定 Web Web Web API HBase Hive/Impala RabbitMQ MariaDB Batch Worker 依存元 依存先 それぞれの 接続先アドレス設定 入り組んだ 依存関係
18. 17 Hadoop クラスタの構築 Web API HBase Hive/Impala RabbitMQ MariaDB Batch Worker インストール が難しい Web Web Cloudera Manager （GUI）で インストール Flume HDFS Zookeeper
19. 18 過去の苦労 • 約 1 年前の発表 – GMOプライベートDMP開発で取り組んできたDevOpsと今後の 展望 http://www.slideshare.net/beniyama/gmo-private- dmpdevops2014
20. 19 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014
21. 20 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014
22. 21 現在のアプローチ • サービス間の依存関係の設定 → 機能追加の頻度が高いサービスのみ、 Vagrant + Ansible で構築自動化 （ローカル環境用に設定ベタ書き） • Hadoopクラスタの構築 → 開発・テスト用 Hadoop Cluster を 開発チーム内で共用
23. 22 問題は、依然として残っている なんとか改善できないか？
24. 23 課題解決へのアプローチ
25. 24 おことわり • これ以降のプレゼンの内容は、 「将来の改善に向けた先行検討の結果」 です （＝まだ実サービスには導入できていません）
26. 25 課題解決へのアプローチ • サービス間の依存関係の設定 – 依存先のアドレス設定自動化 → Consul – 依存関係の明確化 → Otto • Hadoopクラスタの構築 → ローカル開発環境は Cloudera QuickStart VM
27. 26 • HashiCorp 社の Consul が提供する Service Discovery 機能を利用 • サービス提供元の IP アドレス・ポートを 設定ファイルに書く必要がなくなる 依存先のアドレス設定自動化 Web Impala サービス "impala"を提供する IP アドレス・ポート IP アドレス・ポート の 1 つを選んで接続 "impala" "impala" "impala"
28. 27 依存関係の明確化 • HashiCorp 社の Otto が提供する 依存関係の管理機能を利用 • 2015 年 9 月末にリリースされたばかり 最新版は version 0.1.2
29. 28 Hadoopクラスタの構築 • Cloudera QuickStart VM – Cloudera が提供している、オールインワンの VM – ローカル開発環境で使うには十分な機能 http://www.cloudera.com/content/www/en-us/downloads/quickstart_vms.html
30. 29 • サービス間の依存関係の設定 → Consul + Atlas で実現 • Hadoopクラスタの構築 → Vagrant + Cloudera QuickStart VM で実現 2章：現在実現できる範囲
31. 30 2章：現在実現できる範囲 Web DB Web DB Hadoop Cluster 開発環境 本番環境 deploy deploy Cloudera QuickStart VM
32. 31 • サービス間の依存関係の設定 → Otto + Consul + Atlas で実現 • Hadoopクラスタの構築 → Vagrant + VirtualBox + Cloudera QuickStart VM で実現 • 本番環境との設定共通化 → Otto + Packer + Terraform で実現 3章：Otto が将来的に実現する範囲
33. 32 3章：Otto が将来的に実現する範囲 Web DB Web DB Hadoop Cluster 開発環境 本番環境 Cloudera QuickStart VM deploy deploy
34. 33 2. Vagrant + Consul + Atlas による ローカル開発環境の構築自動化
35. 34 HashiCorp とは？
37. 36 HashiCorp • Vagrant 開発者の Mitchell Hashimoto 氏 により、2012年に設立 • いわゆる DevOps を実現するツール群を多 数開発し、多くのユーザの支持を受ける • “The TAO of HashiCorp” を 彼らの活動を定める基盤として掲げる
38. 37 The TAO of HashiCorp • Workflows, not Technologies • Simple, Modular, Composable • Communicating Sequential Processes • Immutability • Versioning through Codification • Automation through Codification • Resilient systems • Pragmatism https://hashicorp.com/blog/tao-of-hashicorp.html （日本語参考訳: pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/）
39. 38 Vagrant • ローカル環境に仮想マシンを構築するため のソフトウェア • 仮想化ソフトウェアのラッパー – VirtualBox, VMware, KVM – Docker – Amazon EC2 • 構成管理ツール（provisioner）のラッパー – Chef, Puppet, Ansible, ... • box ファイルによる VM の共有
40. 39 Vagrantfile • Ruby を DSL に用い、変数や制御文を使用可能 Vagrant.configure(2) do |config| config.vm.define "cdh-quickstart" do |c| c.vm.box = "quickstart/cdh" c.vm.hostname = "quickstart.cloudera" c.vm.network "private_network", ip: "192.168.33.40" c.vm.provider "virtualbox" do |vb| vb.cpus = 2 vb.memory = "8192" end c.vm.provision "ansible" do |ansible| ansible.playbook = "ansible/cdh_quickstart.yml" end end end
41. 40 Vagrant を使う場合、使わない場合 $ vagrant up $ vagrant ssh
42. 41 • Service Discovery および Configuration のためのソフトウェア • Consul Cluster を構成 – 2 種類のノード： Server, Client • Health Check、Key-Value Store の機能 も提供 Consul
43. 42 Service Discovery { "service": { "name": "impala", "port": 21050, } } impala.json Web Impala サービス "impala"を提供する IP アドレス・ポート IP アドレス・ポート の 1 つを選んで接続 "impala" "impala" "impala"
44. 43 Atlas • HashiCorp 製品の統合管理サービス – Vagrant box のビルド、ホスティング、配布 – Consul の join 支援、クラスタ可視化 – Packer build および artifact の保存 – Terraform によるインフラ管理
45. 44 Packer, Terraform, Vault • Packer – VM image や docker image など、 いわゆる “ゴールデンイメージ” を作成するため のソフトウェア • Terraform – IaaS 環境を構築、変更、バージョン管理するた めのソフトウェア • Vault – 秘密情報（トークン、パスワード、秘密鍵など ）を、分散ネットワーク上の必要な場所に安全 に配置するためのソフトウェア
46. 45 今回構築した開発環境
47. 46 今回構築した開発環境 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Sample Web Application Cloudera QuickStart VM MariaDB Server ... Consul Server
48. 47 使用したマシン • MacBook Pro (Retina, 15-inch, Mid 2014) • CPU: 2.2 GHz Intel Core i7 • メモリ: 16 GB 1600 MHz DDR3 • OS X Yosemite 10.10.5 • 今日のプレゼンに使っているこれ
49. 48 設定ファイルのサンプル一式 https://github.com/muziyoshiz/hashicorp-sample $ git clone https://github.com/muziyoshiz/hashicorp- sample.git $ cd hashicorp-sample $ echo "your github token" > ./github_token $ echo "your atlas token" > ./atlas_token $ echo "your atlas infra name" > ./atlas_infra $ vagrant up
50. 49 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) manager1 cloudera mariadb1 ... consul1 Playbook Template Sample Web App CDH (Including Impala) Consul Client Consul Client Consul Client MariaDB Server Consul Server Nginx FuelPHP Vagrant Ansible Vagrantfile
51. 50 デモ
52. 51 依存関係の定義
53. 52 依存関係の定義 • Vagrantfile を書くときに、 依存関係を考慮して、VM の起動順序を決める – Consul サーバが最初 – 次にデータベース（MariaDB、Impala） – 最後に Web アプリ • Consul + Dnsmasq の組合せにより、 Consul クラスタ内でのみ使えるホスト名を割り当てる
54. 53 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible consul1 Consul Server Join Vagrantfile
55. 54 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible mariadb1 Consul Client MariaDB Server consul1 Consul Server Join Join Vagrantfile "mariadb"
56. 55 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible mariadb1 Consul Client MariaDB Server consul1 Consul Server cloudera CDH (Including Impala) Consul Client Join Join Vagrantfile "impala"
57. 56 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible manager1 Consul Client Nginx FuelPHP mariadb1 Consul Client MariaDB Server consul1 Consul Server cloudera CDH (Including Impala) Consul Client Join Join Sample Web App Vagrantfile
58. 57 依存先のアドレス設定自動化 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) manager1 cloudera mariadb1 Sample Web App CDH (Including Impala) MariaDB Server impala.service.consul mariadb.service.consul
59. 58 consul member コマンド [vagrant@manager1 ~]$ consul members Node Address Status Type Build Protocol DC manager1 192.168.33.30:8301 alive client 0.5.2 2 dc1 quickstart.cloudera 192.168.33.40:8301 alive client 0.5.2 2 dc1 mariadb1 192.168.33.20:8301 alive client 0.5.2 2 dc1 consul1 192.168.33.10:8301 alive server 0.5.2 2 dc1
60. 59 dig コマンド [vagrant@manager1 ~]$ dig @127.0.0.1 -p 8600 manager.service.consul SRV ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @127.0.0.1 -p 8600 manager.service.consul SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62152 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;manager.service.consul. IN SRV ;; ANSWER SECTION: manager.service.consul. 0 IN SRV 1 1 80 manager1.node.dc1.consul. ;; ADDITIONAL SECTION: manager1.node.dc1.consul. 0 IN A 192.168.33.30
61. 60 Dnsmasq の設定 • ドメイン名 .consul への問合せを Dnsmasq 経由で、Consul Agent に送るように設定 server=/consul/127.0.0.1#8600 strict-order dnsmasq.conf
62. 61 HAProxy を利用したい場合 • Consul Template – Consul への問合せを行うデーモン – Consul cluster への agent 参加・離脱を契機に 設定ファイルの更新、サービスの再起動などを実行 • 今回のサンプルでは未使用
63. 62 Consul Cluster の可視化 with Atlas
64. 63 Atlasの設定 • Consul Agent の起動時に、 Join 先を Consul Server ではなく、Atlas に指定 /usr/local/bin/consul agent -data-dir /tmp/consul - bind 192.168.33.xxx –atlas muziyoshiz/hashicorp-sample -atlas-join -atlas-token {{ token-string }} /usr/local/bin/consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul –bind 192.168.33.xxx –atlas muziyoshiz/hashicorp-sample -atlas-join -atlas-token {{ token-string }} -config-dir=/etc/consul.d
65. 64 Atlasの画面表示例 • Datacenters • Services • Nodes • Health Checks
71. 70 Cloudera QuickStart VM の構築
72. 71 Cloudera QuickStart VM とは • Single-node Apache Hadoop cluster • VMware, KVM, VirtualBox のイメージを配布 • Cloudera Manager が同梱された Cloudera Express バージョンを動作させる場合、 メモリ 8 GiB 以上が必要 • [NEW!] 2015 年 12 月 1 日に Docker 版(Beta) リリース https://blog.cloudera.com/blog/2015/12/docker-is-the-new- quickstart-option-for-apache-hadoop-and-cloudera/
73. 72 box ファイル • Cloudera からは、box ファイルの配布なし • 今回は、有志が配布している box ファイルを利用 – https://atlas.hashicorp.com/quickstart/boxes/cdh – box ファイルは CDH 5.4.2 （CDH の最新は 5.5.0） • Atlas で共有されており、 ‘quickstart/cdh’ という名前で参照可能
75. 74 Cloudera Manager • VM 起動後に、Cloudera Manager も自動的に起動 • 細かい設定は GUI を通して行う必要あり （この自動化は今後の課題）
77. 76 自動構築の結果
78. 77 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible manager1 mariadb1 consul1 Sample Web App Consul Client Nginx FuelPHP Consul Server cloudera CDH (Including Impala) Consul Client Consul Client MariaDB Server Vagrantfile
79. 78 設定ファイルの行数 VM File # of lines 全体 Vagrantfile 170 共通 Ansible files 9 Consul Agent共通 Ansible files 276 consul1 Ansible files 11 mariadb1 Ansible files 53 cdh-quickstart Ansible files 25 manager1 Ansible files 359 Total 903
80. 79 初回の vagrant up にかかる時間（深夜1時台） VM 実行時間 (sec) consul1 125.59 mariadb1 187.76 cdh-quickstart 171.87 manager1 779.95 Total 1265.17 (21.09 min) ※ box ファイルのダウンロード時間は除く
81. 80 初回の vagrant up にかかる時間（朝7時台） VM 実行時間 (sec) consul1 107.55 mariadb1 134.49 cdh-quickstart 138.89 manager1 683.24 Total 1064.17 (17.74 min) → パッケージのダウンロード速度が 実行時間に強く影響 ※ box ファイルのダウンロード時間は除く
82. 81 • vagrant up がたまに途中で止まってしまう – vagrant halt → vagrant destroy → vagrant up の順にやり直すと、うまくいくことがある – OS X 固有の問題？ • Cloudera QuickStartVM が clock offset エラー – Host Clock Offset Thresholds（ホストクロックオフセットの しきい値）オプションを「Never（行わない）」に設定 環境依存と思われる問題
83. 82 本番環境との関係 • 依存先のアドレス設定は、Consul を用いて共通化 • デプロイ設定は別（Ansible playbook は一部共通） Web DB Web DB Hadoop Cluster 開発環境 本番環境 deploy Cloudera QuickStart VM deploy
84. 83 • 依存関係が1個の Vagrantfile に詰め込まれている • サービス単位の依存関係が不明確 • 本番環境では Vagrantfile は使えない 課題 Vagrantfile Sample Web Application Cloudera QuickStart VM MariaDB Server ... Consul Server
85. 84 Config Config Config 理想形は？ • サービスごとに設定ファイルを分離 • 依存先のサービスに関する知識は最小限に Config Sample Web Application Cloudera QuickStart VM MariaDB Server Consul Server
86. 85 3. 新プロダクト Otto の活用による 本番環境との設定共通化
88. 87 Otto • “The successor to Vagrant” • HashiCorp がこれまでに得た知見 – Development environments are similar （開発環境は似たり寄ったり） – Developers want to deploy （本番環境へのデプロイまでしてほしい） – Microservices are difficult （マイクロサービスのモデリングは難しい）
89. 88 Otto のアプローチ • 開発環境は似たり寄ったり – Otto が開発環境のベストプラクティスを持ち、 アプリの種類にあった設定を自動生成する • 本番環境へのデプロイまでしてほしい – 1つの設定ファイル Appfile をもとに 本番環境へのデプロイも行う • マイクロサービスのモデリングは難しい – Appfile に定義された依存関係をもとに そのアプリに必要なサービスすべてをデプロイする
90. 89 Appfile が依存関係を定義する application { name = "my-app" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/postgresql" } } Appfile
91. 90 application { name = "my-app" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/postgresql" } } Appfile application { name = "postgresql" type = "docker-external" } customization { image = "postgres:9.5" run_args = "-p 5432:5432" } postgresql/Appfile
92. 91 Ottoの実行例
93. 92 otto コマンド $ otto dev $ otto dev ssh $ otto infra $ otto build $ otto deploy $ otto compile $ otto dev destroy $ otto deploy destroy $ otto infra destroy 開発環境 本番環境
94. 93 • Appfile のコンパイル • .otto ディレクトリ以下に、設定ファイルを自動生成 – アプリケーション自動設定のためのシェルスクリプト (Bash) – Vagrant の設定 – Consul の設定 – Packer の設定 – Terraform の設定 • Appfile がないときは、 アプリのソースコードをもとに Appfile すら自動生成 otto compile
95. 94 • ローカル環境の構築 • 実体は Vagrant のラッパー • "shell" provisioner otto dev
96. 95 otto dev の実行結果 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) default my-app Consul Server Otto Vagrant Docker Container PostgreSQL Server main.sh Vagrantfile Appfile .otto
97. 96 • otto dev ssh – vagrant ssh 相当 • otto dev destroy – vagrant destroy 相当 • なぜか vagrant halt 相当のコマンドはまだない？ その他の開発用コマンド
98. 97 • 本番環境のサービスが共有する機能（foundation） の構築 • Consul Server は foundation に含まれる • Otto 0.1 は Infrastructure type "AWS" のみ対応 – fravor: "simple" または "vpc-public-private" otto infra
99. 98 例）flavor "simple" の場合
100. 99 • VM またはコンテナイメージの作成 • 現在は Amazon Machine Image (AMI) のみ対応 otto build
101. 100 • VM またはコンテナのデプロイ • 現在は AWS EC2 のみ対応 （AWS ECS は未対応） otto deploy
102. 101 例）サンプルアプリ "otto-getting-started" の場合 • AWSの画面例
103. 102 Otto 0.1 の試用
104. 103 設定ファイルのサンプル一式（Otto バージョン） https://github.com/muziyoshiz/hashicorp-sample- otto-version $ git clone https://github.com/muziyoshiz/hashicorp- sample-otto-version.git $ cd hashicorp-sample-otto-version $ otto compile （※ Otto 0.1 で無理矢理動かすには、ここで手作業が必要） $ otto dev
105. 104 Appfile の custom type • これを使えば Vagrant でできることは何でもできる？ application { name = "cdh-quickstart" type = "custom" } customization "dev" { vagrantfile = "./Vagrantfile" } customization "dev-dep" { vagrantfile = "./Vagrantfile.fragment" } cdh_quickstart/Appfile
106. 105 結論：Otto 0.1 では、まだ動きませんでした • うまくいかない原因 – 依存先の dev-dep の設定を、 自動生成した Vagrantfile のなかに単純にコピーするため、 自動生成した設定の一部を上書きしてしまう – provisioner が読み込むファイルをコピーしてこない • otto compile の実行後に、以下の手作業を行えば otto dev を実行できるようになる – .otto/compiled/app/dev/Vagrantfile の編集 – .otto/compiled/app/dev 以下への Ansible playbook のコピー
107. 106 • Dependency（※ Otto 0.1 で一部実装済みだが不完全） • Application type, infrastructure type のプラグイン • Custom Foundations • Dependency Versioning • Docker 対応（※ Otto 0.1 は otto dev のみ Docker 対応） • Shared Directory（Atlas 対応） • Vault と Nomad の自動インストール • Datadog のようなサービスとの依存関係の定義 • Safe Upgrade （Ottoのアップグレード時の後方互換性） Otto 0.1 で未実装の機能 解説：Otto の基本概念、フォルダ構造、および Otto 0.1 では未実装の機能一覧 - 無印吉澤 http://muziyoshiz.hatenablog.com/entry/2015/11/01/163413
108. 107 将来の Otto への期待
109. 108 期待：サービス間の依存関係の明確化 • 今回の場合は、3 つの Appfile で依存関係を定義可能 • Consul は foundation に含まれるため、Appfile 不要 Appfile Appfile Appfile Sample Web Application Cloudera QuickStart VM MariaDB Server Vagrant file Vagrant file
110. 109 期待：設定量の削減 • Otto はベストプラクティスに基づいて、設定を 自動生成する → これが実現されたら、設定はどれくらい減る？ • 試算にあたっての仮定 – Web アプリの動作に必要なミドルウェア（FuelPHP 等）は otto が自動インストールする – Consul Server および Client は otto が自動インストールする – otto が自動インストールしないミドルウェアは Ansible を使ってインストールする
111. 110 設定ファイルの行数（Otto 利用後の試算値） VM File # of lines manager1 Appfile 12 mariadb1 Appfile 13 Vagrantfile.fragment 75 Ansible files 52 cdh- quickstart Appfile 13 Vagrantfile.fragment 52 Ansible files 20 Total 237
112. 111 Otto 利用前／利用後 の比較 170 733 127 72 38 利用前 利用後 Otto Vagrant Ansible 74%減
113. 112 期待：開発環境-本番環境の設定共通化 • Appfile で設定共通化 – 共通化できない部分は Vagrant と Packer, Terraform の 設定ファイルを別に用意する必要あり • Service Discovery は、Consul に統一 Web DB Web DB Hadoop Cluster Cloudera QuickStart VM Appfile
114. 113 Otto に対する懸念（1） • いままでの HashiCorp 製品とは毛色が違う 統合型のソフトウェア • ベストプラクティスの整備に関する不安 – ベストプラクティスをどのように定義するか？ – 例：どの OS を採用するか？ • Vagrant は Ubuntu • AWS は Amazon Liux （RHEL ベース） – 構成管理ツールがすでに多数ある状況で、Otto のための手順を 整備し、公開する人がどれだけ現れるか？
115. 114 Otto に対する懸念（2） • 構成管理ツール（provisioner）との関係が不明 – 今後もシェルのみで構築か？ – 特定の provisioner をサポートするか？ 中立を保つと、複数の provisioner が混在してしまうのではないか？ • infra（IaaS）の更新に対する考え方が不明 – Appfile を更新した場合、infra の設定が壊れることはないか？ – IaaS 側の仕様変更、機能追加があった場合に、otto はどこまで 追従するか？ otto の過去 ver. をいつまでサポートするか？
116. 115 まとめ
117. 116 まとめ • 開発環境構築にあたり、 「サービス間の依存関係の設定」 「Hadoopクラスタの構築」が主な課題となっている • Consul + Atlas により、開発/本番環境とも同じ方法 で、依存先サービスのアドレス設定を自動化できる • Otto で現在予定されている機能が実現された暁には、 「サービス間の依存関係の定義」 「設定量の削減」 「開発環境-本番環境の設定共通化」が期待できる
118. 117 • 2 章で検証した設定の、実際の開発環境への導入 – Consul + Atlas – Vagrant + VirtualBox + Cloudera QuickStart VM – サンプルアプリの範囲を超えても、問題なく動作するか • Packer, Terraform, Vault の導入検討 – GMO アプリクラウド、ConoHa への適用も含めて検討 • いわゆる DevOps ツールの動向調査 – Otto のアップデート状況 – Docker Machine, Docker Compose 今後の課題