Dockerエコシステム:スケジューリングとオーケストレーション

前書き

Dockerツールは、コンテナの構築、アップロード、ダウンロード、開始、停止に必要なすべての機能を提供します。 コンテナーの数が最小限の単一ホスト環境でこれらのプロセスを管理するのに適しています。

ただし、多くのDockerユーザーは、さまざまなホスト間で多数のコンテナーを簡単にスケーリングするためのツールとしてプラットフォームを活用しています。 クラスター化されたDockerホストには、異なるツールセットを必要とする特別な管理上の課題があります。

このガイドでは、Dockerスケジューラーとオーケストレーションツールについて説明します。 これらは、分散展開の管理者向けの主要なコンテナ管理インターフェイスを表します。

コンテナ、オーケストレーション、クラスター管理のスケジューリング

アプリケーションが複数のホストシステムにスケールアウトされると、各ホストシステムを管理し、基盤となるプラットフォームの複雑さを抽象化する機能が魅力的になります。 オーケストレーションは、コンテナスケジューリング、クラスター管理、および場合によっては追加のホストのプロビジョニングを指す広義の用語です。

この環境では、「スケジューリング」とは、特定のコンテナの実行方法を確立するホストシステムに管理者がサービスファイルをロードする機能のことです。 スケジューリングとは、サービス定義をロードする特定の行為を指しますが、より一般的な意味では、スケジューラーはホストの初期化システムに接続して、必要な容量のサービスを管理します。

クラスタ管理は、ホストのグループを制御するプロセスです。 これには、クラスターへのホストの追加と削除、ホストとコンテナーの現在の状態に関する情報の取得、プロセスの開始と停止が含まれます。 スケジューラーは、サービスをスケジュールするためにクラスター内の各ホストにアクセスする必要があるため、クラスター管理はスケジューリングに密接に関連しています。 このため、多くの場合、同じツールが両方の目的に使用されます。

クラスター全体のホストでコンテナーを実行および管理するには、スケジューラーが各ホストの個々のinitシステムと対話する必要があります。 同時に、管理を容易にするために、スケジューラーはクラスター全体のサービスの状態を統一したビューで表示します。 これは、クラスター全体の初期化システムのように機能することになります。 このため、多くのスケジューラーは、抽象化するinitシステムのコマンド構造を反映しています。

スケジューラの最大の責任の1つは、ホストの選択です。 管理者がクラスターでサービス(コンテナー)を実行することを決定した場合、多くの場合、スケジューラーは自動的にホストを選択するよう求められます。 管理者は、必要に応じてスケジューリングの制約をオプションで提供できますが、スケジューラは最終的にこれらの要件を実行する責任があります。

スケジューラはどのようにスケジューリングを決定しますか?

多くの場合、スケジューラーはデフォルトのスケジューリングポリシーを定義します。 これにより、管理者からの入力がない場合のサービスのスケジュール方法が決まります。 たとえば、スケジューラは、現在アクティブなサービスが最も少ないホストに新しいサービスを配置することを選択する場合があります。

スケジューラは通常、管理者が選択プロセスを微調整して特定の要件を満たすために使用できるオーバーライドメカニズムを提供します。 たとえば、2つのコンテナが1つのユニットとして動作するため、常に同じホストで実行する必要がある場合、多くの場合、そのアフィニティはスケジューリング中に宣言できます。 同様に、たとえば同じサービスの2つのインスタンスの高可用性を確保するために、2つのコンテナを同じホストに配置しない場合は、これも定義できます。

スケジューラが注意を払う可能性のあるその他の制約は、任意のメタデータで表すことができます。 個々のホストは、スケジューラによってラベル付けされ、ターゲットにされる場合があります。 これは、たとえば、アプリケーションに必要なデータボリュームがホストに含まれている場合に必要になることがあります。 一部のサービスは、クラスター内のすべてのホストにデプロイする必要がある場合があります。 ほとんどのスケジューラーでこれを行うことができます。

スケジューラーが提供するクラスター管理機能とは?

多くの場合、スケジューリングはクラスター管理機能に関連付けられています。これは、両方の機能が特定のホストおよびクラスター全体で動作する機能を必要とするためです。

クラスター管理ソフトウェアを使用して、クラスターのメンバーに関する情報を照会したり、メンバーを追加または削除したり、個々のホストに接続して、よりきめ細かな管理を行うことができます。 これらの機能は、スケジューラに含まれている場合もあれば、別のプロセスの責任である場合もあります。

多くの場合、クラスター管理は、サービス検出ツールまたは分散キーと値のストアにも関連付けられています。 これらは、このタイプの情報を保存するのに特に適しています。これは、情報がクラスター自体全体に分散されており、プラットフォームがその主要機能のためにすでに存在しているためです。

このため、スケジューラ自体がメソッドを提供しない場合、提供されたAPIを使用して構成ストアの値を変更することにより、一部のクラスター管理操作を実行する必要があります。 たとえば、クラスターメンバーシップの変更は、ディスカバリサービスへの生の変更を通じて処理する必要がある場合があります。

キーバリューストアは通常、個々のホストに関するメタデータを保存できる場所でもあります。 前述したように、ホストにラベルを付けると、個人またはグループをターゲットとしてスケジュールを決定できます。

マルチコンテナ展開はどのようにスケジューリングに適合しますか?

場合によっては、アプリケーションの各コンポーネントが個別のサービスに分割されていても、それらを単一のユニットとして管理する必要があります。 各サービスが提供する機能のために、あるサービスを別のサービスなしでデプロイすることが意味をなさない場合があります。

コンテナのグループ化を考慮した高度なスケジューリングは、いくつかの異なるプロジェクトで利用できます。 ユーザーがこの機能にアクセスすることで得られる利点はかなりあります。

グループコンテナ管理により、管理者はコンテナのコレクションを単一のアプリケーションとして扱うことができます。 緊密に統合されたコンポーネントをユニットとして実行すると、個々の機能を区分化する利点を犠牲にすることなく、アプリケーション管理が簡素化されます。 実際、管理者は、追加の管理オーバーヘッドを最小限に抑えながら、コンテナ化とサービス指向アーキテクチャから得た利益を維持できます。

アプリケーションをグループ化するということは、単にそれらを一緒にスケジュールし、それらを同時に開始および停止する機能を提供することを意味します。 また、アプリケーションの各グループに個別のサブネットを構成したり、以前はコンテナスケールでしかスケールできなかったコンテナセット全体をスケールしたりするような、より複雑なシナリオも可能になります。

プロビジョニングとは

クラスター管理に関連する概念はプロビジョニングです。 プロビジョニングとは、新しいホストをオンラインにし、基本的な方法で構成して、作業の準備ができるようにするプロセスです。 Dockerデプロイメントでは、これは多くの場合、Dockerを構成し、既存のクラスターに参加するように新しいホストをセットアップすることを意味します。

ホストのプロビジョニングの最終結果は常に新しいシステムが使用できるようになりますが、使用するツールとホストのタイプによって方法論は大きく異なります。 たとえば、ホストが仮想マシンの場合、「+ vagrant +」などのツールを使用して新しいホストを起動できます。 ほとんどのクラウドプロバイダーでは、APIを使用して新しいホストを作成できます。 対照的に、裸のハードウェアのプロビジョニングには、おそらくいくつかの手動手順が必要です。 ホストの初期構成を処理し、既存のクラスターに接続するために必要な情報を提供するために、Chef、Puppet、Ansible、Saltなどの構成管理ツールが関与する場合があります。

プロビジョニングは管理者が開始するプロセスとして残される場合があります。または、自動スケーリングのためにクラスター管理ツールにフックされる可能性があります。 この後者の方法では、追加のホストを要求するプロセスと、これが自動的にトリガーされる条件を定義します。 たとえば、アプリケーションに深刻な負荷がかかっている場合、輻輳を緩和するために、システムに追加のホストをスピンアップさせ、新しいインフラストラクチャ全体でコンテナを水平方向にスケーリングすることができます。

一般的なスケジューラとは何ですか?

基本的なスケジューリングとクラスター管理の観点から、いくつかの一般的なプロジェクトは次のとおりです。

  • フリート:フリートは、CoreOSのスケジューリングおよびクラスター管理コンポーネントです。 etcdからクラスター内の各ホストの接続情報を読み取り、systemdのようなサービス管理を提供します。

  • * marathon *:Marathonは、Mesosphereインストールのスケジューリングおよびサービス管理コンポーネントです。 mesosと連携して長時間実行されるサービスを制御し、プロセスおよびコンテナー管理用のWeb UIを提供します。

  • * Swarm *:Docker’s Swarmは、Dockerプロジェクトが2014年12月に発表したスケジューラーです。 Dockerネイティブの構文を使用して、Dockerでプロビジョニングされたホスト上でコンテナを起動できる堅牢なスケジューラを提供したいと考えています。

クラスター管理戦略の一環として、Mesosphere構成は次のコンポーネントに依存しています。

  • * mesos *:Apache mesosは、クラスター内のすべてのホストのリソースを抽象化して管理するツールです。 クラスター全体で利用可能なリソースのコレクションを、その上に構築されたコンポーネント(マラソンなど)に提示します。 クラスタ化された構成の「カーネル」に類似していると説明しています。

コンテナのグループを1つのユニットとして高度なスケジューリングと制御を行うという点では、次のプロジェクトを利用できます。

  • * kubernetes *:Googleの高度なスケジューラであるkubernetesを使用すると、インフラストラクチャで実行されているコンテナをより詳細に制御できます。 コンテナにラベルを付け、グループ化し、通信用に独自のサブネットを与えることができます。

  • * compose *:宣言的な構成ファイルを使用してコンテナーのグループ管理を可能にするために、Dockerの構成プロジェクトが作成されました。 Dockerリンクを使用して、コンテナー間の依存関係について学習します。

結論

クラスター管理と作業スケジューラーは、ホストの分散セットにコンテナー化されたサービスを実装する重要な部分です。 これらは、アプリケーションを提供しているサービスを実際に開始および制御するための管理の主要ポイントを提供します。 スケジューラを効果的に利用することで、ごくわずかな労力でアプリケーションに大幅な変更を加えることができます。

前の投稿:Goでのメソッドの定義
次の投稿:FreeBSD 11.0にGitをインストールする方法