第458回 ではUbuntuにおけるDocker のインストール方法を紹介しました。ところでDockerと同じコンテナ技術を利用したソフトウェアとして「LXD 」が存在します。このLXDとDockerは排他的な存在ではなく、用途にあわせて組み合わせて使うと便利なツールです。そこで今回はLXDで作った仮想環境上でDockerコンテナを動かす方法を紹介します。
LXDの上でDockerを使う
Dockerと同様にカーネルのコンテナ技術を利用したソフトウェアのひとつにLXD が存在します。Dockerがひとつのコンテナでひとつのアプリケーションを動かす「アプリケーションコンテナ」としての利用をメインに据えているのに対して、LXDは軽量な仮想マシンのように使える「システムコンテナ」としての使い方を提案していることがもっとも大きな違いです[1] 。
[1] とはいえどちらも似たような技術に立脚している以上、メインの用途とは異なる使い方も可能です。たとえばひとつのDockerコンテナでも、プロセス管理ツールを使えば複数のサービスを立ち上げるようなシステムコンテナとして設定できますし、LXDコンテナを単一のアプリケーションを起動するアプリコンテナとして動かせます。また以前はDockerもLXDと同じく裏でLXC を利用してコンテナの作成を行なっていました。現在のDockerはLXCではなくrunCと呼ばれるツールを使っています。
両者の具体的な違いを見ていきましょう。ちなみに個々の環境や運用方針によって成り立たないものもあります。オプションやツールを組み合わせることで変えられるものもあります。あくまで「原則として」という但し書きがつく違いだということを踏まえてください。
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] 。
[2] LXDを支えているコンテナ技術全般については、gihyo.jpで連載されているLXCで学ぶコンテナ入門 が参考になります。ちなみにLXCはカーネルのコンテナ機能を用いてシステムコンテナを構築するためのツールやライブラリ群です。LXDはLXCが提供するAPIを利用して、より簡単にユーザーがコンテナを管理できるようにしたコマンドやサービスとなります。
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」にすると、さらに次の問いに答えることになりますが、基本的にすべて初期設定値のままでかまいません。
図1 コンテナからホストの外に通信できるようにブリッジの設定を行うかどうか
図2 ブリッジの名前
図3 コンテナにIPv4アドレスを割り当てるかどうか
図4 デフォルトゲートウェイ
図5 サブネットマスク
図6 DHCPが割り当てる範囲の最初のアドレス
図7 DHCPが割り当てる範囲の最後のアドレス
図8 DHCPが割り当てるアドレスの個数
図9 IPv4のNAT設定を行うかどうか(以下IPv6についても同様の設定を行う)
これで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のマイグレーションが役に立つのではないでしょうか。