Lxd は次世代のシステム コンテナ マネージャーであるため、 ソース。 仮想マシンに似たユーザー インターフェイスを提供しますが、代わりに Linux コンテナを使用します。

LXDコア は、ローカルの UNIX ソケット経由で、また適切な構成がインストールされている場合はネットワーク経由で REST API を提供する特権デーモン (root 権限で実行されるサービス) です。 LXD で提供されるコマンド ライン ツールなどのクライアントは、この REST API を通じてリクエストを作成します。 これは、ローカル ホストにアクセスしているかリモート ホストにアクセスしているかに関係なく、すべてが同じように機能することを意味します。

この記事では、LXD の概念については詳しく説明しません。また、コンテナーと並行して QEMU 仮想マシンをサポートする最新バージョンの LXD での最近の実装を含め、ドキュメントで概要が説明されているすべての利用可能な機能については考慮しません。 代わりに、ストレージ プールのセットアップ、ネットワーク、コンテナの実行、リソース制限の適用、スナップショットの使用方法など、コンテナ管理の基本だけを学びます。これにより、LXD の基本を理解し、Linux でコンテナを使用できるようになります。

完全な情報については、公式ソースを参照してください。

• 開発者のウェブサイト
• Документация
• フォーラム

ナビゲーション

• インストールLXD
  • Ubuntu ディストリビューションへの LXD のインストール
  • Arch Linux ディストリビューションへの LXD のインストール
• ストレージLXD（ストレージ）
• LXDの初期化中
  • ストレージプールのファイルシステムの選択
  • ウィザードを使用したネットワークとストレージ プールの初期化
  • 追加のストレージプールの作成
    • ストレージプールのサイズを増やす
    • ループバックファイルをループバックデバイススロットに自動挿入
  • 安全性。 コンテナの権限
  • 仮想ネットワークスイッチの作成
  • 構成プロファイル
    • プロフィールを編集する
    • 新しいプロファイルの作成
  • 画像リポジトリ
    • リモートイメージリポジトリ
    • ローカルイメージリポジトリ
  • LXD 構成
• コンテナの作成と管理
  • 静的IPアドレスの設定
  • コンテナの削除
  • コンテナへのアクセス
  • コンテナリソース管理
    • RAMリソースの制限
    • CPUリソース制限
    • ディスク容量の制限
    • リソース消費統計
  • スナップショットの操作

インストールLXD ^

Ubuntu ディストリビューションへの LXD のインストール ^

Ubuntu 19.10 配布パッケージ内 lxd に放送があります スナップパッケージ:

apt search lxd

lxd/eoan 1:0.7 all
  Transitional package - lxd -> snap (lxd)

これは、XNUMX つのパッケージが一度にインストールされ、XNUMX つはシステム パッケージとして、もう XNUMX つはスナップ パッケージとしてインストールされることを意味します。 システムに XNUMX つのパッケージをインストールすると、スナップ パッケージ マネージャーによってスナップ パッケージが削除された場合にシステム パッケージが孤立するという問題が発生する可能性があります。

パッケージを探す lxd スナップ リポジトリでは、次のコマンドを使用できます。

snap find lxd

Name             Version        Summary
lxd              3.21           System container manager and API
lxd-demo-server  0+git.6d54658  Online software demo sessions using LXD
nova             ocata          OpenStack Compute Service (nova)
nova-hypervisor  ocata          OpenStack Compute Service - KVM Hypervisor (nova)
distrobuilder    1.0            Image builder for LXC and LXD
fabrica          0.1            Build snaps by simply pointing a web form to...
satellite        0.1.2          Advanced scalable Open source intelligence platform

コマンドを実行することで list パッケージであることを確認できます lxd まだインストールされていません:

snap list

Name  Version    Rev   Tracking  Publisher   Notes
core  16-2.43.3  8689  stable    canonical✓  core

LXD はスナップ パッケージであるにもかかわらず、システム パッケージを通じてインストールする必要があります lxd、システム内に対応するグループ、必要なユーティリティが作成されます。 /usr/bin 等

sudo apt update
sudo apt install lxd

パッケージがスナップ パッケージとしてインストールされていることを確認してみましょう。

snap list

Name  Version    Rev    Tracking  Publisher   Notes
core  16-2.43.3  8689   stable    canonical✓  core
lxd   3.21       13474  stable/…  canonical✓  -

Arch Linux ディストリビューションへの LXD のインストール ^

システムに LXD パッケージをインストールするには、次のコマンドを実行する必要があります。最初のコマンドはリポジトリで利用可能なシステム上のパッケージのリストを更新し、XNUMX 番目のコマンドはパッケージを直接インストールします。

sudo pacman -Syyu && sudo pacman -S lxd

パッケージのインストール後、通常のユーザーで LXD を管理するには、システム グループに追加する必要があります lxd:

sudo usermod -a -G lxd user1

ユーザーを確認しましょう user1 グループに追加されました lxd:

id -Gn user1

user1 adm dialout cdrom floppy sudo audio dip video plugdev netdev lxd

グループの場合 lxd がリストに表示されない場合は、ユーザー セッションを再度アクティブにする必要があります。 これを行うには、ログアウトして、同じユーザーでログインする必要があります。

でアクティブ化する systemd システム起動時に LXD サービスをロードします。

sudo systemctl enable lxd

サービスを開始しましょう:

sudo systemctl start lxd

サービスのステータスを確認する:

sudo systemctl status lxd

ストレージLXD（ストレージ） ^

初期化を開始する前に、LXD のストレージがどのように論理的に配置されているかを理解する必要があります。

ストレージ （Storage) состоит XNUMXつ以上から ストレージプール ZFS、BTRFS、LVM、または通常のディレクトリなど、サポートされているファイル システムのいずれかを使用します。 毎 ストレージプール ボリュームに分かれています (ストレージボリューム) 他の目的のイメージ、コンテナ、またはデータが含まれています。

• 画像 - これらは、Linux カーネルを含まずに特別に組み立てられたディストリビューションであり、外部ソースから入手できます。
• コンテナ - これらはイメージからデプロイされたディストリビューションであり、すぐに使用できます
• スナップショット - これらは、元に戻すことができるコンテナーの状態のスナップショットです。

LXD でストレージを管理するには、次のコマンドを使用します lxc storage キーを指定して取得できる証明書 - lxc storage --help

次のコマンドは、すべてのリストを表示します。 ストレージプール LXD ストレージ内:

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | /dev/loop1                     | 2       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | /var/lib/lxd/disks/ssdpool.img | 4       |
+---------+-------------+--------+--------------------------------+---------+

すべてのリストを表示するには ストレージボリューム 選択した ストレージプール チームに貢献する lxc storage volume list:

lxc storage volume list hddpool

+-------+----------------------------------+-------------+---------+
| TYPE  |          NAME                    | DESCRIPTION | USED BY |
+-------+----------------------------------+-------------+---------+
| image | ebd565585223487526ddb3607f515... |             | 1       |
+-------+----------------------------------+-------------+---------+

lxc storage volume list ssdpool

+-----------+----------------------------------+-------------+---------+
|   TYPE    |            NAME                  | DESCRIPTION | USED BY |
+-----------+----------------------------------+-------------+---------+
| container | alp3                             |             | 1       |
+-----------+----------------------------------+-------------+---------+
| container | jupyter                          |             | 1       |
+-----------+----------------------------------+-------------+---------+
| image     | ebd565585223487526ddb3607f515... |             | 1       |
+-----------+----------------------------------+-------------+---------+

また、 ストレージプール 作成時にBTRFSファイルシステムが選択され、リストを取得します ストレージボリューム または サブボリューム BTRFS 解釈では、このファイル システムのツールキットを使用できます。

sudo btrfs subvolume list -p /var/lib/lxd/storage-pools/hddpool

ID 257 gen 818 parent 5 top level 5 path images/ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3

sudo btrfs subvolume list -p /var/lib/lxd/storage-pools/ssdpool

ID 257 gen 1820 parent 5 top level 5 path images/ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
ID 260 gen 1819 parent 5 top level 5 path containers/jupyter
ID 263 gen 1820 parent 5 top level 5 path containers/alp3

LXDの初期化中 ^

コンテナを作成して使用する前に、ネットワークとストレージを作成および構成する一般的な LXD 初期化を実行する必要があります。 これは、リストにある標準のクライアント コマンドを使用して、次のコマンドを呼び出して手動で行うことができます。 lxc --help または初期化ウィザードを使用する lxd init いくつかの質問に答えます。

ストレージプールのファイルシステムの選択 ^

初期化中に、LXD はデフォルトのファイル システム タイプの決定など、いくつかの質問をします。 ストレージプール。 デフォルトでは、BTRFS ファイル システムが選択されます。 作成後に別のFSに変更することはできません。 FS を選択することをお勧めします 機能比較表:

特徴
ディレクトリ
Btrfs
LVM
ZFS
セフ

最適化された画像ストレージ
いいえ
はい
はい
はい
はい

最適化されたインスタンス作成
いいえ
はい
はい
はい
はい

最適化されたスナップショット作成
いいえ
はい
はい
はい
はい

最適化された画像転送
いいえ
はい
いいえ
はい
はい

最適化されたインスタンス転送
いいえ
はい
いいえ
はい
はい

コピーオンライト
いいえ
はい
はい
はい
はい

ブロックベース
いいえ
いいえ
はい
いいえ
はい

インスタントクローン作成
いいえ
はい
はい
はい
はい

コンテナ内で使用可能なストレージドライバー
はい
はい
いいえ
いいえ
いいえ

古いスナップショット (最新ではない) からの復元
はい
はい
はい
いいえ
はい

ストレージ割り当て
はい（*）
はい
はい
はい
いいえ

ウィザードを使用したネットワークとストレージ プールの初期化 ^

次に説明するコマンドは、初期化ウィザードを使用して簡単な質問に答えることで、LXD の主要コンポーネントをセットアップすることを提案します。

コマンドを実行 lxc init 以下の例に示すように、コロンの後に質問への回答を入力するか、条件に応じて回答を変更します。

lxd init

Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: ssdpool         
Name of the storage backend to use (lvm, btrfs, dir) [default=btrfs]: 
Create a new BTRFS pool? (yes/no) [default=yes]: 
Would you like to use an existing block device? (yes/no) [default=no]: 
Size in GB of the new loop device (1GB minimum) [default=15GB]: 10GB
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=lxdbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 10.0.5.1/24
Would you like LXD to NAT IPv4 traffic on your bridge? [default=yes]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none
Would you like LXD to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes] no
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 

追加のストレージプールの作成 ^

前のステップで作成した ストレージプール 名前が付けられたのは ssdpool そのファイルは私のシステム上の次の場所にあります。 /var/lib/lxd/disks/ssdpool.img。 このファイル システム アドレスは、PC の物理 SSD ドライブに対応します。

が果たす役割についての理解を深めるため、次のような取り組みを行います。 ストレージプール リポジトリに XNUMX 番目のリポジトリを作成します ストレージプール これは物理的には別の種類のディスク (HDD) に配置されます。 問題は、LXD では作成できないことです。 ストレージプール 住所外 /var/lib/lxd/disks/ シンボリックリンクも機能しません 開発者の応答を参照してください。 初期化/フォーマット中にこの制限を回避できます。 ストレージプール ループバック ファイルへのパスの代わりにブロック デバイスとして値を指定し、これをキーに指定します。 source.

ということで、作成する前に ストレージプール ループバック ファイル、またはそれが使用するファイル システム上の既存のパーティションを定義する必要があります。 これを行うには、サイズを 10 GB に制限するファイルを作成して使用します。

dd if=/dev/zero of=/mnt/work/lxd/hddpool.img bs=1MB count=10000

10000+0 records in
10000+0 records out
10000000000 bytes (10 GB, 9,3 GiB) copied, 38,4414 s, 260 MB/s

ループバック ファイルを空きループバック デバイスに接続しましょう。

sudo losetup --find --show /mnt/work/lxd/hddpool.img

/dev/loop1

鍵のおかげで --show コマンドを実行すると、ループバック ファイルが接続されているデバイスの名前が画面に返されます。 必要に応じて、このタイプのビジー状態のすべてのデバイスのリストを表示して、アクションが正しいことを確認できます。

losetup -l

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                      DIO LOG-SEC
/dev/loop1         0      0         0  0 /mnt/work/lxd/hddpool.img        0     512
/dev/loop0         0      0         1  0 /var/lib/lxd/disks/ssdpool.img   0     512

リストから、デバイスに次の機能があることがわかります。 /dev/loop1 ループバックファイルが含まれています /mnt/work/lxd/hddpool.img、そしてデバイス内で /dev/loop0 ループバックファイルが含まれています /var/lib/lxd/disks/ssdpool.img これはデフォルトに対応します ストレージプール.

次のコマンドは新しいコマンドを作成します ストレージプール 準備したばかりのループバック ファイルに基づいて LXD で作成します。 LXD はループバック ファイルをフォーマットします /mnt/work/lxd/hddpool.img デバイス内で /dev/loop1 BTRFS ファイル システムの場合:

lxc storage create hddpool btrfs size=10GB source=/dev/loop1

すべてのリストを表示してみましょう ストレージプール 画面へ:

lxc storage list

+---------+-------------+--------+--------------------------------+---------+
|  NAME   | DESCRIPTION | DRIVER |             SOURCE             | USED BY |
+---------+-------------+--------+--------------------------------+---------+
| hddpool |             | btrfs  | /dev/loop1                     | 0       |
+---------+-------------+--------+--------------------------------+---------+
| ssdpool |             | btrfs  | /var/lib/lxd/disks/ssdpool.img | 0       |
+---------+-------------+--------+--------------------------------+---------+

ストレージプールのサイズを増やす ^

作成後 ストレージプール、必要に応じて拡張できます。 のために ストレージプール BTRFS ファイル システムに基づいて、次のコマンドを実行します。

sudo truncate -s +5G /mnt/work/lxd/hddpool.img
sudo losetup -c /dev/loop1
sudo btrfs filesystem resize max /var/lib/lxd/storage-pools/hddpool

ループバックファイルをループバックデバイススロットに自動挿入 ^

小さな問題が XNUMX つあります。ホスト システムを再起動すると、ファイルが /mnt/work/lxd/hddpool.img デバイスから「飛び出す」 /dev/loop1 また、このデバイスでは LXD サービスが認識されないため、ロード時に LXD サービスがクラッシュします。 この問題を解決するには、このファイルをデバイスに挿入するシステム サービスを作成する必要があります。 /dev/loop1 ホスト システムの起動時。

作成しましょう 単位 ファイルの種類 サービス в /etc/systemd/system/ SystemD 初期化システムの場合:

cat << EOF | sudo tee -a /etc/systemd/system/lxd-hddpool.service
[Unit]
Description=Losetup LXD Storage Pool (hddpool)
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img
RemainAfterExit=true

[Install]
WantedBy=local-fs.target
EOF

サービスをアクティブ化します。

sudo systemctl enable lxd-hddpool

Created symlink /etc/systemd/system/local-fs.target.wants/lxd-hddpool.service → /etc/systemd/system/lxd-hddpool.service.

ホスト システムを再起動した後、サービスのステータスを確認します。

systemctl status lxd-hddpool.service 

● lxd-hddpool.service - Losetup LXD Storage Pool (hddpool)
     Loaded: loaded (/etc/systemd/system/lxd-hddpool.service; enabled; vendor preset: disabled)
     Active: active (exited) since Wed 2020-04-08 03:43:53 MSK; 1min 37s ago
    Process: 711 ExecStart=/sbin/losetup /dev/loop1 /mnt/work/lxd/hddpool.img (code=exited, status=0/SUCCESS)
   Main PID: 711 (code=exited, status=0/SUCCESS)

апр 08 03:43:52 manjaro systemd[1]: Starting Losetup LXD Storage Pool (hddpool)...
апр 08 03:43:53 manjaro systemd[1]: Finished Losetup LXD Storage Pool (hddpool).

出力から、サービスの状態が次であることを確認できます。 アクティブXNUMX つのコマンドからのスクリプトの実行が完了したにもかかわらず、オプションによりこれを実行できるようになりました。 RemainAfterExit=true.

安全性。 コンテナの権限 ^

すべてのコンテナ プロセスは実際にはカーネルを使用してホスト システム上で分離して実行されるため、ホスト システムへのコンテナ プロセスのアクセスをさらに保護するために、LXD はプロセス権限を提供します。

• 特権コンテナ - これらは、UID と GID を持つプロセスがホスト システム上と同じ所有者に対応するコンテナーです。 たとえば、UID が 0 のコンテナ内で実行されているプロセスには、UID が 0 のホスト システム上のプロセスとすべて同じアクセス権があります。つまり、コンテナ内の root ユーザーは、コンテナ内のすべての権限を持っています。コンテナーだけでなく、コンテナーの分離された名前空間の外に出ることができる場合はホスト システム上でも同様です。

• 特権のないコンテナ - これらは、プロセスが 0 ～ 65535 の番号を持つ UID と GID の所有者に属するコンテナーですが、ホスト システムの場合、所有者はそれぞれ追加された SubUID ビットと SubGID ビットを使用してマスクされます。 たとえば、コンテナ内の UID=0 を持つユーザーは、ホスト システム上では次のように表示されます。 SubUID + UID。 これにより、コンテナー内のプロセスが分離された名前空間から脱出できる場合、未知の非常に高い UID/GID を持つプロセスとしてのみホスト システムと通信できるため、ホスト システムが保護されます。

デフォルトでは、新しく作成されたコンテナーは非特権ステータスを持っているため、SubUID と SubGID を定義する必要があります。

それぞれ SubUID と SubGID のマスクを設定する XNUMX つの構成ファイルを作成しましょう。

sudo touch /etc{/subuid,/subgid}
sudo usermod --add-subuids 1000000-1065535 root 
sudo usermod --add-subgids 1000000-1065535 root

変更を適用するには、LXD サービスを再起動する必要があります。

sudo systemctl restart lxd

仮想ネットワークスイッチの作成 ^

以前に初期化ウィザードを使用してネットワークを初期化したため、 lxd init ネットワークデバイスを作成しました lxdbr0次に、このセクションでは、LXD のネットワークと、クライアント コマンドを使用して仮想スイッチ (ブリッジ) を作成する方法について簡単に説明します。

次の図は、スイッチ (ブリッジ) がホストとコンテナーをネットワークに接続する方法を示しています。

コンテナーは、ネットワークを介して他のコンテナーまたはこれらのコンテナーが提供されるホストと通信できます。 これを行うには、コンテナの仮想ネットワーク カードを仮想スイッチにリンクする必要があります。 最初にスイッチを作成し、コンテナ自体が作成された後、後続の章でコンテナのネットワーク インターフェイスをリンクします。

次のコマンドは、サブネットを持つスイッチを作成します。 10.0.5.0/24 およびIPv4アドレス 10.0.5.1/24、また、 ipv4.nat コンテナが NAT サービスを使用してホスト経由でインターネットにアクセスできるようにします。

lxc network create lxdbr0 ipv4.address=10.0.5.1/24 ipv4.nat=true ipv6.address=none

LXD で利用可能なネットワーク デバイスのリストを確認します。

lxc network list

+--------+----------+---------+-------------+---------+
|  NAME  |   TYPE   | MANAGED | DESCRIPTION | USED BY |
+--------+----------+---------+-------------+---------+
| eno1   | physical | NO      |             | 0       |
+--------+----------+---------+-------------+---------+
| lxdbr0 | bridge   | YES     |             | 0       |
+--------+----------+---------+-------------+---------+

Linux ディストリビューションの標準ツールを使用してネットワーク デバイスが作成されたことを確認することもできます。 ip link または ip addr:

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:ee:7b:5a:6b:44 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet6 fe80::9571:11f3:6e0c:c07b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c2:38:90:df:cb:59 brd ff:ff:ff:ff:ff:ff
    inet 10.0.5.1/24 scope global lxdbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::c038:90ff:fedf:cb59/64 scope link 
       valid_lft forever preferred_lft forever
5: veth3ddab174@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
    link/ether ca:c3:5c:1d:22:26 brd ff:ff:ff:ff:ff:ff link-netnsid 0

構成プロファイル ^

LXD の各コンテナーには独自の構成があり、グローバルに宣言された構成を使用して拡張できます。 構成プロファイル。 コンテナーへの構成プロファイルの適用にはカスケード モデルがあり、次の例はこれを示しています。

この例では、LXD システムに XNUMX つのプロファイルが作成されています。 default, hddpool и hostfs。 XNUMX つのプロファイルはすべて、ローカル構成 (灰色の領域) を持つコンテナーに適用されます。 プロフィール default デバイスを持っています root パラメータがあるもの pool 等しい ssdpoolただし、カスケード構成アプリケーション モデルのおかげで、プロファイルをコンテナに適用できます。 hddpool パラメータがあるもの pool プロファイルの同じパラメータをオーバーライドします default コンテナはデバイス構成を受け取ります root パラメータ付き pool 等しい hddpoolとプロフィール hostfs 新しいデバイスをコンテナに追加するだけです。

使用可能な構成プロファイルのリストを表示するには、次のコマンドを使用します。

lxc profile list

+---------+---------+
|  NAME   | USED BY |
+---------+---------+
| default | 1       |
+---------+---------+
| hddroot | 0       |
+---------+---------+
| ssdroot | 1       |
+---------+---------+

プロファイルを操作するために使用できるコマンドの完全なリストは、キーを追加することで取得できます。 --help:

lxc profile --help

Description:
  Manage profiles

Usage:
  lxc profile [command]

Available Commands:
  add         Add profiles to instances
  assign      Assign sets of profiles to instances
  copy        Copy profiles
  create      Create profiles
  delete      Delete profiles
  device      Manage instance devices
  edit        Edit profile configurations as YAML
  get         Get values for profile configuration keys
  list        List profiles
  remove      Remove profiles from instances
  rename      Rename profiles
  set         Set profile configuration keys
  show        Show profile configurations
  unset       Unset profile configuration keys

プロフィールを編集する ^

デフォルトの構成プロファイル default コンテナにはネットワーク カード構成がなく、新しく作成されたコンテナにはネットワークがありません。そのため、別のコマンドでローカル (専用) ネットワーク デバイスを作成する必要がありますが、構成でグローバル ネットワーク デバイスを作成できます。このプロファイルを使用するすべてのコンテナ間で共有されるプロファイル。 こうすることで、新しいコンテナを作成するコマンドの直後に、ネットワークにアクセスできるネットワークが確立されます。 同時に、制限はなく、必要に応じていつでもローカル ネットワーク デバイスを作成できます。

次のコマンドは、デバイスを構成プロファイルに追加します。 eth0 типа nic ネットワークに接続されている lxdbr0:

lxc profile device add default eth0 nic network=lxdbr0 name=eth0

実際にデバイスを構成プロファイルに追加したため、デバイスに静的 IP アドレスを指定した場合、このプロファイルを使用するすべてのコンテナが同じ IP アドレスを共有することに注意することが重要です。 コンテナに静的 IP アドレスが割り当てられたコンテナを作成する必要がある場合は、プロファイル レベルではなく、IP アドレス パラメータを使用してコンテナ レベル (ローカル構成) でネットワーク デバイス構成を作成する必要があります。

プロフィールを確認してみましょう:

lxc profile show default

config: {}
description: Default LXD profile
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: /
    pool: ssdpool
    type: disk
name: default
used_by: []

このプロファイルでは、新しく作成されたすべてのコンテナーに対して XNUMX つのデバイスが作成されることがわかります。

• eth0 - デバイスタイプ nic スイッチ（ネットワークブリッジ）に接続 lxdbr0
• root - デバイスタイプ disk ストレージプールを使用する ssdpool

新しいプロファイルの作成 ^

以前に作成したものを使用するには ストレージプール コンテナ、構成プロファイルを作成する ssdroot ここで次のようなデバイスを追加します disk マウントポイントあり / (root) 以前に作成したものを使用 ストレージプール - ssdpool:

lxc profile create ssdroot
lxc profile device add ssdroot root disk path=/ pool=ssdpool

同様に、次のようなデバイスを作成します disk、ただし、この場合は次を使用します ストレージプール - hddpool:

lxc profile create hddroot
lxc profile device add hddroot root disk path=/ pool=hddpool

構成プロファイルの確認:

lxc profile show ssdroot

config: {}
description: ""
devices:
  root:
    path: /
    pool: ssdpool
    type: disk
name: ssdroot
used_by: []

lxc profile show hddroot

config: {}
description: ""
devices:
  root:
    path: /
    pool: hddpool
    type: disk
name: hddroot
used_by: []

画像リポジトリ ^

コンテナーは、Linux カーネルを持たない特別に組み立てられたディストリビューションであるイメージから作成されます。 したがって、コンテナーを実行する前に、このイメージからコンテナーをデプロイする必要があります。 イメージのソースはローカル リポジトリで、イメージは外部リポジトリからダウンロードされます。

リモートイメージリポジトリ ^

デフォルトでは、LXD は XNUMX つのリモート ソースから画像を受信するように構成されています。

• Ubuntu： (安定した Ubuntu イメージの場合)
• ubuntu-daily: (毎日の Ubuntu イメージの場合)
• 画像： (他の多くのディストリビューションの場合)

lxc remote list

+-----------------+------------------------------------------+--------+--------+
|      NAME       |                   URL                    | PUBLIC | STATIC |
+-----------------+------------------------------------------+--------+--------+
| images          | https://images.linuxcontainers.org       | YES    | NO     |
+-----------------+------------------------------------------+--------+--------+
| local (default) | unix://                                  | NO     | YES    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu          | https://cloud-images.ubuntu.com/releases | YES    | YES    |
+-----------------+------------------------------------------+--------+--------+
| ubuntu-daily    | https://cloud-images.ubuntu.com/daily    | YES    | YES    |
+-----------------+------------------------------------------+--------+--------+

たとえば、リポジトリ ubuntu: には次のようなイメージがあります。

lxc image -c dasut list ubuntu: | head -n 11

+----------------------------------------------+--------------+----------+------------+
|                   DESCRIPTION                | ARCHITECTURE |   SIZE   |   TYPE     |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150728)  | x86_64       | 153.72MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150819)  | x86_64       | 152.91MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150906)  | x86_64       | 154.69MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+
| ubuntu 12.04 LTS amd64 (release) (20150930)  | x86_64       | 153.86MB | CONTAINER  |
+----------------------------------------------+--------------+----------+------------+

限られた数の列を表示するには、オプションを使用しました -c パラメータ付き dasut、また、コマンドを使用してリストの長さを制限しました head.

画像をフィルタリングして一覧表示できます。 次のコマンドは、利用可能なすべてのディストリビューション アーキテクチャを一覧表示します。 AlpineLinux:

lxc image -c ldast list images:alpine/3.11

+------------------------------+--------------------------------------+--------------+
|            ALIAS             |             DESCRIPTION              | ARCHITECTURE |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11 (3 more)         | Alpine 3.11 amd64 (20200220_13:00)   | x86_64       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/arm64 (1 more)   | Alpine 3.11 arm64 (20200220_13:00)   | aarch64      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/armhf (1 more)   | Alpine 3.11 armhf (20200220_13:00)   | armv7l       |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/i386 (1 more)    | Alpine 3.11 i386 (20200220_13:01)    | i686         |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/ppc64el (1 more) | Alpine 3.11 ppc64el (20200220_13:00) | ppc64le      |
+------------------------------+--------------------------------------+--------------+
| alpine/3.11/s390x (1 more)   | Alpine 3.11 s390x (20200220_13:00)   | s390x        |
+------------------------------+--------------------------------------+--------------+

ローカルイメージリポジトリ ^

コンテナの使用を開始するには、グローバル リポジトリからローカル リポジトリにイメージを追加する必要があります local:。 これでローカル リポジトリは空になり、コマンドによってこれが確認されます。 lxc image list。 方法の場合 list リポジトリを指定しない場合、デフォルトでローカル リポジトリが使用されます。 local:

lxc image list local:

+-------+-------------+--------+-------------+--------------+------+------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE |
+-------+-------------+--------+-------------+--------------+------+------+

リポジトリ内のイメージは、次の方法を使用して管理されます。

チーム
説明

lxc画像 alias
イメージのエイリアスを管理する

lxc画像 copy
サーバー間で画像をコピーする

lxc画像 削除
画像を削除する

lxc画像 edit
画像のプロパティを編集する

lxc画像 export
画像のエクスポートとダウンロード

lxc画像 import
イメージをイメージ ストアにインポートする

lxc画像 info
画像に関する役立つ情報を表示する

lxc画像 リスト
画像一覧

lxc画像 リフレッシュ
画像を更新する

lxc画像 表示する
画像のプロパティを表示

イメージをグローバル リポジトリからローカル リポジトリにコピーします images::

lxc image copy images:alpine/3.11/amd64 local: --alias=alpine3

Image copied successfully!

ローカル リポジトリで現在利用可能なすべてのイメージのリストを表示してみましょう local::

lxc image -c lfdatsu list local:

+---------+--------------+------------------------------------+--------------+
|  ALIAS  | FINGERPRINT  |            DESCRIPTION             | ARCHITECTURE |
+---------+--------------+------------------------------------+--------------+
| alpine3 | 73a3093d4a5c | Alpine 3.11 amd64 (20200220_13:00) | x86_64       |
+---------+--------------+------------------------------------+--------------+

LXD 構成 ^

対話型モードに加えて、LXD は非対話型構成インストール モードもサポートしています。これは、構成が YAML ファイルの形式で指定される場合であり、実行をバイパスして構成全体を一度にインストールできる特別な形式です。ネットワーク構成、構成プロファイルの作成など、この記事で上で説明した多くの対話型コマンドのうちの XNUMX つです。 この領域についてはここでは説明しませんので、ご自身で確認してください。 ドキュメントの中で.

次の対話型コマンド lxc config これにより、構成を設定できるようになります。 たとえば、ローカル リポジトリにダウンロードされたイメージがグローバル リポジトリから自動的に更新されないようにするには、次のコマンドを使用してこの動作を有効にします。

lxc config set images.auto_update_cached=false

コンテナの作成と管理 ^

コンテナを作成するには、次のコマンドを使用します lxc init 値が渡される先 репозиторий:образ 次に、コンテナーに必要な ID を入力します。 リポジトリはローカルとして指定できます local: グローバルなものも同様です。 リポジトリが指定されていない場合、デフォルトではローカル リポジトリがイメージの検索に使用されます。 イメージがグローバル リポジトリから指定されている場合、イメージはまずローカル リポジトリにダウンロードされ、次にコンテナの作成に使用されます。

次のコマンドを実行して、最初のコンテナを作成しましょう。

lxc init alpine3 alp --storage=hddpool --profile=default --profile=hddroot

ここで使用するコマンド キーを順番に見てみましょう。

• alpine3 — ローカル リポジトリに以前にアップロードされたイメージに対して別名 (エイリアス) が指定されています。 このイメージのエイリアスが作成されていない場合は、いつでもそのイメージを参照できます。 指紋 それが表に表示されます。
• alp — コンテナの識別子を設定します
• --storage — このキーは、どの領域にあるかを示します。 ストレージプール コンテナが作成されます
• --profile — これらのキーは、以前に作成された構成プロファイルからコンテナーに構成をカスケード適用します。

コンテナを起動すると、ディストリビューションの init システムの起動が始まります。

lxc start alp

コマンドを使用することもできます lxc launch チームを組み合わせることができます lxc init и lxc start XNUMX回の操作で。

コンテナの状態を確認する:

lxc list -c ns46tb
+------+---------+------------------+------+-----------+--------------+
| NAME |  STATE  |       IPV4       | IPV6 |   TYPE    | STORAGE POOL |
+------+---------+------------------+------+-----------+--------------+
| alp  | RUNNING | 10.0.5.46 (eth0) |      | CONTAINER | hddpool      |
+------+---------+------------------+------+-----------+--------------+

コンテナ構成の確認:

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: vethb1fe71d8
  volatile.eth0.hwaddr: 00:16:3e:5f:73:3e
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  root:
    path: /
    pool: hddpool
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

セクションで profiles このコンテナがXNUMXつの構成プロファイルを使用していることを確認できます- default и hddroot。 セクション内 devices ネットワークデバイスはプロファイルレベルで作成されているため、検出できるデバイスは XNUMX つだけです default。 コンテナで使用されているすべてのデバイスを表示するには、キーを追加する必要があります --expanded:

lxc config show alp --expanded

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: vethb1fe71d8
  volatile.eth0.hwaddr: 00:16:3e:5f:73:3e
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    name: eth0
    network: lxdbr0
    type: nic
  root:
    path: /
    pool: hddpool
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

静的IPアドレスの設定 ^

ネットワークデバイスにIPアドレスを設定しようとすると eth0 チーム lxc config device set alp コンテナ構成を対象としている場合、デバイスが存在しないことを報告するエラーが表示されます。 eth0 プロファイルに属するコンテナによって使用される default:

lxc config device set alp eth0 ipv4.address 10.0.5.5

Error: The device doesn't exist

もちろん、静的 IP アドレスを設定することもできます。 eth0 ただし、このプロファイルを使用するすべてのコンテナで同じになります。 したがって、コンテナ専用のデバイスを追加しましょう。

lxc config device add alp eth0 nic name=eth0 nictype=bridged parent=lxdbr0 ipv4.address=10.0.5.5

次に、コンテナを再起動する必要があります。

lxc restart alp

今コンテナの構成を見ると、オプションを使用する必要はありません。 --expanded ネットワークデバイスを確認するには eth0コンテナレベルで作成し、プロファイルから同じデバイスにカスケードしたためです。 default:

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200326_13:39)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200326_13:39"
  image.type: squashfs
  volatile.base_image: ebd565585223487526ddb3607f5156e875c15a89e21b61ef004132196da6a0a3
  volatile.eth0.host_name: veth2a1dc59d
  volatile.eth0.hwaddr: 00:16:3e:0e:e2:71
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    ipv4.address: 10.0.5.5
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: hddpool
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

コンテナの削除 ^

コンテナを削除するには、次のコマンドを使用します lxc deleteただし、コンテナを削除する前に、次のコマンドを使用してコンテナを停止する必要があります。 lxc stop:

lxc stop alp

lxc list

+------+---------+-------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4        | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+-----------+-----------+
| alp  | STOPPED | 10.0.5.10 (eth0)  |      | CONTAINER | 0         |
+------+---------+-------------------+------+-----------+-----------+

コンテナの状態が以下になっていることを確認した後、 停止から削除できます。 ストレージプール:

lxc delete alp

コンテナへのアクセス ^

ネットワーク接続をバイパスしてコンテナ内でコマンドを直接実行するには、次のコマンドを使用します。 lxc exec これにより、システム シェルを起動せずにコンテナ内でコマンドが実行されます。 変数、ファイル リダイレクト (パイプ) などのシェル パターンを使用してシェルでコマンドを実行する必要がある場合は、シェルを明示的に起動し、コマンドをキーとして渡す必要があります。次に例を示します。

lxc exec alp -- /bin/sh -c "echo $HOME"

コマンドで特殊なエスケープ文字が使用されました 特殊な文字の場合 $ 変数が $HOME ホスト マシン上では解釈されず、コンテナ内でのみ解釈されました。

インタラクティブ シェル モードを開始し、ホットキーを実行してセッションを終了することもできます。 CTRL+D:

lxc exec alp -- /bin/sh

コンテナリソース管理 ^

LXD では、特別な構成セットを使用してコンテナー リソースを管理できます。 コンテナ構成パラメータの完全なリストはこちらからご覧いただけます。 ドキュメントの中で.

RAMリソースの制限 ^

パラメーター limits.memory コンテナーで使用できる RAM の量を制限します。 値は数値であり、次のいずれかです。 利用可能なサフィックス.

コンテナーの RAM 制限を 256 MB に設定しましょう。

lxc config set alp limits.memory 256MB

また、メモリを制限するための他のパラメータもあります。

• limits.memory.enforce
• limits.memory.hugepages
• limits.memory.swap
• limits.memory.swap.priority

チーム lxc config show 設定されている適用されたリソース制限を含む、コンテナー構成全体を表示できます。

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200220_13:00)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200220_13:00"
  image.type: squashfs
  limits.memory: 256MB
  volatile.base_image: 73a3093d4a5ce0148fd84b95369b3fbecd19a537ddfd2e2d20caa2eef0e8fd60
  volatile.eth0.host_name: veth75b6df07
  volatile.eth0.hwaddr: 00:16:3e:a1:e7:46
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

CPUリソース制限 ^

CPU リソースを制限するには、いくつかの方法があります。 制限の種類:

• limit.cpu - コンテナを XNUMX つ以上の CPU コアにバインドします
• limits.cpu.allowance - 制限時間が経過した場合は CFS スケジューラ クォータを管理し、パーセンテージを経過した場合はユニバーサル CPU リソース共有メカニズムを管理します。
• limits.cpu.priority - 一連のプロセッサを共有する複数のインスタンスに同じ割合のプロセッサが割り当てられている場合のスケジューラの優先順位

lxc config set alp limits.cpu.allowance 40%

lxc config show alp

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine 3.11 amd64 (20200220_13:00)
  image.os: Alpine
  image.release: "3.11"
  image.serial: "20200220_13:00"
  image.type: squashfs
  limits.cpu.allowance: 40%
  limits.memory: 256MB
  volatile.base_image: 73a3093d4a5ce0148fd84b95369b3fbecd19a537ddfd2e2d20caa2eef0e8fd60
  volatile.eth0.host_name: veth75b6df07
  volatile.eth0.hwaddr: 00:16:3e:a1:e7:46
  volatile.idmap.base: "0"
  volatile.idmap.current: '[]'
  volatile.idmap.next: '[]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""

ディスク容量の制限 ^

などの制限に加えて、 limits.read, limits.write コンテナによって消費されるディスク容量を制限することもできます (ZFS または BTRFS でのみ機能します)。

lxc config device set alp root size=2GB

インストール後のパラメータで devices.root.size 設定された制限を確認できます。

lxc config show alp
...
devices:
  root:
    path: /
    pool: hddpool
    size: 2GB
    type: disk
ephemeral: false
profiles:
- default
- hddroot
stateful: false
description: ""

使用されているディスク クォータを表示するには、次のコマンドから取得できます。 lxc info:

lxc info alp
...
Resources:
  Processes: 5
  Disk usage:
    root: 1.05GB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 5.46MB
  Network usage:
    eth0:
      Bytes received: 802B
      Bytes sent: 1.59kB
      Packets received: 4
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

コンテナのルート デバイスの制限を 2GB に設定しているにもかかわらず、次のようなシステム ユーティリティ df この制限は表示されません。 これを行うために、小さなテストを実施し、それがどのように機能するかを確認します。

同じコンテナ内に 2 つの新しい同一のコンテナを作成しましょう ストレージプール (hddプール):

lxc init alpine3 alp1 --storage=hddpool --profile=default --profile=hddroot
lxc init alpine3 alp2 --storage=hddpool --profile=default --profile=hddroot

lxc list
+------+---------+------------------+------+-----------+-----------+
| NAME |  STATE  |       IPV4       | IPV6 |   TYPE    | SNAPSHOTS |
+------+---------+------------------+------+-----------+-----------+
| alp1 | RUNNING | 10.0.5.46 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+
| alp2 | RUNNING | 10.0.5.30 (eth0) |      | CONTAINER | 0         |
+------+---------+------------------+------+-----------+-----------+

いずれかのコンテナに 1 GB のファイルを作成しましょう。

lxc exec alp1 -- dd if=/dev/urandom of=file.img bs=1M count=1000

ファイルが作成されたことを確認してみましょう。

lxc exec alp1 -- ls -lh
total 1000M  
-rw-r--r--    1 root     root     1000.0M Mar 27 10:16 file.img

XNUMX 番目のコンテナーを調べて、同じ場所にファイルが存在するかどうかを確認すると、コンテナーは独自のコンテナーで作成されるため、このファイルは存在しません。これは予想されることです。 ストレージボリューム 同じように ストレージプール:

lxc exec alp2 -- ls -lh
total 0

しかし、それが生成する値を比較してみましょう df 一方のコンテナともう一方のコンテナでは次のようになります。

lxc exec alp1 -- df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
/dev/loop1           btrfs           9.3G   1016.4M      7.8G  11% /
...

lxc exec alp2 -- df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
/dev/loop1           btrfs           9.3G   1016.4M      7.8G  11% /
...

デバイス /dev/loop1 ルートパーティションとしてマウントされます ストレージプール これらのコンテナはこれを使用するため、XNUMX つのコンテナ間でそのボリュームを共有します。

リソース消費統計 ^

次のコマンドを使用して、コンテナのリソース消費統計を表示できます。

lxc info alp

Name: alp
Location: none
Remote: unix://
Architecture: x86_64
Created: 2020/04/08 18:05 UTC
Status: Running
Type: container
Profiles: default, hddroot
Pid: 19219
Ips:
  eth0: inet    10.0.5.5        veth2a1dc59d
  eth0: inet6   fe80::216:3eff:fe0e:e271        veth2a1dc59d
  lo:   inet    127.0.0.1
  lo:   inet6   ::1
Resources:
  Processes: 5
  Disk usage:
    root: 495.62kB
  CPU usage:
    CPU usage (in seconds): 1
  Memory usage:
    Memory (current): 4.79MB
  Network usage:
    eth0:
      Bytes received: 730B
      Bytes sent: 1.59kB
      Packets received: 3
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

スナップショットの操作 ^

LXD には、スナップショットを作成し、そこからコンテナーの状態を復元する機能があります。

スナップショットを作成するには、次のコマンドを実行します。

lxc snapshot alp snapshot1

チーム lxc snapshot 利用可能な鍵がありません listしたがって、スナップショットのリストを表示するには、コンテナーに関する一般情報を表示するコマンドを使用する必要があります。

lxc info alp
...
...
Snapshots:
  snapshot1 (taken at 2020/04/08 18:18 UTC) (stateless)

次のコマンドを使用して、スナップショットからコンテナを復元できます。 lxc restore 復元を実行するコンテナとスナップショットのエイリアスを指定します。

lxc restore alp snapshot1

スナップショットを削除するには、次のコマンドを使用します。 コマンド構文は他のコマンド構文と似ていないことに注意してください。ここでは、コンテナ名の後にスラッシュを指定する必要があります。 スラッシュを省略すると、スナップショットを削除するコマンドはコンテナを削除するコマンドとして解釈されます。

lxc delete alp/snapshot1

上の例では、いわゆるステートレス スナップショットを調べました。 LXD には別のタイプのスナップショット (ステートフル) があり、コンテナ内のすべてのプロセスの現在の状態を保存します。 ステートフル スナップショットに関連する興味深い便利な機能が多数あります。

他に何がありますか？ ^

• Python 開発者向けのモジュールが利用可能です PyLXD LXD に API を提供します

UPDATE 10.04.2020/15/00 XNUMX:XNUMX: ナビゲーションを追加

出所： habr.com