Container Linux

Container Linux（旧称：CoreOS Linux）は、 Linuxカーネルをベースにしたオープンソースの軽量なオペレーティングシステムである。クラスター向けのデプロイにインフラストラクチャを提供するために開発されており、自動化、アプリケーションのデプロイの容易さ、セキュリティ、信頼性、スケーラビリティに重点を置いて設計されている。オペレーティングシステムとしては、Container Linuxは、ソフトウェアコンテナ（英語版）内のアプリケーションのデプロイに必要な最小限の機能のみを提供するが、同時に、サービス・ディスカバリーや設定を共有するためのビルトインのメカニズムも備えている。 現地時間2018年1月30日、レッドハットがCoreOS, Inc.を買収する最終合意を締結したと発表。それに伴い、Container LinuxはFedora Atomic Hostに統合され、Fedora CoreOSとなった。Container Linuxについては現地時間2020年5月26日にEOLを迎えた旨のアナウンスがされており、同2020年9月1日以降関連リソースは削除または読み取り専用となっている。記事中でFedora CoreOSが公式の後継であるとされている。 Container Linuxは、Gentoo Linux、ChromeOS、Chromium OSと共通のSDKを利用しており、これらのオペレーティングシステムとソフトウェアの基盤を共有している。さらに、この共通基盤に新しい機能とカスタマイズを加えることで、サーバー向けのハードウェアやユースケースをサポートしている。2015年1月 (2015-01)現在[update]、CoreOSは主にAlex Polvi、Brandon Philips、Michael Marineauによって積極的に開発されており、主要機能は安定版リリースとして利用できる。 Container Linuxは、ペイロードとなるアプリケーションを配布する方法としてパッケージマネージャーを提供せず、その代わりに、すべてのアプリケーションをコンテナー内で実行する必要がある。一つの制御ホストとして機能するContainer Linuxインスタンスは、そのベースとしてLinuxカーネルのOSレベル仮想化（英語版）の機能を使用することで、隔離されたLinuxシステムとして動作する複数のコンテナを作成・設定する。このようにして、Container Linuxでは、ハイパーバイザーや本格的な仮想マシンを提供するのではなく、複数の隔離されたユーザー空間（英語版）のインスタンスを用いることにより、コンテナ間のリソース（英語版）のパーティション分割を実現している。このアプローチはLinuxカーネルのcgroupsおよびnamespaces（英語版）の機能に依存しており、これらの機能は、ユーザー空間のプロセスに対して、リソース使用量（CPU、メモリ、ディスクI/Oなど）を制限、集計、隔離する機能を提供している。 当初、Container Linuxは、Dockerのみをコンポーネントとして使用して、抽象化とインターフェイスの追加レイヤをLinuxカーネルのOSレベル仮想化機能に提供し、異なる環境上でアプリケーションを実行可能にするコンテナ向けの標準化フォーマットを提供していた。2014年12月、CoreOSは、rkt（当初はRocketという名前だった）を公開し、サポートを開始した。これは、アプリケーションコンテナイメージの別の標準フォーマットであり、関連するコンテナのランタイム環境の定義、コンテナイメージの検索と取得のためのプロトコルとして、Dockerの代替となるものである。CoreOSは、アプリケーションコンテナイメージ（application container image、ACI）に必要とされる属性を説明する、いわゆるアプリコンテナ（app container、appc）の仕様を定める実装としてrktを提供している。2015年6月、CoreOSは、appcとACIを独立した委員会の主導で定める仕様として提供し、特定のベンダー・OSに依存しないコンテナ化標準のイニシアティブのOpen Container Initiative（OCI、当初はOpen Container ProjectまたはOCPと呼ばれていた）の一部とすることを発表した。 Container Linuxは、Gentoo Linuxのebuildスクリプトを使用してシステムコンポーネントの自動コンパイルを行い、 systemdをメインのinitシステムとして使用し、systemdと各種Container Linuxの内部メカニズムを密接に統合してさせている。 Container Linuxは、FastPatchと呼ばれるデュアルパーティションの枠組みを活用することにより、OSのアップデート時にも追加のセキュリティと信頼性を実現している。FastPatchでは、アップデートはシステム全体に対して実行され、初めにパッシブなセカンダリーのブートパーティションにインストールされ、再起動またはkexecの実行時に有効化されるようになっている。このアプローチにより、OSの特定の一部分のみがアップデートされることにより起こりうる問題を回避することができ、OSの安定であることが分かっているバージョンに簡単にロールバックできることが保証され、追加のセキュリティのためにブートパーティションごとに署名を行うことができるようになる。ルートパーティションとルートファイルシステムは自動的に利用可能なディスクサイズまでサイズ変更される。ルートパーティションは読み書き可能なストレージ空間を提供するが、OS自体は/usr/usrに読み込み専用でマウント（英語版）される。 アップデート適用時に一度にクラスタの一部のみが再起動することを保証し、デプロイされた実行中のアプリケーションがリソースを要求するのを防ぐために、CoreOSはContainer Linux向けにlocksmithと呼ばれる再起動マネージャを提供している。locksmithを利用すると、アップデートの最終ステップで再起動する際に、異なるアップデート戦略の中から1つを選ぶことができる。たとえば、同時に再起動できるクラスタのメンバー数を指定できる。内部では、locksmithはクラスタのメンバー上でlocksmithdデーモンを起動しており、locksmithctlコマンドラインユーティリティマネージャでパラメータを設定できる。LocksmithはGo言語で書かれており、Apache License 2.0ライセンスで配布されている。 で使用しているディストリビューションシステムのアップデートは、GoogleのオープンスースOmahaプロジェクトをベースとしている。Omahaは、ローリングアップデートのメカニズムを提供しており、XMLがベースのリクエスト・レスポンス（英語版）プロトコルがベースになっている。また、CoreOSは、クラスタ全体のアップデートを管理するためのCoreUpdateというウェブベースのデジタルダッシュボードも提供している。CoreUpdateで利用可能な操作には、カスタムのアップデートポリシーを共有する異なるグループにユーザーを所属させる機能や、クラスタ全体のContainer Linuxのバージョンを確認する機能、アップデートの停止と再開、アップデートログの記録の確認機能などがある。CoreUpdateはHTTPベースのAPIも提供しており、サードパーティのユーティリティやデプロイシステム（英語版）と統合することができる。 Container Linuxは、クラスタ内のすべてのコンピュータ上で動作し、動的な設定レジストリとして、etcdを提供している。これにより、様々な設定データを簡単かつ信頼性の高い方法でクラスタメンバー間で共有できる。 etcdに保存されたキーバリューデータは、Raftアルゴリズムを用いて自動的なマスター選出とコンセンサスが確立され、自動的に分散、複製が行われるため、保存されたデータのすべての変更がクラスタ全体に反映されるとともに、1つのクラスタメンバーが障害で失われても、データの損失が生じない冗長性が実現されている。設定の管理に加えて、etcdは自身と自身が提供するサービスを通知することにより、サービスディスカバリの機能も提供している。etcdとの通信は、公開されたRESTベースのAPIにより行われ、内部ではHTTPプロトコル上のJSONが使用されている。APIは直接使用することもできるし（たとえば、curlやwgetを使用して）、CoreOSが提供する専用のコマンドラインユーティリティのetcdctl経由で間接的に利用することもできる。etcdはKubernetesのソフトウェアとしても利用されている。 Container Linuxは、2017年まで、fleetと呼ばれるクラスタマネージャも提供しており、Container Linuxの別のsystemdインスタンスをクラスタレベルで管理することができた。しかし、2017年2月7日、Kubernetesがクラスタマネージャのデファクトスタンダードとなっていることから、1年後の2018年2月1日にfleetを廃止することが発表された。fleetdを使用すると、Container Linuxは別々のsystemdインスタンスを結びつけて分散化されたinit systemを構築することができ、クラスタ全体にetcdをデプロイできる。内部では、fleetdデーモンがローカルのsystemdインスタンスとD-Bus経由で通信しており、etcdのデプロイはsystemdの公開APIで行われる。fleetdにより、1つまたは複数のコンテナ（英語版）をクラスタ全体にデプロイすることが可能になり、さらに冗長化、フェイルオーバー、特定のクラスタメンバーへのデプロイ、コンテナ間の依存関係の定義、コンテナのグループ化デプロイなどの発展的なオプションが利用できる。fleetctlと呼ばれるコマンドラインユーティリティを用いて、この分散initシステムを設定・監視することができる。内部では、fleetdデーモンとの間でHTTP上のJSONベースのAPIを用いて通信を行っており、このAPIは直接利用することもできる。クラスタメンバーのローカルで使用した場合は、fleetctlはローカルのfleetdインスタンスとUnixドメインソケットで通信し、外部のホストからはSSHの公開鍵で認証されたSSHトンネリングが使われる。 これらすべてのデーモンとコマンドラインユーティリティ（etcd、etcdctl、fleetd、fleetctl）は、Go言語で書かれており、Apache License 2.0ライセンスで配布されている。 専用のハードウェアで実行する場合には、Container Linuxはハードディスクドライブ（HDD）やソリッドステートドライブ（SSD）などのローカルディスクに永続的にインストールされる。リモートでブートする場合には、Preboot Execution Environment (PXE) in general, or iPXEを使用してネットワーク越しにブート（英語版）される。CoreOSはさまざまなハードウェア仮想化プラットフォームをサポートしており、Amazon EC2、DigitalOcean（英語版）、Google Compute Engine（英語版）、Microsoft Azure、OpenStack、QEMU/KVM、Vagrant、VMwareに対応している 。Container Linuxは、CoreOS向け「template」があるCitrix XenServerにもインストールできる。 Container Linuxは、Tectonicと呼ばれる商業ディストリビューションにデプロイすることもでき、追加コンポーネントとしてGoogleのKubernetesをクラスタ管理ユーティリティとして統合している。2015年4月 (2015-04)現在[update]、Tectonicはベータ版として一部の顧客にのみ提供される予定である。さらに、CoreOSは主にKubernetesとの統合のためのオーバーレイ・ネットワークを実装するコンポーネントとしてFlannelを提供している。 2015年2月 (2015-02)現在[update]、Container Linuxはx86-64アーキテクチャのみをサポートしている。 2018年1月、CoreOS, Inc.はレッドハットに買収され、その後、レッドハットはCoreOSのContainer Linuxを同社のProject Atomicと統合し、新しいOSであるRed Hat CoreOSを開発することを発表した。Project Atomicには、Fedora ProjectのFedora CoreOSに関係するオープンソースコミュニティがあり、双方の技術を取り込んでいる。 2018年3月6日、Kinvolk GmbHはCoreOS Container Linuxの派生OSとして、Flatcar Linuxを発表した。Flatcar Linuxは、アップストリームのCoreOS alpha/beta/stableチャンネルのリリースを追跡しており、2019年5月には、実験的なEdgeリリースチャンネルが追加された。 2014年、LWN.netはCoreOSを以下のように評価している。 大規模な分散システム—主な例としてはウェブアプリケーション—を統合しようとしている人にとっては、CoreOSは興味深い機能を多数備えているように見えるだろう。これらの機能により、この種のアプリケーションで必要な需要に応じたスケールの拡大や縮小が可能になり、アップグレードが頭痛の種にならないような安定したプラットフォームを提供できるようになるはずだ。「大規模なサーバーのデプロイ」にとって、CoreOSや同じような特徴を持つOSは、未来を先取りしているように思える。