大企業が取り組んでいるコンテナ技術とは一体何でしょうか?

導入

有名な雑誌「エコノミスト」はかつて「コンテナがなければ、グローバリゼーションはあり得ない」と評した。コンテナの出現により、現代の貨物輸送システムが再編され、運輸業界の標準化が実現し、物流と輸送コストが効果的に削減され、貨物の積み替え効率が大幅に向上したと言えます。クラウドネイティブ分野では、コンテナは輸送コンテナに相当します。ソフトウェアのリリースとソフトウェア操作の分離を標準化し、クラウドネイティブ インフラストラクチャの飛躍的な発展につながります。ある意味、コンテナ技術はソフトウェアサプライチェーン全体を再形成しました。今日は、大手企業が使用しているコンテナ技術についてお話します。

なぜコンテナ技術が必要なのでしょうか?

コンテナ技術を正式に紹介する前に、まずソフトウェア分野でコンテナ技術が必要な理由を見てみましょう。新しいテクノロジーの出現は、現時点で直面している特定の問題を解決するか、既存のソフトウェアの動作効率を向上させるために行われる必要があります。コンテナ技術が登場する以前にソフトウェア分野がどのような問題に直面していたかを分析してみましょう。

昔は、サービスをハードウェア サーバーに直接展開していました。サービス容量を拡張したい場合は、サーバーを購入し、アプリケーションの展開やさまざまな面倒な環境設定、サービス設定を行う必要があります。これらはすべて手動操作であるため、エラーが発生しやすく、時間の無駄になるだけでなく、プログラマーが必要になります。そのため、サービスの展開と移行の効率は極めて低くなります。インターネットの初期の頃は、ユーザー数もビジネス量もそれほど多くなく、まだ手作業でも対応可能でした。しかし、事業規模の継続的な発展とユーザー数の爆​​発的な増加により、このソフトウェアサービス制作方法では、急速な事業発展のニーズを満たすことができなくなりました。アプリケーション サービスをサーバーに直接展開する場合、主に 3 つの問題があります。

サービスが互いに干渉する

通常、サーバーは 1 つのサービス アプリケーションではなく複数のサービス アプリケーションを展開します。しかし、これらのサービスはすべてパブリック サーバーの CPU、メモリ、ハード ディスク、ネットワーク IO などのサーバー リソースを使用するため、リソースの競合やサービスの相互影響が必然的に発生します。

リソース利用率が低い

ビジネスにはピーク期と谷期があります。電子商取引プラットフォームの場合、深夜は一般的にビジネスが最も低迷する時間帯です。この時間帯のサーバーのリソース使用率は、業務ピーク時に比べて大幅に低下しています。したがって、ビジネスが低迷しているときには、実際のサーバー リソースの使用率は比較的低く、十分に活用することができません。

困難な移行と拡大

既存のサーバー数ではビジネスの急速な成長に対応できない場合は、サーバーインスタンスを継続的に拡張する必要があります。ただし、サービスはサーバー上に直接デプロイされるため、サービスの移行や拡張時にはさまざまな依存ライブラリ、環境構成、ネットワーク構成が必要になります。手順が複雑で拡張が難しい。

ソフトウェア分野が多くの課題に直面しているからこそ、優秀な人材が知恵と才能を発揮し、技術開発を継続的に進めていくのです。そこで、専門家は、異なるサービス構成を実現できる展開方法があれば、サービス展開のさまざまな構成問題を解決できるのではないかと考えました。プロセスが互いに影響を及ぼさないように、真のリソース分離を実現し、相互影響の問題を解決できるテクノロジーがあったら、どんなに素晴らしいことでしょう。これらの素晴らしい技術的アイデアは、実際にコンテナ技術の発展の原動力となっています。もちろん、テクノロジーの発展は一夜にして起こるものではなく、時間の経過とともに常に改善されていきます。

コンテナ テクノロジのアイデアは、Unix バージョン V7 がリリースされた 1979 年にまで遡ります。このバージョンでは、作者は chroot システム コールを発明しました。これを使用すると、プロセスとその子プロセスのルート ディレクトリを別のディレクトリに変更し、プロセスに別の新しいファイル システム コンテキスト環境を指定できます。 Unix の達人たちは、非常に早い時期からプロセス分離の認識とアイデアを持っていたことがわかります。

では、プロセス分離とは一体何でしょうか?一目で理解できるように例を挙げてみましょう。多くの学生がWebコンテナTomcatを使用したことがあると思います。 tomcat に war サービスを展開できます。 1 つの Tomcat インスタンスに 3 つのサービスがデプロイされているとします。いずれかのサービスを再起動する必要がある場合は、Tomcat 全体を再起動する必要があります。そうすると、Tomcat の 3 つのサービスすべてが再起動されます。 1 つのサービスを再起動すると、他の 2 つのサービスに影響し、サービス操作は高度に結合されます。ただし、3 つのサービスを 3 つの異なる tocmat コンテナ インスタンスにデプロイすると、いずれかのサービスを再起動しても他の 2 つのサービスには影響がないため、サービスの独立した管理が可能になります。

複数のインスタンスを展開することで、サービス間のプロセス分離が実現され、プロセスは独立したアドレス空間と実行コンテキストを持ちます。しかし、このような形の独立経営は、真の独立経営とは言えません。なぜそんなことを言うのでしょうか？実際のところ、それらはサーバーの CPU、メモリ、IO、およびその他のサーバー リソースを共有しているからです。 Tomcat1 が大量のサーバー メモリを占有する場合、Tomcat2 の残りのメモリと Tomcat2 のメモリ割り当ては比較的小さくなります。したがって、これら 3 つの Tomcat は独立したプロセスですが、相互に影響を及ぼします。お互いに影響を与えずに真の独立を達成する方法はあるのでしょうか?

実際、ハードウェア仮想化、OS 仮想化、ハードウェア パーティショニングなど、リソースの分離を実現する一般的な方法がいくつかあります。しかし、あらゆる面を考慮すると、OS 仮想化は、コンテナ技術のその後の発展において主流の技術ルートとなっています。

コンテナ テクノロジが解決する中心的な問題は、ソフトウェア実行時に環境の分離を実現することです。コンテナを通じて、差別化されていない標準のサービス運用環境を構築することで、環境、構成、依存関係などの理由により、あるサーバーでは正常に動作しても別のサーバーでは動作しないといった厄介な問題は発生しなくなります。 2008 年、Cgroups のリソース管理機能と Namespace のビュー分離機能を組み合わせることで、Linux Container が Linux メインラインに統合されました。 Linux コンテナは、軽量の仮想化機能を提供し、プロセスとリソースを分離できる、Linux システムによって提供されるコンテナ テクノロジです。この OS レベルの仮想化技術により、コンテナの核心的な問題、つまりサービス実行時に分離をどのように実現するかが実際に解決されます。したがって、Linux コンテナは、その後の Docker テクノロジの実装の基盤であると言えます。

2013年にDockerが正式にリリースされました。 Docker は Linux コンテナ テクノロジーに基づいて開発されており、そのスローガンは「あらゆるアプリをどこでも構築、出荷、実行する」です。 Docker は、ソフトウェアのパッケージ化、ソフトウェアの配布、ソフトウェアの操作のための新しいメカニズムを革新的に構築します。コンテナ イメージを通じて、アプリケーション サービス自体だけでなく、サービスを実行するために必要な環境、構成、リソース ファイル、依存ライブラリも、ソフトウェア イメージ パッケージの一意のバージョンにパッケージ化されます。将来、どこで実行されるサービスもすべてこのソフトウェア イメージ パッケージに基づいて構築および実行されるため、ソフトウェアを効率的にリリースする方法とソフトウェアを効率的に実行する方法という 2 つの中核的な問題が真に解決されます。 Docker を紹介する特別記事は後ほど掲載予定です。

以下のような仮想マシンとコンテナの比較表を皆さんも見たことがあると思います。左側の部分は仮想マシンの一般原理です。実際、サーバー ハードウェア リソースの仮想化はハイパーバイザーを通じて実現され、サーバーおよびゲスト OS 内の CPU、メモリ、ハード ディスクなどの完全なコンピューター ハードウェア インフラストラクチャをシミュレートします。簡単に言えば、サーバー内に新しい仮想サーバーが生成されます。ユーザーのアプリケーション サービス プロセスはすべて、これらの仮想化されたコンピュータ リソース上で実行されます。同じサーバーで複数のオペレーティング システムを同時に実行でき、各オペレーティング システムは互いに分離されています。セキュリティ分離は非常に完全ですが、ハードウェア仮想化には追加のパフォーマンス オーバーヘッドが必要になるため、非常に重いリソース分離テクノロジであることがわかります。

コンテナ技術の原則

先ほど、コンテナ技術の発展について簡単に紹介しました。コンテナの中核は、アプリケーション サービス リソースの分離を実現することであることは誰もが知っています。では、コンテナはどのようにしてリソースの分離を実現するのでしょうか?実際、これは Namespace と Cgroups という Linux カーネルの基盤となるテクノロジーに依存しています。

名前空間

まず、Wiki の Linux Namespace の説明を見てみましょう。

名前空間は、あるプロセス セットが 1 つのリソース セットを認識し、別のプロセス セットが別のリソース セットを認識するようにカーネル リソースを分割する Linux カーネルの機能です。この機能は、一連のリソースとプロセスに同じ名前空間を持つことで機能しますが、それらの名前空間は個別のリソースを参照します。

この説明はわかりにくいかもしれませんが、要約すると、Linux 名前空間は、リソースの分離のために Linux カーネルによって提供される低レベルの機能です。名前空間は、グローバル サーバー リソースをカプセル化して分離するために使用され、異なる名前空間内のプロセスを独立させ、相互に透過的にします。

次の図に示すように、ホスト サーバーでは、Linux 名前空間は実際には Linux カーネル内のリソース分離の実装方法です。 Docker を扱ったことがある学生なら、Docker イメージを実行すると、サーバー上に Docker コンテナが生成されることを知っています。コンテナに入り、ps コマンドを使用して表示すると、コンテナ内でサービス pid=1 が実行されていることに驚くでしょう。これは、このサービスがコンテナ内の最初のプロセスであることを意味します。このサービスをサーバー上で実行すると、オペレーティング システムは、サービス プロセスにグローバルに一意のプロセス番号 (34134 と仮定) を割り当てます。同じプログラムは、サーバーでは pid 34134 で実行されますが、Docker コンテナーでは pid 1 で実行されます。何が起こっているのか？

この分離技術は、ネームスペース メカニズムであり、ネームスペースを通じて新しいオペレーティング環境を構築します。この新しいオペレーティング環境は他のオペレーティング環境に対して透過的であり、この小さなスペースでサービスが主導権を握ることを可能にします。実際、これは Linux カーネルによって提供されるシステム コール関数 clone() です。クローン機能によって作成された新しいプロセスは、まったく新しいプロセス スペースに存在します。したがって、コンテナの本質は実際にはプロセスですが、それは特別なプロセスです。作成時に、コンテナーが現在の名前空間内のファイル、IO、およびその他のリソースにのみアクセスできるように、いくつかのパラメーターが指定されます。

 int pid = clone ( main_function 、 stack_size 、 SIGCHLD 、 NULL );

PID に加えて、Namespace は他のさまざまなリソース レベルの分離も実装します。

 名前マクロ定義はコンテンツを分離します
IPC CLONE_NEWIPC System V IPC 、 POSIX メッセージキュー( Linux 2.6.19 以降)
 ネットワークCLONE_NEWNET ネットワークデバイス、 スタック、 ポートなど( Linux 2.6.24 以降)
 CLONE_NEWNS マウントポイントをマウントする( Linux 2.4.19 以降)
 PID CLONE_NEWPID プロセスID ( Linux 2.6.24 以降)
 ユーザーCLONE_NEWUSER ユーザーおよびグループID ( Linux 2.6.23 で開始され、 Linux 3.8 で完了)
 UTS CLONE_NEWUTS ホスト名とNIS ドメイン名( Linux 2.6.19 以降)

Cグループ

名前空間メカニズムはリソースの分離の問題を解決するのに役立ちますが、コンテナの操作には分離だけで十分なのでしょうか?アプリケーション サービスはコンテナー内ではキングであり、すべてのリソースが排他的ですが、サーバー カーネル内の実際のプロセスにマッピングされた後は、単なる普通のブロンズとなり、他のブロンズとさまざまなコンピューター リソースを共有する必要があります。明らかに、これはコンテナに必要な効果ではありません。 Linux Cgroups テクノロジーは、リソース制限を設定するのに役立つ機能です。 Linux Cgroups (Linux コントロール グループ) は、CPU、メモリ、ディスク、ネットワーク帯域幅など、プロセス グループが使用できるリソースの上限を制限します。

Linux オペレーティング システムでは、Cgroup の機能はカーネルのファイル システム操作インターフェイスを通じて公開され、オペレーティング システムの /sys/fs/cgroup パスの下のファイルとディレクトリの形式で編成されます。 Linux サーバーで mount -t cgroup と入力すると、次のディレクトリ ファイル構造が表示されます。

上の図から、/sys/fs/cgroup ディレクトリの下に、cpucet、cpu、memory など、リソースに関連するサブディレクトリまたはサブシステムが多数あることがわかります。これらのディレクトリは、現在のサーバー上の Cgroup によって制限できるリソース カテゴリです。サブシステムに対応するリソース タイプの下に、このタイプのリソースを制限できる具体的な方法が表示されます。メモリの下の設定ファイルは、ls /sys/fs/cgroup/memory で確認できます。

Docker のソースコードをもう一度見てみましょう。

 // New は新しい containerd サーバーを作成して初期化します
func New ( ctx context . Context , config * Config ) ( * Server , error ) {
 //...
 エラーの場合: = apply ( ctx , config ); エラー!= ゼロ{
 nilまたはerr を返す
 }
 //...
 }
 // サーバープロセスに構成設定を適用します
func apply ( ctx context . Context , config * Config ) エラー{
 設定の場合。 OOMScore != 0 {
 ログ。 G ( ctx ) 。 Debugf ( "OOM スコアを %d に変更しています" 、 config . OOMScore )
 err : = sys の場合。 SetOOMScore ( os.Getpid () , config.OOMScore ); エラー!= ゼロ{
 ログ。 G ( ctx ) 。 エラーが発生した場合( err )。 エラー( 「OOM スコアを %d に変更できませんでした」 、 config . OOMScore )
 }
 }
 設定の場合。 Cグループ。 パス!= "" {
 cg 、 エラー: = cgroups 。 ロード( cgroups . V1 、 cgroups . StaticPath ( config . Cgroup . Path ))
 err != nil の場合{
 err != cgroups の場合。 ErrCグループが削除されました{
 エラーを返す
 }
 cg の場合、 err = cgroups になります。 新規( cgroups.V1 、 cgroups.StaticPath ( config.Cgroup.Path ) 、 およびspecs.LinuxResources { } ) ; エラー!= ゼロ{
 エラーを返す
 }
 }
 err : = cg の場合。 追加( cgroups . Process {
 Pid : os 。 ゲットピッド（）、
 }); エラー!= ゼロ{
 エラーを返す
 }
 }
 ゼロを返す
}

コードから、Docker コンテナを作成するときに、apply 関数が呼び出され、cgourp がロードされ、作成されたコンテナ ID が cg.Add を通じてコン​​トロール グループのタスク ファイルに追加されることがわかります。

要約する

この記事では、コンテナ技術の発展について簡単に説明します。昔のサービスの展開と適用における欠点から始めて、コンテナ技術の出現によってどのような問題が解決されたかを説明します。同時に、コンテナ技術の本質と原則も共有します。この記事を通じて、コンテナ技術の基礎を理解できたと思います。後ほど、クラウド ネイティブ技術のシステムについて引き続きご紹介したいと思います。