先月公開した第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のログイン画面が表示されるはずです。

注1）

とくに12.04を使っている場合は，そのままだと古いJujuがインストールされてしまいますので，PPAを使うようにしてください。

注2）

これにより13.04で採用されているLinxu 3.8がインストールされます。今後13.10や14.04がリリースされ，12.04 LTS用のバックポートカーネルが提供されるようになったら，ここでインストールすべきパッケージの名前も変わりますので，読む時期に合わせて適宜公式のドキュメントを参照するようにしてください。

ホストの外からアクセスする

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⁠）⁠。

注3）

リモートマシンのiptablesの設定は，失敗するとネットワーク越しにアクセスできなくなる可能性があります。

注4）

このままだと「wordpress/0」のIPアドレスが変わってしまうと動かなくなります。必要に応じて，LXCの特定のインスタンスは静的にアドレスを割り当てるなり，ホスト名で解決できる別の方法を用意すると良いでしょう。

注5）

より「Ubuntuらしい」方法を使うのであれば，iptablesを直接設定するのではなく，ufwを使うと良いでしょう。Ubuntu上でufwとLXCをともに使う場合，ブリッジ経由のアクセスをコンテナの中へフォワードできるよう，/etc/default/ufwのDEFAULT_FORWARD_POLICYを“⁠DROP⁠”から“⁠ACCEPT⁠”に変更することを忘れないでください。

AWSやLXC以外にも

JujuはAWSやLXC以外にも，OpenStackやHP Cloud，Windows AzureといったIaaS系のクラウドプラットフォームに対応しています。さらに最近は，新規に仮想or物理マシンを立ち上げることなく既存のUbuntuマシン上にデプロイする「Manual Provisioning」も試験的に実装されました。これらはいずれもLXCと同様に，最初の環境設定ファイル（~/.juju/environments.yaml）の記述方法が異なるだけで，あとは他の環境と同じように使えます。もちろん環境は個別にラベルを設定することができるので，「⁠juju switch」コマンドで複数の環境を使い分けることもできます。

このためJujuを使えば，複数のクラウドプラットフォームを同じインターフェースで操作できるのです。