コンテナの簡単な歴史: 1979年から現在まで

クラウド コンピューティングの発展に伴い、コンテナはますます広く使用されるようになり、特に過去 2 年間で、ますます多くの企業や組織が新しい IT インフラストラクチャとしてコンテナを採用し始めています。歴史を振り返ると、コンテナが実際に形になったのは 1970 年代後半でした。 jail、ゾーン、VPS、VM、コンテナはすべて分離とリソース制御を目的としていますが、各テクノロジはそれぞれ異なる方法でそれを実現し、それぞれに制限と利点があります。

1979: Unix V7

コンピューティング リソースが不足していた当時、インフラストラクチャをすぐに破壊して再構築することでテスト環境の汚染の問題を解決することはほぼ不可能でした。ソフトウェアの構築とテストのための環境を分離するために、chroot (change root) システム コール プログラムが登場しました。

1979 年の Unix V7 の開発中に、各プロセスに独立したディスク領域を提供し、プロセスとそのサブプロセスのルート ディレクトリをファイル システム内の新しい場所に変更して、これらのプロセスがそのディレクトリにのみアクセスできるようにする chroot システム コールが正式に導入されました。この新しい隔離された環境は Chroot Jail と呼ばれます。これはプロセス分離の始まりを示し、各プロセスのファイル アクセス権限を分離します。下の図に示すように、ベル研究所は Unix V7 オペレーティング システムのリリースに向けて最終的な開発とテスト作業を行っています。

[[318045]]

2000: FreeBSD の監獄

2000 年、FreeBSD オペレーティング システムは FreeBSD jail 分離環境を正式にリリースし、プロセスのサンドボックス化を真に実現しました。これにより、ファイル システム、ユーザー、ネットワーク、およびその他の分離にプロセス サンドボックス機能が追加され、顧客サービス間の分離と管理が実装されます。

このサンドボックスの実装は、ハードウェア仮想化テクノロジではなく、オペレーティング システム レベルの分離および制限機能に依存します。 FreeBSD Jails を使用すると、管理者は FreeBSD コンピュータ システムを「jails」と呼ばれる複数の独立した小規模なシステムに分割し、各システムと構成に IP アドレスを割り当て、ソフトウェアのインストールと構成をカスタマイズできます。

2001: Linux VServer

FreeBSD Jails と同様に、Linux VServer は、コンピュータ システム上のリソース (ファイル システム、ネットワーク アドレス、メモリ) をパーティション分割できる、前述の Jails に似たメカニズムです。各パーティションはセキュリティ コンテキストと呼ばれ、その中の仮想システムは仮想プライベート サーバー (VPS) と呼ばれます。オペレーティング システムの仮想化は、2001 年に Linux カーネルにパッチを適用することで導入されました。実験的なパッチはまだ利用可能ですが、最後の安定したパッチは 2006 年にリリースされました。

2004: Solaris コンテナ

2004 年 2 月、Oracle は X86 および SPARC プロセッサ向けの Linux-Vserver バージョンである Oracle Solaris Containers をリリースしました。 Solaris コンテナは、システム リソース制御とゾーンによって提供される境界分離を組み合わせたものです。ゾーンは、単一のオペレーティング システム インスタンス内の完全に分離された仮想サーバーです。

2005: オープン VZ (オープン ヴィルトゥッツォ)

これは、Linux カーネル パッチの形式で仮想化、分離、リソース管理、およびステータス検査を実行する Linux オペレーティング システム レベルの仮想化テクノロジです。 OS レベルの仮想化にはいくつかの制限があります。これは、コンテナーが同じアーキテクチャとカーネル バージョンを共有するためです。これは、クライアントがホストとは異なるカーネル バージョンを必要とする場合に明らかになります。このコードは公式の Linux カーネルの一部としてリリースされていません。各 OpenVZ コンテナには、分離されたファイル システム、ユーザーとグループ、プロセス ツリー、ネットワーク、デバイス、IPC オブジェクトがあります。

2006: プロセスコンテナ

プロセス コンテナ (2006 年に Google が開始) は、一連のプロセスのリソース使用量 (CPU、メモリ、ディスク I/O、ネットワーク) を制限、考慮、分離するように設計されています。 1 年後、Linux カーネルのコンテキストで「コンテナ」という用語との混同を避けるため、ControlGroups に名前が変更され、Cgroups と略され、最終的に Linux カーネル 2.6.24 に統合されました。これは、Google がコンテナ テクノロジーの開発に非常に早い段階から関わってきたことも示しています。

2008: LXC

Linux Containers (LXC) は、Linux コンテナ マネージャーの最初の、そして最も完全な実装です。 2008 年には、Cgroups のリソース管理機能と Linux Namespace のビュー分離機能を組み合わせることで、LXC の完全なコンテナ テクノロジが Linux カーネルに登場し、パッチなしで単一の Linux カーネル上で実行できるようになりました。

LXC は liblxc ライブラリに存在し、Python3、Python2、Lua、Go、Ruby、Haskell などのさまざまなプログラミング言語の API 実装を提供します。 LXC プロジェクトは現在、Canonical によってスポンサーおよびホストされています。

2011年: ウォーデン

Warden は、分離された一時的なリソース制御環境を管理するための API として、2011 年に CloudFoundry によって設立されました。 Warden の最初のバージョンでは LXC を使用していましたが、後に独自の実装に置き換えました。 LXC とは異なり、Warden は Linux に密接に結合されておらず、あらゆるシステムに分離されたオペレーティング環境を提供できます。 Warden はデーモンとして実行され、コンテナ管理用の API を提供します。複数のホストにまたがるコンテナ クラスターを管理するための CS (クライアント サーバー) モデルを開発し、Cgroup、名前空間、およびプロセス ライフサイクルを管理するための関連サービスを提供します。

2013: LMCTFY

LMCTFY は、2013 年に開始された Google のコンテナ テクノロジーのオープン ソース バージョンです。Linux アプリケーション コンテナを提供し、保証されたパフォーマンス、高いリソース使用率、リソース共有、オーバーセリング、ほぼゼロの消費量を備えたコンテナを提供することを目指しています。

LMCTFY は、Docker によって開始された Libcontainer に Google が LMCTFY コア コンセプトの提供を開始した後、2015 年に自主的に展開を停止しました。 Libcontainer は現在、Open Container Foundation の一部です。

2013: ドッカー

2013 年に Docker が登場して以来、コンテナは急速に人気を集め始めました。もともとは dotCloud という PaaS サービス会社の内部プロジェクトでしたが、後に Docker に名前が変更されました。 Docker の成長は偶然ではありません。効率的な階層化コンテナ イメージ モデル、グローバルおよびローカル コンテナ レジストリ、明確な REST API、コマンド ラインなど、コンテナを管理するための完全なエコシステムが導入されました。

Warden と同様に、Docker も初期段階では LXC を使用していましたが、後に独自のライブラリ libcontainer に置き換えました。 Docker は、Docker Swarm と呼ばれるコンテナ クラスター管理ソリューションの実装を推進しています。

2014年: ロケット

Rocket は CoreOS によって開始されたプロジェクトで、Docker と非常に似ていますが、Docker で見つかったいくつかの問題を修正しています。 CoreOS はもともと、Docker よりも厳格なセキュリティと製品要件を提供することを目的としていました。さらに重要なのは、よりオープンな標準の AppContainer 仕様に基づいて実装されていることです。 Rocket に加えて、CoreOS は、CoreOS オペレーティング システム、etcd、flannel など、Docker および Kubernetes で使用できる他のコンテナー関連製品もいくつか開発しています。

2016: Windows コンテナー

2015 年、Microsoft は Windows Server 上の Windows ベースのアプリケーションに対するコンテナー サポートを追加し、これを Windows コンテナーと呼びました。 Windows Server 2016 と同時にリリースされました。Docker では、Docker を実行するための仮想マシンを起動しなくても、Windows 上で Docker コンテナーをネイティブに実行できます (以前は Windows 上で Docker を実行するには、Linux 仮想マシンを使用する必要がありました)。

2017年: コンテナツールが成熟

2017 年以前は、コンテナを管理するためのツールが何百も市場に出回っていました。こうしたタイプのツールは何年も前から存在していましたが、2017 年は多くのツールが目立った年でした。たとえば、Kubernetes が 2016 年に Cloud Native Computing Foundation (CNCF) に組み込まれて以来、VMWare、Azure、AWS、さらには Docker も、自社のインフラストラクチャ上で関連するサポートを発表しています。

コンテナ市場が進化し成長するにつれて、コンテナの特定の機能を定義するツールがいくつか登場し始めました。 Ceph と REX-Ray はコンテナ ストレージの標準を確立し、CI/CD では Jenkins がアプリケーションの構築と展開の方法を完全に変えました。

2017 年、CoreOS と Docker は共同で rkt と containerd を CNCF の新しいプロジェクトとして含めることを提案しました。これは、コンテナ エコシステムの最初の形成と、コンテナ プロジェクト間のより豊富なコラボレーションを示しました。

Docker がコアランタイムをスピンオフするという最初の発表から 2017 年の CNCF への寄付まで、「containerd」プロジェクトは過去 2 年間で大きな成長と進歩を遂げてきました。 Docker の寄付の主な目的は、コンテナ システム ベンダーやオーケストレーション プロジェクト (Kubernetes、Swarm など) が活用できるコア コンテナ ランタイムを提供することで、コンテナ エコシステムのさらなるイノベーションを促進することです。 「containerd」の重要な設計原則は、Kubernetes に対して第一級のサポートを提供できるものの、Kubernetes に完全に依存するわけではないということです。これにより、開発者デスクトップ、CI/CD、単一ノード展開、エッジ、IoT など、多くのコンテナ使用ケースに新たな扉が開かれます。

2018年：ますます標準化

コンテナ化は現代のソフトウェア インフラストラクチャの基礎となり、Kubernetes はほとんどのエンタープライズ コンテナ プロジェクトで使用されています。 2018 年、GitHub の Kubernetes プロジェクトには 1,500 人を超える貢献者がおり、27,000 を超えるスターを持つ最も重要なオープンソース コミュニティの 1 つとなっています。

Kubernetes の普及により、AWS などのクラウド プロバイダーはマネージド Kubernetes サービスを提供するようになりました。さらに、VMWare、RedHat、Rancher などの大手ソフトウェアベンダーも Kubernetes ベースの管理プラットフォームの提供を開始しています。

2019年：歴史的な変化

2019年はコンテナにとって歴史的な変化の年でした。今年は、コンテナ エコシステムの変化、産業資本の合併と買収、新しいテクノロジー ソリューションの出現など、多くの歴史的な出来事がありました。

今年、新しいランタイム エンジンが Docker ランタイム エンジンに取って代わり始めました。最も代表的な新しいエンジンは、CNCF の Containerd と CRI-O (Kubernetes 用の軽量ランタイム) です。 CRI-O を使用すると、ユーザーは不要なコードやツールを使用せずに、Kubernetes から直接コンテナを実行できます。コンテナが OCI 標準に準拠している限り、CRI-O はそれを実行できます。

2019年、業界にも大きな変化が見られました。 Docker Enterprise は、Mirantis (OpenStack と Kubernetes に重点を置くクラウド コンピューティング企業) に売却されました。 Docker Swarm は段階的に廃止されることが予想されます。同時に、rkt は正式に CNCF の一部となったものの、その人気は徐々に低下していることもわかります。さらに、VMware は Heptio と Pivotal Software (PAS と PKS を含む) を相次いで買収しており、これによりエンタープライズ顧客による Kubernetes ベースのコンテナ化アーキテクチャの構築と実行をより強力に支援できるようになります。 Heptio は、2014 年に Google が Kubernetes プロジェクトを共同で立ち上げるのを支援した 2 人によって設立されました (当時はプロジェクト リーダーが 3 人いました)。創設者とそのチームは VMware に一緒に参加します。創業者の経歴がこのように明確であることは、VMware が Kubernetes 分野に本格的に参入する意向があることを意味しているのかもしれません。また、VMware が Kubernetes を企業のビジネス運営の基本的な基盤の 1 つと見なしていることも示しています。

2019年にはコンテナ技術の分野でも新たな変化が起こりました。 Function as a Service (「機能」または「サーバーレス」) は、新しい抽象的なトレンドになっています。これにより、開発者はイベントの需要に応じて迅速に拡張できるコード スニペットをより簡単に実行および展開できるようになります。たとえば、企業は、Google と Pivotal、IBM、Red Hat、SAP などの企業が共同で開発したクロスクラウド サーバーレス管理プラットフォームである Knative を使用している限り、プライベート クラウド、パブリック クラウド、またはさまざまなハイブリッド クラウド アーキテクチャにわたって、Kubernetes をサポートするクラウド プラットフォーム上でワークロードを自由に移行できます。

図2: 可能な限り高い抽象化を使用する

2019 年には、IBM CloudPaks、Google Anthos、AWS Outposts、Azure Arc などの Kubernetes ベースのハイブリッド クラウド ソリューションも登場しました。これらのクラウド プラットフォームは、クラウド環境とオンプレミス環境間の従来の境界を曖昧にし、オンプレミスとベンダーのクラウド サービスの管理を容易にします。

Kubernetes は現在、コンテナ化されたプラットフォーム システムを構築するためのデフォルトの抽象化になっています。これらの新機能の出現は、Anthos、Arc、Outposts などのスーパー抽象化など、Kubernetes の次の進化の方向性も表しています。ハイパー抽象化では、コンピューティング リソースは管理レイヤーから分離されます。これは、ワークロードを管理レイヤーから分離する Kubernetes の動作に似ています。

2020年: コンテナのセキュリティに対処する必要がある

コンテナは軽量な仮想化技術として使いやすく操作も簡単なため、開発者の作業効率が大幅に向上し、業界で広く使用されています。しかし同時に、安全でないイメージソース、コンテナ侵入インシデント、運用環境におけるセキュリティ問題など、コンテナセキュリティインシデントが頻繁に発生しています。

• 安全でない画像ソース。開発者は通常、Docker の公式 Docker Hub リポジトリからイメージをダウンロードします。これらの画像の一部は、画像内の対応するソフトウェアを開発する公式組織から提供されており、大部分の画像はサードパーティの組織や個人から提供されています。これらのイメージリポジトリからイメージを取得すると、潜在的なセキュリティリスクも生じます。たとえば、ダウンロードしたイメージ自体のソフトウェアに脆弱性が含まれているかどうか、ダウンロードしたイメージに悪意を持ってバックドアが埋め込まれているかどうか、送信中にイメージが改ざんされているかどうかなどです。
• コンテナ侵入インシデントは、Docker 自体のアーキテクチャとメカニズムから発生する可能性のある問題です。この攻撃シナリオは主に、ハッカーがすでにホストマシン上の一部のコンテナを制御している場合（またはパブリッククラウド上にコンテナを構築することでこの状態を取得している場合）、ホストマシンまたは他のコンテナに攻撃を仕掛けて影響を与える場合に発生します。
• Docker 自体の問題に加えて、Docker の動作環境の問題も Docker の使用にリスクをもたらします。

コンテナはインフラストラクチャとプラットフォーム間の仮想化テクノロジであるため、インフラストラクチャ仮想化のための従来のクラウド セキュリティ ソリューションでは、前述のセキュリティの問題に完全に対処することはできません。コンテナをサポート技術として使用して DevOps 環境を構築する場合は、コンテナ イメージの作成から本番環境の起動までのライフサイクル全体をカバーするコンテナ セキュリティ ソリューションを設計する必要があります。

現在、Neuvector、Twistlock、StackRox、Aquaなど、数多くのコンテナセキュリティ製品ベンダーが市場に登場しています。独自のコンテナセキュリティ製品を開発している国内企業には、Qingteng Cloud Securityなどがあります。コンテナ セキュリティ製品の技術的ソリューションの観点から見ると、現在のコンテナ セキュリティ ベンダーのほとんどは並列コンテナを使用してホスト マシン上のコンテナを保護していますが、Qingteng Cloud Security はホスト エージェント ベースのアプローチを採用しています。

並列コンテナ テクノロジ ソリューション: コンテナの分離性と優れたリソース制御機能を活用して、コンテナ ホストでコンテナを起動します。コンテナはホストのすべてのファイルシステムをマウントし、コンテナ内でこれらのファイルシステムをリアルタイムで監視および処理してコンテナを保護します。

ホストエージェントに基づく技術ソリューション：つまり、Qingteng Agent のホスト保護機能に基づいて、ホスト上のコンテナに関連するファイル、プロセス、システムコールなどの情報を監視し、コンテナに対するエージェントのインベントリ、監視、保護機能を高め、ホストセキュリティとコンテナセキュリティを 1 つのエージェントを通じて実現します。

上記 2 つのソリューションの概略図は次のとおりです。