第294回　仮想化ソフトLXC上でデプロイツールJujuを使う

先月公開した第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を使えば、複数のクラウドプラットフォームを同じインターフェースで操作できるのです。