Loading article…
| Container Linux | |
|---|---|
 | |
| 開発者 | CoreOSチーム、Red Hat |
| OSファミリー | Linux （ Gentoo Linuxベース） |
| 動作状態 | 販売終了[ 1 ] |
| ソースモデル | オープンソース |
| 初回リリース | 2013年10月 3日 （2013-10-03）[ 2 ] |
| 最終リリース | 2512.3.0 [ 3 ] / 2020年5月22日 ( 2020-05-22 ) |
| 最終プレビュー | 2513.2.0 [ 4 ] (ベータ版) / 2020年5月22日 ( 2020-05-22 ) 2514.1.0 [ 5 ] (アルファ版) / 2020年5月22日 ( 2020-05-22 ) |
| リポジトリ | github.com/coreos |
| マーケティングターゲット | サーバーとクラスター |
| 対応プラットフォーム | x86-64 [ 6 ] |
| カーネルタイプ | モノリシック（Linuxカーネル） |
| ライセンス | Apache License 2.0 [ 7 ] [ 8 ] |
| 後継者 | Fedora CoreOS RHEL CoreOS Flatcar Container Linux |
| 公式サイト | fedoraproject.org/coreos/ |
Container Linux (旧称CoreOS Linux ) は、 Linux カーネルをベースとした、クラスタ展開のインフラストラクチャを提供するように設計された、開発が終了したオープンソースの軽量オペレーティングシステムです。その重点の 1 つはスケーラビリティでした。オペレーティングシステムとして、Container Linux は、ソフトウェア コンテナ内にアプリケーションを展開するために必要な最小限の機能のみを提供し、サービス検出と構成共有のための組み込みメカニズムも提供していました。 [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ]
Container Linux は、共通のソフトウェア開発キット(SDK) を通じてGentoo Linux [ 14 ] [ 15 ] ChromeOSおよびChromiumOSと基盤を共有しています。 Container Linux は、この共有基盤に新しい機能とカスタマイズを追加して、サーバー ハードウェアとユース ケースをサポートします。[ 12 ] [ 16 ] : 7:02 CoreOS は主にAlex Polvi、Brandon Philips、および Michael Marineauによって開発され[ 11 ] 、その主要な機能は安定版として利用可能です。[ 17 ] [ 18 ] [ 19 ]
CoreOSチームは2020年5月26日にContainer Linuxのサポート終了を発表し[ 1 ]、Fedora CoreOS [ 20 ]とRHEL CoreOSを後継として提供しました。
Container Linux は、ペイロード アプリケーションを配布するためのパッケージマネージャを提供しないため、すべてのアプリケーションはコンテナ内で実行する必要があります。単一の制御ホストとして機能する Container Linux インスタンスは、 Linux カーネルの基盤となるオペレーティングシステム レベルの仮想化機能を使用して、分離されたLinuxシステムとして動作する複数のコンテナを作成および構成します。このようにして、ハイパーバイザを使用して本格的な仮想マシンを提供するのではなく、複数の分離されたユーザースペース インスタンスを介してコンテナ間のリソースパーティショニングが実行されます。このアプローチは、Linux カーネルのcgroupsおよびnamespaces機能に依存しており、[ 21 ] [ 22 ]これらが連携して、ユーザー スペースプロセスの集合のリソース使用 ( CPU、メモリ、ディスクI/Oなど)を制限、カウント、および分離する機能を提供します。[ 10 ] [ 13 ] [ 23 ]
当初、Container Linux は、Linux カーネルのオペレーティングシステムレベルの仮想化機能に追加の抽象化レイヤーとインターフェースを提供するコンポーネントとしてDockerのみを使用しており[ 24 ] 、アプリケーションをさまざまな環境で実行できるようにするコンテナの標準化されたフォーマットも提供していました。 [ 10 ] [ 23 ] 2014 年 12 月、CoreOS はDocker の代替としてrkt (当初はRocketとしてリリース) をリリースし、サポートを開始しました。これにより、アプリケーション コンテナ イメージの別の標準化されたフォーマット、コンテナランタイム環境の関連定義、およびコンテナ イメージの検出と取得のためのプロトコルが提供されます。[ 25 ] [ 26 ] [ 27 ] [ 28 ] CoreOS は、アプリケーション コンテナ イメージ(ACI)に必要なプロパティを記述する、いわゆるアプリ コンテナ(appc) 仕様の実装として rkt を提供しています。 CoreOS は、ベンダーやオペレーティングシステムに依存しないOpen Container Initiative、または OCIの一部となることを目指した、独立した委員会主導の仕様セットとして appc と ACI を作成しました[ 29 ] [ 30 ]。当初はOpen Container Project ( OCP) コンテナ化標準と呼ばれ、2015 年 6 月に大手テクノロジー企業のグループによって発表されました[ 32 ] [ 33 ] [ 34 ] 。
Container Linux は、システム コンポーネントの自動コンパイルに Gentoo Linux のebuildスクリプトを使用し、 [ 14 ] [ 15 ]主要なinitシステムとしてsystemdを使用し、systemd と Container Linux のさまざまな内部メカニズムが密接に統合されています。[ 10 ] [ 35 ]
Container Linux は、インストールの読み取り専用部分にFastPatch をデュアルパーティション方式として採用することで、オペレーティングシステムの更新のセキュリティと信頼性をさらに高めています。つまり、更新は全体として実行され、再起動またはkexecでアクティブになるパッシブなセカンダリブートパーティションにインストールされます。このアプローチにより、オペレーティングシステムの特定の部分のみを更新することによって発生する可能性のある問題を回避し、既知の安定版のオペレーティングシステムに簡単にロールバックでき、各ブートパーティションに署名してセキュリティを強化できます。[ 10 ] [ 13 ] [ 36 ]ルートパーティションとそのルートファイルシステムは、再起動時に利用可能なディスク領域すべてを埋めるように自動的にサイズ変更されます。ルートパーティションは読み書き可能なストレージ領域を提供しますが、オペレーティングシステム自体は/usrの下に読み取り専用でマウントされます。[ 37 ] [ 38 ] [ 39 ]
オペレーティングシステムのアップデートを適用する際に、クラスタの特定の部分のみが一度に再起動し、デプロイされたアプリケーションの実行に必要なリソースが確保されるようにするため、CoreOS はContainer Linux の再起動マネージャとしてlocksmithを提供しています。 [ 40 ] locksmith を使用すると、アップデート適用の最終ステップとして再起動がどのように実行されるかによって決まるさまざまなアップデート戦略を選択できます。たとえば、同時に再起動できるクラスタ メンバーの数を設定できます。内部的には、locksmith はクラスタ メンバー上で実行されるlocksmithdデーモンとして動作し、locksmithctlコマンドライン ユーティリティが構成パラメータを管理します。[ 41 ] [ 42 ] Locksmith はGo 言語で記述され、 Apache License 2.0の条件で配布されています。[ 43 ]
Container Linux で採用されているアップデート配布システムは、 GoogleのオープンソースOmahaプロジェクトに基づいており、アップデートを展開するためのメカニズムと、XMLに基づく基盤となるリクエスト/レスポンスプロトコルを提供します。[ 6 ] [ 44 ] [ 45 ]さらに、CoreOS は、クラスタ全体のアップデートを管理するためのWeb ベースのダッシュボードとしてCoreUpdateを提供しています。CoreUpdate で利用できる操作には、カスタマイズされたアップデート ポリシーを共有するさまざまなグループにクラスタ メンバーを割り当てること、クラスタ全体の Container Linux バージョンの内訳を確認すること、アップデートを停止および再開すること、記録されたアップデート ログを確認することなどがあります。CoreUpdate はまた、サードパーティのユーティリティやデプロイメント システムとの統合を可能にするHTTPベースのAPI も提供しています。[ 36 ] [ 46 ] [ 47 ]
Container Linux は、クラスタ内のすべてのコンピュータで実行され、動的な構成レジストリを提供するデーモン etcd を提供し、さまざまな構成データをクラスタ メンバー間で簡単かつ確実に共有できるようにします。[ 6 ] [ 37 ] etcd内に保存されるキーと値のデータは、 Raftアルゴリズムを使用した自動マスター選出と合意形成によって自動的に分散および複製されるため、保存されたデータのすべての変更がクラスタ全体に反映され、実現された冗長性により、単一のクラスタ メンバーの障害によるデータ損失を防ぎます。[ 28 ] [ 49 ] etcd は構成管理に加えて、デプロイされたアプリケーションが自身と提供するサービスを通知できるようにすることで、サービス検出も提供します。etcd との通信は、公開されたRESTベースの APIを介して行われ、内部的にはHTTP 上でJSON を使用します。この API は、直接 (たとえばcurlやwgetを介して) 使用することも、 CoreOSによって提供される専用のコマンドライン ユーティリティであるetcdctlを介して間接的に使用することもできます。 [ 10 ] [ 13 ] [ 50 ] [ 51 ] [ 52 ] etcd はKubernetesソフトウェアでも使用されています。
Container Linux は、クラスタ レベルで Container Linux の個別の systemd インスタンスを制御するfleetクラスタマネージャも提供しています。2017 年現在、「fleet」はもはや積極的に開発されておらず、Kubernetes に置き換えられて非推奨となっています。 [ 53 ] fleetdを使用することで、Container Linux は個別の systemd インスタンスとクラスタ全体のetcdデプロイメントを結び付ける分散init システムを作成します。 [ 49 ] fleetdデーモンは内部的に、D-Busを介してローカルsystemdインスタンスと通信し、公開されている API を介してetcdデプロイメントと通信します。fleetdを使用すると、クラスタ全体に単一または複数のコンテナをデプロイでき、冗長性、フェイルオーバー、特定のクラスタ メンバーへのデプロイ、コンテナ間の依存関係、コンテナのグループ化されたデプロイなどの高度なオプションが利用できます。fleetctlと呼ばれるコマンドライン ユーティリティを使用して、この分散 init システムを構成して監視します。[ 54 ] fleetctl は内部的に、 HTTP 上の JSON ベースの API を使用してfleetdデーモンと通信し、この API は直接使用することもできます。クラスター メンバー上でローカルで使用する場合、fleetctl はUnix ドメイン ソケットを介してローカルのfleetdインスタンスと通信します。外部ホストから使用する場合は、公開 SSH キーによる認証でSSH トンネルが使用されます。[ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ]
上記のデーモンとコマンドラインユーティリティ（etcd、etcdctl、fleetd、fleetctl）はすべてGo言語で記述されており、Apache License 2.0の条件に基づいて配布されています。[ 8 ] [ 60 ]
専用ハードウェア上で実行する場合、Container Linux は、ハードディスク ドライブ(HDD) やソリッドステート ドライブ(SSD) などのローカル ストレージに永続的にインストールすることも、[ 61 ]一般的にPreboot Execution Environment (PXE) またはiPXE を実装として使用してネットワーク経由でリモート ブートすることもできます。 [ 62 ] [ 63 ] CoreOS は、 Amazon EC2、DigitalOcean、Google Compute Engine、Microsoft Azure、OpenStack、QEMU / KVM、Vagrant、VMwareなど、さまざまなハードウェア仮想化プラットフォームへの展開もサポートしています。[ 13 ] [ 64 ] [ 65 ] [ 66 ] Container Linux は Citrix XenServer にもインストールできます。CoreOS 用の「テンプレート」が存在することに注意してください。
Container Linuxは、 Tectonicと呼ばれる商用ディストリビューションを通じてデプロイすることも可能で、TectonicにはさらにGoogleのKubernetesがクラスタ管理ユーティリティとして統合されています。2015年4月現在 Tectonicは、一部の顧客向けにベータ版ソフトウェアとして提供される予定です。 [ 29 ] [ 67 ] [ 68 ]さらに、CoreOSは、主にKubernetesとの統合に必要なオーバーレイネットワークを実装するコンポーネントとしてFlannelを提供します。[ 29 ] [ 69 ] [ 70 ]
2018年1月にCoreOS, Inc. [ 71 ]を買収した後、Red Hatは[ 72 ]、CoreOS Container LinuxをRed HatのProject Atomicと統合して新しいオペレーティングシステムRed Hat CoreOSを作成するとともに、上流のFedora ProjectオープンソースコミュニティをFedora CoreOSに合わせ、両方の前身の技術を組み合わせることを発表しました。
2018 年 3 月 6 日、Kinvolk GmbH は CoreOS Container Linux の派生版である Flatcar Container Linux を発表しました。[ 73 ] Flatcar は、CoreOS の上流のアルファ、ベータ、安定版チャネルのリリースを追跡しており、2019 年 5 月に実験的な Edge リリース チャネルが追加されました。 [ 74 ] 2021 年 4 月 29 日、Kinvolk GmbH は Microsoft に買収されました。[ 75 ] Flatcar Container Linux は Azure Container Linux の上流になりました。[ 76 ]
LWN.netは2014年にCoreOSをレビューした：[ 77 ]
大規模な分散システム（Webアプリケーションはその代表例）を構築する人々にとって、CoreOSは多くの魅力的な機能を備えているように見える。CoreOSは、需要に応じてアプリケーションを柔軟に拡張・縮小できるだけでなく、アップグレードが常に悩みの種となることのない安定したプラットフォームを提供するはずだ。「大規模サーバー展開」においては、CoreOS、あるいは同様の特性を多く備えたシステムが、未来の主流となるだろう。
月曜日にサンフランシスコで開催されたDockerConカンファレンスで発表されたOpen Container Project (OCP)は、Dockerから寄贈されたコードと仕様の一部に基づいて、共通のコンテナランタイムとイメージフォーマットを維持および開発します。
