Tweet
Tweet

Slide 1

Slide 1 text

HashiCorp製品 （Vagrant, Consul, Atlas, Otto） の活用による 開発環境構築の自動化 GMOインターネット株式会社 次世代システム研究室 吉澤 政洋

Slide 2

Slide 2 text

1 内容 1. 実サービスにおける開発環境構築の課題 2. Vagrant + Consul + Atlas による ローカル開発環境の構築自動化 3. 新プロダクト Otto の活用による 本番環境との設定共通化

Slide 3

Slide 3 text

2 1. 実サービスにおける 開発環境構築の課題

Slide 4

Slide 4 text

3 • 開発プロジェクトに人が増えると、必ず発生する作業 • OS • ミドルウェア • ドライバ • … • 開発したいアプリケーション 開発環境の構築

Slide 5

Slide 5 text

4 • マシンを用意し、OS も開発環境に合わせる必要が… – 仮想マシン、コンテナの普及 – IaaS の普及 • システムが複雑だと、手順書を用意するのが大変で… – 構成管理ツールの普及 • 一般に、ローカル開発環境の構築は 容易になってきた 近年の状況

Slide 6

Slide 6 text

5 サーバ 1 台なら容易 複数台のサーバ、 多種多様な構成要素から成る システムはどうか？

Slide 7

Slide 7 text

6 具体例

Slide 8

Slide 8 text

7 http://pr.gmopdmp.jp/

Slide 9

Slide 9 text

8

Slide 10

Slide 10 text

9 • 目的に応じて、複数のミドルウェア、 Webフレームワークを使い分け • 構成要素については、すでに社外セミナにて 開発チームメンバが発表済み GMO プライベート DMP の構成要素

Slide 11

Slide 11 text

10 参考：HBase × Impalaで作るアドテク「GMOプライベートDMP」 http://www.slideshare.net/michiokatano/hbase-meetup-tokyo-2015-summer-gmo

Slide 12

Slide 12 text

11 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

13 この開発環境を ローカルマシン上に作るには？

Slide 15

Slide 15 text

14 課題の整理

Slide 16

Slide 16 text

15 • サービス間の依存関係の設定 • Hadoopクラスタの構築 開発環境構築の課題

Slide 17

Slide 17 text

16 サービス間の依存関係の設定 Web Web Web API HBase Hive/Impala RabbitMQ MariaDB Batch Worker 依存元 依存先 それぞれの 接続先アドレス設定 入り組んだ 依存関係

Slide 18

Slide 18 text

17 Hadoop クラスタの構築 Web API HBase Hive/Impala RabbitMQ MariaDB Batch Worker インストール が難しい Web Web Cloudera Manager （GUI）で インストール Flume HDFS Zookeeper

Slide 19

Slide 19 text

18 過去の苦労 • 約 1 年前の発表 – GMOプライベートDMP開発で取り組んできたDevOpsと今後の 展望 http://www.slideshare.net/beniyama/gmo-private- dmpdevops2014

Slide 20

Slide 20 text

19 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014

Slide 21

Slide 21 text

20 参考：GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 http://www.slideshare.net/beniyama/gmo-private-dmpdevops2014

Slide 22

Slide 22 text

21 現在のアプローチ • サービス間の依存関係の設定 → 機能追加の頻度が高いサービスのみ、 Vagrant + Ansible で構築自動化 （ローカル環境用に設定ベタ書き） • Hadoopクラスタの構築 → 開発・テスト用 Hadoop Cluster を 開発チーム内で共用

Slide 23

Slide 23 text

22 問題は、依然として残っている なんとか改善できないか？

Slide 24

Slide 24 text

23 課題解決へのアプローチ

Slide 25

Slide 25 text

24 おことわり • これ以降のプレゼンの内容は、 「将来の改善に向けた先行検討の結果」 です （＝まだ実サービスには導入できていません）

Slide 26

Slide 26 text

25 課題解決へのアプローチ • サービス間の依存関係の設定 – 依存先のアドレス設定自動化 → Consul – 依存関係の明確化 → Otto • Hadoopクラスタの構築 → ローカル開発環境は Cloudera QuickStart VM

Slide 27

Slide 27 text

26 • HashiCorp 社の Consul が提供する Service Discovery 機能を利用 • サービス提供元の IP アドレス・ポートを 設定ファイルに書く必要がなくなる 依存先のアドレス設定自動化 Web Impala サービス "impala"を提供する IP アドレス・ポート IP アドレス・ポート の 1 つを選んで接続 "impala" "impala" "impala"

Slide 28

Slide 28 text

27 依存関係の明確化 • HashiCorp 社の Otto が提供する 依存関係の管理機能を利用 • 2015 年 9 月末にリリースされたばかり 最新版は version 0.1.2

Slide 29

Slide 29 text

28 Hadoopクラスタの構築 • Cloudera QuickStart VM – Cloudera が提供している、オールインワンの VM – ローカル開発環境で使うには十分な機能 http://www.cloudera.com/content/www/en-us/downloads/quickstart_vms.html

Slide 30

Slide 30 text

29 • サービス間の依存関係の設定 → Consul + Atlas で実現 • Hadoopクラスタの構築 → Vagrant + Cloudera QuickStart VM で実現 2章：現在実現できる範囲

Slide 31

Slide 31 text

30 2章：現在実現できる範囲 Web DB Web DB Hadoop Cluster 開発環境 本番環境 deploy deploy Cloudera QuickStart VM

Slide 32

Slide 32 text

31 • サービス間の依存関係の設定 → Otto + Consul + Atlas で実現 • Hadoopクラスタの構築 → Vagrant + VirtualBox + Cloudera QuickStart VM で実現 • 本番環境との設定共通化 → Otto + Packer + Terraform で実現 3章：Otto が将来的に実現する範囲

Slide 33

Slide 33 text

32 3章：Otto が将来的に実現する範囲 Web DB Web DB Hadoop Cluster 開発環境 本番環境 Cloudera QuickStart VM deploy deploy

Slide 34

Slide 34 text

33 2. Vagrant + Consul + Atlas による ローカル開発環境の構築自動化

Slide 35

Slide 35 text

34 HashiCorp とは？

Slide 36

Slide 36 text

35

Slide 37

Slide 37 text

36 HashiCorp • Vagrant 開発者の Mitchell Hashimoto 氏 により、2012年に設立 • いわゆる DevOps を実現するツール群を多 数開発し、多くのユーザの支持を受ける • “The TAO of HashiCorp” を 彼らの活動を定める基盤として掲げる

Slide 38

Slide 38 text

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/）

Slide 39

Slide 39 text

38 Vagrant • ローカル環境に仮想マシンを構築するため のソフトウェア • 仮想化ソフトウェアのラッパー – VirtualBox, VMware, KVM – Docker – Amazon EC2 • 構成管理ツール（provisioner）のラッパー – Chef, Puppet, Ansible, ... • box ファイルによる VM の共有

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

40 Vagrant を使う場合、使わない場合 $ vagrant up $ vagrant ssh

Slide 42

Slide 42 text

41 • Service Discovery および Configuration のためのソフトウェア • Consul Cluster を構成 – 2 種類のノード： Server, Client • Health Check、Key-Value Store の機能 も提供 Consul

Slide 43

Slide 43 text

42 Service Discovery { "service": { "name": "impala", "port": 21050, } } impala.json Web Impala サービス "impala"を提供する IP アドレス・ポート IP アドレス・ポート の 1 つを選んで接続 "impala" "impala" "impala"

Slide 44

Slide 44 text

43 Atlas • HashiCorp 製品の統合管理サービス – Vagrant box のビルド、ホスティング、配布 – Consul の join 支援、クラスタ可視化 – Packer build および artifact の保存 – Terraform によるインフラ管理

Slide 45

Slide 45 text

44 Packer, Terraform, Vault • Packer – VM image や docker image など、 いわゆる “ゴールデンイメージ” を作成するため のソフトウェア • Terraform – IaaS 環境を構築、変更、バージョン管理するた めのソフトウェア • Vault – 秘密情報（トークン、パスワード、秘密鍵など ）を、分散ネットワーク上の必要な場所に安全 に配置するためのソフトウェア

Slide 46

Slide 46 text

45 今回構築した開発環境

Slide 47

Slide 47 text

46 今回構築した開発環境 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Sample Web Application Cloudera QuickStart VM MariaDB Server ... Consul Server

Slide 48

Slide 48 text

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 • 今日のプレゼンに使っているこれ

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

50 デモ

Slide 52

Slide 52 text

51 依存関係の定義

Slide 53

Slide 53 text

52 依存関係の定義 • Vagrantfile を書くときに、 依存関係を考慮して、VM の起動順序を決める – Consul サーバが最初 – 次にデータベース（MariaDB、Impala） – 最後に Web アプリ • Consul + Dnsmasq の組合せにより、 Consul クラスタ内でのみ使えるホスト名を割り当てる

Slide 54

Slide 54 text

53 MacBook Pro (OS X Maverick) VirtualBox VMs (Guest OSes) Playbook Template Vagrant Ansible consul1 Consul Server Join Vagrantfile

Slide 55

Slide 55 text

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"

Slide 56

Slide 56 text

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"

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

60 Dnsmasq の設定 • ドメイン名 .consul への問合せを Dnsmasq 経由で、Consul Agent に送るように設定 server=/consul/127.0.0.1#8600 strict-order dnsmasq.conf

Slide 62

Slide 62 text

61 HAProxy を利用したい場合 • Consul Template – Consul への問合せを行うデーモン – Consul cluster への agent 参加・離脱を契機に 設定ファイルの更新、サービスの再起動などを実行 • 今回のサンプルでは未使用

Slide 63

Slide 63 text

62 Consul Cluster の可視化 with Atlas

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

64 Atlasの画面表示例 • Datacenters • Services • Nodes • Health Checks

Slide 66

Slide 66 text

65

Slide 67

Slide 67 text

66

Slide 68

Slide 68 text

67

Slide 69

Slide 69 text

68

Slide 70

Slide 70 text

69

Slide 71

Slide 71 text

70 Cloudera QuickStart VM の構築

Slide 72

Slide 72 text

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/

Slide 73

Slide 73 text

72 box ファイル • Cloudera からは、box ファイルの配布なし • 今回は、有志が配布している box ファイルを利用 – https://atlas.hashicorp.com/quickstart/boxes/cdh – box ファイルは CDH 5.4.2 （CDH の最新は 5.5.0） • Atlas で共有されており、 ‘quickstart/cdh’ という名前で参照可能

Slide 74

Slide 74 text

73

Slide 75

Slide 75 text

74 Cloudera Manager • VM 起動後に、Cloudera Manager も自動的に起動 • 細かい設定は GUI を通して行う必要あり （この自動化は今後の課題）

Slide 76

Slide 76 text

75

Slide 77

Slide 77 text

76 自動構築の結果

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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 ファイルのダウンロード時間は除く

Slide 81

Slide 81 text

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 ファイルのダウンロード時間は除く

Slide 82

Slide 82 text

81 • vagrant up がたまに途中で止まってしまう – vagrant halt → vagrant destroy → vagrant up の順にやり直すと、うまくいくことがある – OS X 固有の問題？ • Cloudera QuickStartVM が clock offset エラー – Host Clock Offset Thresholds（ホストクロックオフセットの しきい値）オプションを「Never（行わない）」に設定 環境依存と思われる問題

Slide 83

Slide 83 text

82 本番環境との関係 • 依存先のアドレス設定は、Consul を用いて共通化 • デプロイ設定は別（Ansible playbook は一部共通） Web DB Web DB Hadoop Cluster 開発環境 本番環境 deploy Cloudera QuickStart VM deploy

Slide 84

Slide 84 text

83 • 依存関係が1個の Vagrantfile に詰め込まれている • サービス単位の依存関係が不明確 • 本番環境では Vagrantfile は使えない 課題 Vagrantfile Sample Web Application Cloudera QuickStart VM MariaDB Server ... Consul Server

Slide 85

Slide 85 text

84 Config Config Config 理想形は？ • サービスごとに設定ファイルを分離 • 依存先のサービスに関する知識は最小限に Config Sample Web Application Cloudera QuickStart VM MariaDB Server Consul Server

Slide 86

Slide 86 text

85 3. 新プロダクト Otto の活用による 本番環境との設定共通化

Slide 87

Slide 87 text

86

Slide 88

Slide 88 text

87 Otto • “The successor to Vagrant” • HashiCorp がこれまでに得た知見 – Development environments are similar （開発環境は似たり寄ったり） – Developers want to deploy （本番環境へのデプロイまでしてほしい） – Microservices are difficult （マイクロサービスのモデリングは難しい）

Slide 89

Slide 89 text

88 Otto のアプローチ • 開発環境は似たり寄ったり – Otto が開発環境のベストプラクティスを持ち、 アプリの種類にあった設定を自動生成する • 本番環境へのデプロイまでしてほしい – 1つの設定ファイル Appfile をもとに 本番環境へのデプロイも行う • マイクロサービスのモデリングは難しい – Appfile に定義された依存関係をもとに そのアプリに必要なサービスすべてをデプロイする

Slide 90

Slide 90 text

89 Appfile が依存関係を定義する application { name = "my-app" type = "ruby" dependency { source = "github.com/hashicorp/otto/examples/postgresql" } } Appfile

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

91 Ottoの実行例

Slide 93

Slide 93 text

92 otto コマンド $ otto dev $ otto dev ssh $ otto infra $ otto build $ otto deploy $ otto compile $ otto dev destroy $ otto deploy destroy $ otto infra destroy 開発環境 本番環境

Slide 94

Slide 94 text

93 • Appfile のコンパイル • .otto ディレクトリ以下に、設定ファイルを自動生成 – アプリケーション自動設定のためのシェルスクリプト (Bash) – Vagrant の設定 – Consul の設定 – Packer の設定 – Terraform の設定 • Appfile がないときは、 アプリのソースコードをもとに Appfile すら自動生成 otto compile

Slide 95

Slide 95 text

94 • ローカル環境の構築 • 実体は Vagrant のラッパー • "shell" provisioner otto dev

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

96 • otto dev ssh – vagrant ssh 相当 • otto dev destroy – vagrant destroy 相当 • なぜか vagrant halt 相当のコマンドはまだない？ その他の開発用コマンド

Slide 98

Slide 98 text

97 • 本番環境のサービスが共有する機能（foundation） の構築 • Consul Server は foundation に含まれる • Otto 0.1 は Infrastructure type "AWS" のみ対応 – fravor: "simple" または "vpc-public-private" otto infra

Slide 99

Slide 99 text

98 例）flavor "simple" の場合

Slide 100

Slide 100 text

99 • VM またはコンテナイメージの作成 • 現在は Amazon Machine Image (AMI) のみ対応 otto build

Slide 101

Slide 101 text

100 • VM またはコンテナのデプロイ • 現在は AWS EC2 のみ対応 （AWS ECS は未対応） otto deploy

Slide 102

Slide 102 text

101 例）サンプルアプリ "otto-getting-started" の場合 • AWSの画面例

Slide 103

Slide 103 text

102 Otto 0.1 の試用

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

104 Appfile の custom type • これを使えば Vagrant でできることは何でもできる？ application { name = "cdh-quickstart" type = "custom" } customization "dev" { vagrantfile = "./Vagrantfile" } customization "dev-dep" { vagrantfile = "./Vagrantfile.fragment" } cdh_quickstart/Appfile

Slide 106

Slide 106 text

105 結論：Otto 0.1 では、まだ動きませんでした • うまくいかない原因 – 依存先の dev-dep の設定を、 自動生成した Vagrantfile のなかに単純にコピーするため、 自動生成した設定の一部を上書きしてしまう – provisioner が読み込むファイルをコピーしてこない • otto compile の実行後に、以下の手作業を行えば otto dev を実行できるようになる – .otto/compiled/app/dev/Vagrantfile の編集 – .otto/compiled/app/dev 以下への Ansible playbook のコピー

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

107 将来の Otto への期待

Slide 109

Slide 109 text

108 期待：サービス間の依存関係の明確化 • 今回の場合は、3 つの Appfile で依存関係を定義可能 • Consul は foundation に含まれるため、Appfile 不要 Appfile Appfile Appfile Sample Web Application Cloudera QuickStart VM MariaDB Server Vagrant file Vagrant file

Slide 110

Slide 110 text

109 期待：設定量の削減 • Otto はベストプラクティスに基づいて、設定を 自動生成する → これが実現されたら、設定はどれくらい減る？ • 試算にあたっての仮定 – Web アプリの動作に必要なミドルウェア（FuelPHP 等）は otto が自動インストールする – Consul Server および Client は otto が自動インストールする – otto が自動インストールしないミドルウェアは Ansible を使ってインストールする

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

111 Otto 利用前／利用後 の比較 170 733 127 72 38 利用前 利用後 Otto Vagrant Ansible 74%減

Slide 113

Slide 113 text

112 期待：開発環境-本番環境の設定共通化 • Appfile で設定共通化 – 共通化できない部分は Vagrant と Packer, Terraform の 設定ファイルを別に用意する必要あり • Service Discovery は、Consul に統一 Web DB Web DB Hadoop Cluster Cloudera QuickStart VM Appfile

Slide 114

Slide 114 text

113 Otto に対する懸念（1） • いままでの HashiCorp 製品とは毛色が違う 統合型のソフトウェア • ベストプラクティスの整備に関する不安 – ベストプラクティスをどのように定義するか？ – 例：どの OS を採用するか？ • Vagrant は Ubuntu • AWS は Amazon Liux （RHEL ベース） – 構成管理ツールがすでに多数ある状況で、Otto のための手順を 整備し、公開する人がどれだけ現れるか？

Slide 115

Slide 115 text

114 Otto に対する懸念（2） • 構成管理ツール（provisioner）との関係が不明 – 今後もシェルのみで構築か？ – 特定の provisioner をサポートするか？ 中立を保つと、複数の provisioner が混在してしまうのではないか？ • infra（IaaS）の更新に対する考え方が不明 – Appfile を更新した場合、infra の設定が壊れることはないか？ – IaaS 側の仕様変更、機能追加があった場合に、otto はどこまで 追従するか？ otto の過去 ver. をいつまでサポートするか？

Slide 116

Slide 116 text

115 まとめ

Slide 117

Slide 117 text

116 まとめ • 開発環境構築にあたり、 「サービス間の依存関係の設定」 「Hadoopクラスタの構築」が主な課題となっている • Consul + Atlas により、開発/本番環境とも同じ方法 で、依存先サービスのアドレス設定を自動化できる • Otto で現在予定されている機能が実現された暁には、 「サービス間の依存関係の定義」 「設定量の削減」 「開発環境-本番環境の設定共通化」が期待できる

Slide 118

Slide 118 text

117 • 2 章で検証した設定の、実際の開発環境への導入 – Consul + Atlas – Vagrant + VirtualBox + Cloudera QuickStart VM – サンプルアプリの範囲を超えても、問題なく動作するか • Packer, Terraform, Vault の導入検討 – GMO アプリクラウド、ConoHa への適用も含めて検討 • いわゆる DevOps ツールの動向調査 – Otto のアップデート状況 – Docker Machine, Docker Compose 今後の課題