コンテナの歴史を振り返る ~1970から現在まで~ #AquaSecurity #Kubernetes #Container #Security

本ブログは「Aqua Security」社の技術ブログで2020年1月10日に公開された「 A Brief History of Containers: From the 1970s Till Now 」の日本語翻訳です。

コンテナの歴史を振り返る ~1970から現在まで~

---

2017年に弊社がブログ投稿をしはじめた頃と比較し、現在のコンテナ技術の状況は大きく異なります。過去2年間でコンテナの採用方法に影響を及ぼすような重要な変化がありました。私たちが新しい10年を迎えるにあたり、私たちが見た変化と発展を要約することで2020年にコンテナがどこへ向かうのかについての見解をお話したいと思います。

1979：UNIX V7
私が当時10歳未満の頃の出来事です。1979年の UNIX V7 の開発中に chroot システムコールが導入されました。chroot により、親プロセスとその子プロセスのルートディレクトリがファイルシステム内の他の場所へ変更されます。この進歩がプロセス分離の始まりとなり、各プロセスのファイルアクセスを分離しました。chroot は1982年に BSD へ追加されました。

2000: FreeBSD Jails
約20年後に話を進めます。小規模な共有環境ホスティングプロバイダが、セキュリティと管理の簡便さのために、サービスと顧客のサービスを明確に分離する FreeBSD Jails を思いついたころです。 FreeBSD Jails を使用すると、管理者は FreeBSD コンピュータシステムを「jails」と呼ばれる独立した複数の小さなシステムに分割することができ、各システムと設定に IP アドレスを割り当てることができます。

2001: Linux VServer
FreeBSD Jails と同様に Linux VServer はコンピューターシステム上のリソース(ファイルシステム・ネットワークアドレス・メモリ)を分割できる jail メカニズムです。 2001年に導入されたこの OS の仮想化は、Linux カーネルにパッチを適用することで実装されます。実験パッチはまだ利用可能ですが、最後の安定版パッチは2006年にリリースされました。

2004: Solaris Containers
2004年 Solaris Containers の最初のパブリックベータ版がリリースされました。これはシステムリソース制御とゾーンによって提供される境界分離を組み合わせたもので、スナップショットや ZFS からのクローン作成などの機能を活用できました。

2005: Open VZ (Open Virtuzzo)
これは仮想化・分離・リソース管理・チェックポイント設定にパッチを適用した Linux カーネルを使用する、Linux 用の OS レベルの仮想化テクノロジーです。

2006: Process Containers
process containers (2006年に Google が開始)はプロセスのコレクションのリソース使用量(CPU・メモリ・ディスクI/O・ネットワーク)を制限・アカウンティング・分離するために設計されました。 1年後「Control Groups (cgroups)」と名前が変更され、最終的に Linux カーネル2.6.24へ統合されました。

2008: LXC
LXC (LinuX Containers)は 最初のLinux コンテナマネージャーで最も完全な実装でした。2008年に cgroup と Linux ネームスペースを使用して実装され、パッチを必要とせずに単一の Linux カーネルで動作します。

2011: Warden
CloudFoundry は2011年に Warden を開始し、初期段階で LXC を使用していましたが、後に独自の実装に置き換えました。Warden は任意の OS 上で、環境の分離・プロセスのデーモン化・コンテナ管理用 API の3つを提供できます。複数のホストにまたがるコンテナのコレクションを管理するクライアント/サーバモデルを開発し、Warden には cgroup・ネームスペース・プロセスライフサイクルを管理するサービスが含まれています。

2013: LMCTFY
Linux アプリケーションコンテナを提供する Google のコンテナスタックのオープンソースバージョンとして2013年にキックオフしました(LMCTFY)。アプリケーションを「コンテナ対応」にして、独自のサブコンテナを作成および管理できます。Google が libcontainer に LMCTFY のコアコンセプトを提供し始めた後、2015年に LMCTFY のアクティブな展開は停止しました。libcontainer は現在 Open Container Foundation の一部です。

2013: Docker
Docker が2013年に登場したとき、コンテナの人気が爆発的に高まりました。Docker とコンテナの使用の増加が密接に関連しているのは偶然ではありません。

Warden が行ったように Docker も初期段階で LXC を使用し、後にそのコンテナマネージャーを独自のライブラリ libcontainer に置き換えました。しかしコンテナ管理のためのエコシステム全体を提供することで、Docker が頭ひとつ抜け出たことは間違いありません。

2016: コンテナセキュリティの重要性が高まる
コンテナベースのアプリケーションが広く採用されると、システムはより複雑になり、リスクが増加しました。同時にコンテナセキュリティの必要性が生まれてきました。duty C​​OW のような脆弱性はこの考え方を促進させました。これによりソフトウェア開発ライフサイクルに沿ってセキュリティのシフトレフトを実現すること、コンテナアプリ開発(DevSecOps とも呼ばれる)の各段階の重要な部分になりました。目標は市場投入までの時間に影響することなく、安全なコンテナを一から構築することです。

2017: コンテナの成熟
コンテナ管理を容易にするため、何百ものツールが開発されました。これらのタイプのツールは何年も使用されてきましたが、2017年は多くのツールが昇格を得た年です。Kubernetes が良い例です。2016年、 Cloud Native Computing Foundation (CNCF)に採用されて以来、VMWare・Azure・AWS といった各々の基盤環境に加え、Docker をもサポートすることを発表しています。

市場はまだ成長していますが、いくつかのツールがコンテナコミュニティの特定の機能を定義するようになりました。Ceph と REX-Ray はコンテナストレージの標準を設定し、Flannel はデータセンター全体で数百万のコンテナを接続します。また CI/CD では、Jenkins がアプリの構築と展開の方法・考え方を変えました。

CNCF による rkt およびContainerdの採用
コンテナエコシステムはコミュニティ全体の努力とオープンソースプロジェクトへの取り組みによって支えられており、ある意味独特です。2017年に Docker が Containerd プロジェクトを CNCF へ寄贈したことはこのコンセプトの象徴であり、ほぼ同時期に CNCF が rkt (「ロケット」と発音)コンテナランタイムを採用したことにも表れています。これによりプロジェクト間のコラボレーションが強化され、ユーザの選択肢が増え、コンテナエコシステムの改善を中心としたコミュニティが生まれました。

Kubernetes の成長
2017年オープンソースプロジェクトは、より成熟したテクノロジーになるための大きな前進を示しました。Kubernetes はますます複雑化するアプリケーションクラスをサポートし、ハイブリッドクラウドとマイクロサービスの両方へのエンタープライズ移行を可能にします。コペンハーゲンの DockerCon で Docker は Kubernetes コンテナオーケストレーターをサポートすると発表しました。Azure と AWS は AKS(Azure Kubernetes Service)と、独自の ECS に匹敵する Kubernetes サービスである EKS と並んでいます。また CNCF が採用した最初のプロジェクトであり、サードパーティのシステム統合サービスプロバイダーのリストを拡大しています。

2018: 標準化
2018年にはコンテナ化が最新のソフトウェアインフラストラクチャの基盤となり、ほとんどのエンタープライズコンテナプロジェクトで Kubernetes が使用されています。 2018年 GitHub の Kubernetes プロジェクトには1500人以上のコントリビューターがおり、最も重要なオープンソースコミュニティの1つであり、27000以上のスターがつけられています。Kubernetes の大規模な採用で、クラウドベンダーがマネージド Kubernetes サービスを提供するようになりました。AWS・GoogleとGKE(Google Kubernetes Engine)・Azure・Oracle と Kubernetes の Container Engine などがその例です。さらに VMware・Red Hat・Rancher などの主要なソフトウェアベンダーが Kubernetes ベースの管理プラットフォームの提供を開始しました。

インフラストラクチャプロバイダの VMware は2018年後半に、Kubernetes の導入と管理を支援するコンサルタント会社 Heptio の買収を発表しました。この買収により、 VMware は Kubernetes の採用へ移行しました。

また VM のような分離とコンテナの速度を組み合わせた、新しいハイブリッドテクノロジーが出現しました。Kata containers・gVisor・Nabla などのオープンソースプロジェクトは、軽量の仮想マシン上で「コンテナと同じ方法で」実行されるセキュアなコンテナランタイムを提供します。ただしこれらのプロジェクトは、ワークロードの分離を強化します。

2019: 変化する風景
この年はコンテナ業界に大きな変化をもたらしました。新しいランタイムエンジンは、既存ランタイムエンジンの置き換えを検討しました。これはオープンソースコンテナーランタイムエンジンである containerd・Kubernetes の軽量ランタイムエンジンである CRI-O が対象としています。

2019年には Docker Enterprise が買収されたことによりコンテナランドスケープで構造変化が発生し、その結果、Docker Swarmが残り2年間でサポート終了ということになりました。同時に rkt コンテナエンジンの人気が低下するのを目撃しましたが、正式にはまだ CNCF 安定版の一部です。

VMware は最初に Heptio を買収し次に Pivotal Software(PAS と PKS の両方)を買収することで、Kubernetes へのコミットメントを倍にしました。この移行は企業がオンプレ運用環境を、クラウドネイティブ環境で利用しているかのような機能を利用可能にすることを目的としています。

昨年、 Knative などのプラットフォームを使用したサーバーレステクノロジーの採用にも進展が見られました。Knative は Kubernetes ベースのサーバーレスワークロード管理プラットフォームで、組織のサーバレス化を牽引しました。

2019年には IBM Cloud Paks・Google Anthos・AWS Outposts・Azure Arc などの Kubernetes ベースのハイブリッドクラウドソリューションが発売されました。これらのクラウドプラットフォームは、オンプレミスおよびシングルベンダークラウドクラスタを管理できるようになったため、クラウド環境とオンプレミス環境の間の従来の境界線がなくなります。

これらの新しい機能の出現は Kubernetes の進化における次のステップを表すと考えています。Anthos・Arc・Outposts などの新しいクラウド機能は Kubernetes と同様に、管理層からコンピューティングリソース・ワークロードが分離・抽象化される未来を示しています。

今日の Kubernetes では、マスターノードはワーカーノードと同じ物理クラスターにあります。抽象化によりワークロード管理プレーンは、複数のコンピューティング インフラストラクチャに分散できるノードのワークロードを管理し、ユーザは物理的にどこで実行されるかを意識する必要がありません。

KubeCon San Diego の過去最高の12,000人以上の参加者から判断すると、Kubernetes はコンテナ・仮想マシン・その他のクラウドネイティブワークロードの標準管理プラットフォームになると考えられます。

Kubernetes Security eBook を今すぐダウンロードし、Aqua ブログを忘れずに購読してください。