これは、 Container runtimes Part 1：An Introduction to Container runtimesの記事の翻訳です。
原著の著者： Ian Lewis 。
コンテナを扱うときによく耳にする用語の1つは、 「コンテナランタイム」です （ 以降、 「ランタイム」は 「ランチャー環境」 -約Translatorとして翻訳されます ）。 「コンテナ起動環境」は人によって意味が異なるため、ユーザーや開発者のDockerコミュニティであっても、これが非常にわかりにくく曖昧に理解できる用語であることは驚くことではありません。
この投稿は、4つのパートで構成されるシリーズの最初の投稿です。
- パート1：コンテナー起動環境の概要：なぜそんなに混乱するのですか？
- パート2：低レベルの打ち上げ環境でのディープイマージョン
- パート3：高レベルの打ち上げ環境の詳細
- パート4：KubernetesおよびCRIで環境を起動する
この投稿では、コンテナの起動環境とは何か、また誤解の原因はどこにあるのかを説明します。 その後、さまざまな種類のコンテナー起動環境、それらが行うこと、およびそれらが互いにどのように異なるかについて詳しく調べます。
（写真ではしゃれ： これがコンテナのKubernetes起動環境、コンテナの低レベル起動環境、または映画の継続時間に適用されるかどうかはわかりません -翻訳者による注意）
伝統的に、プログラマーは「実行時」 を、プログラムが実行されるプログラムのライフサイクルのフェーズとして、またはこの実行をサポートする言語環境として理解できます 。 ここでの例は、Java HotSpotランタイムです。 最後の値は、 「ランタイム」コンテナに最も近い値です。 コンテナ起動環境は、プログラム自体の起動に直接関与しないコンテナ起動のすべてのフェーズを担当します。 このシリーズの後半で説明するように、ランチャーはさまざまなレベルの機能を提供しますが、ツールの「コンテナーを起動する」機能は、基本的にコンテナーランチャーを呼び出すために必要なすべてです。
コンテナにあまり詳しくない場合は、まずこれらの資料をよく理解してから戻ってください。
コンテナランタイムが非常に混乱しているのはなぜですか？
Dockerは2013年にリリースされ、コンテナを連続チェーンで起動することで多くの開発者の問題を解決しました。 含まれるもの：
- コンテナイメージ形式
- コンテナイメージの構築方法（Dockerfile / docker build）
- コンテナイメージ（dockerイメージ、docker rmなど）を管理する機能
- コンテナインスタンスを管理する機能（docker ps、docker rmなど）
- コンテナイメージを共有する機能（ドッカープッシュ/プル）
- コンテナを実行する機能（docker run）
この間ずっと、Dockerはモノリシックシステムでした。 しかし、これらの機能はどれも互いに依存していません。 それらのそれぞれは、一緒に使用できる、より小さく専用のツールで実装できます。 各ツールは、コンテナの標準である共通の形式を使用して、他のツールと連携して機能します。
このため、Docker、Google、CoreOS、およびその他のベンダーがOpen Container Initiative（OCI）を作成しました。 その後、コンテナをツールとして実行するためのコードとruncというライブラリを分離し、起動環境のOCI仕様の参照実装としてOCIに渡しました。
最初は、Dockerが正確に送信したOCIの混乱が問題です。 彼らが伝えたのは、コンテナを発射する標準的な方法であり、それ以上のものではありませんでした。 これらには、イメージレジスタ（イメージストレージ）からコンテナーイメージを受信/アンロードするためのイメージ形式またはプロトコルは含まれていませんでした。 Dockerコンテナを起動すると、Dockerが実際に実行する手順は次のとおりです。
- 画像をダウンロードします。
- イメージを「バンドル」に解凍します。 このアクションは、レイヤーを単一のファイルシステムに揃えます。
- パッケージからコンテナを実行します。
Dockerが標準化したという事実は、ステップ3のみでした。 これが明確になるまで、誰もがコンテナー起動環境をDockerがサポートするすべての機能をサポートするシステムとして認識していました。 時間が経つにつれて、Dockerのメンバーは、 元の仕様では「起動コンテナー」部分のみが「起動環境」を形成すると主張していることを明確にしました。 現在も続いているこの切断により、「コンテナ起動環境」は非常に混乱したトピックになります。 両当事者がある程度正しいことを示したいと思います。この投稿では、この用語をかなり広く使用します。
低レベルおよび高レベルのコンテナー起動環境。
開発者がコンテナ起動環境を考えるとき、ここに思い浮かぶかもしれないいくつかの例のリストがあります：runc、lxc、lmctfy、Docker（containerd）、rkt、cri-o。 それらはそれぞれ異なる状況に合わせて設計されており、さまざまな機能を実行します。 containerdやcri-oなどの一部では、実際にruncを使用してコンテナーを実行していますが、イメージ管理を行い、その上にAPIを備えています。 これらの関数（画像転送、画像管理、画像展開、APIなど）は、低レベルのrunc実装と比較して高レベルの関数と考えることができます。
これを念頭に置いて、コンテナ起動環境の範囲は非常に複雑であることがわかります。 各起動環境は、このスペクトルの低レベルから高レベルまでのさまざまな部分をカバーしています。 これは非常に主観的なチャートです。
実際には、単にコンテナの起動に焦点を合わせたコンテナ起動環境は、一般に「低レベルのコンテナ起動環境」と呼ばれます。 画像管理やさまざまなgRPC / Web APIなどの高レベル機能をサポートする他のランチャーは、一般に「高レベルコンテナーランチャー」、「高レベルコンテナーランチャー」、または単に「コンテナーランチャー」と呼ばれます。 それらを「高レベルのコンテナ起動環境」と呼びます。 低レベルと高レベルの起動環境は、さまざまな問題を解決する根本的に異なるものであることに注意することが重要です。
コンテナは、Linux 名前空間メカニズムとcgroupを使用して実装されます 。 名前空間を使用すると、各コンテナのファイルシステムやネットワークなどのシステムリソースを仮想化できます。 Cgroupsは、各コンテナーが使用できるCPUやメモリなどのリソースの量を制限する方法を提供します。 最下位レベルでは、コンテナー起動環境がこれらの名前空間とcgroupの構成を担当します。 低レベルのスタートアップ環境のサポートでは、オペレーティングシステムのこれらの機能をそのまま使用します。
通常、コンテナでアプリケーションを実行する開発者は、低レベルの起動環境が提供するよりも多くの機能を必要とします。 画像形式、画像管理、画像共有機能に関するAPIと機能が必要です。 これらの機能は、高レベルの起動環境を提供します。 低レベルの打ち上げ環境には、そのような日々のニーズに十分な機能がありません。 これらの理由から、低レベルの起動環境を使用するのは、高レベルの起動環境とコンテナツールの開発者だけです。
低レベルランチャーの開発者は、containerdやcri-oなどの高レベルランチャーは、実際にはコンテナーランチャーではないと言うでしょう。なぜなら、彼らの観点からは、コンテナーrunc runcの実行を委任するからです。 ただし、ユーザーの観点から見ると、コンテナを実行する機能を提供する完全なツールです。 ある実装は別の実装と交換できるため、この観点からそれらを起動環境と呼ぶのは理にかなっています。 containerdとcri-oの両方がruncを使用するという事実にもかかわらず、これらは非常に異なる機能をサポートする2つの非常に異なるプロジェクトです。
次回...
コンテナの起動環境とは何か、なぜ理解が難しいのかを理解する助けになれば幸いです。 記事（著者のサイト-翻訳者のメモ）またはTwitterにコメントを残して、コンテナ起動環境で最も理解しにくいことを教えてください。
次の投稿では、低レベルのコンテナー起動環境に真っ向から取り組みます。 その中で、まさに低レベルのコンテナー起動環境が何をするかについてお話します。 人気のある低レベルの起動環境（runcやrktなど）と、人気のない重要な環境（lmctfyなど）の両方について説明します。 単純な低レベルのスタートアップ環境の実行方法についても説明します。 次の投稿が公開されたときに通知されるように、RSSフィードまたはTwitterに登録してください。
それまでは、次のチャンネルを通じてKubernetesコミュニティに参加できます。
- スタックオーバーフローに関する質問の送信と回答
- Twitterで@Kubernetesioをフォローする
- Kubernetes Slackに参加し、チャットすることにより。 （私はianlewisだからこんにちは！）
- GitHubで Kubernetesに貢献する
この投稿の下書きをチェックしてくれたSandeep Dinesh 、 Mark Mandel 、 Craig Box 、 Maya Kaczorowski 、Joe Burnettに感謝します。
翻訳者から ：私は、ユーザーGDApsyに翻訳の下書きをチェックしてくれたことに感謝します。