Fedora Projectが6月20日、「Fedora CoreOS」プロジェクトを発表した。CoreOS Container Linux（CL）とFedora Atomic Hostの良いところを組み合わせ、コンテナ化されたワークロードを安全に動かすことができるコンテナホストを作成するとしている。 Fedora CoreOSはFedora Projectの最新のプロジェクト。小規模でフォーカスを絞ったベースを持つOS向けコンポーネントを目指し、CoreOSのアップストリームとしての役割を持つ。 CoreOSのContainer Linux（CL）、FedoraのAtomic Hostの取り組みは類似性が多く、同じようなユースケースをターゲットとしていたことから合体させることにしたという。お互いから良いところを組み合わせるとしており、例えば、CLのプロビジョニングツール「Ignition

はじめに こんにちは、技術顧問の武内です。 本記事はサイボウズの次期インフラ開発チーム(Necoチーム)が遭遇した、CoreOS Container Linux (以降 CoreOS)においてリアルタイムプロセスを実行できないという問題について、次のようなことを記載したものです。 どういう問題なのか どのように根本原因を突き止めたのか 今後どのように対処するのか 問題要旨 本来なら成功するはずのroot権限におけるリアルタイムプロセスの実行が失敗する 根本原因 CoreOSではカーネルのリアルタイムグループスケジューリングという機能が有効になっている 同機能が有効な場合、cpu cgroup配下のプロセスはデフォルトではリアルタイムプロセスを実行できない systemd環境下で生成されたプロセスは何らかのcpu cgroupに所属させられる 対処方法 リアルタイムプロセスが属するcpu c

米Red Hatは1月30日、コンテナ向けディストリビューションなどで知られる米CoreOSを買収する計画を発表した。買収金額は2億5000万ドル、Kubernetesとコンテナ関連のポートフォリオを強化する狙い。 CoreOSはコンテナインフラの自動化と安全化を行う「CoreOS」、Kubernetesの商用ソリューション「Tectonic」、分散システム向けのキーバユーストア「etcd」などの技術を持つベンチャー企業。2013年に創業、コンテナレジストリの「Quay」などのプロジェクトも持ち、Kubernetesの母体であるLinux Foundation傘下のCloud Native Computing Foundation（CNCF）に貢献したアプリケーションコンテナエンジン「rkt」はコンテナ標準化の取り組みOpen Container Initiative（OCI）の加速に役立

コンテナに最適化したCoreOS、ブランド名を「Container Linux」に変更。背景にはコンテナ関連ビジネスの変化が CoreOSと言えば、もともとDocker専用の軽量Linux OSとして同名のCoreOS社によって開発されたLinuxディストリビューションの1つです。その後CoreOS社はDockerのセキュリティ面の課題を解決することなどを主な理由として、独自のコンテナ実装であるrkt（当時はRocket）を開発し搭載するなど、Dockerとは異なるもう1つのコンテナ実装として知られてきました。 そのCoreOSの名称が、「Container Linux」に変更されることをCoreOS社が発表しました。 Over the years, CoreOS (the brand) has grown to represent not just a product but the l

For customersCustomer supportSubscription managementSupport casesRed Hat Ecosystem CatalogFind a partnerFor partnersPartner portalPartner supportBecome a partner Try, buy, & sellRed Hat MarketplaceRed Hat StoreContact salesStart a trialLearning resourcesDocumentationTraining and certification Hybrid cloud learning hubInteractive labsLearning communityRed Hat TVOpen source communitiesAnsibleGlobal

3. • Lightweight OS based on Gentoo Linux • Has a distributed key-value store at the core • Read-only rootfs. Writeable /etc o All services are in containers CoreOS 4. • One CIDR subnet per machine, like Kubernetes o Host 1: 10.10.10.0/24 o Host 2: 10.10.11.0/24 • No Docker port-based mapping • Containers reach each other through IP • Peer network configs exchanged over etcd • Packets encapsulated

昨日2015/04/09開催されたCoreOS Meetup Tokyo #1で登壇させて頂きました。ホストして頂いたみなさん、会場を提供頂いたフリークアウトさん、ありがとうございました。rktの話題もキャッチアップできたし、CoreOSのリリースの仕組みにも触れられて良かったです。CRIUすごくおもしろいし未来かんじました。 speakerdeck.com pixivでCoreOSを運用してみて、こういうこと考えないといけないよね、って思ったことを雑多に羅列しておきました。CoreOSでクラスタを用意するのは良いんですが、デプロイの仕組みだったり、オーケストレーションの仕組みだったり、ロギングの仕組みだったり必要で、結局PaaSにあるような機能は必要になるよね、っていうのが結論で、そうなったときに、本当に毎回全部用意する必要があるのかどうか、ちゃんと考えないといけないのでは、と最近考えて

Linuxコンテナに最適化した「CoreOS」を提供するCoreOS社が、同社のCoreOSおよび関連ソフトウェア群と、Linuxコンテナのクラスタを管理する「Kubernertes」を統合したパッケージ「Toctonic」を発表しました。 TectonicのWebサイトでは、Tectonicとは次のようなソフトウェアだと説明されています。 Tectonic combines Kubernetes and the CoreOS software portfolio in an integrated package. This includes a management console for workflows and dashboards, an integrated registry to build and share Linux containers, and additional

rktは、セキュリティや効率、構築のしやすさが重視されるアプリケーションに適したコンテナのランタイムで、Application Container（appc）specに準拠する。 「rkt v0.5」は、アプリケーションコンテナのイメージとランタイム環境をカプセル化できるpodを規定した、最新のappc specに準拠しており、最新のLinux環境におけるoverlayfsをサポートしている。 初期バージョンのrktでは、アプリケーションコンテナ起動時のデフォルトstage1にCoreOS Linuxのディストリビューションイメージのコピーを使用していたが、「rkt v0.5」では、KVMベースのバーチャルマシンがアプリケーションを起動するテクノロジーとは異なる実装を用いた、systemdをベースにしたstage1を独自開発した。 なお、従来は「rocket」や「Rocket」、あるいは「

更新(2014/07/11)： 自動アップデートをスキップする方法を最後に追加しました。 お詫びと訂正(2014/07/10)： 本エントリの中で、「ロールバック後アップデートがスキップされ次回アップデートまでそのまま使い続けられる」旨の記述がありましたが、間違いでした。 しばらくすると、再度同じアップデートが行われてしまいます。 これが意図された正しい動作なのか疑問が残りますが、アップデートは必ず実行されるようです。 不正確な情報発信をしてしまい、申し訳ありませんでした。 CoreOS は、リードオンリーの /usr パーティションを A、B ２つ持っていて、自動アップデートでは使われていない方のパーティションにインストールされ、リブート(これも自動)時に切り替えています。 下の図では 最初 A が使われていて、A が起動中に自動アップデートが始まると、B に対してインストールが始まりま

CoreOSで採用されているKey-Valueストア「etcd」開発チームは1月28日、初の安定版メジャーリリースとなる「etcd 2.0.0」を公開した。 etcdはCoreOSが設定やログの管理などで使用しているKey-Valueストア型データベース。共通の設定、サービスディスカバリー、スケジューラー調整などで利用されている。CoreOSだけでなくLinuxやMac OS X、BSD系システムでも利用できる。Go言語で作成されており、コンセンサスアルゴリズムのRaftを利用して可用性のある複製ログを管理する。etcdを利用することで、サーバーダウンなどの障害が発生した時もアプリケーションがそのまま動くという。HTTPでアクセスできるAPIやSSLクライアント認証のオプション提供などの特徴を持ち、高速、高い信頼性もうたっている。CoreOSのほか、GoogleのKubernates、Pi

1月17日に「Docker Meetup Tokyo #4」に参加してきました。ここ1〜2年ぐらいで、Dockerなどのインフラに関する技術が変化してきたことをキャッチアップ出来ないでいたので、コミュニティーも含めて知りたかったので助かりました。 CoreOSの基礎/CoreOSに期待すること @deeeet 楽天 GHR go で作られたツール 資料 Docker が与えたくれたもの Googleなど、インフラの選択肢を与えてくれたもの Docker が与えてくれないもの オーケストレーション サービスディスカバリー スケジューリング デプロイ 死活監視 Dockrホストの統一 DevとProductionは同じ？ CoreOS 特徴 minimal RAMの使用量は114MB 機能をそぎ落とし Update System 安全かつ容易なOSアップデート機能 設定値etcd Chefとか