序章

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

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

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

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

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

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

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

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

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

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

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

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

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

スケジューラーはどのようなクラスター管理機能を提供しますか?

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

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

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

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

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

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

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

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

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

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

プロビジョニングとは何ですか?

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

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

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

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

基本的なスケジューリングとクラスター管理に関して、いくつかの人気のあるプロジェクトは次のとおりです。

  • フリート:フリートは、CoreOSのスケジューリングおよびクラスター管理コンポーネントです。 etcdからクラスター内の各ホストの接続情報を読み取り、systemdのようなサービス管理を提供します。
  • marathon :Marathonは、Mesosphereインストールのスケジューリングおよびサービス管理コンポーネントです。 mesosと連携して、長時間実行されるサービスを制御し、プロセスとコンテナを管理するためのWebUIを提供します。
  • Swarm :Docker’s Swarmは、Dockerプロジェクトが2014年12月に発表したスケジューラーです。 Dockerネイティブの構文を使用して、Dockerでプロビジョニングされたホスト上のコンテナーを起動できる堅牢なスケジューラーを提供したいと考えています。

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

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

コンテナのグループを単一のユニットとして高度にスケジューリングおよび制御するという観点から、次のプロジェクトを利用できます。

  • kubernetes :Googleの高度なスケジューラであるkubernetesを使用すると、インフラストラクチャで実行されているコンテナをより詳細に制御できます。 コンテナには、ラベルを付けたり、グループ化したり、通信用に独自のサブネットを指定したりできます。
  • compose :Dockerのcomposeプロジェクトは、宣言型構成ファイルを使用してコンテナーのグループ管理を可能にするために作成されました。 Dockerリンクを使用して、コンテナー間の依存関係について学習します。

結論

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