先月公開した第288回 では、Ubuntuのサービスオーケストレーションツールである「Juju」を使ってAmazon Web Service上のUbuntuインスタンスを作成したり、スケールする方法を紹介しました。今回はAmazon Web Serviceではなく、LXCを用いて「ローカルにデプロイする方法」を紹介しましょう。
Juju on LXC
LXC(Linux Containers)は第226回 でも紹介した仮想化ソフトウェアです。Linuxカーネルの機能を使っているため、Linuxカーネルが動く環境であれば、どのホストやゲストでも動かすことができます。たとえば、現在スマートフォンやタブレット向けに開発している「Ubuntu Touch」は、Ubuntu用にカスタマイズしたLinuxカーネルとUbuntu環境を動かしつつ、その中でLXCを使ってAndroidの仮想マシンとAndroidサービスを動かしています。
Jujuがリリースされた当初も「実験環境」としてLXC上へのデプロイを行えましたが、1.11.3から本格的なサポートに向けての準備が開始し、現在では「Local Provider」という形でLXCをサポートするようになりました。
LXCを使う最大のメリットは、1台の物理マシンの上で特定のハードウェアを必要とせずに複数のサービスを独立して立ち上げられるということです。ハードウェアの仮想化支援機能が必要ないため、最新のARM SoCを使用していない環境やKVMが使えないVPSマシン上でも複数の仮想マシン上で個々のサービスをデプロイできます。たとえばVPSを1台借りて、その上で複数のサービスを運用したい場合に、JujuのLocal Providerはその効果を発揮するのです。
もちろんOpenStackのバックエンドとしてLXCを使えばJujuから直接LXCを使えなくても同様のことは実現できます。ただしその場合はOpenStackとLXCの組み合わせで「ちゃんと動く」ようにする必要があります。
LXC上にデプロイする
第288回の内容に従って、クライアント側にはJujuの最新版がインストールされているものとします[1] 。LXCを使う場合、クライアント=Bootstrapノードがインストールされるマシン=各種サービスがデプロイされるマシン、になります。そのため、JujuではLXCにデプロイする場合を「Local Provider」と呼んでいます。Local Providerは本来Bootstrapノードのみ必要なMongoDBなどをクライアント側にインストールする必要があるため、jujuパッケージだけでなくjuju-localパッケージもインストールする必要があります。
$ sudo apt-get install juju-local
Ubuntu 12.04 LTSを使用しているなら、より最新のカーネルをインストールするためにカーネルパッケージもインストールして再起動しておきましょう[2] 。
$ sudo apt-get install linux-image-generic-lts-raring linux-headers-generic-lts-raring
「juju init」コマンドで設定ファイルのひな形を作れば、「 ~/.juju/environments.yaml」の中に以下のような設定が存在するはずです。
local:
type: local
admin-secret: 199a161299f5284867242f40aca1b062
Amazon EC2のときと異なり、今回はこの設定ファイルを変更する必要はありません。あとは標準で使われる環境を「local」に変更しておきましょう。
$ juju switch local
Changed default environment from "amazon" to "local"
環境設定さえ行えばあとは通常のJujuと使い方は(ほとんど)同じです。いつもどおり、WordPresssとMySQLをデプロイして公開してみましょう。
$ sudo juju bootstrap
$ juju deploy wordpress
$ juju deploy mysql
$ juju add-relation wordpress mysql
$ juju expose wordpress
1点異なるのは、Bootstrapノードを管理者権限で起動する必要があるということです。BootstrapノードではMongoDBをrootで立ち上げているためにこれが必要になります。同様にJujuの環境をすべて削除するdestroy-environmentコマンドも管理者権限で実行する必要があります。
デプロイ完了までの時間はマシンに依存します。ただしBootstrapはローカルに存在するので、juju statusの応答速度はAmazon EC2のときよりも速くなります。
lxc-listコマンドやpsコマンドを使えば、各ノードごとにコンテナが起動してることがわかります。
$ sudo lxc-list
RUNNING
ubuntu-local-machine-1 (auto)
ubuntu-local-machine-2 (auto)
$ ps afx
29861 ? Ss 0:00 lxc-start --daemon -n ubuntu-local-machine-1 ...
29881 ? Ss 0:00 \_ /sbin/init
(中略)
3424 ? Ss 0:00 \_ nginx: master process /usr/sbin/nginx
3426 ? S 0:00 \_ nginx: worker process
(中略)
22259 ? Ss 0:00 lxc-start --daemon -n ubuntu-local-machine-2 ...
22265 ? Ss 0:00 \_ /sbin/init
(中略)
32611 ? Ssl 0:01 \_ /usr/sbin/mysqld
あとは「juju status」コマンドで「wordpress/0」に割り当てられているpublic-address宛にアクセスすれば、WordPressのログイン画面が表示されるはずです。
ホストの外からアクセスする
JujuでデプロイしたWordPressサービスだけホストの外からアクセスできるようにしましょう。この場合に必要になる作業は、LXC上のサービスをホストの外に公開する方法と違いはありません。いくつかの方法が考えられますが、今回はiptablesで設定する方法を紹介します[3] 。
ホストの80番ポートへのアクセスを「wordpress/0」の80番ポートへ転送するルールを追加します。ここで「10.0.3.13」はjuju statusコマンドで確認した「wordpress/0」の公開アドレスです[4] 。
$ sudo iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 \
-j DNAT --to-destination 10.0.3.13:80
この時点でホストのアドレスの80番ポートにアクセスすれば、WordPressの初期設定画面が表示されるようになっているはずです。もし表示されないようなら、「 sudo iptables -t nat -L」などで設定内容を確認してください。
ちなみにこのままだと再起動を行うとiptablesの設定は破棄されます。再起動後も同じ設定を反映したい場合は、Ubuntuのiptablesのドキュメント を参考に、各環境に合わせて設定ファイルを記述しておきましょう[5] 。
AWSやLXC以外にも
JujuはAWSやLXC以外にも、OpenStackやHP Cloud、Windows AzureといったIaaS系のクラウドプラットフォームに対応しています。さらに最近は、新規に仮想or物理マシンを立ち上げることなく既存のUbuntuマシン上にデプロイする「Manual Provisioning」も試験的に実装されました。これらはいずれもLXCと同様に、最初の環境設定ファイル(~/.juju/environments.yaml)の記述方法が異なるだけで、あとは他の環境と同じように使えます。もちろん環境は個別にラベルを設定することができるので、「 juju switch」コマンドで複数の環境を使い分けることもできます。
このためJujuを使えば、複数のクラウドプラットフォームを同じインターフェースで操作できるのです。