先日リリースされたUbuntu 18.
本記事の続編として次の記事が公開されています。
システムコンテナの管理ツールであるLXD
LXDはCanonical主導のもと開発されているシステムコンテナの管理ツールです。
コンテナ型の仮想環境と言えばDockerが有名ですが、
LXDは一度インスタンスを構築しログインしたあとは、
つまりLXDはコンテナ技術を利用した、
Ubuntu 18.
- LXD 2.
0.x: 2018年4月以前のLTSブランチ - LXD 2.
x: 2018年4月以前のフィーチャーブランチ - LXD 3.
0.x: 最新のLTSブランチ - LXD 3.
x: 現在のフィーチャーブランチ
16.
LXD 3.
いくつかの改善ポイントをあげてみましょう
- ホストとコンテナ間でのGPUパススルーやSR-IOVなどの設定が簡単に
- storage/
networkの設定UIの拡充 - UID/
GIDマッピングをコンテナごとに設定できるように - 事前設定ファイルを用いた
lxd initの自動化 - EC2ライクな
「インスタンスタイプ」 によるリソース制限設定 - Dockerライクな
「ストレージボリューム」 機能 lxc consoleによるコンソールへのアタッチ- 複数のマシン間のLXDのクラスタリング
- ホスト上のキャラクターデバイス・
ブロックデバイスのホットプラグ （コンテナへの自動追加） のサポート - ホスト・
コンテナ間のネットワーク転送を簡単に実現できるproxyデバイスの追加
なお、
LXDのインストール方法
Ubuntu 18.
$ sudo apt install lxd btrfs-progs
btrfs-progsパッケージは、
Ubuntu 16.
（Ubuntu 16.04 LTSで2.0系よりあとのリリースをインストールする方法） $ sudo apt -t xenial-backports install lxd
18.
snap版はchannelを利用してリリースブランチを指定可能です。
- latest: 現在のフィーチャーブランチ
- 2.
0: 一つ前のLTSブランチ - 3.
0: 最新のLTSブランチ
$ sudo snap install lxd ←常に最新のフィーチャーリリースに更新される $ sudo snap install lxd --channel=2.0 ←2.0系の最新LTS版を使用する $ sudo snap install lxd --channel=3.0 ←3.0系の最新LTS版を使用する
ちなみにLXDの管理コマンドであるlxcコマンドを管理者権限なしに実行したい場合は、
Ubuntuサーバーをインストールした場合は、
上記に該当しないユーザーを管理者権限なしにLXDの操作をしたい場合は、
LXDの初期設定
LXDを利用する前に、
$ sudo lxd init
Would you like to use LXD clustering? (yes/no) [default=no]:
=> 異なるマシンに存在するLXDサービスと連携したいかどうか
Do you want to configure a new storage pool? (yes/no) [default=yes]:
=> ストレージプール（コンテナの保存先）を作成するかどうか
Name of the new storage pool [default=default]:
=> 作成するストレージプールの名前
Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]:
=> ストレージバックエンドの選択
速度・利便性の両方においてbtrfsを選ぶのが無難です
ホストのファイルシステムがbtrfsである必要はありません
Create a new BTRFS pool? (yes/no) [default=yes]:
=> btrfsのプールを作成するかどうか
Would you like to use an existing block device? (yes/no) [default=no]:
=> 既存のブロックデバイスを利用するかどうか
利用しない場合はbtrfsでフォーマットしたイメージファイルを作成します
Size in GB of the new loop device (1GB minimum) [default=21GB]:
=> ストレージプールのサイズ
Would you like to connect to a MAAS server? (yes/no) [default=no]:
=> MAASサーバーに接続するかどうか
Would you like to create a new network bridge? (yes/no) [default=yes]:
=> LXD用にネットワークブリッジI/Fを作成するかどうか
What should the new bridge be called? [default=lxdbr0]:
=> ネットワークブリッジのデバイス名
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
=> コンテナインスタンス向けIPv4アドレスの設定
autoにすると適当なサブネットマスクを割り当てます
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]:
=> コンテナインスタンス向けIPv6アドレスの設定
Would you like LXD to be available over the network? (yes/no) [default=no]:
=> LXDサービスをネットワーク上の他のマシンから見えるようにするか
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]
=> 取得したコンテナベースイメージを自動的に更新するか
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:
=> 上記設定情報をYAML形式で出力するか
ちなみにLXD 2.sudo lxd init」
おそらく初期設定のうちもっとも利用に影響しそうなのがストレージプールの設定でしょう。ストレージプールは、
ストレージバックエンドによって、
デスクトップ上で試す場合など、
btrfsを使う場合、
$ lxc storage list +---------+-------------+--------+--------------------------------+---------+ | NAME | DESCRIPTION | DRIVER | SOURCE | USED BY | +---------+-------------+--------+--------------------------------+---------+ | default | | btrfs | /var/lib/lxd/disks/default.img | 1 | +---------+-------------+--------+--------------------------------+---------+ $ sudo file /var/lib/lxd/disks/default.img /var/lib/lxd/disks/default.img: BTRFS Filesystem label "default", （後略）
しかしながらbtrfsやZFSのループバックイメージファイルをプロダクション用途で使うのは推奨されていないようです。もし本格的に使用する予定であれば、
たとえばbtrfsの場合、/dev/などを用意しておきます。lxd init時の/dev/」lxd init完了後に/dev/」
$ lxc storage show default config: source: 7d555893-d8a9-4c42-a609-f4f40900ee7b volatile.initial_source: /dev/sdb2 description: "" name: default driver: btrfs used_by: - /1.0/profiles/default status: Created locations: - none $ lxc storage info default info: description: "" driver: btrfs name: default space used: 16.62MB total space: 1.36TB used by: profiles: - default
LXDの基本的な使い方
コンテナのライフサイクルから、
インスタンスの作成と起動
まずコンテナのイメージからインスタンスを作成・
$ lxc launch ubuntu:18.04 bionic bionic を作成中 bionic を起動中
上記コマンドを実行することによりリモートイメージーサーバーであるubuntuから、
LXDにはベースイメージファイルを公開するイメージサーバーという概念があります。ローカルのLXDサービス自身もイメージサーバーになるので、
$ lxc remote list +-----------------+------------------------------------------+---------------+-----------+--------+--------+ | NAME | URL | PROTOCOL | AUTH TYPE | PUBLIC | STATIC | +-----------------+------------------------------------------+---------------+-----------+--------+--------+ | images | https://images.linuxcontainers.org | simplestreams | | YES | NO | +-----------------+------------------------------------------+---------------+-----------+--------+--------+ | local (default) | unix:// | lxd | tls | NO | YES | +-----------------+------------------------------------------+---------------+-----------+--------+--------+ | ubuntu | https://cloud-images.ubuntu.com/releases | simplestreams | | YES | YES | +-----------------+------------------------------------------+---------------+-----------+--------+--------+ | ubuntu-daily | https://cloud-images.ubuntu.com/daily | simplestreams | | YES | YES | +-----------------+------------------------------------------+---------------+-----------+--------+--------+
NAMEフィールドで指定された名前をイメージ名の前のコロンの前に追加することで、
URLとPROTOCOLのフィールドは提供元のURLとそのイメージの提供方法です。
AUTH TYPEフィールドはイメージサーバーとして利用するにあたって認証が必要かどうか、lxc remoteで設定変更可能かどうかを示します。
イメージサーバーからダウンロードするイメージは、
$ lxc image list +-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE | +-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+ | | 9879a79ac2b2 | no | ubuntu 18.04 LTS amd64 (release) (20180522) | x86_64 | 172.97MB | May 27, 2018 at 9:10am (UTC) | +-------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
初回はダウンロードに時間がかかりますが、
lxc launchコマンドは、
$ lxc init ubuntu:18.04 bionic $ lxc start bionic
もし作成したコンテナを起動する前に設定を行いたい場合は、lxc launchではなくこちらのコマンドを使うと良いでしょう。
コンテナの操作
作成したコンテナはlxc listコマンドで確認できます。
$ lxc list +--------+---------+--------------------+-----------------------------------------------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +--------+---------+--------------------+-----------------------------------------------+------------+-----------+ | bionic | RUNNING | 10.41.184.9 (eth0) | fd42:dbb6:9ea0:3ab0:216:3eff:fed7:124e (eth0) | PERSISTENT | 0 | +--------+---------+--------------------+-----------------------------------------------+------------+-----------+
起動中のコンテナはSTATEフィールドがRUNNINGになります。IPアドレスが割り当てられているので、
また、lxc infoコマンドでコンテナインスタンスの詳細を確認できます。
$ lxc info bionic
コンテナ名: bionic
リモート名: unix://
アーキテクチャ: x86_64
作成日時: 2018/05/27 09:10 UTC
状態: Running
タイプ: persistent
プロファイル: default
Pid: 2311
IPアドレス:
eth0: inet 10.41.184.9 veth4335QT
eth0: inet6 fd42:dbb6:9ea0:3ab0:216:3eff:fed7:124e veth4335QT
eth0: inet6 fe80::216:3eff:fed7:124e veth4335QT
lo: inet 127.0.0.1
lo: inet6 ::1
リソース:
プロセス数: 36
CPU使用量:
CPU使用量（秒）: 6
メモリ消費量:
メモリ (現在値): 132.04MB
メモリ (ピーク): 215.07MB
ネットワーク使用状況:
eth0:
受信バイト数: 306.69kB
送信バイト数: 12.77kB
受信パケット: 331
送信パケット: 158
lo:
受信バイト数: 892B
送信バイト数: 892B
受信パケット: 12
送信パケット: 12
Ubuntuのcloud-imageの場合、
lxc execコマンドを使うと、
$ lxc exec bionic bash root@bionic:~#
たとえばGitHubに登録しているSSHの公開鍵を、~/.ssh/に追加したい場合は、
root@bionic:~# sudo -i -u ubuntu ssh-import-id gh:（GitHubのアカウント名）
コンテナ内部とファイルのやりとり
先程実行したbashのプロセスをコンテナの中から見てみましょう。
root@bionic:~# ps -f $$ UID PID PPID C STIME TTY STAT TIME CMD root 321 0 0 09:49 ? Ss 0:00 bash
コンテナの中のプロセスIDは321で、ps -fe | grep "321.*bash"」
$ grep NSpid.*321$ /proc/*/status /proc/22494/status:NSpid: 22494 321 $ ps -f 22494 UID PID PPID C STIME TTY STAT TIME CMD 165536 22494 22485 0 18:49 pts/5 Ss+ 0:00 bash
これによりホスト上のプロセスIDは22494になっていることがわかります。さらにUIDも1665536になっています。これはコンテナ上のrootアカウントは、
ユーザー名前空間を用いたUID/lxc fileを用いたファイルの管理方法が存在しています。
コンテナからファイルを取得する $ lxc file pull コンテナ名/フルパス 保存先 コンテナにファイルを渡す $ lxc file push ファイル コンテナ名/フルパス コンテナ上のファイルを削除する $ lxc file delete コンテナ名/フルパス コンテナ上のファイルを編集する $ lxc file edit コンテナ名/フルパス
気をつけなければいけないのは、/etc/ならsample/」-r」
またlxc file pushの場合は、
単にファイルをやり取りするのであれば、lxc fileを使う一番のメリットはコンテナ間でも同じインターフェースを使えることでしょう。特に別のホスト上にあるLXDサービスのコンテナに対してもlxc fileを用いてファイルを送受信することが可能です。
lxc file editで編集時に使用するテキストエディターは、
コンテナを停止・終了する
lxc stopでコンテナを停止できます。
$ lxc stop bionic
もしうまく停止できないようなら--force」
一度停止したコンテナはlxc startで起動できます。また、lxc restartでコンテナを再起動できます。
startやstop、--all」
コンテナを削除する
使わなくなったコンテナインスタンスはlxc deleteで削除できます。
$ lxc delete bionic
一度削除したコンテナインスタンスは復旧できませんので注意してください。
LXDでコンテナ生活を
このようにLXDを使うと、
今回は紹介しませんでしたが、
単に決まったサービスを立ち上げるだけであればDockerを始めとするOCI準拠なあれやこれやを使うほうがシンプルですし、