Red Hatでは、「コンテナーはLinuxであり、Linuxはコンテナーです」と言いたいです。これが意味することです。従来のコンテナは、通常、次の3つの特性を持つシステム上のプロセスです。
1。リソースの制約
Linuxコンテナ
- Linuxコンテナとは何ですか？
- コンテナ用語の概要
- ダウンロード：Containers Primer
- Kubernetesオペレーター：コンテナオーケストレーションプラットフォームの自動化
- eBook：クラウドネイティブアプリを設計するためのKubernetesパターン
- Kubernetesとは何ですか？
システムで多数のコンテナーを実行する場合、コンテナーがオペレーティングシステムを独占することは望ましくないため、リソースの制約を使用して、CPU、メモリ、ネットワーク帯域幅などを制御します。Linuxカーネルはcgroups機能を提供します。コンテナプロセスリソースを制御するように構成できます。
2。セキュリティ上の制約
通常、コンテナが相互に攻撃したり、ホストシステムを攻撃したりすることは望ましくありません。 Linuxカーネルのいくつかの機能を利用して、SELinux、seccomp、機能などのセキュリティ分離を設定します。
3。仮想分離
コンテナプロセスは、コンテナ外のプロセスを表示してはなりません。それらは独自のネットワーク上にある必要があります。コンテナプロセスは、さまざまなコンテナのポート80にバインドできる必要があります。各コンテナには、そのイメージの異なるビューが必要であり、独自のルートファイルシステム（rootfs）が必要です。 Linuxでは、カーネル名前空間を使用して仮想分離を提供します。
したがって、cgroupで実行され、セキュリティ設定があり、名前空間で実行されるプロセスは、コンテナと呼ばれます。 Red Hat Enterprise Linux7システムのPID1、systemdを見ると、systemdがcgroupで実行されていることがわかります。
# tail -1 /proc/1/cgroup
1:name=systemd:/
ps コマンドは、システムプロセスにSELinuxラベルがあることを示しています...
# ps -eZ | grep systemd
system_u:system_r:init_t:s0 1 ? 00:00:48 systemd
と機能。
# grep Cap /proc/1/status
...
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapBnd: 0000003fffffffff
最後に、/proc/1/nsを見ると subdirには、systemdが実行されている名前空間が表示されます。
ls -l /proc/1/ns
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 mnt -> mnt:[4026531840]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 net -> net:[4026532009]
lrwxrwxrwx. 1 root root 0 Jan 11 11:46 pid -> pid:[4026531836]
...
PID 1（および実際にはシステム上の他のすべてのプロセス）にリソースの制約、セキュリティ設定、および名前空間がある場合、システム上のすべてのプロセスがコンテナー内にあると主張します。
コンテナランタイムツールは、これらのリソースの制約、セキュリティ設定、および名前空間を変更するだけです。次に、Linuxカーネルがプロセスを実行します。コンテナが起動された後、コンテナランタイムはコンテナ内のPID1またはコンテナのstdinを監視できます。 / stdout -コンテナランタイムは、これらのプロセスのライフサイクルを管理します。
コンテナランタイム
あなたは自分自身に言うかもしれませんが、よくシステム化されたサウンドはコンテナランタイムに非常に似ています。さて、コンテナランタイムがsystemd-nspawnを使用しない理由についていくつかの電子メールディスカッションを行った後 コンテナーを起動するためのツールとして、コンテナーのランタイムについて説明し、いくつかの歴史的背景を説明する価値があると判断しました。
Dockerはコンテナランタイムと呼ばれることがよくありますが、「コンテナランタイム」はオーバーロードされた用語です。人々が「コンテナランタイム」について話すとき、彼らは実際には、開発者機能を備えたDocker、CRI-O、RKTなどの高レベルのツールについて話します。それらはAPI駆動型です。これには、コンテナレジストリからコンテナイメージをプルし、ストレージを設定し、最後にコンテナを起動するなどの概念が含まれます。コンテナの起動には、多くの場合、コンテナを実行するようにカーネルを構成する専用ツールの実行が含まれます。これらは「コンテナランタイム」とも呼ばれます。これらを「低レベルのコンテナランタイム」と呼びます。 DockerやCRI-Oのようなデーモン、およびPodmanやBuildahのようなコマンドラインツールは、おそらく代わりに「コンテナマネージャー」と呼ばれるべきです。
Dockerが最初に作成されたとき、Dockerはlxcを使用してコンテナーを起動しました systemd-nspawnより前のツールセット 。 Red HatのDockerでの最初の作業は、 libvirtを統合しようとすることでした。 （libvirt-lxc ）lxcの代わりにDockerに RHELでサポートされていなかったツール。 libvirt-lxc systemd-nspawnも使用しませんでした 。その時、systemdチームはsystemd-nspawnと言っていました はテスト用のツールであり、本番用ではありませんでした。
同時に、私のRed Hatチームの一部のメンバーを含むアップストリームのDocker開発者は、別のアプリケーションを起動するのではなく、コンテナーを起動するためのGolangネイティブの方法が必要であると判断しました。コンテナを起動するためのネイティブgolangライブラリとして、libcontainerの作業が開始されました。 Red Hatエンジニアリングは、これが最善の道であると判断し、libvirt-lxcを削除しました。 。
その後、Open Container Initiative（OCI）が結成されました。これは、人々が追加の方法でコンテナを起動できるようにしたかったためです。従来の名前空間で区切られたコンテナが人気でしたが、人々は仮想マシンレベルの分離も望んでいました。 IntelとHyper.shはKVMで区切られたコンテナーに取り組んでおり、MicrosoftはWindowsベースのコンテナーに取り組んでいました。 OCIは、コンテナーとは何かを定義する標準仕様を求めていたため、OCIランタイム仕様が誕生しました。
OCIランタイム仕様は、実行するバイナリ、その格納方法、およびコンテナーのrootfsの場所を記述するJSONファイル形式を定義します。ツールはこのJSONファイルを生成できます。次に、他のツールがこのJSONファイルを読み取り、rootfsでコンテナーを実行できます。 Dockerのlibcontainer部分が分割され、OCIに寄付されました。アップストリームのDockerエンジニアとエンジニアは、OCIランタイム仕様のJSONファイルを読み取り、libcontainerと対話してコンテナーを実行するための新しいフロントエンドツールの作成を支援しました。このツールはrunc と呼ばれます 、OCIにも寄付されました。 runc OCI JSONファイルを読み取ることができ、ユーザーはそれを自分で生成する必要があります。 runc それ以来、最も人気のある低レベルのコンテナランタイムになりました。ほとんどすべてのコンテナ管理ツールはrunc をサポートしています 、CRI-O、Docker、Buildah、Podman、CloudFoundryGardenなど。それ以来、他のツールもOCIランタイム仕様を実装してOCI準拠のコンテナーを実行しています。
ClearContainersとHyper.shのrunVの両方 ツールは、OCIランタイム仕様を使用してKVMベースのコンテナーを実行するために作成され、Kataと呼ばれる新しいプロジェクトでそれらの取り組みを組み合わせています。昨年、オラクルはRustで記述されたRailCarと呼ばれるOCIランタイムツールのデモバージョンを作成しました。 GitHubプロジェクトが更新されてから2か月が経過しているため、まだ開発中であるかどうかは不明です。数年前、VincentBattsはツール nspawn-ociの追加に取り組みました。 、OCIランタイム仕様ファイルを解釈し、systemd-nspawnを起動しました 、しかし実際には誰もそれを理解していませんでした、そしてそれはネイティブの実装ではありませんでした。
誰かがネイティブのsystemd-nspawn --oci OCI-SPEC.jsonを実装したい場合 そして、それをsystemdチームに受け入れてサポートしてもらうと、CRI-O、Docker、そして最終的にはPodmanがrunc に加えてそれを使用できるようになります。 コンテナ/runV（カタ）をクリアします。 （私のチームの誰もこれに取り組んでいません。）
結論としては、3、4年前に、上流の開発者がコンテナを起動するための低レベルのgolangツールを作成したいと考えていたため、このツールは最終的にrunc になりました。 。当時の開発者は、これを行うためのlxcと呼ばれるCベースのツールを持っていました。 そしてそれから離れました。彼らがlibcontainerを構築することを決定したとき、彼らはsystemd-nspawnに興味がなかったと確信しています。 または、「名前空間」で区切られたコンテナを実行するその他の非ネイティブ（golang）の方法。