コンテナ化に関する一連の記事を続けます。 今日は、Open Containersプロジェクトの一部として開発されたコンテナー起動ツールである
runCについて
説明します。 このプロジェクトの目標は、コンテナ技術の分野で単一の標準を開発することです。 このプロジェクトは、Facebook、Google、Microsoft、Oracle、EMC、Dockerなどの企業によってサポートされています。 2015年の夏、仕様の草案が
Open Container Initiative（OCI）という名前で公開されました。
RunCは、最新のコンテナ化ツールですでに積極的に使用されています。 そのため、Dockerの最新バージョン（今年の春にリリースされた1.11以降）
は、OCI仕様に従って作成され、runCに基づいて動作します。 また、基本的にruncの一部であるlibcontainerライブラリは、バージョン1.8以降、LXCではなくDockerで使用されています。
この記事では、runCを使用してコンテナーを作成および管理する方法を示します。
設置
Ubuntu 16.04用のruncのインストールについて説明します。 このオペレーティングシステムでは、Goの現在の安定バージョン（1.6）が公式リポジトリに既に含まれており、標準的な方法でインストールされています。
$ sudo apt-get install golang-go
RuncはUbuntu 16.04リポジトリにも含まれていますが、最新バージョンとはほど遠いものです。 最新バージョン（1.0.0）は、ソースコードからコンパイルする必要があります。 これを行うには、まず必要な依存関係をインストールする必要があります。
sudo apt-get install build-essential make libseccomp-dev
以上で、runCの構築を開始できます。
$ git clone https://github.com/opencontainers/runc $ cd runc $ make $ sudo make install
これらのコマンドの実行の結果、runcはディレクトリ/ usr / local / bin / runcにインストールされます。
最初のコンテナーを作成する
これで、すべてが最初のコンテナを作成する準備ができました。
最初に行う必要があるのは、新しいコンテナ用に別のディレクトリを作成することです。その中にはrootfsディレクトリがあります。
$ mkdir /mycontainer $ cd /mycontainer $ mkdir rootfs
最も単純な例から始めましょう。 memcachedドッカーイメージをダウンロードし、* .tarアーカイブに変換して、rootfsディレクトリに解凍します。
$ docker export $(docker create memcached) | tar -C rootfs -xvf -
このコマンドの結果、将来のコンテナのシステムファイルはrootfsディレクトリに配置されます。
$ ls rootfs bin dev etc lib media opt root sbin sys usr boot entrypoint.sh home lib64 mnt proc run srv tmp var
その後、Dockerに頼らずにコンテナを起動して管理できます。 新しいコンテナの設定が書き込まれる構成ファイルを作成します。
$ sudo runc spec
その後、新しいファイルがrootfsディレクトリに表示されます-config.json。 すべてが新しいコンテナを起動する準備ができています。 実行：
$ sudo runc run mycontainer
コンテナ内でコマンドシェルが起動します。
コンテナが自動的に生成された設定で起動される最も基本的な例を検討しました。 コンテナを微調整するには、上記のconfig.jsonファイルを手動で編集する必要があります。 その構造をさらに詳しく分析しましょう。
Config.json構成ファイル
構成ファイルの最初の部分では、コンテナの一般的な特性、OCIバージョン、オペレーティングシステムとそのアーキテクチャ、端末パラメータについて説明します。
"ociVersion": "1.0.0-rc1", "platform": { "os": "linux", "arch": "amd64" }, "process": { "terminal": true, "user": { "uid": 0, "gid": 0 }, "args": [ "sh" ], "env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ],
次のセクションでは、コンテナが機能するディレクトリの設定を提供します。
"cwd": "/", "capabilities": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE" ],
CWDは現在の作業ディレクトリを表します。 私たちの場合、これは「/」ディレクトリです。 以下は一連の
機能です （ロシア語では、この用語は「機能」として完全に翻訳されていません）-実行可能ファイルがルート特権なしで特定のサブシステムを使用するための許可。 CAP_AUDIT_WRITEを使用すると、監査ログに書き込みできます。CAP_KILL-プロセスにシグナルを送信し、CAP_NET_BIND_SERVICE-ソケットを特権ポート（つまり、1024未満の番号のポート）にバインドできます。
次のセクションはrlimitsです。
"rlimits": [ { "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 } ], "noNewPrivileges": true },
ここで、コンテナのリソース制限、つまり同時に開くことができるファイルの最大数（RLIMIT_NOFILE）を1024に設定します。
以下は、ルートファイルシステム設定の説明です。
"root": { "path": "rootfs", "readonly": true }
mountsセクションでは、コンテナにマウントされているディレクトリについて説明します。
"mounts": [ { "destination": "/tmp", "type": "tmpfs", "source": "tmpfs", "options": ["nosuid","strictatime","mode=755","size=65536k"] }, { "destination": "/data", "type": "bind", "source": "/volumes/testing", "options": ["rbind","rw"] } ]
config.jsonファイルの最も基本的なセクションのみを調べました。 他のセクションのいくつかについては、以下で説明します。 このファイルの詳細な説明は
ここにあります 。
フック
別の興味深いrunc機能はフックの設定です：コンテナでユーザープロセスが開始する前（開始前）、ユーザープロセスが開始した後（ポストスタート）、停止した後（ポストストップ）に実行される特定のアクションを設定ファイルで指定できます。
フックが必要な理由と、対応する設定が構成ファイルにどのように書き込まれるかをよりよく理解するための例をいくつか示します。 このような状況を想像してください。コンテナでプログラムを開始する前に、ネットワークを構成する必要があります。 これを行うには、そのようなフックを構成ファイルに追加します（例は公式ドキュメントから取られています）。
"hooks": { "prestart": [ { "path": "/path/to/script" }
パスセクションには、プログラムへのパスが書き込まれ、ネットワークを構成します。 この種の既製のソフトウェアツールはGithubにあり
ます 。たとえば、
こちらを参照してください。
ポストスタートフックの例を考えてみましょう。
"poststart": [ { "path": "/usr/bin/notify-start", "timeout": 5 }
このフックが機能すると、スクリプトが起動され（この例ではnotify-startと呼ばれます）、ログにコンテナの起動に関連するイベントに関する情報が記録されます。
ポストストップフックは、コンテナ内のユーザープロセスが完了した後に実行されるアクションを開始します。 たとえば、システム内のコンテナによって残されたログとセッションファイルを削除する必要がある場合や、同時にコンテナ自体が必要になる場合があります。 以下に簡単な例を示します。
"poststop": [ { "path": "/usr/sbin/cleanup.sh", "args": ["cleanup.sh", "-f"] }
このフックがトリガーされると、cleanup.shスクリプトが起動され、上記のすべての手順が実行されます。
コンテナ管理：基本コマンド
Runcは、シンプルで使い慣れたコマンドを使用してコンテナを管理します。 以下にそれらの短いリストを示します。
ネットワーク設定
基本的なコンテナ管理操作を理解しました。 コンテナでネットワークを構成してみましょう。 これは簡単な作業ではありません。 すべての操作は手動で実行する必要があります。
まず、次の一連のコマンドを実行します（
この記事から
引用 ）。
$ sudo brctl addbr runc0 $ sudo ip link set runc0 up $ sudo ip addr add 192.168.10.1/24 dev runc0 $ sudo ip link add name veth-host type veth peer name veth-guest $ sudo ip link set veth-host up $ sudo brctl addif runc0 veth-host $ sudo ip netns add runc $ sudo ip link set veth-guest netns runc $ sudo ip netns exec runc ip link set veth-guest name eth1 $ sudo ip netns exec runc ip addr add 192.168.10.101/24 dev eth1 $ sudo ip netns exec runc ip link set eth1 up $ sudo ip netns exec runc ip route add default via 192.168.10.1
上記のチームは、彼ら自身のために話します。 最初に、コンテナとメインホスト上のインターフェイス間の通信用のブリッジを作成します。 次に、仮想インターフェイスを「レイズ」して、ブリッジに追加します。 その後、runcという名前のネットワーク名前空間（名前空間）を作成し、その中のeth1インターフェイスにIPアドレスを割り当てます。
コンテナでネットワークを構成するには、runc名前空間をそれに関連付ける必要があります。 これを行うには、config.jsonファイルに小さな変更を加えます。
...... "root": { "path": "rootfs", "readonly": false }
名前空間セクションで、runc名前空間へのパスを指定します。
{ "type": "network", "path": "/var/run/netns/runc" },
それだけです：必要な設定はすべて綴られています。 変更を保存し、コンテナを再起動します。 メインホストでコマンドを実行します。
$ ping 192.168.10.101 PING 192.168.10.101 (192.168.10.101) 56(84) bytes of data. 64 bytes from 192.168.10.101: icmp_seq=2 ttl=64 time=0.070 ms 64 bytes from 192.168.10.101: icmp_seq=3 ttl=64 time=0.090 ms 64 bytes from 192.168.10.101: icmp_seq=4 ttl=64 time=0.106 ms 64 bytes from 192.168.10.101: icmp_seq=5 ttl=64 time=0.091 ms 64 bytes from 192.168.10.101: icmp_seq=6 ttl=64 time=0.097 ms
彼女の結論は、コンテナがメインホストからのpingを受け入れることを示しています。
おわりに
この記事は、runCの簡単な紹介です。 もっと知りたい人のために、ここに便利なリンクの小さな選択があります：
runを既に実験している場合は、コメントで経験を共有してください。