今日のコンテナ化は、最も関連性の高いトピックの1つです。 LXCやDockerなどの一般的なツールに関する出版物の数は、数万ではないにしても、数千です。
この記事では、これまでにロシア語で出版物がほとんどない別のソリューションについて説明したいと思います。 systemd-nspawn -systemdのコンポーネントの1つである分離された環境を作成するためのツールについて話しています。 また、Linuxの世界でsystemdを標準として修正することは、すでに達成された事実です。 この事実に照らして、近い将来、systemd-nspawnの範囲が大幅に拡大すると信じるあらゆる理由があり、このツールを知る価値があります。
Systemd-nspawn：一般情報
systemd-nspawnという名前は、名前空間生成の略です。 すでにこの名前から、systemd-nspawnはプロセスの分離を制御するだけで、リソースを分離することはできません（ただし、これはsystemd自体を使用して実行できます。これについては以下で説明します）。
systemd-nspawnを使用すると、/ procおよび/ sys疑似ファイルシステムが自動的にマウントされる完全に分離された環境を作成でき、分離ループバックインターフェイスとプロセス識別子（PID）の独立した名前空間を作成できます。 Linuxカーネル。
systemd-nspawnには、Dockerのような特別なイメージリポジトリはありません。 サードパーティのツールを使用して、イメージを作成およびダウンロードできます。 tar、raw、qcow2、およびdkrの形式がサポートされています（dkrはDockerのイメージです。systemd-nspawnのドキュメントでは、これについてはどこにも明示的に書かれておらず、著者はDockerという単語を慎重に避けています）。 画像の処理は、 BTRFSファイルシステムに基づいています。
Debianコンテナーで実行する
systemd-nspawnの紹介は、シンプルですが実例から始めます。 OC Fedoraを実行しているサーバーで、Debian OSを起動する分離環境を作成します。 以下のすべてのサンプルコマンドは、systemd 219を搭載したFedora 22用です。 他のLinuxディストリビューションおよびsystemdの他のバージョンでは、コマンドが異なる場合があります。
必要な依存関係をインストールすることから始めましょう。
sudo dnf install debootstrap bridge-utils
次に、将来のコンテナ用のファイルシステムを作成します。
sudo debootstrap --arch=amd64 jessie /var/lib/machines/container1/
すべての準備作業が完了したら、コンテナの起動に進むことができます。
sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container
ゲストオペレーティングシステムのプロンプトがコンソールに表示されます。
root@test_container
ルートパスワードを設定します。
passwd Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
キーの組み合わせCtrl +]]]を押してコンテナを終了し、次のコマンドを実行します。
sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container -b
これには-bフラグ（または--boot）が含まれています。これは、コンテナでオペレーティングシステムのインスタンスを起動するときに、すべてのデーモンを実行した状態でinitを実行する必要があることを示します。このフラグは、systemd対応システムがコンテナで実行されている場合にのみ使用できますそうでない場合、システムのロードは保証されません。
これらのすべての操作が完了すると、システムはログイン名とパスワードの入力を求めます。
そのため、隔離された環境で本格的なOSが実行されています。 次に、ネットワークを構成する必要があります。コンテナを終了し、メインホスト上のインターフェイスに接続するブリッジを作成しましょう。
sudo brctl addbr cont-bridge
このブリッジにIPアドレスを割り当てます。
ip aa [IP-] dev cont-bridge
その後、次のコマンドを実行します。
sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container --network-bridge=cont-bridge -b
ネットワークを構成するには、-network-ipvlanオプションを使用することもできます。これは、ipvlanを使用して、メインホスト上の指定されたインターフェイスにコンテナを接続します。
sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container -b --network-ipvlan=[ ]
コンテナをサービスとして実行する
systemdを使用すると、システムの起動時にコンテナが自動的に起動するように構成できます。 これを行うには、次の構成ファイルを/ etc / systemd / systemディレクトリに追加します。
[Unit] Description=Test Container [Service] LimitNOFILE=100000 ExecStart=/usr/bin/systemd-nspawn --machine=test_container --directory=/var/lib/machines/container1/ -b --network-ipvlan=[ ] Restart=always [Install] Also=dbus.service
特定のフラグメントについてコメントしましょう。 [説明]セクションでは、コンテナの名前を指定するだけです。 [Service]セクションでは、最初にコンテナ内の開いているファイルの数に制限を設定し（LimitNOFILE）、次に必要なオプション（ExecStart）でコンテナを起動するコマンドを指定します。 「再起動=」という表示は、「落下」が発生した場合にコンテナを再起動する必要があることを意味します。 [Install]セクションには、ホストで自動起動するために追加する必要のある追加ユニットが示されています（この例では、D-Busプロセス間通信システムです）。
変更を構成ファイルに保存し、コマンドを実行します。
sudo systecmctl start test_container
別のより簡単な方法で、コンテナをサービスとして開始できます。 Systemdには、/ var / lib / machinesディレクトリに置かれたコンテナを自動的に起動するための事前設定された設定ファイルがあります。 次のコマンドを使用して、このワークに基づいて起動をアクティブにできます。
sudo systemctl enable machine.target mv ~/test_container /var/lib/machines/test_container sudo systemctl enable systemd-nspawn@test_container.service
コンテナー管理：machinectlユーティリティー
コンテナーは、machinectlユーティリティーを使用して制御できます。 その主なオプションを簡単に検討してください。
システムで使用可能なすべてのコンテナをリストします。
sudo machinectl list
コンテナのステータス情報を表示：
sudo machinectl status test_container
コンテナを入力してください：
sudo machinectl login test_container
コンテナをリロード：
sudo machinectl reboot test_container
コンテナを停止します：
sudo machinectl poweroff test_container
systemdと互換性のあるOSがコンテナにインストールされている場合、最後のコマンドが機能します。 sysvinitを使用するオペレーティングシステムの場合、終了オプションを使用します。
machinectlユーティリティの最も基本的な機能についてのみ説明しました。 その使用方法の詳細な手順は、たとえばここにあります 。
画像をダウンロードする
systemd-nspawnの助けを借りて、他の形式のイメージを実行できると既に述べました。 ただし、1つの重要な条件があります。イメージの操作は、/ var / lib / machinesディレクトリにマウントする必要があるBTRFSファイルシステムに基づいてのみ可能です。
sudo dnf install btrfs-progs mkfs.btrs /dev/sdb mount /dev/sdb /var/lib/machines mount | grep btrfs dev/sdb on /var/lib/machines type btrfs (rw,relatime,seclabel,space_cache)
空きディスクがない場合は、ファイルでBTRFSを実行することもできます。
systemdの新しいバージョンでは、「すぐに」イメージをダウンロードする機能がサポートされており、BTRFSをマウントする必要はありません。
Dockerイメージをロードしてみましょう。
sudo machinectl pull-dkr --verify=no library/redis --dkr-index-url=https://index.docker.io
ロードされたイメージに基づいてコンテナを起動するのは簡単です：
sudo systemd-nspawn --machine redis
コンテナログを表示する
コンテナ内で発生するすべてのイベントに関する情報はログに記録されます。 ロギング設定は、オプションを使用してコンテナを作成するときに直接設定できます
---リンクジャーナル、たとえば：
sudo systemd-nspawn -D /var/lib/machines/container1/ --machine test_container -b --link-journal=host
与えられたコマンドは、コンテナのログがディレクトリ/ var / log / journal / machine-idのメインホストに保存されることを示します。 オプション--link-journal = guestを設定すると、すべてのログは/ var / log / journal / machine-idディレクトリのコンテナに保存され、同じアドレスを持つディレクトリのメインホストにシンボリックリンクが作成されます。 --link-journalオプションは、systemdシステムがコンテナで起動されている場合にのみ機能します。 それ以外の場合、正しいロギングは保証されません。
journalctlユーティリティを使用して、コンテナの開始と停止に関する情報を表示できます。これについては、以前の出版物のいずれかで既に説明しました。
journalctl -u test_container.service
Journalctlは、コンテナ内のイベントログを表示する機能を提供します。
これを行うには、-Mオプションを使用します（出力の小さな断片のみを示します）。
journalctl -M test_container Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Runtime journal is using 8.0M (max allowed 197.6M, trying to leave 296.4M free of 1.9G available <E2><86><92> current limit 197.6M). Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Runtime journal is using 8.0M (max allowed 197.6M, trying to leave 296.4M free of 1.9G available <E2><86><92> current limit 197.6M). Sep 18 11:50:21 octavia.localdomain systemd-journal[16]: Journal started Sep 18 11:50:21 octavia.localdomain systemd[1]: Starting Slices. Sep 18 11:50:21 octavia.localdomain systemd[1]: Reached target Slices. Sep 18 11:50:21 octavia.localdomain systemd[1]: Starting Remount Root and Kernel File Systems... Sep 18 11:50:21 octavia.localdomain systemd[1]: Started Remount Root and Kernel File Systems. Sep 18 11:50:21 octavia.localdomain systemd[1]: Started Various fixups to make systemd work better on Debian.
リソース割り当て
確認したsystemd-nspawnの主な機能。 重要なポイントが1つ残っていました：コンテナへのリソースの割り当て。 上記のように、systemd-nspawnはリソースを分離しません。 systemctlを使用して、コンテナのリソース消費を制限できます。次に例を示します。
sudo systemctl set-property [ ] CPUShares=200 CPUQuota=30% MemoryLimit=500M
コンテナのリソース制限は、[Slice]セクションのユニットファイルでも指定できます。
おわりに
Systemd-nspawnは興味深く、有望なツールです。 間違いない利点の中で、強調する価値があります。
- 他のsystemdコンポーネントとの緊密な統合。
- さまざまな形式の画像を操作する機能。
- カーネルに追加のパッケージやパッチパッチをインストールする必要はありません。
もちろん、本番環境でsystemd-nspawnを完全に使用することについて話すのは時期尚早です。このツールはまだ「未加工」の状態であり、テストと実験にのみ適しています。 ただし、systemdが拡大し続けているため、systemd-nspawnの改善を待つ価値があります。
当然、レビュー記事の枠組みでは、すべてを完全に伝えることは不可能です。 コメント、コメント、追加は歓迎です。
systemd-nspawnのいくつかの詳細を見逃したり、興味深い機能について説明しなかった場合は、書き込みを行ってください。レビューを確実に補足します。
また、systemd-nspawnを使用している方がいれば、あなたの経験を共有してください。
何らかの理由でここにコメントを投稿できない読者は、私たちのブログに参加してください 。