Container Linux

Container Linux（旧称：CoreOS Linux）は、 Linuxカーネルをベースにしたオープンソースの軽量なオペレーティングシステムである。クラスター向けのデプロイにインフラストラクチャを提供するために開発されており、自動化、アプリケーションのデプロイの容易さ、セキュリティ、信頼性、スケーラビリティに重点を置いて設計されている。オペレーティングシステムとしては、Container Linuxは、label=ソフトウェアコンテナ内のアプリケーションのデプロイに必要な最小限の機能のみを提供するが、同時に、サービス・ディスカバリーや設定を共有するためのビルトインのメカニズムも備えている。 
現地時間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を利用しており、これらのオペレーティングシステムとソフトウェアの基盤を共有している。さらに、この共通基盤に新しい機能とカスタマイズを加えることで、サーバー向けのハードウェアやユースケースをサポートしている7:02。1、CoreOSは主にAlex Polvi、Brandon Philips、Michael Marineauによって積極的に開発されており、主要機能は安定版リリースとして利用できる。 

**概要**
Container Linuxは、ペイロードとなるアプリケーションを配布する方法としてパッケージマネージャーを提供せず、その代わりに、すべてのアプリケーションをコンテナー内で実行する必要がある。一つの制御ホストとして機能するContainer Linuxインスタンスは、そのベースとしてLinuxカーネルのlabel=の機能を使用することで、隔離されたLinuxシステムとして動作する複数のコンテナを作成・設定する。このようにして、Container Linuxでは、ハイパーバイザーや本格的な仮想マシンを提供するのではなく、複数の隔離されたredirect=1のインスタンスを用いることにより、コンテナ間のpreserve=1のパーティション分割を実現している。このアプローチはLinuxカーネルのcgroupsおよびlabel=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に読み込み専用でlabel=マウントされる。
アップデート適用時に一度にクラスタの一部のみが再起動することを保証し、デプロイされた実行中のアプリケーションがリソースを要求するのを防ぐために、CoreOSはContainer Linux向けにlocksmithと呼ばれる再起動マネージャを提供している。locksmithを利用すると、アップデートの最終ステップで再起動する際に、異なるアップデート戦略の中から1つを選ぶことができる。たとえば、同時に再起動できるクラスタのメンバー数を指定できる。内部では、locksmithはクラスタのメンバー上でlocksmithdデーモンを起動しており、locksmithctlコマンドラインユーティリティマネージャでパラメータを設定できる。LocksmithはGo言語で書かれており、Apache License 2.0ライセンスで配布されている。
で使用しているディストリビューションシステムのアップデートは、GoogleのオープンスースOmahaプロジェクトをベースとしている。Omahaは、ローリングアップデートのメカニズムを提供しており、XMLがベースのlabel=プロトコルがベースになっている。また、CoreOSは、クラスタ全体のアップデートを管理するためのCoreUpdateというウェブベースのデジタルダッシュボードも提供している。CoreUpdateで利用可能な操作には、カスタムのアップデートポリシーを共有する異なるグループにユーザーを所属させる機能や、クラスタ全体のContainer Linuxのバージョンを確認する機能、アップデートの停止と再開、アップデートログの記録の確認機能などがある。CoreUpdateはHTTPベースのAPIも提供しており、サードパーティのユーティリティやlabel=デプロイシステムと統合することができる。

**クラスタ・インフラストラクチャ**
CoreOSのクラスターアーキテクチャの概要図 
Container Linuxは、クラスタ内のすべてのコンピュータ上で動作し、動的な設定レジストリとして、etcdを提供している。これにより、様々な設定データを簡単かつ信頼性の高い方法でクラスタメンバー間で共有できる。
に保存されたキーバリューデータは、label=アルゴリズムを用いて自動的なマスター選出とコンセンサスが確立され、自動的に分散、複製が行われるため、保存されたデータのすべての変更がクラスタ全体に反映されるとともに、1つのクラスタメンバーが障害で失われても、データの損失が生じない冗長性が実現されている。設定の管理に加えて、etcdは自身と自身が提供するサービスを通知することにより、サービスディスカバリの機能も提供している。etcdとの通信は、公開されたRESTベースのAPIにより行われ、内部ではHTTPプロトコル上のJSONが使用されている。APIは直接使用することもできるし（たとえば、Mono|curlやMono|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つまたは複数のlabel=コンテナをクラスタ全体にデプロイすることが可能になり、さらに冗長化、フェイルオーバー、特定のクラスタメンバーへのデプロイ、コンテナ間の依存関係の定義、コンテナのグループ化デプロイなどの発展的なオプションが利用できる。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を使用してpreserve=1される。CoreOSはさまざまなハードウェア仮想化プラットフォームをサポートしており、Amazon EC2、label=、label=、Microsoft Azure、OpenStack、QEMU/KVM、Vagrant、VMwareに対応している 。Container Linuxは、CoreOS向け「template」があるCitrix XenServerにもインストールできる。
Container Linuxは、Tectonicと呼ばれる商業ディストリビューションにデプロイすることもでき、追加コンポーネントとしてGoogleのKubernetesをクラスタ管理ユーティリティとして統合している。04、Tectonicはベータ版として一部の顧客にのみ提供される予定である。さらに、CoreOSは主にKubernetesとの統合のためのオーバーレイ・ネットワークを実装するコンポーネントとしてFlannelを提供している。
、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を以下のように評価している。 

**脚注**

**関連項目**
 アプリケーションの仮想化アプリケーションソフトウェアを実行するOSに対してカプセル化するソフトウェア技術 - label=さまざまなポータブル言語とスクリプト言語の仮想マシンの比較 - label=物理コンピューター全体をエミュレートする、ざまなエミュレーターやハイパーバイザーの比較 - LXC（Linuxコンテナー）Linuxが制御する1つのホスト上で、複数の隔離されたLinuxシステム（コンテナ）を実行するための環境 - label=複数の隔離されたユーザー空間インスタンスに対するOSカーネルのサポートに基づいている - Software as a Service (SaaS) ソフトウェアを中央でホストしてサブスクリプションベースでライセンスを供与するタイプのソフトウェアのライセンスと配信のモデル - 仮想化コンピュータハードウェアプラットフォーム、オペレーティングシステム、ストレージデバイスなどの仮想バージョンを提供する一般的な概念

**外部リンク**
 Official CoreOS and Tectonic websites, and GitHub source code repositories: CoreOS, etcd, fleet, rkt and CoreOS-overlay- CoreOS-  First glimpse at CoreOS, September 3, 2013, by Sébastien Han-  CoreOS: Linux for the cloud and the datacenter, ZDNet, July 2, 2014, by Steven J. Vaughan-Nichols-  What's CoreOS? An existential threat to Linux vendors, InfoWorld, October 9, 2014, by Matt Asay-  Understanding CoreOS distributed architecture, March 4, 2015, a talk to Alex Polvi by Aaron Delp and Brian Gracely-  CoreOS fleet architecture, August 26, 2014, by Brian Waldon et al.-  Running CoreOS on Google Compute Engine, May 23, 2014-  CoreOS moves from Btrfs to Ext4 + OverlayFS, Phoronix, January 18, 2015, by Michael Larabel-  Containers and persistent data, LWN.net, May 28, 2015, by Josh Berkus