コンテナを理解するには、まずその歴史から始めましょう

コンテナの歴史、開発、技術的な性質については、インターネット上にすでに多くの記事があります。ここでの目的は、私自身の仕事経験と理解に基づいた一連の記事を通じて、この技術をわかりやすく説明することです。

コンテナの歴史と発展

前世

コンテナについて語るとき、Docker の前身である LXC (Linux Container) について触れなければなりません。言い換えれば、Docker は LXC のユーザーです。完全な LXC 機能は 2008 年に Linux メインラインに統合されたため、コンテナーの概念は基本的に 2008 年に確定しており、Docker によって後から作成されたものではありません。 LXC についての紹介はたくさんあります。ほとんどの人は、「LXC は Linux カーネルによって提供されるコンテナ テクノロジであり、軽量の仮想化機能を提供し、プロセスとリソースを分離できます」と言うでしょう。しかし、要約すると、重要な知識ポイントは Cgroups (Linux コントロール グループ) と Linux 名前空間の 2 つだけです。これら 2 つを理解すれば、コンテナ技術の基本を理解できます。

• Cgroups: 「制限」に重点が置かれています。 CPU、メモリ、ディスク使用量などのリソース使用量を制限することは、リソースを管理する能力を反映します。
• 名前空間: 「分離」に重点が置かれています。分離されたプロセスから見た Linux ビュー。簡単に言えば、コンテナは互いに影響を与えてはならず、コンテナとホスト マシンも互いに影響を与えてはなりません。

思春期の困難なスタート

2009 年、Cloud Foundry は LXC に基づくコンテナ操作を実装し、プロジェクトは Warden と名付けられました。 2010 年には、dotCloud は Go 言語 (現在の Docker) を使用して LXC テクノロジーに基づくコンテナー エンジンも実装しました。当時、dotCloud はまだ小さな会社であり、つつましい状況で生まれた Docker はあまり人気がなく、非常に苦戦していました。

巨人へと成長する

2013 年、dotCloud は Docker をオープンソース化することを決定しました。オープンソース化された後、このプロジェクトは突然人気が出ました。一般的に言えば、Docker の人気の理由は「一度ビルドすれば、どこでも実行できる」というスローガンです。ハハ、見覚えがあるかな？はい、これは Java の Write Once, Run Anywhere と同じ原理です。プログラマーにとっては、プログラムが書かれた後は、それをイメージにパッケージ化してどこにでも展開して実行することができ、開発、テスト、本番環境は完全に一貫しています。これはなんと大きな誘惑でしょう。プログラマーは、環境の違いによって生じるさまざまな問題をトラブルシューティングする必要がなくなりました。

Docker オープンソース プロジェクトの並外れた人気により、dotCloud は 2013 年にその名前を Docker に変更しました。Docker も急速に成長し、CoreOS の rkt コンテナや Google の lmctfy コンテナに取って代わり、コンテナの事実上の標準となりました。そのため、コンテナについて言及すると、人々は Docker を思い浮かべることになります。

まとめると、Docker が人気がある理由は、Docker イメージにあります。彼は、アプリケーションの依存関係をすべてパッケージ化し、環境の一貫性の問題を完全に解決し、ソフトウェアの提供方法を​​再定義し、生産効率を向上させました。

大国に侵略される

Docker はコンテナ分野で急速に成長しており、その野心も当然大きくなっています。同社は2014年に事業拡大を目指してコンテナクラウド製品「Swarm」（Kubenetesと同様の製品）を発売した。同時に、Docker はオープンソース コミュニティで絶対的な発言力を持っており、非常に強力です。独自の道を進み、他者に道を譲らないというこの行動は、コンテナ分野の他の主要企業を非常に不満にさせています。 Docker が市場を独占するのを防ぐために、彼らは Docker と戦うことを決意しました。

2015 年 6 月、Google や Redhat などの大手企業の「運営」の下、Linux Foundation は、コンテナ形式とランタイムを中心としたオープンな業界標準 (OCI 標準と呼ばれることが多い) の開発を目指して OCI (Open Container Initiative) 組織を設立しました。同時に、Docker は Libcontainer モジュールを OCI 標準の実装として CNCF コミュニティに寄贈しました。これは現在 RunC プロジェクトとなっています。簡単に言えば、この分野では標準が確立され、特定のプロジェクトに縛られることなく、誰もが一緒にプレイできるようになりました。

Docker について話すときは、Google の Kubernetes について話さなければなりません。コンテナクラウドプラットフォームのデファクトスタンダードとして広く利用されており、大手メーカーの標準構成となっています。 Kubernetes は Docker をネイティブにサポートしており、これにより Docker の市場シェアは高く維持されています。次の図は、2019 年のコンテナ ランタイムの市場シェアを示しています。

しかし、2020年にKubernetesは突然、バージョン1.20以降、つまり2021年以降はデフォルトのコンテナランタイムとしてDockerをサポートしなくなり、メインコードからdockershimを削除すると発表しました。

図に示すように、Kubenetes 自体は、CRI インターフェイスを実装する任意のコンテナ ランタイムに接続するための標準コンテナ ランタイム インターフェイス CRI (Container Runtime Interface) を定義します。初期の頃、Docker はコンテナ ランタイムの王者として誰もが認める存在でした。Kubenetes には Docker のサポートが組み込まれており、dockershim を使用して標準の CRI インターフェイスを Docker インターフェイスに適合させ、より多くのユーザーを引き付けていました。オープンソースのコンテナ ランタイム Containerd (CRI インターフェイスを実装し、Docker から CNCF に寄贈されている) が成熟したため、Kubenetes は dockershim を保守しなくなり、標準の CRI の保守のみを担当するようになり、特定のコンテナ ランタイムに縛られることがなくなりました。もちろん、Kubenetes が Docker をサポートしていないわけではなく、dockershim を誰が保守するかという問題です。 Kubenetes の姿勢が変化するにつれて、オープンソースの Containerd に直接接続することを選択する開発者が増えることが予想されます。 Docker と Docker オープンソース プロジェクト (現在は Moby に名前が変更されています) に将来どのような変化が起こるかは誰にも予測できません。

この時点で、Docker が実際に Containerd と runC を寄贈したことに気づいたでしょうか。この二人はいったい何なのでしょう？簡単に言えば、runC は OCI 標準の実装であり、OCI ランタイムとも呼ばれ、コンテナの操作を実際に担当します。 Containerd は、runC を管理および制御するための外部インターフェースを提供します。したがって、上の写真は実際には次のようになるはずです。

Docker は、ヒットプロジェクトによって人気が出た小規模企業の典型的な例です。技術的なレベルなのか、会社のビジネスレベルなのか、大企業とどう戦っているのか、それが良いのか悪いのか、その背景にあるストーリーを学び、理解することは価値があります。

コンテナとは何か

国際的な慣例によれば、新しい概念を導入するときは、誰もがよく知っているものから始めなければなりません。幸いなことに、コンテナの概念は比較的理解しやすいです。水を飲むためのコップ、足を洗うためのバケツ、水槽などはすべて容器です。コンテナ技術における「コンテナ」は同様の概念ですが、含まれるものは異なります。アプリケーション ソフトウェア自体と、ソフトウェアの実行に必要な依存関係が含まれています。水槽を例にすると、水槽内のアプリケーションは魚であり、依存関係は魚の餌と水です。これで誰もが Docker ロゴを理解できるようになりました。海がホスト、Docker がクジラ、クジラの背中のコンテナがコンテナ、そして私たちのアプリケーションはコンテナ内にインストールされます。

コンテナについて話すとき、コンテナ イメージを避けることはできません。ここでは、コンテナ イメージを単に圧縮されたパッケージとして理解しますが、これについては後で詳しく説明します。圧縮されたパッケージには、アプリケーションの実行可能プログラムと、プログラムが依存するファイル (たとえば、呼び出す必要がある構成ファイルや動的ライブラリ) が含まれています。次に、実際の操作を通じてコン​​テナとは何かを見てみましょう。

ホストの視点から見たコンテナ

1. まず、コンテナを起動します。

 docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"  

これは標準の Docker コマンドです。これは、euleros_arm:2.0SP8SPC306 イメージ (イメージ名: バージョン番号) を使用して「aimar-1-container」という名前の新しいコンテナを作成し、コンテナ内でシェル コマンド print "aimar-1-container" を 1 秒に 1 回実行することを意味します。

パラメータの説明:

• -d: コンテナをバックグラウンド モードで起動し、コンテナ ID を返します。
• --name: コンテナの名前を指定します。

 docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"    
 207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c

出力から、長い文字列 207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c が確認できます。コンテナを一意に識別できるコンテナ ID です。もちろん、使用時にはフルIDを使用する必要はなく、短縮ID（フルIDの最初の数桁）を直接使用できます。たとえば、下の図では、docker ps によって照会されるコンテナ ID は 207b7c0cbd81 です。

aimar-1-container コンテナが正常に起動したら、ps を使用してホスト マシン上で表示します。この時点で、起動したコンテナは PID が 12280 のプロセスであることがわかります。

さらに 2 つのコンテナを起動して、ホスト上で再度確認してみます。さらに 2 つのプロセス (それぞれ PID 20049 と 21097) が追加されていることがわかります。

それで、結論を得ることができます。ホストの観点から見ると、コンテナはプロセスです。

2. 次に、このコンテナに入ります。

 docker exec -it 207b7c0cbd81 /bin/bash

Docker exec も、コンテナに入るために使用される標準の Docker コマンドです。これは、コンテナ ID 207b7c0cbd81 のコンテナに入り、入った後に /bin/bash コマンドを実行し、コマンド対話を開始することを意味します。

パラメータの説明:

• -it は実際には 2 つのパラメータ -i と -t であり、コンテナの起動後に、コンテナとのやり取りを容易にし、コンテナと「対話」する機能を実現するために、入出力ターミナルを割り当てる必要があることを意味します。

ホスト名が kwephispra09909 から 207b7c0cbd81 に変わり、コンテナに入ったことが示されます。コンテナ内で、新しいプロセスを開始してみます。

 [root@207b7c0cbd81 /]# /bin/sh -c "while true; do echo aimar-1-container-embed; sleep 1; done" &

ホストマシンに戻り、ps を再度実行します。コンテナを直接起動するか、コンテナ内で新しいプロセスを起動するかに関係なく、ホスト マシンの観点からは、それらはすべてプロセスであることがわかります。

コンテナの視点から見たコンテナ

先ほどコンテナに入り、新しいプロセスを開始しました。しかし、コンテナ内のプロセスは表示されませんでした。コンテナ内で ps を実行すると、ホスト上で ps を実行した場合に得られる結果とはまったく異なる結果が得られることがわかります。次の図はコンテナ内での実行結果を示しています。

Container1 では、新しく開始されたシェル プロセス (container1 と container1-embed) のみが表示されます。ホスト マシン上の他のプロセスは表示されず、Container2 および Container3 内のプロセスも表示されません。これらのプロセスは箱の中に閉じ込められているようなもので、外の世界をまったく知らず、実行しているコンテナ 1 がプロセス 1 であるとさえ考えています (プロセス 1 は init プロセスとも呼ばれ、システム内の他のすべてのユーザー プロセスの祖先プロセスです)。したがって、コンテナの観点から見ると、コンテナは「私は空です、私は地球です、私の世界へようこそ」と感じます。

しかし、恥ずかしいことに、ホスト マシン上では、それらはありきたりのプロセスであり、それ以上普通ではないということです。同じプロセスであっても、コンテナ内に表示されるプロセス ID はホスト上に表示されるプロセス ID とは異なることに注意してください。コンテナ内のプロセス ID は 1 と 1859 で、ホスト上の対応するプロセス ID は 12280 と 9775 です (上図を参照)。

要約する

上記の実験を通じて、コンテナの定義に属性を追加する必要があることがわかりました。コンテナはプロセスです => コンテナはシステムの他の部分から分離されたプロセスです。次の図を見ると理解しやすくなります。コンテナは、ホスト OS 上で実行されるプロセスです (仮想マシン コンテナのホスト OS はゲスト OS です)。コンテナ間およびコンテナとホスト間には分離があり、たとえばプロセス ID が分離されます。

同じプロセスのプロセス ID がコンテナ内とホスト上で異なります。たとえば、コンテナ内の Container1 の PID は 1 で、ホスト上のそれは 12280 です。では、プロセスの実際の PID は何でしょうか?もちろん12280です！では、なぜコンテナ 1 に PID が表示されるのでしょうか?この錯覚を引き起こすのは Linux 名前空間です。

Linux 名前空間は、Linux カーネルがリソースを分離する方法です。各名前空間内のリソースは不透明であり、他の名前空間からは見えません。

名前空間は分離されたリソースによって分類されます。

前述のように、コンテナの内外に表示されるプロセス ID は異なりますが、これは PID 名前空間の使用によるものです。では、この名前空間はどこにあるのでしょうか? Linux では、すべてがファイルです。はい、名前空間はファイル内にあります。プロセスに対応する名前空間情報は、ホストマシン上の proc ファイル (/proc/プロセス番号/ns) に記録されます。次の図に示すように、数字 (例: pid:[4026534312]) は名前空間を表します。

3 つのコンテナ Container1、Container2、Container3 では、PID 名前空間が異なることがわかります。これは、3 つのコンテナ内の PID が互いに分離されていることを意味します。つまり、3 つのコンテナは同時に同じ PID 番号を持つプロセスを持つことができます。たとえば、すべてのコンテナに PID=1 のプロセスがあることになります。

名前空間では、2 つのプロセスは相互に表示されますが、PID はホスト マシンに表示されるものとは異なります。

この時点で、コンテナの定義をさらに細かく設定できます。コンテナは、システムの他の部分から分離されたプロセスです。コンテナは、Linux 名前空間を使用してシステムの他の部分から分離されたプロセスです。