第459回　LXDを使ってDockerコンテナをマイグレーション

第458回ではUbuntuにおけるDockerのインストール方法を紹介しました。ところでDockerと同じコンテナ技術を利用したソフトウェアとして「LXD」が存在します。このLXDとDockerは排他的な存在ではなく、用途にあわせて組み合わせて使うと便利なツールです。そこで今回はLXDで作った仮想環境上でDockerコンテナを動かす方法を紹介します。

LXDの上でDockerを使う

Dockerと同様にカーネルのコンテナ技術を利用したソフトウェアのひとつにLXDが存在します。Dockerがひとつのコンテナでひとつのアプリケーションを動かす「アプリケーションコンテナ」としての利用をメインに据えているのに対して、LXDは軽量な仮想マシンのように使える「システムコンテナ」としての使い方を提案していることがもっとも大きな違いです[1]⁠。

両者の具体的な違いを見ていきましょう。ちなみに個々の環境や運用方針によって成り立たないものもあります。オプションやツールを組み合わせることで変えられるものもあります。あくまで「原則として」という但し書きがつく違いだということを踏まえてください。

Docker

単一のコンテナには単一のサービスが動いている
docker runで構築済みイメージをコンテナインスタンスとして実行する
/sbin/initは実行されない
個々のコンテナの設定はdocker runコマンドの引数として渡す
イメージはDockerfileによって構築する
永続的なデータは「データボリューム」に保存する
ユーザーはコンテナインスタンスの中に入って操作することはない
CMDで指定したプロセスが終了すればインスタンスは停止する
コンテナのrootはホストのrootと同じUIDが使われる
マシン間のライブマイグレーションは将来的に対応予定
コンテナはホストから名前空間の機能によって隔離されている
Dockerコンテナの中でDockerコンテナを起動できる

LXD

単一のコンテナの中に複数のサービスが動いている
lxc startで構築済みイメージをコンテナインスタンスとして起動する
/sbin/initは実行される
個々のコンテナの設定は設定コマンドを使ってメタデータファイルに保存する
イメージはrootfsイメージとして構築する
永続的なデータはコンテナの中に保存する
ユーザーはコンテナインスタンスの中に入って操作する
コンテナの中でshutdownコマンドを実行すればインスタンスは終了する
コンテナのrootはホストのrootと異なるUIDが使われる
マシン間のライブマイグレーションが実験的ではあるものの実装済み
コンテナはホストから名前空間の機能によって隔離されている
LXDコンテナの中でLXDコンテナを起動できる

使う上で一番大きな違いは、コンテナとして起動したインスタンス対する操作の方法です。Dockerを「使用する」場合は、すでに目的のサービスやアプリケーションを提供する構築済みイメージが存在します。構築済みイメージは「完成されたもの」であるため、デバッグ用途でもない限りはインスタンスの中に入ってインタラクティブに何かすることはありません。コンテナの内容を恒久的に変更したい場合は、新たにイメージを作りなおしてそれをdocker runで実行することになります。

それに対してLXDは、起動した段階ではインストール直後のOSと大差ありません。Cloud InitやAnsibleといったツールを併用することで、自動的に目的のサービスやアプリケーションの環境を構築することも可能ではありますがそれはLXDの範囲外の話です。コンテナの内容を変更したい場合は、そのインスタンスに「ログイン」した上で、普通のLinuxと同じようにコマンド操作することになります。もちろんコンテナを終了してもインスタンスの変更は残っていますし、再び起動すればPCを再起動した時と同じような状態になります。

実際のところLXDが比較されるべきはDockerよりもむしろ、VMWareやvirt-manager、VirtualBoxといった仮想マシンの管理ツールです。KVMやXenの代わりにコンテナを利用して仮想環境を管理するツールがLXDなのです。それゆえにLXDは「コンテナのハイパーバイザ」と名乗っています。既存の導入方法が確立しているサービスやツールをコンテナの中で動かしたいのであればDockerを選び、とりあえず何でもできるUbuntu環境がほしいのであればLXDを選ぶと良いでしょう。

ところでLXDによって「何でもできるUbuntu環境」を用意できるのであれば、その環境の上でDockerを動かせたら何かと便利です。そこでここからは、Ubuntu 16.04 LTSを使ってLXDの上でDockerを導入する方法を紹介します[2]⁠。

LXDのインストールと初期設定

LXDはUbuntu公式のリポジトリにパッケージが用意されていますので、それをインストールするだけです。デーモンであるlxdとそれを操作するツールであるlxcがインストールされます。Dockerと同じような感じでlxcコマンドを使うにはlxdグループに所属する必要があります。ただしグループはインストール時に作成されますし、adminグループとsudoersグループのユーザーは自動的にlxdグループに所属することになりますので、sudoコマンドを使えるユーザーであれば単にインストール後に一度ログインしなおすだけでかまいません。

$ sudo apt install lxd

LXDを使うにはまず初期設定を行う必要があります。これはlxdコマンドを使います。lxcコマンドと混同しそうですが、lxdコマンドを直接使うのはこのタイミングだけです。

$ sudo lxd init
Name of the storage backend to use (dir or zfs) [default=zfs]: dir
Would you like LXD to be available over the network (yes/no) [default=no]?
Do you want to configure the LXD bridge (yes/no) [default=yes]?
LXD has been successfully configured.

最初に設定するのが「ストレージバックエンド」です。要するにコンテナイメージをどのように保存するかという話になります。zfsutils-linuxパッケージがインストール済みの環境であれば、導入の容易さと速度のバランスからZFSが推奨されています。またZFSの場合はホストのファイルシステムには依存しません。ただしLXD上でDockerを動かす分には相性が悪いようです。

BtrfsやLVMという選択肢もあります。特にBtrfsは機能の面から言えばZFSよりも便利なのですが、BtrfsもLVMもホストのファイルシステム（正確には/var/lib/lxdが存在するファイルシステム）と一致していなくてはなりません[3]⁠。つまりExt4上では使えません。Directoryバックエンドは単純にルートファイルシステムをディレクトリとして保存する方法です。他のバックエンドに比べるとストレージの使用量は多いですし、コンテナの作成やスナップショットの速度は遅いのですが、ホストのファイルシステムに依存せずにコンテナのネストなどができるというメリットもあります。今回はDirectoryバックエンドを設定しています。

2つ目はLXDのサービスをネットワーク越しに操作できるかどうかの設定です。あとからでも設定変更可能ですので、とりあえずは「no」でもいいでしょう。3つ目はコンテナのネットワーク設定になります。こちらは設定しておきましょう。「⁠yes」にすると、さらに次の問いに答えることになりますが、基本的にすべて初期設定値のままでかまいません。

これでLXDを利用できる環境が整いました。

$ lxc info
apiextensions:
- id_map
apistatus: stable
apiversion: "1.0"
auth: trusted
environment:
  addresses: []
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    （中略）
    -----END CERTIFICATE-----
  certificatefingerprint: e2deb928a0ab2192ab428b66ed6fe7802bf1809043bfcc8f01ef5a8dae77e849
  driver: lxc
  driverversion: 2.0.6
  kernel: Linux
  kernelarchitecture: x86_64
  kernelversion: 4.4.0-62-generic
  server: lxd
  serverpid: 29207
  serverversion: 2.0.8
  storage: dir
  storageversion: ""
config: {}
public: false

Docker用コンテナの作成

では実際にDockerを動かすためのLXDコンテナを作成し、起動しましょう。ちなみにDockerをLXD上で動かすためには、最低でもLXD 2.0とUbuntu版のカーネル4.4、Ubuntuリポジトリ上のDockerが必要です。Ubuntu 16.04 LTSならいずれも揃っています。

LXD上でDockerを動かすためにはコンテナ作成時に「defaultプロファイル」だけでなく「dockerプロファイル」を明示的に指定する必要があります。これにより、必要な権限がコンテナに設定され、コンテナの中でDockerが使えるようになります。

$ lxc init ubuntu:16.04 docker -p default -p docker
$ lxc start docker
$ lxc list
+--------+---------+---------------------+-----------------------------------------------+------------+-----------+
|  NAME  |  STATE  |        IPV4         |                     IPV6                      |    TYPE    | SNAPSHOTS |
+--------+---------+---------------------+-----------------------------------------------+------------+-----------+
| docker | RUNNING | 10.55.74.241 (eth0) | fdf5:4b0a:8212:503d:216:3eff:fe2e:c662 (eth0) | PERSISTENT | 0         |
+--------+---------+---------------------+-----------------------------------------------+------------+-----------+

コンテナが起動したら、必要に応じてパッケージのアップデートやロケールの設定、再起動などを行います。

$ lxc exec docker -- sed -i "s/archive.ubuntu.com/jp.archive.ubuntu.com/g" /etc/apt/sources.list
$ lxc exec docker apt update
$ lxc exec docker -- apt full-upgrade -y
$ lxc exec docker -- apt install -y language-pack-ja
$ lxc exec docker update-locale LANG=ja_JP.UTF-8
$ lxc exec docker timedatectl set-timezone Asia/Tokyo
$ lxc restart docker

上記のようにexecサブコマンドを使えば、コンテナの中にログインすることなくコマンドを実行可能です。ただ仮想環境として使う場合、毎回lxc execを打つのは面倒ですので、ログインできるようにしましょう。/bin/bashをexecすることでもコンテナの中に移動できますが、SSHログインするという手もあります。Ubuntuコンテナであれば最初からSSHサーバーが起動していますので、あとは公開鍵をコンテナの中に移動するだけです。ちなみにUbuntuコンテナには「ubuntu」アカウントが最初から作られています。よってlxc file pushでホストのファイルをコンテナにコピーしてしまいましょう。

$ lxc file push ~/.ssh/id_rsa.pub docker/home/ubuntu/.ssh/authorized_keys
$ lxc exec docker chown ubuntu: /home/ubuntu/.ssh/authorized_keys

もしGitHubにすでに公開鍵を登録済みであれば、ssh-import-idを使ってGitHubからインストールする方法もあります。

$ lxc exec docker -- ssh-import-id -o /home/ubuntu/.ssh/authorized_keys gh:（GitHubのアカウント名）

さて次にDockerそのものをインストールしましょう。これについては第458回の「Ubuntuのdocker.ioパッケージ」と手順は同じです。あえてホストからlxc execを実行すると、次のようになります。

$ lxc exec docker -- apt install -y docker.io
$ lxc exec docker getent group docker
docker:x:116:
$ lxc exec docker systemctl is-enabled docker
enabled

ちなみにここまでの手順をCloud Initに任せたい場合は、Cloud Initの設定ファイルを作成した上で、lxc initのあとlxc startの前に次のコマンドを実行してください。

$ lxc config set docker user.user-data - < cloud.cfg

さて実際にDockerが動作しているか試してみましょう。

$ lxc exec docker docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.3
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
（中略）

$ lxc exec docker docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
78445dd45222: Pull complete
（中略）

$ lxc exec docker docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
hello-world         latest              48b5124b2768        4 weeks ago         1.84 kB

簡単に動きましたね。このようにLXDを使えば、仮想マシンの代わりに軽量コンテナを使った仮想環境を用意した上で、Dockerのテスト環境を作ることができます。

Docker Composeによるマルチコンテナの管理

Docker Composeを使うと、複数のDockerコンテナをYAMLファイルで管理できます。ためしにWordPressコンテナとMySQLコンテナを導入するDocker Composeを使ってみましょう。

Docker ComposeはDocker本体とは別にインストールする必要があります。Ubuntuの公式リポジトリにもdocker-composeパッケージが存在しますが、こちらはバージョンが古い状態です。そこでDockerのサイトからバイナリをダウンロードしてインストールしましょう[4]⁠。

今回はLXDコンテナの中でDockerを動かしているため、lxc execコマンド経由でコンテナの中にDocker Composeをインストールしています。ホストに直接インストールするなら、適宜コマンドを読み替えてください。

$ lxc exec docker -- curl -L "https://github.com/docker/compose/releases/download/1.11.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ lxc exec docker -- chmod +x /usr/local/bin/docker-compose
$ lxc exec docker -- docker-compose --version
docker-compose version 1.11.1, build 7c5d5e4

Docker Composeはdocker-compose.ymlファイルを作って、その中に個々のコンテナの設定を記述します。今回はDocker ComposeのドキュメントにあるWordPressの例をそのまま使いましょう。

version: '2'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_PASSWORD: wordpress
volumes:
    db_data:

ホストで作ったdocker-compose.ymlをLXDコンテナの中にコピーします。LXDは「lxd file」コマンドを使うことで、コンテナとホスト間のファイルのやり取りが行えます。なおDocker Compose用のプロジェクトディレクトリとしてwordpressディレクトリも作っています。

$ lxc exec docker -- sudo -u ubuntu mkdir /home/ubuntu/wordpress
$ lxc file push docker-compose.yml docker/home/ubuntu/wordpress/

最後にDocker Compose経由でWordPressコンテナとMySQLコンテナを起動しましょう。詳細は省きますが、プロジェクトディレクトリの中で「docker-compose up」コマンドを実行するだけです。「⁠-d」オプションをつけるとバックグラウンドで起動します。

$ lxc exec docker -- sh -c "cd /home/ubuntu/wordpress && docker-compose up -d"
Creating network "wordpress_default" with the default driver
Creating volume "wordpress_db_data" with default driver
Pulling db (mysql:5.7)...
5.7: Pulling from library/mysql
（中略）
Status: Downloaded newer image for wordpress:latest
Creating wordpress_db_1
Creating wordpress_wordpress_1

$ lxc exec docker -- sh -c "cd /home/ubuntu/wordpress && docker-compose ps"
        Name                       Command               State          Ports
-------------------------------------------------------------------------------------
wordpress_db_1          docker-entrypoint.sh mysqld      Up      3306/tcp
wordpress_wordpress_1   docker-entrypoint.sh apach ...   Up      0.0.0.0:8000->80/tcp

起動中のコンテナの状態は「docker-compose ps」で確認します。もちろん「docker ps」でもコンテナの状態は確認できます。さらに「lxc list」コマンドを使えばLXDコンテナの情報を取得できます。

$ lxc list docker -c 46
+--------------------------------+-----------------------------------------------+
|              IPV4              |                     IPV6                      |
+--------------------------------+-----------------------------------------------+
| 172.18.0.1 (br-3b0ff7fa92ef)   | fdf5:4b0a:8212:503d:216:3eff:fe2e:c662 (eth0) |
| 172.17.0.1 (docker0)           |                                               |
| 10.55.74.241 (eth0)            |                                               |
+--------------------------------+-----------------------------------------------+

eth0に割り当てられているアドレスにアクセスすれば、WordPressの初期設定ページが表示されることでしょう。上記の例であれば、次のようなアドレスになります。

http://10.55.74.241:8000/
http://[fdf5:4b0a:8212:503d:216:3eff:fe2e:c662]:8000/

DockerコンテナをLXDごとマイグレーション

LXDには実験的機能ではありますが、稼働中のコンテナを別のホストへライブマイグレーションする機能があります。正確には以下の機能が存在します。

停止中のコンテナを他のホストへ移動するマイグレーション機能
停止中のコンテナを他のホストへ複製するコピー機能
稼働中のコンテナを読み込み専用のコンテナとして保存するスナップショット機能
スナップショットされたコンテナをリストアする機能
稼働中のコンテナを他のホストへ移動するライブマイグレーション機能

ライブマイグレーション機能は実際のところ、「⁠稼働中のコンテナをプロセスの状態も含めて（ステートフルに）スナップショットをとる」「⁠スナップショットコンテナを他のホストへマイグレーションする」「⁠他のホスト上で移動したコンテナをリストアする」という3段階のステップで実現しています。

このステートフルなスナップショットとリストアのために、バージョン2.0以上のCRIU（Checkpoint/Restore In Userspace）と、そのCRIU機能を使うための4.4以上のカーネル、それにいくつかのカーネルコンフィグが必要になります。とりあえずホストがUbuntu 16.04 LTSであれば、条件は一通り整うはずです。

ただこのライブマイグレーション機能は実験的ということもあって、まだまだ「きちんと動く」とは言いがたい状況です。ちょっとした環境の違いやコンテナ内部の状態の違いによってマイグレーションに失敗します。一応マイグレーションに失敗した場合は、移動元のコンテナがそのまま残るようにはなっています。

そこで今回はライブマイグレーションではなく、単純に停止中のコンテナを移動する方法を紹介しましょう。なおライブマイグレーションするのであれば、移動元・移動先の双方でCRIUパッケージをインストールしておきましょう。

$ sudo apt install criu

ここからはリモート側のホストの名前を「serval」として説明します。プロンプトが「$」だけの場合はローカルでの作業、「⁠serval$」の場合はリモートの作業だと考えてください。

まずはリモート側で、LXDのデーモンにネットワークアドレスを紐付けます。「⁠lxd init」時に「Would you like LXD to be available over the network」という問い合わせに対して「no」と答えた場合に必要です。またこのアドレスはホストから直接見えるアドレスである必要があります[5]⁠。また外部からこのLXDサービスに接続する際に入力するパスワードもあわせて設定しておきましょう。

serval$ lxc config set core.https_address [::]:8443
serval$ lxc config set core.trust_password （パスワード）

上記の例では、「⁠[::]」を設定することでホスト上のすべてのインターフェースに割り当てられているアドレスが紐付けられます。ただこの方法だと移動先と移動元のアドレスの交換において齟齬をきたすことがありますので、現時点では可能であれば明示的にアドレスを指定したほうが良いでしょう。

次にローカル側でもネットワークアドレスの紐付けを行い、リモートのLXDサーバーをローカルに追加します。「⁠[::]」の部分については、リモートと同じく明示的に指定したほうが良いでしょう。

$ lxc config set core.https_address [::]:8443
$ lxc remote add serval リモート側のアドレス
証明書のフィンガープリント: （中略）
ok (y/n)? y
serval の管理者パスワード: （リモート側で設定したパスワード）
クライアント証明書がサーバに格納されました:  serval

追加されたリモートのリストは「lxc remote list」で確認できます。

$ lxc remote list
+-----------------+------------------------------------------+---------------+--------+--------+
|      NAME       |                   URL                    |   PROTOCOL    | PUBLIC | STATIC |
+-----------------+------------------------------------------+---------------+--------+--------+
| images          | https://images.linuxcontainers.org       | simplestreams | YES    | NO     |
+-----------------+------------------------------------------+---------------+--------+--------+
| local (default) | unix://                                  | lxd           | NO     | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+
| serval          | https://（リモートのアドレス）:8443      | lxd           | NO     | NO     |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | simplestreams | YES    | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | simplestreams | YES    | YES    |
+-----------------+------------------------------------------+---------------+--------+--------+

PROTOCOLが「lxd」なサーバーがリモートサーバーになります。ちなみにPROTOCOLが「simplestream」なものはイメージサーバーです。「⁠lxc init」時に指定したイメージのうちローカルに存在しないイメージは、これらのイメージサーバーの中から検索・ダウンロードしているのです。LXDをインストールしたら自動的にいくつかのイメージサーバーが追加されます。

PUBLICは認証なしにリモートに接続するかどうかのフラグです。イメージサーバーは認証なしに接続しますが、リモートサーバーには認証が必要になります。

lxcコマンドはリモート名を明示的に指定することで、リモートの情報の取得や操作が可能です。

（ローカルのコンテナ情報）
$ lxc list
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
|  NAME  |  STATE  |              IPV4              |                     IPV6                      |    TYPE    | SNAPSHOTS |
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
| docker | RUNNING | 172.18.0.1 (br-3b0ff7fa92ef)   | fdf5:4b0a:8212:503d:216:3eff:fe2e:c662 (eth0) | PERSISTENT | 0         |
|        |         | 172.17.0.1 (docker0)           |                                               |            |           |
|        |         | 10.55.74.241 (eth0)            |                                               |            |           |
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+

（リモートservalのコンテナ情報）
$ lxc list serval:
+-------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
| NAME  |  STATE  |              IPV4              |                     IPV6                      |    TYPE    | SNAPSHOTS |
+-------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
| kaban | RUNNING | 172.18.0.1 (br-d2860119fbd1)   | fd3b:f724:c6b0:f8f8:216:3eff:fee8:1f37 (eth0) | PERSISTENT | 0         |
|       |         | 172.17.0.1 (docker0)           |                                               |            |           |
|       |         | 10.241.13.124 (eth0)           |                                               |            |           |
+-------+---------+--------------------------------+-----------------------------------------------+------------+-----------+

ちなみにkabanコンテナでは、ローカルのdockerコンテナと同様にDockerを動かしています。

ここまででマイグレーションの準備は完了です。さっそくリモートにあるkabanコンテナを一旦停止して、ローカルにマイグレーションしてみましょう。

$ lxc stop serval:kaban
$ lxc move serval:kaban kaban
$ lxc start kaban

移動後にコンテナのリストを確認すると、期待通りに移動していることがわかります。なおIPアドレスは移動先のホストの状態にあわせて変わります。

（ローカルのコンテナ情報）
$ lxc list
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
|  NAME  |  STATE  |              IPV4              |                     IPV6                      |    TYPE    | SNAPSHOTS |
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
| docker | RUNNING | 172.18.0.1 (br-3b0ff7fa92ef)   | fdf5:4b0a:8212:503d:216:3eff:fe2e:c662 (eth0) | PERSISTENT | 0         |
|        |         | 172.17.0.1 (docker0)           |                                               |            |           |
|        |         | 10.55.74.241 (eth0)            |                                               |            |           |
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+
| kaban  | RUNNING | 172.18.0.1 (br-d2860119fbd1)   | fdf5:4b0a:8212:503d:216:3eff:fee8:1f37 (eth0) | PERSISTENT | 0         |
|        |         | 172.17.0.1 (docker0)           |                                               |            |           |
|        |         | 10.55.74.235 (eth0)            |                                               |            |           |
+--------+---------+--------------------------------+-----------------------------------------------+------------+-----------+

（リモートservalのコンテナ情報）
$ lxc list serval:
+----------+---------+------+------+------------+-----------+
|   NAME   |  STATE  | IPV4 | IPV6 |    TYPE    | SNAPSHOTS |
+----------+---------+------+------+------------+-----------+

今回のような（ライブではない）マイグレーションを行う場合、どうしても一度コンテナを止めなくてはなりません。よって「Blue-Green Deployment」のような仕組みを実施している環境だと、デメリットのほうが大きいでしょう。ただしLXDを用いたマイグレーションは、Dockerボリュームやローカルのイメージレジストリごとホストをまたいで移動できます。停止時間が発生してもいいから、気軽に環境ごとホストを移動したいような状況なら、LXDのマイグレーションが役に立つのではないでしょうか。