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 を利用しており、これらのオペレーティングシステムとソフトウェアの基盤を共有している。さらに、この共通基盤に新しい機能とカスタマイズを加えることで、サーバー向けのハードウェアやユースケースをサポートしている:7:02 。2015-01-01、CoreOSは主にAlex Polvi、Brandon Philips、Michael Marineauによって積極的に開発されており、主要機能は安定版リリース として利用できる。
Container Linuxは、ペイロードとなるアプリケーションを配布する方法としてパッケージマネージャー を提供せず、その代わりに、すべてのアプリケーションをコンテナー内で実行する必要がある。一つの制御ホストとして機能するContainer Linuxインスタンスは、そのベースとしてLinuxカーネルのOSレベルの仮想化 の機能を使用することで、隔離されたLinux システムとして動作 する複数のコンテナを作成・設定する。このようにして、Container 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 に読み込み専用でマウント （英語版 ）
アップデート適用時に一度にクラスタ の一部のみが再起動することを保証し、デプロイされた実行中のアプリケーションがリソースを要求するのを防ぐために、CoreOSはContainer Linux向けにlocksmith と呼ばれる再起動 マネージャを提供している。locksmithを利用すると、アップデートの最終ステップで再起動する際に、異なるアップデート戦略の中から1つを選ぶことができる。たとえば、同時に再起動できるクラスタのメンバー数を指定できる。内部では、locksmithはクラスタのメンバー上でlocksmithd デーモン を起動しており、locksmithctl コマンドライン ユーティリティマネージャでパラメータを設定できる。LocksmithはGo言語 で書かれており、Apache License 2.0 ライセンスで配布されている。
で使用しているディストリビューションシステムのアップデートは、Google のオープンスースOmaha プロジェクトをベースとしている。Omahaは、ローリングアップデートのメカニズムを提供しており、XML がベースのリクエスト・レスポンス （英語版 ） CoreUpdate というウェブベースのデジタルダッシュボード も提供している。CoreUpdateで利用可能な操作には、カスタムのアップデートポリシーを共有する異なるグループにユーザーを所属させる機能や、クラスタ全体のContainer Linuxのバージョンを確認する機能、アップデートの停止と再開、アップデートログの記録の確認機能などがある。CoreUpdateはHTTP ベースのAPI も提供しており、サードパーティのユーティリティやデプロイシステム （英語版 ）
CoreOSのクラスターアーキテクチャの概要図 Container Linuxは、クラスタ内のすべてのコンピュータ上で動作し、動的な設定レジストリとして、etcdを提供している。これにより、様々な設定データを簡単かつ信頼性の高い方法でクラスタメンバー間で共有できる。
etcd に保存されたキーバリューデータ は、Raft マスター選出 とコンセンサス が確立され、自動的に分散 、複製 が行われるため、保存されたデータのすべての変更がクラスタ全体に反映されるとともに、1つのクラスタメンバーが障害で失われても、データの損失が生じない冗長性 が実現されている。設定の管理に加えて、etcd は自身と自身が提供するサービスを通知することにより、サービスディスカバリ の機能も提供している。etcd との通信は、公開されたREST ベースのAPIにより行われ、内部ではHTTPプロトコル上のJSON が使用されている。APIは直接使用することもできるし（たとえば、curl wget 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 ライセンスで配布されている。
