CoreOSシステムコンポーネントの概要

CoreOSは、さまざまなインフラストラクチャでの大規模でスケーラブルな展開を管理しやすくするために構築された強力なLinuxディストリビューションです。 Chrome OSのビルドに基づいて、CoreOSは軽量ホストシステムを維持し、すべてのアプリケーションにDockerコンテナーを使用します。 このシステムはプロセスの分離を提供し、アプリケーションをクラスター全体に簡単に移動できるようにします。

これらのクラスターを管理するために、CoreOSは「+ etcd +」と呼ばれるグローバルに分散されたキーと値のストアを使用して、ノード間で構成データを渡します。 このコンポーネントはサービス検出のプラットフォームでもあり、共有リソースを介して利用可能な情報に基づいてアプリケーションを動的に構成できます。

クラスター全体でアプリケーションをスケジュールおよび管理するために、「+ fleet 」というツールが使用されます。 フリートは、クラスター全体のプロセスを管理するために使用できるクラスター全体の初期化システムとして機能します。 これにより、可用性の高いアプリケーションを簡単に構成し、クラスターを単一のポイントから管理できます。 これは、個々のノードの「 systemd +」initシステムに結び付けることで行います。

このガイドでは、CoreOSの重要な概念をいくつか紹介し、システムが動作するための各コアコンポーネントを紹介します。 後のガイドで、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean [DigitalOceanでCoreOSを開始する方法]について説明します。 。

CoreOSインストールの一般的な設計は、クラスタリングとコンテナ化を対象としています。

メインホストシステムは比較的単純であり、従来のサーバーの一般的な「機能」の多くを使用しません。 実際、CoreOSにはパッケージマネージャーすらありません。 代わりに、追加のアプリケーションはすべてDockerコンテナーとして実行されることが期待されており、サービスの分離、移植性、および外部管理が可能になります。

起動時に、CoreOSは「cloud-config」と呼ばれるユーザー指定の構成ファイルを読み取り、初期構成を行います。 このファイルにより、CoreOSはクラスターの他のメンバーと接続し、重要なサービスを起動し、重要なパラメーターを再構成できます。 これは、CoreOSが作成時にすぐに作業ユニットとしてクラスターに参加できる方法です。

通常、「cloud-config」ファイルは、少なくとも、既存のクラスターに参加する方法をホストに指示し、ホストに「+ etcd 」および「 fleet +」と呼ばれる2つのサービスを起動するように指示します。 これら3つのアクションはすべて関連しています。 新しいホストが既存のサーバーに接続できるようにし、クラスター内の各ノードの構成と管理に必要なツールを提供します。 基本的に、これらはCoreOSノードをクラスターにブートストラップするための要件です。

`+ etcd `デーモンは、クラスター内の各ホストにデータを保存および配布するために使用されます。 これは、一貫性のある構成を維持するのに役立ち、サービスが自分自身をアナウンスできるプラットフォームとしても機能します。 このサービス検出メカニズムを他のサービスで使用して、情報を照会し、構成の詳細を調整できます。 たとえば、ロードバランサーは、起動時に複数のバックエンドWebサーバーのIPアドレスを ` etcd +`に照会できます。

+ fleet +`デーモンは、基本的に分散initシステムです。 クラスタ内の個々のホストの `+ systemd + initシステムにフックすることで機能します。 サービスのスケジューリングを処理し、ユーザー定義の基準に基づいて展開ターゲットを制限します。 ユーザーは、個々のサーバーを気にすることなく、「+ fleet +」を使用してクラスターを単一のユニットとして概念化できます。

これでシステム全体についての一般的なアイデアが得られたので、特定のコンポーネントのそれぞれについてさらに詳しく見ていきましょう。 これらのそれぞれが果たす役割を理解することは重要です。

Dockerは、Linuxコンテナーとも呼ばれるLXCを利用し、プロセスを分離するためにカーネルネームスペースとcgroupsを使用するコンテナー化システムです。

分離は、アプリケーションの実行環境をクリーンで予測可能な状態に保つのに役立ちます。 ただし、このシステムの主な利点の1つは、ソフトウェアの配布が簡単になることです。 Dockerコンテナーは、動作環境に関係なくまったく同じように実行できる必要があります。 つまり、ラップトップ上に構築されたコンテナは、データセンター全体のクラスターでシームレスに実行できます。

Dockerを使用すると、必要なすべての依存関係を備えた稼働中のソフトウェア環境を配布できます。 Dockerコンテナーは他のコンテナーと並行して実行できますが、個別のサーバーとして機能します。 仮想化に対するDockerコンテナーの利点は、Dockerがオペレーティングシステム全体をエミュレートするのではなく、アプリケーションの実行に必要なコンポーネントのみを実装することです。 このため、Dockerには仮想化の多くの利点がありますが、リソースコストはかかりません。

CoreOSは、基本インストールに含まれる小さなセット以外のソフトウェアのDockerコンテナーを活用します。 これは、ほとんどすべてがコンテナ内で実行する必要があることを意味します。 これは最初は面倒に思えるかもしれませんが、クラスターオーケストレーションを大幅に簡単にします。 CoreOSは、個々のサーバーのレベルではなく、主にクラスターレベルで操作されるように設計されています。

これにより、CoreOSでのサービスの配布と負荷の分散が容易になります。 付属のツールとサービスを使用すると、指定された制約内で使用可能なノードのいずれかでプロセスを開始できます。 Dockerでは、これらのサービスとタスクを、各ノードで構成する必要があるアプリケーションではなく、自己完結型のチャンクとして配布できます。

グローバルデータの一貫したセットをクラスター内の各ノードに提供し、サービス検出機能を有効にするために、「+ etcd +」と呼ばれるサービスが開発されました。

etcdサービスは、各ノードが構成データの取得、実行中のサービスに関する情報の照会、および他のメンバーに知られるべき情報の公開に使用できる、可用性の高いキーと値のストアです。 各ノードは、独自のetcdクライアントを実行します。 これらは、クラスター内の他のクライアントと通信して情報を共有および配布するように構成されています。

ストアから情報を取得したいアプリケーションは、ローカルマシンの `+ etcd `インターフェースに接続するだけです。 実際に保存されている場所に関係なく、すべての「 etcd +」データは各ノードで使用でき、保存された各値はクラスター全体に自動的に分散および複製されます。 リーダーの選挙も自動的に処理されるため、キーストアの管理は非常に簡単になります。

etcdデータとやり取りするには、単純なHTTP / JSON API（デフォルトで `+ http：//127.0.0.1：4001 / v2 / keys / `からアクセス可能）を使用するか、 ` + etcdctl + `でデータを操作または読み取ります。 ` etcdctl +`コマンドとHTTP APIはどちらも、ストアとやり取りするためのシンプルで予測可能な方法です。

HTTP APIは、Dockerコンテナ内で実行されているアプリケーションからもアクセスできることを認識することが重要です。 つまり、個々のコンテナの構成では、etcdに保存されている値を考慮することができます。

構築しているCoreOSクラスターを実際に調整するために、 `+ fleet +`と呼ばれるツールが使用されます。 かなり単純な概念であるフリートは、クラスター全体の初期化システムとして機能します。

クラスター環境内の各ノードは、独自の従来の「+ systemd 」initシステムを操作します。 これは、ローカルマシンでサービスを開始および管理するために使用されます。 簡単に言えば、フリートは、各クラスターメンバーの「 systemd +」システムを制御するためのインターフェースを提供します。

サービスを開始または停止したり、クラスター全体で実行中のプロセスに関する状態情報を取得したりできます。 ただし、艦隊はこれをより使いやすくするためにいくつかの重要なことを行います。 プロセス配布メカニズムを処理するため、負荷の少ないホストでサービスを開始できます。

実行しているサービスの配置条件を指定することもできます。 サービスの場所、既に実行されている内容などに応じて、特定のホストでサービスを実行する必要があるかどうかを主張できます。 フリートはローカルプロセスの開始にsystemdを利用するため、サービスを定義する各ファイルはsystemdユニットファイルです（いくつかのカスタムオプションがあります）。 これらの構成ファイルを1回フリートに渡して、クラスター全体で管理できます。

この柔軟性により、可用性の高い構成を簡単に設計できます。 たとえば、各Webサーバーコンテナを別々のノードにデプロイするように要求できます。 同様に、ヘルパーコンテナが親コンテナを実行しているノードにのみデプロイされるようにすることができます。

任意のメンバーノードを使用して、 `+ fleetctl `ユーティリティを使用してクラスターを管理できます。 これにより、サービスのスケジュール、ノードの管理、およびシステムの一般的な状態を確認できます。 ` fleetctl +`プログラムは、クラスターとのメインインターフェースになります。

CoreOSは、皆さんがよく知っている他のほとんどのLinuxディストリビューションとは異なる場合があります。 設計上の各決定は、クラスター管理の容易さとアプリケーションの移植性を考慮して行われました。 これにより、最新のインフラストラクチャおよびアプリケーションのスケーリングのニーズに対応するために構築された、集中的で強力なディストリビューションが実現しました。

開始方法の詳細については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean [CoreOSクラスターの取得]のガイドをご覧ください。 DigitalOceanで実行中]。