【参考訳】Docker Machine 0.3.0 Deep Dive

【参考訳】Docker Machine 0.3.0 Deep Dive はてなブックマーク - 【参考訳】Docker Machine 0.3.0 Deep Dive


先日、Docker 社の blog に「Docker Machine 0.3.0 Deep Dive」という、Docker Machine の新機能に関する詳しい記事が出ていました。手許で日本語に訳していたのですが、例によって死蔵するのもアレなので、内容未保証ですが放流します。例によって、参考程度にどうぞ。

開発途上であり、Docker Machine は本番環境での利用は推奨されていませんが、もし興味がありましたら、何らかの参考になればと思っています。

■ Docker Machine 0.3.0 Deep Dive

Docker 社のオープンソース・エンジニア Nathan LeClaire による投稿です。

私達は最近 Docker Machine 0.3.0 をリリースしました。私はプロジェクトのメンテナです。そして、前回のリリースから数ヶ月に渡って、組み込みに注力してきた利点についてを共有したいと思います。

■ おさらい

あまり慣れてない方向けに整理すると、Docker Machine とは、Docker が利用できるマシンの自動生成・設定を簡単にするためのツールです。そして、ローカルの VirtualBox で動いている仮想マシン上でも、Amazon Web Services のようなクラウド・プロバイダ上でも動作します。これは由緒ある boot2docker コマンドライン・ツール(以下 CLI )の崇高なる継承ツールです(最終的には置き換えられます)。Docker Machine によって、素早く接続できて、TLS の自動設定を用いて安全なDocker を扱えるインスタンスを非常に早く準備できるようになるので、私は嬉しく思います。そして、とても便利だと思っているのは、ローカルの仮想マシンだけでなく、クラウド・プロバイダ上で動いている仮想マシンも同様に管理できる点です。

基本的な Docker Machine を起動するには、次のように実行します:

$ docker-machine create --driver virtualbox dev

このコマンドによって、ローカルで稼働している VirtualBox 上で Docker が使えるマシンを作成し、Docker CLI を使うことで、適切な箇所へ接続できるようになります。同じ Machine コマンド(訳注;docker-machine)を使って、作成した仮想マシンの起動・停止や SSH ログインが可能です。

今回のリリースでは、これらを拡張する面白い機能を複数追加しましたので、今日はそれらのいくつかを紹介します。私達が取り組んだのは次の点です:

  1. 既存のマシンを取り込むための generic ドライバ
  2. 作成時に Docker Engine のオプションを設定
  3. 作成時に Docker Swarm の strategy(訳注;コンテナ分散方式の指定)を設定
  4. docker-machine scp を使ってマシンからマシンへのファイルのコピー
  5. 既存の boot2docker 仮想マシン上から Docker Machine への取り込み( import )
  6. 基本的なオペレーティング・システムに RancherOS や Red Hat などを対応

この他にもいくつかの機能を追加しましたが、ここでは取り扱いません。詳細についてはリリースノートをご覧ください。

■ 既存のマシンを取り込むための generic ドライバ

もし Docker Machine を使って作成されていない SSH が可能なマシンがあれば、他の Docker Machine で作成したホストと同様に管理したいと思いませんか? あるいは、Docker Machine に取り込む方法や、TLS/Swarm を使ったプロビジョニングに比べた利点や、マシン作成時にセットアップする方法を知りたくありませんでしたか?

以前であれば、これらを解決する方法ありませんでした。しかし、最近マージされた generic ドライバが取り込まれたリリースでは、これら全てが変わりました。

問題となっているマシンに SSH 接続ができるのであれば、そのマシンを Docker Machine に取り込めるようになりました。

$ docker-machine create -d generic \
--generic-ssh-user ubuntu \
--generic-ssh-key ~/Downloads/manually_created_key.pub \
--generic-ip-address 12.34.56.78 \
jungle

これにより、実行中のインスタンス上に Docker のインストールが可能であり(Docker Machine とは別に作ったインスタンスであり、おそらく AWS CLI で作成したものも)、TLS を使って安全に通信して設定をおこない、似たようなワークフローでマシンを「取り込む」ことができます。

$ eval "$(docker-machine env jungle)"
$ docker info
...
$ docker-machine ssh jungle
Welcome to Ubuntu! etc.
...

Swarm オプションを指定する事で、適切な Swarm コンテナを準備することもできます。これにより、Docker や TLS、Swarm の初期設定に必要とされていた苦労をとても和らげるため、あなた自身やマシンにプロビジョニングするという負担を減らします。まだ完全ではありませんが、正しい方向への大きな一歩であると信じています。これは AnsibleTerraform といったツールと一緒に Machine を使うという、新しく創造的な手法にドアを開くものです。これは、後の章で明確にします。

もし興味があれば、このドライバと Swarm に関して少し肉付けされた記事を、私の 0.3.0 Sneak Preview 記事をお読みください。

■ 作成時に Docker Engine の設定を行う

ご存知かご存知ではないかもしれませんが、コンテナ実行時などで適切な振る舞いを行えるように、Docker デーモンの実行時に非常に多くのフラグを指定できます。この中にはストレージ・ドライバのように重要なものも含まれています。

従来は、とりわけ不慣れなユーザにとっては、自分自身で各種の設定やフラグを試すことは時間を消費しますし厭なものでした。具体的には:

  1.  適切な設定ファイルを探し出し、必要に応じて編集する。例:boot2docker の /var/lib/boot2docker/profile や Ubuntu の /etc/default/docker など。
  2. 必要なフラグを設定するか、フラグに応じて適切な環境変数の指定。
  3. デーモンの再起動(OSによって方法が異なる。例:boot2docker では sudo /etc/init.d/docker を実行する。あるいは Debian ベース等のディストリビューションであれば sudo service docker restart)。
  4. 正常に処理されたか確認。もし動作しなければ、Docker デーモンのログを確認し、何が問題か確認したり、デバッグを行う。
  5. 失敗したら 1~4 を繰り返す。

Docker Machine は、実行時にOS に依存する繰り返し手順を減らします(新しい実装のために問題もいくつかありますが、基本的な考えはここにあります)。Docker デーモン実行時に指定すべきフラグは、docker-machine create コマンドの –engine- で始まるフラグのサブクラスとして利用できます。

そして、いくつか頻繁に利用されると予想される、新しい「トップレベル」のフラグをサポートしました。たとえば –engine-storage-driver によって、aufs、devicemapper、overlay 等のどれを使うかや、–engine-insecure-registry によって安全ではないレジストリへの接続を行うかどうか指定します(プライベートなレジストリにおけるテストで見受けられます)。さらに、個々のデーモンに対してフラグを指定する「arbitrary flag」(訳注;任意のフラグの意味)オプションは、–engine-opt に key=value ペアを指定することで何でも設定できます。そのため、様々な設定が行われている Docker デーモンを作成しても、それらを混ぜ合わせて一緒に扱えます。

Docker Machine の性質上、これは Docker デーモンが様々な設定を持つマシンを複数並べられることを意味します。私はこれがテストや評価に役立つと思います。この機能が役立つかもしれない例を、いくつか見ていきましょう。

有用な例としては、別のストレージ・ドライバを試したいときです。ご存知かもしれませんが、Docker で階層化されたコピー・オン・ライトのファイルシステムは、ブードゥー教の階層のような働きをするもので、様々な「ドライバ」のオプションが使えます。aufs が一般的なものであり、boot2docker では標準です。

興味深いことに、最近より軽量な OverlayFS のサポートが Docker に取り込まれました。OverlayFS を使うには Kernel 3.18 以上が必要になるため、overlay を使うには boot2docker 1.6 以上に含まれる kernel が必要です。これは Docker Machine 0.3.0 を使えば簡単になります:

$ docker-machine create -d virtualbox --engine-storage-driver overlay overlay
....
$ eval "$(docker-machine env overlay)"
$ docker info
...
Storage Driver: overlay
Backing Filesystem: extfs
...

(メモ:ローカルに「キャッシュ」されている boot2docker.iso が古すぎる場合は、デーモンを起動時にオプションを指定するよりも、docker-machine upgrade を実行することになるでしょう)

先ほどの結果のように、「docker info」コマンドを使って、作成したデーモンが overlay ストレージ・ドライバを使っていることを確認できます。

これだけでストレージ・ドライバを指定できます! 先ほど書いたように、Docker Machine の -engine-* フラグを使えば、他のあらゆる設定が可能です。たとえば、Google の DNS サーバーを使いたいときは、-dns=8.8.8.8 を指定してエンジンを起動します。あるいは、Swarm スケジューリングのためにデーモンに label を追加することもできます(SSD など、マシンのディスク IO に応じて書き換えることになるでしょう)。他にも、デーモンが常にログの出力先を syslog に指定するよう -log-driver フラグを使う事もあるでしょう。

これらを指定して作成するには、次のようになります:

$ docker-machine create -d virtualbox \
--engine-label disktype=ssd \
--engine-label distro=b2d \
--engine-opt dns=8.8.8.8 \
--engine-opt log-driver=syslog \
hotrod
...

作成後は docker-machine ssh コマンドを使って作成したサーバに入り、いろいろ見てみましょう。

この時点では syslog に何も記録されていないかもしれませんが、コンテナを実行しますと、何かしら記録がされるでしょう。これは、デーモンがログ・ドライバに「syslog」を使うよう指定を変更した直後のためです。以降のログは自動的にシステム・ログとして記録されるようになり、そこには、これまで JSON 形式で Docker から参照する必要があったものも含まれます。

$ docker-machine ssh hotrod
Welcome to Ubuntu ...
root@hotrod:~# cat /var/log/syslog
root@hotrod:~# docker run -d busybox nslookup google.com
7901f1e34f24f173f39c907d290ea57a6aadf6f752e0e853c57440c576951d8c
root@hotrod:~# cat /var/log/syslog
May 28 20:11:17 hotrod kernel: [ 1662.659979] device vethc485759 entered promiscuous mode
May 28 20:11:17 hotrod kernel: [ 1662.662329] IPv6: ADDRCONF(NETDEV_UP): vethc485759: link is not ready
May 28 20:11:17 hotrod kernel: [ 1662.689506] IPv6: ADDRCONF(NETDEV_CHANGE): vethc485759: link becomes ready
May 28 20:11:17 hotrod kernel: [ 1662.689571] docker0: port 1(vethc485759) entered forwarding state
May 28 20:11:17 hotrod kernel: [ 1662.689582] docker0: port 1(vethc485759) entered forwarding state
May 28 20:11:17 hotrod docker/7901f1e34f24[3540]: Server:   8.8.8.8
May 28 20:11:17 hotrod docker/7901f1e34f24[3540]: Address 1: 8.8.8.8 google-public-dns-a.google.com
May 28 20:11:17 hotrod docker/7901f1e34f24[3540]:
May 28 20:11:17 hotrod docker/7901f1e34f24[3540]: Name:     google.com
May 28 20:11:17 hotrod docker/7901f1e34f24[3540]: Address 1: 173.194.123.67 lga15s48-in-f3.1e100.net
(省略)

ログファイルには、このように docker/7901f1e34f24 の形式で(この ID は実行時によって異なります)の形式で表示されます。

なお、docker info でデーモンのラベルを参照できます:

root@hotrod:~# docker info
...
Labels:
disktype=ssd
os=ubuntu
provider=digitalocean

■ Docker Swarm の strategy を作成時に設定する

Docker Machine は、Docker Engine のインストールや設定をするだけでなく、Swarm を初期設定する便利なゲートウェイです。

これまでも Docker Hub ディスカバリをサポートしてきましたが、このリリース時点で swarm を使うには、Swarm コンテナのパラメータをカスタマイズして利用する必要がありました。

たとえば、Swarm のコンテナをスケジューリングするデフォルトの strategy は spread ですが、実際に効率的なのは binpack strategy でしょう(binpack は可能な限り展開先のホストを絞るもので、一方の spread は可能な限り分散します)。この Swarm マスタのオプションを指定するには -swarm-stragey フラグを使います。他にも調整のためには、Docker Engine と同じように Swarm マスタのオプションを -swarm-opt で指定できます。例えば swarm の hartbeat をセットするには、次のようにします。

以下の実行例では、Swarm マスタに対して3つのオプションを指定します:

$ docker-machine create -d virtualbox \
--swarm \
--swarm-master \
--swarm-discovery token://<token> \
--swarm-strategy binpack \
--swarm-opt heartbeat=45 \
queenbee

■ マシンからマシンに docker-machine scp でファイルをコピーする

一見すると単純なものですが、私にとっては非常に役立つものです。

既に紹介しているように、docker-machine scp コマンドによって、Docker Machine を実行したホストから作成したマシンに対してファイルを移したり、あるいは、マシンからマシンへと移したりします。

リソースに余裕がないリモートマシンがあったとしても、ローカルのマシンから簡単にファイルを移せます。

使い方の基本になるのはマシン名であり、一般的な scp の文法に似ています。例:

$ docker-machine scp -r droplet:/tmp/build_artifacts .

■ 既存の boot2dockre 仮想マシンから Docker Machine への取り込み

多くのユーザが boot2docker-cli を使って、たくさんのコンテナやイメージを作っていると思いますので、Docker Machine を使って新しい仮想マシンを管理するのはまだ早いと考えているでしょう。そのようなあなたに良いニュースです。既存の boot2docker 仮想マシンには新しいフラグ、-virtualbox-import-boot2dokcer-vm を紹介します。これを使うには、boot2docker 仮想マシン(デフォルトの名前は boot2docker-vm)の名前を指定するだけです。

$ docker-machine create -d virtualbox --virtualbox-import-boot2docker-vm boot2docker-vm b2d

実行しますと VM で作られた全てのコンテナとイメージが確認できますし、これまでの boot2docker VM は、そのまま残ります。

■ RancherOS や Red Hat 等のベース OS をサポート

Docker Machine 0.3.0 からはプロビジョニング・システムを拡張しました。これまで利用可能な OS は Ubuntu か boot2docker のみでした。これらは標準のままですが、Docker のインストールや設定のために他のオプションが選べるようになったことを紹介します。

新しくサポートした OS の1つに RancherOS があります。これは Docker コンテナを動作させるため、cron や ntpd のようなサービスのみを含む最小 OS の1つです。今回のリリースの発表にあたり、Docker Machine から RancherOS を操作できるよう、多大な貢献をした Darren Shepherd に大きな感謝を表明します。

使うには以下のように簡単にコマンドを実行するだけです(Rancher は Docker Machine に対応で ISO をリリースしています。現時点では Docker 1.7 向けですが、より新しいものが出たら、そちらを使うことを強く推奨します)。そうすると、ローカルに RancherOS の仮想マシンを作成できます。

$ docker-machine create -d virtualbox \
--virtualbox-boot2docker-url https://github.com/rancherio/os/releases/download/v0.3.1/machine-rancheros.iso \
rancheros

なお、次のオプション、

--virtualbox-boot2docker-url

これは、リリースのタイミングで名前がもしかしたら変わるかもしれないので注意ください。作成後は中をのぞいてみましょう。

まず、SSH で作成した仮想マシンに入ります:

$ docker-machine ssh rancheros

中では Docker デーモンが次のように動いているのが分かります。

[docker@rancheros ~]$ ps -e | grep 'docker -d'
1 root     {system-docker} docker -d --log-driver syslog -s overlay -b docker-sys --fixed-cidr 172.18.42.1/16 --restart=false -g /var/lib/system-docker -G root -H unix:///var/run/system-docker.sock
1232 root     docker -d -s overlay -G docker -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver overlay --tlsverify --tlscacert /var/lib/rancher/conf/ca.pem --tlscert /var/lib/rancher/conf/server.pem --tlskey /var/lib/rancher/conf/server-key.pem --label provider=virtualbox
1386 docker   grep docker -d

注意して欲しいことの1つは、/var/run/docker.sock と TCP:2376 をリッスンしていることです。これらは通常、Docker Machine によって作成された仮想マシン上で見られるものです。これは「user docker」と呼ばれており、ユーザがウェブアプリや何らかの機能を持ったコンテナを実行する時、Docker と双方向にやりとりします。一方、ここでは別の Docker デーモンも稼働しており、/var/run/system-docker.sock をリッスンしています。どういうことでしょうか?

これは、RancherOS においては cron のようなシステム・プロセスを管理するために “system docker” を使うからです。Docker の -H (ホスト)フラグを使って、中を見ることが出来ます。

[docker@rancheros ~]$ sudo docker -H unix:///var/run/system-docker.sock ps
CONTAINER ID     IMAGE       COMMAND       CREATED                     STATUS       PORTS       NAMES
ac31a2242ff4   ntp:latest   "/usr/sbin/entry.sh   10 minutes ago   Restarting (0) 3 minutes ago   ntp
4e7364981fc5   console:latest "/usr/sbin/entry.sh   10 minutes ago   Up 10 minutes   console
1f5ba4d221fd   docker:latest   "/usr/sbin/entry.sh   10 minutes ago   Up 10 minutes   docker
b6f959e73c69   acpid:latest   "/usr/sbin/entry.sh   10 minutes ago   Up 10 minutes   acpid
f3b1fbcb0b50   udev:latest   "/usr/sbin/entry.sh   10 minutes ago   Up 10 minutes   udev
aca8971302e8   syslog:latest   "/usr/sbin/entry.sh   10 minutes ago   Up 10 minutes   syslog

いいですね! RancherOS の端から端まで Docker です。

ここでは RancherOS について簡単に紹介しましたが、私達のリリースはこれだけに留まりません。今回のサポートでは、同様に直近の Red Hat、CentOS、Fedora、Debian をサポートしました。例えば、Amazon Web Service の EC2 上に Red Hat Enterprise Linux の仮想マシンを起動するには、次のような手順で行えます(マシンは環境変数からフラグを読み込みます)。

$ export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxx
$ export AWS_ACCESS_KEY_ID=yyyyyyyyyy
$ export AWS_VPC_ID=vpc-12345678
$ docker-machine create -d amazonec2 \
--amazonec2-ami ami-12663b7a \
--amazonec2-ssh-user ec2-user \
rhel0
$ docker-machine ssh rhel0 -- uname -a
Linux rhel0 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux

■ 楽しみましょう!

私達がとてもエキサイティングに感じている機能を紹介してきました。いくつかが、あなたに何らかの感触を与えられればと思っています。これらの新機能だけでなく、バグ修正や安定性の向上のために改善を施しました。そして、この投稿では扱えないほど多くの機能を取り込めて嬉しくおもいます。私は、他にも Exoscale ドライバや、boot2docker ISO のカスタム版として VMware Fusion ドライバが利用できる点など(バージョンアップが必要な場合もあります)、これらを1つ1つ確認することをお勧めします。

これまでプロジェクトに貢献いただいた、全ての開発者、テスター、夢想家の皆さんに大きな感謝を申しあげます。そして、あなたのサポートに非常に感謝しています。

Docker Machine を今日から使ってみましょう!

■参考

Docker Machine 0.3.0 Deep Dive | Docker Blog
http://blog.docker.com/2015/06/docker-machine-0-3-0-deep-dive/

 

こちらも、あわせてどうぞ

docker-machine – Docker Machine ドキュメント参考日本語訳 – Qiita
http://qiita.com/zembutsu/items/9d189da5d2c7708717a3