Chef ProvisioningとDockerでConsul Templateのテスト環境を作成する #getchef #docker #consul
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
はじめに
本稿では、Chef Provisioning と Docker を用いて Consul Template のテスト環境を作成してみます。Chef Provisioning と Docker については「Chef ProvisioningとDockerでSerfクラスタ環境を作成する」を、Consul クラスタについては「Chef ProvisioningとVagrantでConsulクラスタ環境を作成する」を参照してください。本稿で使用したソースコードはすべて https://github.com/cl-lab-k/chef-consul-docker-cluster にあります。
事前準備
実験は Debian GNU/Linux 8.1 上で行いました。以下のパッケージやプラグインをインストールしています。
- Chef-DK 0.6.2
- Vagrant 1.7.2
- Vagrant プラグイン: vagrant-hostsupdater 0.0.11
- Vagrant プラグイン: vagrant-cachier 1.2.0
- VirtualBox 4.3.28
ソースコードの取得
https://github. com/cl-lab-k/chef-consul-docker-cluster/tree/sample_blog を clone します。
% git clone https://github.com/cl-lab-k/chef-consul-docker-cluster -b sample_blog
Cloning into 'chef-consul-docker-cluster'...
:
% cd chef-consul-docker-cluster
%
以降はこのツリー内で作業を行います。
VM の作成
Vagrant を用いて、今回の実験用の仮想マシンを作成します。
% ls -la
合計 28
drwxr-xr-x 5 dai dai 240 7月 9 19:17 .
drwxrwxrwt 23 root root 680 7月 10 11:45 ..
drwxr-xr-x 8 dai dai 300 7月 9 19:46 .git
-rw-r--r-- 1 dai dai 172 7月 6 15:20 .gitignore
-rw-r--r-- 1 dai dai 140 7月 6 15:29 Berksfile
-rw-r--r-- 1 dai dai 824 7月 6 12:50 README.md
-rw-r--r-- 1 dai dai 598 7月 1 12:50 Rakefile
-rw-r--r-- 1 dai dai 511 7月 9 14:57 Vagrantfile
-rw-r--r-- 1 dai dai 1114 6月 30 12:11 chefignore
-rw-r--r-- 1 dai dai 344 7月 6 15:54 metadata.rb
drwxr-xr-x 3 dai dai 60 6月 30 18:26 provisioning
drwxr-xr-x 2 dai dai 60 7月 6 12:50 recipes
%
作成する VM の設定は Vagrantfile ファイルで行えます。初期設定では、Box は chef/ubuntu-14.04、IP アドレスは 192.168.33.101、メモリは 8192M の設定となっています。一連の作業は基本的に rake タスクとして定義してあります。デフォルトでは berks vendor サブコマンドを実行して chef-dk Cookbook、docker Cookbook、git Cookbook を取得し、Vagrant によって VirtualBox VM を作成します。起動した VM には Chef Zero Provisioner を用いて chef-consul-docker-cluster::default Recipe を適用し、Docker のインストールと起動、vagrant ユーザの所属グループの変更、chef-provisioning-docker のインストールを行い、Chef Provisioner Docker 用のファイルを VM に転送します。
% rake
berks vendor cookbooks
Resolving cookbook dependencies...
:
:
:
vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
:
:
:
scp -i /tmp/chef-consul-docker-cluster/.vagrant/machines/default/virtualbox/private_key -P 2222 -r /tmp/chef-consul-docker-cluster/provisioning/docker vagrant@127.0.0.1:
:
:
:
%
VM 内で Chef Provisioning Docker を実行
作成した VM にログインします。
% vagrant ssh
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-24-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Tue Oct 21 14:52:42 2014 from 10.0.2.2
vagrant@vagrant:~$
先程 VM に scp したディレクトリがあるので、そちらに移動します。
vagrant@vagrant:~$ cd docker
vagrant@vagrant:~/docker$ ls -la
total 20
drwxr-xr-x 7 vagrant vagrant 4096 Jul 10 01:05 .
drwxr-xr-x 7 vagrant vagrant 4096 Jul 10 00:59 ..
-rw-r--r-- 1 vagrant vagrant 323 Jul 10 00:58 Berksfile
-rw-r--r-- 1 vagrant vagrant 2033 Jul 10 00:58 Rakefile
-rw-r--r-- 1 vagrant vagrant 188 Jul 10 00:58 atlas.json
drwxr-xr-x 5 vagrant vagrant 4096 Jul 10 00:58 consul-client-config
-rw-r--r-- 1 vagrant vagrant 1155 Jul 10 00:58 consul-client.rb
-rw-r--r-- 1 vagrant vagrant 1004 Jul 10 00:58 consul-server.rb
vagrant@vagrant:~/docker$
ここでは chef-provisioning-docker を用いて、Docker 社の公式レポジトリの ubuntu:14.04 イメージから Consul 用イメージを作成し、それを基に 7つ Consul 用コンテナを起動します。そのうち 3つは Consul Server 用、別の 4つは Consul Client 用で、起動したコンテナは自動的にクラスタを構成します。
Consul クラスタの構成には Atlas の Auto-Join を利用しています。atlas.json には Atlas のアカウントと API トークンを記載します。Atlas を用いた Consul クラスタの自動構成についての詳細は「Consulサーバクラスタ構成手順の歴史」参照してください。
なお、この chef-consul-docker-cluster/provisioning/docker は VM 内でなくとも実機上で実行が可能ですので、興味があれば各自試してみてください。
こちらも作業は rake タスクとして定義してあります。ただし、この VM には Ubuntu 公式の rake パッケージが入っていないため、代わりに chef-dk 同梱の /opt/chefdk/embedded/bin/rake を実行してください。
vagrant@vagrant:~/docker$ /opt/chefdk/embedded/bin/rake
berks vendor cookbooks
Resolving cookbook dependencies...
Fetching 'consul' from https://github.com/johnbellone/consul-cookbook.git (at 10d582a)
Fetching 'consul-client-config' from source at consul-client-config
Fetching cookbook index from https://supermarket.chef.io...
Installing 7-zip (1.0.2)
Installing apt (2.7.0)
Installing ark (0.9.0)
Installing bluepill (2.3.1)
Installing build-essential (2.2.3)
Installing chef-provisioning (0.1.2)
Installing chef_handler (1.2.0)
Using consul (0.10.0) from https://github.com/johnbellone/consul-cookbook.git (at 10d582a)
Using consul-client-config (0.1.0) from source at consul-client-config
Installing consul-template (0.8.0)
Installing golang (1.5.1)
Installing libarchive (0.4.4)
Installing nginx (2.7.6)
Installing ohai (2.0.1)
Installing packagecloud (0.0.19)
Installing python (1.4.6)
Installing rsyslog (2.0.0)
Installing runit (1.7.2)
Installing supervisor (0.4.12)
Installing windows (1.37.0)
Installing yum (3.6.1)
Installing yum-epel (0.6.2)
Installing yum-repoforge (0.5.3)
:
:
:
まず Berkshelf を使って、必要な consul Cookbook、nginx Cookbook、supervisor Cookbook の取得を行っています。
CHEF_DRIVER=docker chef-client -z consul-server.rb
[2015-07-10T00:59:36+00:00] WARN: No config file found or specified on command line, using command line options.
Starting Chef Client, version 12.3.0
resolving cookbooks for run list: []
Synchronizing Cookbooks:
Compiling Cookbooks...
[2015-07-10T00:59:37+00:00] WARN: Node vagrant.vm has an empty run list.
Converging 4 resources
Recipe: @recipe_files::/home/vagrant/docker/consul-server.rb
* machine_image[consul-server] action create
- create node consul-server at chefzero://localhost:8889
:
:
:
chef-provisioning-docker を利用して、Consul Server 用の Docker イメージを作成します。この際、Cookbook の適用には Chef-Zero を用いています。
* machine[consul101] action converge
- create node consul101 at chefzero://localhost:8889
:
:
:
* machine[consul102] action converge
- create node consul102 at chefzero://localhost:8889
:
:
:
* machine[consul103] action converge
- create node consul103 at chefzero://localhost:8889
:
:
:
Running handlers:
Running handlers complete
Chef Client finished, 4/4 resources updated in 346.418441609 seconds
引き続き、chef-provisioning-docker を利用して、Consul Server 用の Docker イメージからコンテナを作成していきます。ここでも Chef-Zero を活用しています。
Consul Client 用の Docker コンテナは Using Supervisor with Docker を参考に、Supervisor を起動し、その管理下に複数サービスを持つ形とします。supervisord は provisioning/docker/consul-client.rb にある通り --nodaemon オプションを付与してフォアグラウンドで起動し、nginx は provisioning/docker/consul-client-config/recipes/default.rb にある通り -g "daemon off;" オプションを付与してフォアグラウンドで起動します。
4つの Consul Client 用の Docker コンテナのうち 3つは supervisor + Consul Client + Nginx で、もう 1つは Consul Template を起動しています。Consul Template とは、Consul のイベントを受けてファイルの更新とコマンドの実行を行うエージェントプログラムです。
ここでは 3つのウェブサーバへの振り分けを行うロードバランサを設置するとします。ロードバランサは Consul を通して各ウェブサーバの死活監視を行い、Consul Template を用いて設定ファイルの書き換えとサービスの再起動を行うようにしています。Consul Template は、後述する「lb.ctmpl」というファイルを使ってロードバランシング先の IP アドレスの情報を書き換えます。
Docker コンテナの確認
起動した Docker コンテナの状態を確認してみましょう。
vagrant@vagrant:~/docker$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a8e92ba7c3f3 db88494d511925db26ed56f9aaf647f3e44eccac98dea5f9a69583b1d00ed3d3:latest "/usr/local/bin/supe 2 hours ago Up 2 hours consul119
cc83ba6cef94 f28aa99c791d71900a7a2b9228d7272bd669694d7a148950688e113ea99b0dd3:latest "/usr/local/bin/supe 2 hours ago Up 2 hours consul113
d1080ac64af5 060d5ac515ab7a3b2aad5bb6d52f42a72c269270fe21729a2872d26dfd556613:latest "/usr/local/bin/supe 2 hours ago Up 2 hours consul112
8635f1f53cb2 3e220e8ee57fce19140de264863ed5608fc9331b8926c828f27b5fb041b73d64:latest "/usr/local/bin/supe 2 hours ago Up 2 hours consul111
495dca2561e9 861dd3d598149ce30f396d2beb11cc32d3166936e6284e93238333a4d252f7e5:latest "/usr/local/bin/cons 2 hours ago Up 2 hours consul103
0df300a44541 5bba85c070f97a65322f2cb8670095b72e7ba2ff4071f56e60eb19dd12ebeb06:latest "/usr/local/bin/cons 2 hours ago Up 2 hours consul102
603808f3229e da15b948e41a58445caaeb3c182065571d81d34948e2681bc330964d908996a0:latest "/usr/local/bin/cons 2 hours ago Up 2 hours consul101
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ ps auxwwwf
:
root 4044 0.1 0.2 852812 24456 ? Ssl 00:58 0:16 /usr/bin/docker -d --ip-forward=true --log-level=info --tls=true
root 10944 0.6 0.2 33903548 19740 ? Ssl 01:05 0:51 \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 11471 1.3 0.2 34043904 20184 ? Ssl 01:05 1:49 \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 12025 0.6 0.2 33904636 17732 ? Ssl 01:05 0:51 \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 20379 0.0 0.1 57828 13388 ? Ss 01:11 0:01 \_ /usr/bin/python /usr/local/bin/supervisord --nodaemon
root 20609 0.2 0.1 287412 15276 ? Sl 01:11 0:22 | \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 20610 0.0 0.0 85876 4152 ? S 01:11 0:00 | \_ nginx: master process /usr/sbin/nginx -g daemon off;
www-data 20616 0.0 0.0 86216 2280 ? S 01:11 0:00 | \_ nginx: worker process
root 20937 0.0 0.1 57828 13392 ? Ss 01:11 0:01 \_ /usr/bin/python /usr/local/bin/supervisord --nodaemon
root 21125 0.2 0.1 352948 13208 ? Sl 01:11 0:21 | \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 21126 0.0 0.0 85876 4148 ? S 01:11 0:00 | \_ nginx: master process /usr/sbin/nginx -g daemon off;
www-data 21132 0.0 0.0 86216 2276 ? S 01:11 0:00 | \_ nginx: worker process
root 21483 0.0 0.1 57828 13392 ? Ss 01:12 0:01 \_ /usr/bin/python /usr/local/bin/supervisord --nodaemon
root 21675 0.2 0.1 352948 15188 ? Sl 01:12 0:21 | \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 21676 0.0 0.0 85876 4152 ? S 01:12 0:00 | \_ nginx: master process /usr/sbin/nginx -g daemon off;
www-data 21683 0.0 0.0 86216 2276 ? S 01:12 0:00 | \_ nginx: worker process
root 22507 0.0 0.1 57848 13408 ? Ss 01:13 0:01 \_ /usr/bin/python /usr/local/bin/supervisord --nodaemon
root 22536 0.0 0.0 8988 3796 ? Sl 01:13 0:00 \_ /usr/local/bin/consul-template -config /etc/consul-template.d
root 22539 0.2 0.1 344752 15556 ? Sl 01:13 0:19 \_ /usr/local/bin/consul agent -config-dir /etc/consul.d
root 22540 0.0 0.0 85876 4148 ? S 01:13 0:00 \_ nginx: master process /usr/sbin/nginx -g daemon off;
www-data 22547 0.0 0.0 86232 2284 ? S 01:13 0:00 \_ nginx: worker process
:
vagrant@vagrant:~/docker$
このように、Consul 用コンテナが 7つと所属する各種サービスが起動しています。
コンテナ内で consul members を行う rake タスクを用意してあるので、実行してみます。
vagrant@vagrant:~/docker$ /opt/chefdk/embedded/bin/rake members
:
:
:
docker exec 603808f3229e consul members
Node Address Status Type Build Protocol DC
495dca2561e9 172.17.0.37:8301 alive server 0.5.2 2 dc1
8635f1f53cb2 172.17.0.58:8301 alive client 0.5.2 2 dc1
d1080ac64af5 172.17.0.66:8301 alive client 0.5.2 2 dc1
cc83ba6cef94 172.17.0.74:8301 alive client 0.5.2 2 dc1
a8e92ba7c3f3 172.17.0.82:8301 alive client 0.5.2 2 dc1
603808f3229e 172.17.0.21:8301 alive server 0.5.2 2 dc1
0df300a44541 172.17.0.29:8301 alive server 0.5.2 2 dc1
vagrant@vagrant:~/docker$
このように Consul クラスタが構成されています。
ロードバランサの状態を確認してみます。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 cat /etc/nginx/sites-enabled/default
upstream lb_units {
server 172.17.0.58;
server 172.17.0.74;
server 172.17.0.66;
}
server {
listen 80;
server_name 4670d624aee6;
location / {
proxy_pass http://lb_units;
proxy_set_header Host $http_host;
}
}
vagrant@vagrant:~/docker$
provisioning/docker/consul-client-config/templates/lb.ctmpl.erb の server_name を Chef が置き換えて生成した lb.ctmpl のロードバランシング先の IP アドレスを Consul Template が展開し、upstream とするウェブサーバが 3台登録されています。Consul テンプレートの書式は Introducing Consul Template や hashicorp/consul-template を参照してください。
実際にアクセスしてみます。今回はポートを外に出していないので、コンテナ内で確認します。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$
このように各ウェブサーバに振り分けされていることがわかります。
Consul Client コンテナの停止・起動
手動でウェブサーバ用の Consul Client コンテナを 1つ停止してみましょう。docker stop コマンドを使います。
vagrant@vagrant:~/docker$ docker stop cc83ba6cef94
cc83ba6cef94
vagrant@vagrant:~/docker$
rake members タスクを実行してみます。
vagrant@vagrant:~/docker$ rake members
:
docker exec 603808f3229e consul members
Node Address Status Type Build Protocol DC
a8e92ba7c3f3 172.17.0.82:8301 alive client 0.5.2 2 dc1
603808f3229e 172.17.0.21:8301 alive server 0.5.2 2 dc1
0df300a44541 172.17.0.29:8301 alive server 0.5.2 2 dc1
495dca2561e9 172.17.0.37:8301 alive server 0.5.2 2 dc1
8635f1f53cb2 172.17.0.58:8301 alive client 0.5.2 2 dc1
d1080ac64af5 172.17.0.66:8301 alive client 0.5.2 2 dc1
cc83ba6cef94 172.17.0.74:8301 failed client 0.5.2 2 dc1
vagrant@vagrant:~/docker$
停止したコンテナの Status が failed になっています。
ロードバランサの状態を確認してみます。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 cat /etc/nginx/sites-enabled/default
upstream lb_units {
server 172.17.0.58;
server 172.17.0.66;
}
server {
listen 80;
server_name 4670d624aee6;
location / {
proxy_pass http://lb_units;
proxy_set_header Host $http_host;
}
}
vagrant@vagrant:~/docker$
停止したぶん 1つ upstream が減っています。実際にアクセスしてみます。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$
書き換えられた設定ファイルを反映するためのサービスの再起動が自動的に行われていて、振り分け先が 2つになっていることがわかります。
では、停止した Consul Client コンテナを docker start コマンドで起動します。
vagrant@vagrant:~/docker$ docker start cc83ba6cef94
cc83ba6cef94
vagrant@vagrant:~/docker$
同様の手順で確認していきます。
vagrant@vagrant:~/docker$ rake members
:
docker exec 603808f3229e consul members
Node Address Status Type Build Protocol DC
a8e92ba7c3f3 172.17.0.82:8301 alive client 0.5.2 2 dc1
603808f3229e 172.17.0.21:8301 alive server 0.5.2 2 dc1
0df300a44541 172.17.0.29:8301 alive server 0.5.2 2 dc1
495dca2561e9 172.17.0.37:8301 alive server 0.5.2 2 dc1
8635f1f53cb2 172.17.0.58:8301 alive client 0.5.2 2 dc1
d1080ac64af5 172.17.0.66:8301 alive client 0.5.2 2 dc1
cc83ba6cef94 172.17.0.83:8301 alive client 0.5.2 2 dc1
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 cat /etc/nginx/sites-enabled/default
upstream lb_units {
server 172.17.0.58;
server 172.17.0.83;
server 172.17.0.66;
}
server {
listen 80;
server_name 4670d624aee6;
location / {
proxy_pass http://lb_units;
proxy_set_header Host $http_host;
}
}
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$
再び 3つの upstream に振り分けられるようになりました。
Nginx サービスの停止・起動
今度は Consul Client コンテナ自体を停止するのではなく、コンテナ内の Nginx サービスだけを停止してみます。
provisioning/docker/consul-client-config/files/web.json にある通り、Consul Client は Nginx サービスの監視を行っています。
まずコンテナ内のサービスを確認してみます。
vagrant@vagrant:~/docker$ docker exec cc83ba6cef94 supervisorctl status
consul_client RUNNING pid 7, uptime 0:08:19
nginx_server RUNNING pid 8, uptime 0:08:19
vagrant@vagrant:~/docker$
kill コマンドでサービスを kill することもできますが supervisord がすぐに起動し直してしまうので、supervisorctl stop でサービスを停止します。
vagrant@vagrant:~/docker$ docker exec cc83ba6cef94 supervisorctl stop nginx_server
nginx_server: stopped
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec cc83ba6cef94 supervisorctl status
consul_client RUNNING pid 7, uptime 0:09:18
nginx_server STOPPED Jul 10 03:57 AM
vagrant@vagrant:~/docker$
サービスを停止しました。
rake members タスクを実行してみます。
vagrant@vagrant:~/docker$ rake members
:
docker exec 603808f3229e consul members
Node Address Status Type Build Protocol DC
a8e92ba7c3f3 172.17.0.82:8301 alive client 0.5.2 2 dc1
603808f3229e 172.17.0.21:8301 alive server 0.5.2 2 dc1
0df300a44541 172.17.0.29:8301 alive server 0.5.2 2 dc1
495dca2561e9 172.17.0.37:8301 alive server 0.5.2 2 dc1
8635f1f53cb2 172.17.0.58:8301 alive client 0.5.2 2 dc1
d1080ac64af5 172.17.0.66:8301 alive client 0.5.2 2 dc1
cc83ba6cef94 172.17.0.84:8301 alive client 0.5.2 2 dc1
vagrant@vagrant:~/docker$
コンテナ自体、あるいは Consul Client エージェントを停止したわけではなので、Consul クラスタ内に留まり続けています。
同様の手順で確認していきます。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 cat /etc/nginx/sites-enabled/default
upstream lb_units {
server 172.17.0.58;
server 172.17.0.66;
}
server {
listen 80;
server_name 4670d624aee6;
location / {
proxy_pass http://lb_units;
proxy_set_header Host $http_host;
}
}
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$
このように Nginx サービスを停止したらクラスタから外されていることがわかります。
Nginx サービスを再開します。
vagrant@vagrant:~/docker$ docker exec cc83ba6cef94 supervisorctl start nginx_server
nginx_server: started
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec cc83ba6cef94 supervisorctl status
consul_client RUNNING pid 7, uptime 0:45:39
nginx_server RUNNING pid 614, uptime 0:00:10
vagrant@vagrant:~/docker$
同様の手順で確認していきます。
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 cat /etc/nginx/sites-enabled/default
upstream lb_units {
server 172.17.0.58;
server 172.17.0.84;
server 172.17.0.66;
}
server {
listen 80;
server_name 4670d624aee6;
location / {
proxy_pass http://lb_units;
proxy_set_header Host $http_host;
}
}
vagrant@vagrant:~/docker$
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
2646f38ba78b
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
3c9f3015715d
vagrant@vagrant:~/docker$ docker exec a8e92ba7c3f3 curl http://127.0.0.1/ 2> /dev/null
b8f0aed7b0cd
vagrant@vagrant:~/docker$
再び 3つの upstream に振り分けられるようになりました。
まとめ
本稿では、Chef Provisioning と Docker を用いて Consul Template のテスト環境を作成しました。手軽かつ確実にサービスの構成変更が可能であることがおわかりいただけたと思います。
本実験では Consul Template の動作確認のみに焦点を絞ったので、Chef Provisioning、Docker、Consul や Consul Template そのものにも深く見ていません。それぞれの詳細考察に関しては今後の課題です。
Author
Chef・Docker・Mirantis製品などの技術要素に加えて、会議の進め方・文章の書き方などの業務改善にも取り組んでいます。「Chef活用ガイド」共著のほか、Debian Official Developerもやっています。
