Linuxコンテナは以前から存在していましたが、2008年にLinuxカーネルに導入されたときに広く利用できるようになりました。コンテナは、アプリのソースコードとOSライブラリ、および任意の環境でコードを実行するために必要な依存関係を組み合わせた、軽量で実行可能なアプリケーションコンポーネントです。さらに、イメージベースの展開方法の柔軟性を備えたアプリケーションの分離を利用しながら、アプリケーションのパッケージ化と配信のテクノロジーを提供します。
Linuxコンテナーは、リソース管理用の制御グループ、システムプロセス分離用の名前空間、安全なテナンシーを有効にし、セキュリティの脅威や悪用を減らすためのSELinuxセキュリティを使用します。これらのテクノロジーは、コンテナーを作成、実行、管理、およびオーケストレーションするための環境を提供します。
この記事は、Linuxコンテナーアーキテクチャーの主な要素、コンテナーとKVM仮想化、イメージベースのコンテナー、Dockerコンテナー、コンテナーオーケストレーションツールとの比較に関する入門ガイドです。
コンテナアーキテクチャ
Linuxコンテナーは、cgroups、SELinux、名前空間などの主要なLinuxカーネル要素を利用します。名前空間はシステムプロセスの分離を保証し、cgroups（コントロールグループ）は、その名前が示すように、Linuxシステムリソースを制御するために使用されます。 SELinuxは、ホストとコンテナー間、および個々のコンテナー間の分離を保証するために使用されます。 SELinuxを使用して、安全なマルチテナンシーを有効にし、セキュリティの脅威やエクスプロイトの可能性を減らすことができます。カーネルの後には、他のコンポーネントと対話してコンテナーを開発、管理、およびオーケストレーションする管理インターフェースがあります。
SELinux
セキュリティは、Linuxシステムまたはアーキテクチャの重要なコンポーネントです。 SELinuxは、安全なコンテナー環境の最前線の防御となるはずです。 SELinuxは、システム管理者がコンテナのアーキテクチャへのアクセスをより細かく制御できるようにするLinuxシステムのセキュリティアーキテクチャです。ホストシステムコンテナと他のコンテナを互いに分離できます。
信頼性の高いコンテナ環境では、カスタマイズされたセキュリティポリシーを作成するためにシステム管理者が必要です。 Linuxシステムは、SELinuxコンテナーポリシーを生成するためのpodmanやudicaなどのさまざまなツールを提供します。一部のコンテナポリシーは、コンテナがストレージドライブ、デバイス、ネットワークツールなどのホストリソースにアクセスする方法を制御します。このようなポリシーは、セキュリティの脅威に対してコンテナ環境を強化し、規制コンプライアンスを維持する環境を作成します。
このアーキテクチャは、コンテナ内のルートプロセスがコンテナ外で実行されている他のサービスに干渉するのを防ぐ安全な分離を作成します。たとえば、システムはDockerコンテナにSELinuxポリシーで指定されたSELinuxコンテキストを自動的に割り当てます。その結果、SELinuxは、ホストオペレーティングシステムまたはシステムで強制モードで実行されている場合でも、常にコンテナー内で無効になっているように見えます。
注：ホストマシンでSELinuxを無効または許可モードで実行しても、コンテナーは安全に分離されません。 。
名前空間
カーネル名前空間は、Linuxコンテナーのプロセス分離を提供します。これらは、システムリソースの抽象化を作成し、それぞれが名前空間内のプロセスに対して個別のインスタンスとして表示されるようにします。本質的に、コンテナは競合を発生させることなくシステムリソースを同時に使用できます。名前空間には、ネットワーク、マウント、UTS名前空間、IPC名前空間、PID名前空間が含まれます。
- マウント名前空間は、プロセスのグループで使用可能なファイルシステムマウントポイントを分離します。別のマウント名前空間にある他のサービスは、ファイルシステム階層の代替ビューを持つことができます。たとえば、環境内の各コンテナは独自の/varディレクトリを持つことができます。
- UTS名前空間：ノード名とドメインネームシステム識別子を分離します。これにより、各コンテナに一意のホスト名とNISドメイン名を付けることができます。
- ネットワーク名前空間は、ネットワークコントローラー、ファイアウォール、およびルーティングIPテーブルの分離を作成します。基本的に、仮想デバイスまたは物理デバイスで個別の仮想ネットワークスタックを使用し、それらに一意のIPアドレスまたはiptableルールを割り当てるようにコンテナ環境を設計できます。
- PID名前空間を使用すると、異なるコンテナ内のシステムプロセスが同じPIDを使用できます。本質的に、各コンテナは、コンテナのライフサイクルを管理したり、システムタスクを初期化したりするための一意の初期化プロセスを持つことができます。各コンテナには、コンテナ内で実行されているプロセスを監視するための独自の/procディレクトリがあります。コンテナはそのプロセス/サービスのみを認識し、Linuxシステムのさまざまな部分で実行されている他のプロセスを認識できないことに注意してください。ただし、ホストオペレーティングシステムは、コンテナ内で実行されているプロセスを認識しています。
- IPC名前空間–システムプロセス間通信リソース（System V、IPCオブジェクト、POSIXメッセージキュー）を分離して、異なるコンテナーが同じ名前の共有メモリセグメントを作成できるようにします。ただし、他のコンテナのメモリセグメントや共有メモリとやり取りすることはできません。
- ユーザー名前空間–システム管理者がコンテナ専用のホストUIDを指定できるようにします。たとえば、システムプロセスはコンテナ内でルート権限を持つことができますが、同様にコンテナ外での操作には権限がありません。
コントロールグループ
カーネルcgroupは、プロセスの異なるグループ間のシステムリソース管理を可能にします。 Cgroupは、CPU時間、ネットワーク帯域幅、またはシステムメモリをユーザー定義のタスクに割り当てます。
コンテナVSKVM仮想化
コンテナーとKVM仮想化テクノロジーの両方に、ユースケースまたは環境をデプロイするためのガイドとなる長所と短所があります。まず、KVM仮想マシンには独自のカーネルが必要ですが、コンテナーはホストカーネルを共有します。したがって、コンテナの主な利点の1つは、同じハードウェアリソースを使用する仮想マシンよりも多くのコンテナを起動することです。
Linuxコンテナ
| ログ、適切な読み取りおよび書き込み権限を持つ永続データを管理するには、広範なシステム管理スキルが必要です。 |
アプリケーションの分野：
- 大規模な拡張が必要なアプリケーションアーキテクチャ。
- マイクロサービスアーキテクチャ。
- ローカルアプリケーション開発。
KVM仮想化
| KVMは、Linux、Unix、macOS、Windowsなどのオペレーティングシステムのフルブートを可能にします。 |
| 仮想マシン、管理、およびアプリケーション開発に関連する運用コストの上昇 |
適用分野：
- 明確な専用リソースを必要とするシステム環境。
- 独立して実行されているカーネルを必要とするシステム。
画像ベースのコンテナ
イメージベースのコンテナーは、アプリケーションを個別のランタイムスタックでパッケージ化し、プロビジョニングされたコンテナーをホストオペレーティングシステムから独立させます。基本的に、アプリケーションの複数のインスタンスを、それぞれ異なるプラットフォームで実行できます。このようなアーキテクチャを可能にするには、コンテナとアプリケーションのランタイムをイメージとしてデプロイして実行する必要があります。
イメージベースのコンテナで構成されるシステムアーキテクチャにより、最小限のオーバーヘッドと柔軟性でアプリケーションの複数のインスタンスをホストできます。これにより、ホスト固有の構成に依存しないコンテナーの移植性が可能になります。画像はコンテナなしで存在できます。ただし、コンテナが存在するには、イメージを実行する必要があります。本質的に、コンテナは、アプリケーションを実行するためのランタイム環境を作成するためにイメージに依存しています。
コンテナ
コンテナーは、アプリケーションとして実行されるアクティブなコンポーネントを作成するために必要な構成データを保持するイメージに基づいて作成されます。コンテナを起動すると、指定したイメージの上に書き込み可能なレイヤーが作成され、構成の変更が保存されます。
画像
イメージは、特定の時点でのコンテナの構成データの静的スナップショットです。これは読み取り専用レイヤーであり、最上位の書き込み可能レイヤーですべての構成変更を定義できます。新しい画像を作成するだけで保存できます。各画像は1つ以上の親画像に依存します。
プラットフォーム画像
プラットフォームイメージには親がありません。代わりに、これを使用して、コンテナ化されたアプリケーションを起動および実行するために必要なランタイム環境、パッケージ、およびユーティリティを定義できます。たとえば、Dockerコンテナーを操作するには、読み取り専用のプラットフォームイメージをプルします。定義された変更は、最初のDockerイメージの上にスタックされたコピーされたイメージに反映されます。次に、コンテナ化されたアプリケーションに追加されたライブラリと依存関係を含むアプリケーション層を作成します。
コンテナーは、アプリケーション層に含まれるパッケージと依存関係の数に応じて、非常に大きくなることも小さくなることもあります。さらに、独立したサードパーティのソフトウェアと依存関係を使用して、画像をさらに階層化することができます。したがって、運用の観点からは、画像の背後に多くのレイヤーが存在する可能性があります。ただし、レイヤーはユーザーには1つのコンテナーとしてのみ表示されます。
Dockerコンテナ
Dockerは、アプリケーションとサービスを開発、保守、デプロイ、およびオーケストレーションするためのコンテナー化された仮想環境です。 Dockerコンテナーは、仮想環境の構成またはセットアップのオーバーヘッドを削減します。コンテナには個別のカーネルがなく、ホストオペレーティングシステムから直接実行されます。名前空間とコントロールグループを利用して、ホストOSリソースを効率的に使用します。
コンテナのインスタンスは、他のアプリケーションに影響を与えることなく、1つのプロセスを分離して実行します。本質的に、コンテナ化された各アプリには固有の構成ファイルがあります。
Dockerデーモンを使用すると、コンテナーはpingを実行し、実行する必要のある量に応じて、コンテナー化されたアプリにリソースを割り当てることができます。 Linuxコンテナー（LXC）とは対照的に、Dockerコンテナーは単一のコンテナー化されたアプリケーションのデプロイに特化しています。 Linuxでネイティブに実行されますが、macOSやWindowsなどの他のオペレーティングシステムもサポートします。
Dockerコンテナの主なメリット
- 移植性：– Docker Engineが実行されている他のシステムにコンテナー化されたアプリをデプロイでき、アプリケーションは開発環境でテストしたときとまったく同じように実行されます。開発者は、チームが使用しているオペレーティングシステムに関係なく、追加のパッケージやソフトウェアをインストールしなくても、Dockerアプリを自信を持って共有できます。 Dockerはバージョニングと連携しており、コードを壊すことなくコンテナ化されたアプリケーションを簡単に共有できます。
- コンテナは、Windows、VM、macOS、Linux、オンプレミス、パブリッククラウドなど、サポートされている任意のOSでどこでも実行できます。 Dockerイメージの普及により、Amazon Web Services（AWS）、Google Compute Platform（GCP）、MicrosoftAzureなどのクラウドプロバイダーが広く採用されるようになりました。
- パフォーマンス：–コンテナには、仮想マシンよりもはるかに小さいフットプリントを作成するオペレーティングシステムが含まれておらず、通常、作成と起動が高速です。
- 敏捷性：–コンテナのパフォーマンスと移植性により、チームは継続的インテグレーションと継続的デリバリー（CI / CD）戦略を改善して、適切なソフトウェアを適切なタイミングで提供するアジャイル開発プロセスを作成できます。
- 分離：–アプリケーションを含むDockerコンテナーには、アプリケーションに必要な依存関係とソフトウェアの関連バージョンも含まれています。 Dockerコンテナーは互いに独立しており、指定されたソフトウェア依存関係の異なるバージョンを必要とする他のコンテナー/アプリケーションは、問題なく同じアーキテクチャーに存在できます。たとえば、Docker MariaDBのようなアプリケーションが、一貫したシステムパフォーマンスを維持するためにそのリソースのみを使用することを保証します。
- スケーラビリティ：– Dockerを使用すると、オンデマンドで新しいコンテナーとアプリケーションを作成できます。
- コラボレーション：– Dockerでのコンテナー化のプロセスにより、アプリケーション開発プロセスをセグメント化できます。これにより、開発者は、費用効果が高く時間の節約になる開発プロセスを作成するために大規模なオーバーホールを行うことなく、潜在的な問題をすばやく共有、コラボレーション、および解決できます。
コンテナオーケストレーション
コンテナオーケストレーションは、コンテナ化されたサービスとワークロードの展開、プロビジョニング、管理、スケーリング、セキュリティ、ライフサイクル、負荷分散、およびネットワーキングを自動化するプロセスです。オーケストレーションの主な利点は自動化です。オーケストレーションは、チームが反復サイクルで開発およびデプロイし、新機能をより迅速にリリースできるようにするDevOpsまたはアジャイル開発プロセスをサポートします。人気のあるオーケストレーションツールには、Kubernetes、Amazon ECR Docker Swarm、ApacheMesosなどがあります。
コンテナーオーケストレーションには、基本的に、開発者が構成状態を定義する（YAMLまたはJSON）構成ファイルを作成する3ステップのプロセスが含まれます。次に、オーケストレーションツールがファイルを実行して、目的のシステム状態を実現します。 YAMLまたはJSONファイルは通常、次のコンポーネントを定義します。
- アプリケーションとイメージレジストリを構成するコンテナイメージ。
- ストレージなどのリソースを含むコンテナをプロビジョニングします。
- 第3に、コンテナ間のネットワーク構成を定義します。
- 画像のバージョン管理を指定します。
オーケストレーションツールは、使用可能なCPU容量、メモリ、または構成ファイルで指定されたその他の制約に基づいて、コンテナーまたはコンテナーレプリカのホストへの展開をスケジュールします。コンテナーをデプロイすると、オーケストレーションツールは、コンテナー定義ファイル（Dockerfile）に基づいてアプリのライフサイクルを管理します。たとえば、Dockerfileを使用して次の側面を管理できます。
- スケーラビリティ、リソース割り当て、負荷分散を上下に管理します。
- システムリソースの停止または不足が発生した場合に、コンテナの可用性とパフォーマンスを維持します。
- ログデータを収集して保存し、コンテナ化されたアプリケーションの状態とパフォーマンスを監視します。
Kubernetes
Kubernetesは、クラウドネイティブアプリケーションのアーキテクチャと操作を定義するために使用される最も人気のあるコンテナオーケストレーションプラットフォームの1つであり、開発者は製品開発、コーディング、イノベーションに集中できます。 Kubernetesを使用すると、複数のコンテナーにまたがるアプリケーションを構築し、クラスター全体でそれらをスケジュールし、スケーリングし、時間の経過とともにそれらのヘルスとパフォーマンスを管理できます。本質的に、コンテナ化されたアプリケーションのデプロイとスケーリングに伴う手動プロセスを排除します。
Kubernetesの主要コンポーネント
- クラスター：1つ以上のコンピューティングマシン/ノードを備えたコントロールプレーン。
- コントロールプレーン：さまざまなノードを制御するプロセスのコレクション。
- Kubelet：ノード上で実行され、コンテナーを効果的に開始および実行できるようにします。
- ポッド：単一ノードにデプロイされたコンテナーのグループ。ポッド内のすべてのコンテナは、IPアドレス、ホスト名、IPC、およびその他のリソースを共有します。
Kubernetesは、コンテナオーケストレーションの業界標準になりました。広範なコンテナ機能を提供し、動的な貢献者コミュニティを特徴とし、高度に拡張可能で移植性があります。オンプレミス、パブリック、クラウドなどのさまざまな環境で実行し、他のコンテナテクノロジーで効果的に使用できます。
まとめ
コンテナは、ソースコード、OSライブラリ、および任意の環境でコードを実行するために必要な依存関係で構成される、軽量で実行可能なアプリケーションコンポーネントです。 Dockerプラットフォームが作成されたとき、コンテナーは2013年に広く利用可能になりました。その結果、Linuxコミュニティでは、Dockerコンテナとコンテナを同じものを参照するために同じ意味で使用しているユーザーを見つけることがよくあります。
Dockerコンテナーを使用することにはいくつかの利点があります。ただし、すべてのアプリケーションがコンテナでの実行に適しているわけではありません。一般的な経験則として、グラフィカルユーザーインターフェイスを備えたアプリケーションは、Dockerでの使用には適していません。したがって、コンテナ化されたマイクロサービスまたはサーバーレスアーキテクチャは、クラウドネイティブアプリケーションに不可欠です。
この記事では、Linuxのコンテナー、Dockerイメージ、Kubernetesなどのコンテナーオーケストレーションツールの紹介ガイドを提供しています。このガイドは、開発者がコンテナ化されたアプリケーションの開発と共有を学ぶことができるコンテナ、Dockerエンジン、Kubernetesの操作に基づいて構築されます。