コンテナ Linux

コンテナ Linux

開発者	CoreOS チーム、Red Hat
OSファミリー	Linux ( Gentoo Linuxベース)
作業状態	生産中止[1]
ソースモデル	オープンソース
初回リリース	2013年10月3日; 11年前[2] ( 2013-10-03 )
最新リリース	2512.3.0 [3] / 2020年5月22日; 4年前 ( 2020-05-22 )
最新プレビュー	2513.2.0 [4] (ベータ) / 2020年5月22日; 4年前2514.1.0 [5] (アルファ) / 2020年5月22日; 4年前 ( 2020-05-22 )  ( 2020-05-22 )
マーケティングターゲット	サーバーとクラスター
プラットフォーム	x86-64 [6]
カーネルタイプ	モノリシック( Linux カーネル)
ライセンス	Apacheライセンス2.0 [7] [8]
後継者	Fedora CoreOS RHEL CoreOS Flatcar コンテナ Linux
公式サイト	coreos.com [9]

Container Linux（旧CoreOS Linux）は、Linuxカーネルをベースとしたオープンソースの軽量オペレーティングシステムで、クラスター化されたデプロイメントのインフラストラクチャを提供するために設計されています。その焦点の1つはスケーラビリティでした。オペレーティングシステムとして、Container Linuxは、ソフトウェアコンテナ内にアプリケーションを展開するために必要な最小限の機能と、サービス検出と構成共有の組み込みメカニズムのみを提供しました。^{[10] [11] [12] [13] [14]}

Container Linuxは、共通のソフトウェア開発キット（SDK）を通じて、Gentoo Linux、^{[15] [16]} ChromeOS、ChromiumOSと基盤を共有しています。Container Linuxは、この共有基盤に新しい機能とカスタマイズを追加して、サーバーのハードウェアとユースケースをサポートします。 ^{[13] [17] : 7:02} CoreOSは主にAlex Polvi、Brandon Philips、Michael Marineauによって開発され、^[12]主要な機能は安定版として提供されています。^{[18] [19] [20]}

CoreOSチームは2020年5月26日にContainer Linuxのサポート終了を発表し、 ^[1]その代わりとしてRed Hat Enterprise LinuxをベースにしたFedora CoreOS、^[21]およびRHEL CoreOSを提供した。

コンテナ Linux は、ペイロード アプリケーションを配布するためのパッケージ マネージャーを提供していないため、すべてのアプリケーションをコンテナ内で実行する必要があります。単一の制御ホストとして機能するコンテナ Linux インスタンスは、Linux カーネルの基盤となるオペレーティング システム レベルの仮想化機能を使用して、分離されたLinuxシステムとして動作する複数のコンテナを作成および構成します。このように、コンテナ間のリソースの分割は、ハイパーバイザーを使用して本格的な仮想マシンを提供するのではなく、複数の分離されたユーザー空間インスタンスを通じて実行されます。このアプローチは、Linux カーネルのcgroupと名前空間の機能に依存しており、^{[22] [ 23} ]これらを組み合わせることで、ユーザー空間プロセスのコレクションのリソース使用量 ( CPU、メモリ、ディスクI/Oなど)を制限、計算、および分離する機能が提供されます。^{[11] [14] [24]}

当初、Container Linux は、Linuxカーネルのオペレーティングシステムレベルの仮想化機能に抽象化とインターフェースの追加レイヤー^[25]を提供するコンポーネントとして、またアプリケーションをさまざまな環境で実行できるようにするコンテナの標準フォーマットを提供するコンポーネントとして、Docker を排他的に使用していました。^{[11] [24]} 2014 年 12 月、CoreOS はDocker の代替としてrkt (当初はRocketとしてリリース) をリリースしてサポートを開始し、rkt を通じてアプリケーション コンテナ イメージの別の標準化されたフォーマット、コンテナランタイム環境の関連定義、およびコンテナ イメージを検出および取得するためのプロトコルを提供しました。 ^{[26] [27] [28] [29] CoreOS は、}アプリケーション コンテナ イメージ(ACI)に必要なプロパティを記述する、 いわゆるアプリ コンテナ(appc) 仕様の実装として rkt を提供しています。 CoreOSは、独立した委員会が主導する仕様セットとしてappcとACIを作成しました^{[30] [31]。}ベンダーやオペレーティングシステムに依存しないオープンコンテナイニシアチブ（ OCI）の一部となることを目指していました。当初はオープンコンテナプロジェクト（OCP）コンテナ化標準と呼ばれていました^{[32]。これは[誰が？ ]} 2015年6月に発表されました。 ^{[33] [34] [35]}

Container Linuxは、システムコンポーネントの自動コンパイルにGentoo Linuxのebuildスクリプトを使用し、 ^{[15] [16]} systemdを主要なinitシステムとして使用し、systemdとContainer Linuxのさまざまな内部メカニズムを緊密に統合しています。^{[11] [36]}

Container Linux は、インストールの読み取り専用部分にFastPatch をデュアル パーティション スキームとして採用することで、オペレーティング システムの更新のセキュリティと信頼性をさらに高めています。つまり、更新は全体として実行され、再起動またはkexec時にアクティブになるパッシブなセカンダリ ブートパーティションにインストールされます。このアプローチにより、オペレーティング システムの特定の部分のみを更新することから生じる可能性のある問題を回避し、オペレーティング システムの安定したバージョンへのロールバックを容易にし、各ブート パーティションに署名してセキュリティを強化できます。^{[11] [ 14] [37]} ルート パーティションとそのルート ファイル システムは、再起動時に使用可能なディスク領域をすべて埋めるように自動的にサイズ変更されます。ルート パーティションは読み取り/書き込み可能なストレージ領域を提供しますが、オペレーティング システム自体は/usrの下に読み取り専用でマウントされます。^{[38] [39] [40]}

オペレーティングシステムのアップデートが適用されたときに、クラスターの特定の部分だけが一度に再起動し、デプロイされたアプリケーションの実行に必要なリソースが確保されるように、CoreOS は Container Linux の再起動マネージャーとしてlocksmith を提供しています。 ^[41] locksmith を使用すると、アップデートを適用する最後のステップとして再起動を実行する方法によって決まるさまざまなアップデート戦略を選択できます。たとえば、同時に再起動できるクラスターメンバーの数を設定できます。内部的には、locksmith はクラスターメンバー上で実行されるlocksmithdデーモンとして動作し、locksmithctlコマンドラインユーティリティが設定パラメーターを管理します。^{[42] [43] locksmith は}Go 言語 で書かれており、 Apache License 2.0の条件に基づいて配布されています。^[44]

Container Linux が採用しているアップデート配布システムは、GoogleのオープンソースOmahaプロジェクトに基づいており、アップデートを展開するためのメカニズムと、基礎となるXMLベースの要求応答プロトコルを提供しています。^{[6] [45] [46]} さらに、CoreOS は、クラスター全体のアップデートを管理するためのWeb ベースのダッシュボードとしてCoreUpdate を提供しています。CoreUpdate を通じて実行できる操作には、カスタマイズされたアップデート ポリシーを共有するさまざまなグループにクラスター メンバーを割り当てること、クラスター全体の Container Linux バージョンの内訳を確認すること、アップデートを停止および再開すること、記録されたアップデート ログを確認することなどがあります。CoreUpdate は、サードパーティのユーティリティやデプロイメント システムへの統合を可能にするHTTPベースのAPIも提供しています。^{[37] [47] [48]}

Container Linux は、クラスター内のすべてのコンピューターで実行され、動的な構成レジストリを提供するデーモンである etcd を提供します。これにより、さまざまな構成データをクラスターメンバー間で簡単かつ確実に共有できます。 ^{[6] [38]} etcd内に格納されているキーと値のデータは、 Raftアルゴリズムを使用した自動マスター選出とコンセンサス確立によって自動的に分散および複製されるため、格納されたデータのすべての変更はクラスター全体に反映されます。また、冗長性を実現することで、単一のクラスターメンバーの障害によるデータ損失を防止できます。^{[29] [50]} 構成管理に加えて、etcd は、デプロイされたアプリケーションが自分自身と提供するサービスをアナウンスできるようにすることで、サービス検出も提供します。 etcdとの通信は、公開されているRESTベースの APIを介して実行されます。この API は、内部的にHTTP に加えてJSON を使用します。この API は、直接使用することも (たとえば、curlまたはwgetを介して)、または CoreOS によって提供される特殊なコマンドラインユーティリティである etcdctl を介して間接的に使用することもできます。 ^{[11] [14] [51] [52] [53] etcd は}Kubernetesソフトウェア でも使用されます。

Container Linux はfleetクラスター マネージャーも提供しており、これは Container Linux の個別の systemd インスタンスをクラスター レベルで制御します。2017 年現在、「fleet」は積極的に開発されておらず、Kubernetes に取って代わられて非推奨となっています。^{[54] Container Linux は}fleetd を使用して、個別の systemd インスタンスとクラスター全体のetcdデプロイメントを結び付ける分散init システムを作成します。 ^[50]内部的には、fleetdデーモンはD-Bus経由でローカルsystemdインスタンスと通信し、公開された API を介してetcdデプロイメントと通信します。 fleetdを使用すると、クラスター全体で単一または複数のコンテナーをデプロイでき、冗長性、フェイルオーバー、特定のクラスター メンバーへのデプロイ、コンテナー間の依存関係、コンテナーのグループ化されたデプロイなど、より高度なオプションを使用できます。 この分散 init システムの構成と監視には、 fleetctlと呼ばれるコマンドライン ユーティリティが使用されます。^[55]内部的には、 HTTP 上の JSON ベースの API を使用してfleetdデーモンと通信しますが、これを直接使用することもできます。クラスタメンバー上でローカルに使用される場合、fleetctlはUnixドメインソケットを介してローカルのfleetdインスタンスと通信します。外部ホストから使用される場合、SSHトンネリングが使用され、公開SSHキーを通じて認証が提供されます。^{[56] [57] [58] [59] [60]}

上記のデーモンとコマンドラインユーティリティ（etcd、etcdctl、fleetd、fleetctl）はすべてGo言語で書かれており、Apache License 2.0の条件に基づいて配布されています。^{[8] [61]}

専用ハードウェア上で実行する場合、Container Linuxはハードディスクドライブ（HDD）やソリッドステートドライブ（SSD）などのローカルストレージに永続的にインストールするか、 ^{[62]一般的には}Preboot Execution Environment（PXE）またはその実装の1つであるiPXEを使用してネットワーク経由でリモートブートすることができます。 ^{[63] [64]} CoreOSは、 Amazon EC2、DigitalOcean、Google Compute Engine、Microsoft Azure、OpenStack、QEMU / KVM、Vagrant、VMwareなど、さまざまなハードウェア仮想化プラットフォームへの展開もサポートしています。^{[14] [ 65] [66] [67]} Container LinuxはCitrix XenServerにインストールすることもできますが、CoreOS用の「テンプレート」が存在することに注意してください。

Container Linuxは、 Tectonicと呼ばれる商用ディストリビューションを通じて展開することもできます。Tectonicは、クラスタ管理ユーティリティとしてGoogleのKubernetesをさらに統合しています。2015年4月現在、Tectonicは一部の顧客にベータソフトウェア^{[アップデート]}として提供される予定です。 ^{[30] [68] [69]さらに、CoreOSは}Flannelをコンポーネントとして 提供しており、主にKubernetesとの統合に必要なオーバーレイネットワークを実装しています。 ^{[30] [70] [71]}

2015年2月現在^{[アップデート]}、Container Linuxはx86-64アーキテクチャのみをサポートしています。^[6]

^{2018年1月にCoreOS, Inc. [72]}を買収した後、Red HatはCoreOS Container LinuxとRed HatのProject Atomicを統合して新しいオペレーティングシステムであるRed Hat CoreOSを作成すると発表しました^[73]。同時に、上流のFedora ProjectオープンソースコミュニティをFedora CoreOSを中心に調整し、両方の前身からの技術を組み合わせました。

2018年3月6日、Kinvolk GmbHはCoreOS Container Linuxの派生版であるFlatcar Container Linuxを発表しました^[74]。これはアップストリームのCoreOSアルファ、ベータ、安定チャネルのリリースを追跡し、2019年5月に実験的なEdgeリリースチャネルが追加されました。^[75]

LWN.netは2014年にCoreOSをレビューしました: ^[76]

大規模な分散システム (Web アプリケーションがその代表例) を構築している人にとって、CoreOS は多くの興味深い機能を備えているように見えます。CoreOS は、その種のアプリケーションを必要に応じて需要に応じて拡大および縮小できるようにするとともに、アップグレードが常に頭を悩ませることのない安定したプラットフォームを提供します。「大規模なサーバー展開」には、CoreOS または同様の特性を多く備えたものが将来有望です。

• アプリケーション仮想化 - アプリケーションソフトウェアを、それが実行されるオペレーティングシステムからカプセル化するソフトウェア技術
• アプリケーション仮想化ソフトウェアの比較 - さまざまなポータブルおよびスクリプト言語仮想マシン
• プラットフォーム仮想化ソフトウェアの比較 - 物理コンピュータ全体をエミュレートするさまざまなエミュレーターとハイパーバイザー
• LXC (Linux コンテナ) – 単一の Linux 制御ホスト上で複数の独立した Linux システム (コンテナ) を実行する環境
• オペレーティングシステムレベルの仮想化実装 - オペレーティングシステムカーネルによる複数の分離されたユーザー空間インスタンスのサポートに基づく
• サービスとしてのソフトウェア(SaaS) - ソフトウェアを集中的にホストし、サブスクリプションベースでライセンスを付与するソフトウェアのライセンスおよび配信モデル
• 仮想化 – コンピューターのハードウェア プラットフォーム、オペレーティング システム、ストレージ デバイスなどの仮想バージョンを提供する一般的な概念。

Wikimedia Commons にはCoreOSに関連するメディアがあります。

• 公式CoreOSおよびGitHubソースコード リポジトリ: CoreOS、etcd、fleet、rkt、CoreOS-overlay
• DistroWatchの CoreOS
• CoreOS の概要、2013 年 9 月 3 日、Sébastien Han 著
• CoreOS: クラウドとデータセンター向けの Linux、ZDNet、2014 年 7 月 2 日、Steven J. Vaughan-Nichols 著
• CoreOS とは何か? Linux ベンダーにとっての脅威、InfoWorld、2014 年 10 月 9 日、Matt Asay 著
• CoreOS 分散アーキテクチャの理解、2015 年 3 月 4 日、Aaron Delp と Brian Gracely による Alex Polvi との講演
• CoreOS フリート アーキテクチャ、2014 年 8 月 26 日、Brian Waldon 他著。
• Google Compute Engine で CoreOS を実行する、2014 年 5 月 23 日
• CoreOS が Btrfs から Ext4 + OverlayFS に移行、Phoronix、2015 年 1 月 18 日、Michael Larabel 著
• コンテナと永続データ、LWN.net、2015 年 5 月 28 日、Josh Berkus 著