多機能なコンテナクラスタ構築ツール「Kontena」 4ページ
Kontenaクラスタ上でアプリケーションを実行する
以上でKontenaクラスタが完成したので、続いてはKontenaクラスタ上でのコンテナ実行について説明していこう。Kontenaでは実行されるコンテナを「サービス」と呼び、「kontena service」コマンドで管理できる。
コンテナを実行する場合、まずサービスを作成し、続いてそれをデプロイする、という手順となる。サービスの作成は「kontena service create ＜サービス名＞ ＜コンテナイメージ名＞」コマンドで行える。
たとえば「httpd」というコンテナを実行したい場合、まず次のようにしてサービスを作成する。サービス名には任意のものが使用できるが、ここでは「httpd_test」とした。
$ kontena service create httpd_test httpd
なお、公開するポートやリンク、環境変数、ボリュームなどの設定もサービスの作成時に行う。ここでは「docker run」コマンドで指定できるオプションとほぼ同一のものが利用できるが、詳しくは「kontena service create –help」コマンドなどで確認できるオンラインヘルプなどを参照してほしい。
作成したサービスは、「kontena service ls」コマンドで確認できる。
$ kontena service ls NAME INSTANCES STATEFUL STATE EXPOSED PORTS httpd_test 0 / 1 no initialized
続いて、「kontena serice deploy ＜サービス名＞」コマンドで作成したコンテナのデプロイを行う。
$ kontena service deploy httpd_test
デプロイ後に再度「kontena service ls」コマンドで確認すると、「INSTANCES」が「1/1」となり、「STATE」が「running」となっていることが分かる。
$ kontena service ls NAME INSTANCES STATEFUL STATE EXPOSED PORTS httpd_test 1 / 1 no running
また、「kontena service show ＜サービス名＞」でサービスの詳細情報を確認できる。たとえば下記の例では、「centos11」ノードでこのインスタンスが稼働していることが分かる。
$ kontena service show httpd_test
grid01/httpd_test:
status: running
image: httpd:latest
stateful: no
scaling: 1
strategy: ha
deploy_opts:
min_health: 0.8
dns: httpd_test.grid01.kontena.local
net: bridge
instances:
httpd_test-1:
rev: 2016-08-16 12:48:36 UTC
node: centos11
dns: httpd_test-1.grid01.kontena.local
ip: 10.81.1.161
public ip: ***.***.**.***
status: running
稼働中のコンテナを停止させるには、「kontena service stop ＜サービス名＞」コマンドを使用する。
$ kontena service stop httpd_test
また、サービスを削除するには「kontena service rm ＜サービス名＞」コマンドを使用する。この際、本当に削除を行うかの確認が行われるので、確認して再度サービス名を入力する。また、「–force」オプション付きでコマンドを実行すると確認無しで削除が行われる。
$ kontena service rm httpd_test Destructive command. To proceed, type "httpd_test" or re-run this command with --force option. > httpd_test
複数のコンテナをまとめて管理する
Kontenaでは、複数のコンテナをまとめた「アプリケーション」という単位でコンテナを管理する機能が用意されている。前回紹介した「Docker Compose」と同様、コンテナの起動オプションや設定などを記述したファイルを事前に用意しておくことで、それらコンテナをまとめて管理できるというものだ。
この設定ファイルはDocker Composeの設定ファイルと互換性があり、すでにDocker Compose向けの設定ファイルがある場合、それらをほぼそのまま利用することができる。Kontenaクラスタ内でコンテナが分散実行されることを除いて、実現できる機能や使い勝手はDocker Composeとほぼ同じだ。Docker Composeの使い方や設定ファイルについては以前の記事で解説しているので、そちらも参照してほしい。
アプリケーション単位でのコンテナ管理では、「kontena app」コマンドを使用する。設定ファイルを自動生成する「kontena app init」コマンドが用意されているので、まずは適当なディレクトリでこのコマンドを使って設定ファイルを作成すると良いだろう。
以下では、Docker Compose記事で説明したMySQLとWordPressをデプロイする以下のような設定ファイル（docker-compose.ymlファイル）を元に、Kontenaクラスタでこれらのコンテナを稼働させる例を紹介する。
version: '2'
services:
my_mysql:
image: mysql:5.7
volumes:
- /var/test/mysql:/var/lib/mysql
- /var/test/mysql_conf.d:/etc/mysql/conf.d
environment:
MYSQL_ROOT_PASSWORD: some_password
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress_password
my_wordpress:
image: wordpress:4.5-apache
links:
- my_mysql:mysql
volumes:
- /var/test/wp_plugins:/var/www/html/wp-content/plugins
environment:
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress_password
WORDPRESS_DB_NAME: wordpress
まず、Docker Composeの設定ファイル（docker-compose.ymlファイル）が格納されているディレクトリ（ここでは「wordpress」ディレクトリで「kontena app init」コマンドを実行する。
$ kontena app init Dockerfile not found. Do you want to create it? [Yn]: n ←Dockerfileを作成しないので「n」と入力 Found docker-compose.yml. Creating kontena.yml Your app is ready! Deploy with 'kontena app deploy'.
「kontena app init」コマンドではコンテナイメージを作成するための「Dockerfile」ファイルと、「docker-compose.yml」ファイル、「kontena.yml」ファイルを作成できる。今回の場合Dockerfileファイルは不要なので、「Dockerfile not found. Do you want to create it?」という質問に対し「n」と入力して作成をキャンセルしている。また、docker-compose.ymlファイルは先に用意してあるので作成されず、これをベースにkontena.ymlファイルが作成される。
作成されたkontena.ymlファイルは以下のようになる。
---
version: '2' ←kontena.ymlファイルフォーマットのバージョン
name: wordpress ←プロジェクト名
services: ←サービスの設定
my_mysql: ←サービス名「my_mysql」について
extends: ←「docker-compose.yml」ファイルの「my_mysql」設定を読み込む
file: docker-compose.yml
service: my_mysql
my_wordpress: ←サービス名「my_wordpress」について
extends: ←「docker-compose.yml」ファイルの「my_wordpress」設定を読み込む]
file: docker-compose.yml
service: my_wordpress
kontena.ymlファイルの詳細についてはオンラインドキュメントのリファレンスページを参照して欲しいが、基本的にはDocker Composeのdocker-compose.ymlとほぼ同じだ。
Kontenaにおけるコンテナ間通信
Kontenaでは前述したとおり、独自にVPNを構築することで異なるホスト上にあるコンテナ間の通信を可能にしている。さらにVPN内に独自のDNSサーバーが用意され、コンテナ間では「＜サービス名＞.kontena.local」もしくは「＜サービス名＞-＜インスタンス番号＞.kontena.local」というホスト名で各コンテナにアクセスできるように設定される。
また、「kontena app」コマンドで作成されたサービスはサービス名として「＜プロジェクト名＞-＜サービス名＞」という名前が付けられる。今回の例では、プロジェクト名が「wordpress」、サービス名が「my_mysql」および「my_wordpress」なので、各コンテナは「wordpress-my_mysql.kontena.local」や「wordoress-my_wordpress.kontena.local」というホスト名でアクセスが可能だ。
これを踏まえて、生成されたkontena.ymlファイルに下記の太字の部分を追記している。追加したのはWordPressサービスの設定で使用するデータベースのホスト名を指定する「WORDPRESS_DB_HOST」環境変数の設定だ。これにより、WordPressは「wordpress-my_mysql.kontena.local」というホストをデータベースとして使用するようになる（「${project}」の部分はプロジェクト名に置換される）。
---
version: '2'
name: wordpress
services:
my_mysql:
extends:
file: docker-compose.yml
service: my_mysql
my_wordpress:
extends:
file: docker-compose.yml
service: my_wordpress
environment:
WORDPRESS_DB_HOST: ${project}-my_mysql.kontena.local
アプリケーションのデプロイ
設定ファイルを元にしたデプロイは、設定ファイルが格納されたディレクトリで「kontena app deploy」コマンドを実行することで行える。コマンドを引数無しで実行すると、次のようにkontena.ymlファイル内に記述されたサービスの作成とデプロイが実行される。
$ kontena app deploy Not found any service with build option creating my_mysql creating my_wordpress deploying my_mysql ... done deploying my_wordpress ... done
実行されているサービスは「kontena app ls」コマンドで確認できる。
$ kontena app ls NAME IMAGE INSTANCES STATEFUL STATE PORTS my_mysql mysql:5.7 1 / 1 no running my_wordpress wordpress:4.5-apache 1 / 1 no running 0.0.0.0:80->80/tcp
サービスの停止は「kontena app stop」コマンド、削除は「kontena app rm」コマンドで行える。
$ kontena app stop stopping wordpress-my_mysql stopping wordpress-my_wordpress
$ kontena app rm Destructive command. Are you sure? (y/n) or re-run this command with --force option. > y deleting my_wordpress ... done deleting my_mysql ... done
「kontena app start」コマンドでは個別のサービスを指定することで、そのサービスだけを起動することも可能だ。
$ kontena app start my_mysql starting wordpress-my_mysql
ロードバランサとスケーリング
Kontenaでは、Kontenaクラスタで利用できるロードバランサイメージを公開しており、簡単な設定だけでロードバランサを使った負荷分散/冗長化を行えるようになっている。最後に、このロードバランサの使い方を紹介しておこう。
ロードバランサを使用するには、kontena.ymlファイルにロードバランサコンテナの設定を追加し、ロードバランス対象となるコンテナで環境変数にロードバランスのための各種パラメータおよびリンク設定を追加すれば良い。
たとえば先のWordPressおよびMySQLを使った構成の場合、kontena.ymlファイルは以下のようになる。
---
version: '2'
name: wordpress
services:
internet_lb:
image: kontena/lb:latest
affinity:
- node==centos12
ports:
- 80:80
my_mysql:
extends:
file: docker-compose.yml
service: my_mysql
my_wordpress:
extends:
file: docker-compose.yml
service: my_wordpress
environment:
WORDPRESS_DB_HOST: ${project}-my_mysql.kontena.local
links:
- internet_lb
ここで太字の部分が新たに追加したものだ。追加した「internet_lb」がロードバランサとして実行されるサービスとなり、このサービスに対してリンクを行ったサービス（ここではmy_wordpressサービス）がロードバランシングされる対象のサービスとなる。また、「affinity:」設定で「- node==centos12」と指定することで、このロードバランサは「centos12」というノード上で実行されるようになる。
なお、ロードバランサのデフォルト設定ではHTTPについてロードバランスを行うようになっているため、ここでは特に追加の設定はおこなっていない。HTTP以外のロードバランスを行う場合の設定についてはオンラインドキュメントを参照してほしい。
この設定でコンテナをデプロイすると、ロードバランサ経由で指定したコンテナ（ここでは「my_wordpress」コンテナ）にアクセスが可能になる。
$ kontena app deploy Not found any service with build option creating internet_lb creating my_mysql creating my_wordpress deploying internet_lb ... done deploying my_mysql ... done
正しくロードバランシングが行われているかを確認するため、my_wordpressコンテナの稼働数を増やし、実際にアクセスが振り分けられているかを確認してみよう。まず、「kontena app scale」コマンドで「my_wordpress」サービスのインスタンスを2に設定する。
$ kontena app scale my_wordpress 2
この状態で「kontena app ls」コマンドを実行すると、「INSTANCES」の値が「2/2」になっていることが確認できる。
$ kontena app ls NAME IMAGE INSTANCES STATEFUL STATE PORTS internet_lb kontena/lb:latest 1 / 1 no running 0.0.0.0:80->80/tcp my_mysql mysql:5.7 1 / 1 no running my_wordpress wordpress:4.5-apache 2 / 2 no running
この状態で、centos12ノードにWebブラウザで数回アクセスした後、「kontena app logs my_wordpress」コマンドでmy_wordpressサービスのログを表示させると、「wordpress-my_wordpress-1」と「wordpress-my_wordpress-2:」の2つのコンテナに対しアクセスが振り分けられていることが分かる。
$ kontena app logs my_wordpress ： ： 2016-08-16T14:31:12.000Z wordpress-my_wordpress-1: 10.81.1.162 - - [16/Aug/2016:14:31:12 +0000] "GET / HTTP/1.1" 200 3839 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7" 2016-08-16T14:31:15.000Z wordpress-my_wordpress-2: 10.81.1.162 - - [16/Aug/2016:14:31:14 +0000] "GET / HTTP/1.1" 200 3839 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7" 2016-08-16T14:34:45.000Z wordpress-my_wordpress-1: 10.81.1.162 - - [16/Aug/2016:14:34:45 +0000] "GET / HTTP/1.1" 200 3839 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7" 2016-08-16T14:34:47.000Z wordpress-my_wordpress-2: 10.81.1.162 - - [16/Aug/2016:14:34:47 +0000] "GET / HTTP/1.1" 200 3839 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7"
多機能で使いやすいのが特徴、今後の発展にも期待
Kontenaは2014年にスタートしたプロジェクトでまだ若いプロジェクトだが、現時点で十分に実用的な機能を提供している。また、すでに全世界で2万ノード以上のノードが使われており、開発も活発だ。
近年ではDockerもクラスタ機能に注力しており、Docker 1.12では容易にDockerクラスタを構築できる「Swarmモード」が搭載された。これにより、Dockerだけでも複数のホスト上でコンテナを動作させ、それらを組み合わせてサービスを提供するような構成が可能である。とはいえ、提供されるクラスタ関連機能としてはまだ最低限であり、セットアップの容易さという点以外では、機能的にはまだKontenaやKuberneteには劣っている状況だ。
また、KontenaはDockerの技術を使用しているものの、Docker以外のコンテナ実行環境などもサポートできる構造となっている。そのため、将来性についても今のところ不安はない。Dockerベースのコンテナクラスタ環境構築ツールは今後も厳しい競争が予想されるが、Kontenaは現時点でも十分に利用を検討できる環境になっていると言えるだろう。
