コンテナーオーケストレーション入門: Docker swarm mode、Kubernetes、Mesosphereの説明

この記事では、最も一般的な3種類のコンテナー管理プログラムについて知っておくべき事柄を説明します。

コンテナーは、アプリケーションを仮想化するための軽量な方法であり、あらゆるDevOps計画の重要な要素です。しかし、このようなコンテナーのすべてをどのように管理すればよいでしょうか。Kubernetes、Mesosphere Marathon、Docker swarm modeなどのコンテナーオーケストレーションプログラムを使用すれば、コンテナーの管理に頭を悩ませることがなくなります。

本題に入る前に、基本的な事柄について確認しておきましょう。コンテナーは急速に成長しつつあるクラウド実現テクノロジーです。451 Research社によれば、その主な理由は、コンテナーが使用するシステムリソースが仮想マシン (VM) よりもはるかに少ないという事実です。つまり、VMでは、オペレーティングシステムを実行するだけでなく、OSで必要となるすべてのハードウェアの仮想コピーも実行しなければなりません。一方、コンテナーで要求されるのは、実行するアプリケーションインスタンスに必要なオペレーティングシステムとシステムリソースだけです。

会社のCFOにとってわかりやすい言葉で説明すると、コンテナーを使用すれば、VMを使用しているときと同一のコンピューターハードウェアで4~10倍のサーバーインスタンスを実行できます。結果として、データセンターですでに稼働中のハードウェア上で、これまでよりも多くのアプリケーションを実行できるようになります。気に入らないはずがありません。

さらに、システム管理者が好む利点として、コンテナーを使用すればアプリケーションを簡単に展開できることが挙げられます。「コンテナーがあれば、アプリケーションのポータビリティがすぐに手に入ります」と、大手LinuxカーネルデベロッパーのJames Bottomley氏は述べています。

コンテナーは2000年以降から存在しており、FreeBSD jailでも利用されていましたが、Dockerが2013年に登場するまで、誰からも注目されていませんでした。その後、急成長し、あらゆる組織とそのCTOがコンテナーの展開を求めるようになったのです。451 Research社の調査によれば、2016年に、コンテナーテクノロジーの市場は、7億6200万ドルもの収益を生み出しました。 2020年までに、コンテナーによる収益は27億ドルに達し、年平均成長率は40%に及ぶと見込まれています。

問題となるのは2つの事柄だけです。つまり、すべてのコンテナーをどのようにセキュリティで保護するのかという点 (後日、別の記事で取り上げることになるでしょう) と、どのように展開して管理すればよいかという点です。

コンテナーの導入方法にお悩みでしたら、次のガイドブックをぜひご覧ください。

 

コンテナーに不可欠な管理

クラウドインフラストラクチャのその他の要素と同じく、コンテナーにも監視と制御が必要です。そうしないと、事実上、サーバーで何が実行されているかがわからなくなってしまいます。

Dockerのようなコンテナーは、Puppet、Chef、AnsibleといったDevOpsツールで使用できますが、このようなツールはコンテナー向けに最適化されていません。クラウド監視企業のDataDog社は、Dockerの実際の採用に関するレポートの中で、「コンテナーの存続期間が短いことと、稼働密度が高いことは、インフラストラクチャ監視に大きな影響を与えます。このような特徴は、個々の監視対象の数が1桁増加することを意味します」と指摘しています。

役割中心ではなくホスト中心の監視ソリューションは、すぐに役に立たなくなってしまいます。

一般に、監視ツールには2つのタイプがあります。1つ目はオーケストレーションです。これは、コンテナーのクラスタリングとスケジューリングを指す便利な用語です。オーケストレーションに取り組んでいるデベロッパーはわずかです。2つ目はコンテナー管理で、コンテナー化されたアプリケーションやアプリケーションコンポーネントの管理タスクを処理します。

Docker swarm mode、Kubernetes、Mesosphere DC/OSの説明に入りましょう。これらのオープンソースツールは、置き換え可能ではなく、互いに直接競合するものでもありません。程度の差はありますが、いずれのツールも以下の機能を備えています。

  • プロビジョニング: これらのツールは、コンテナークラスター内のコンテナーをプロビジョニングまたはスケジュールし、起動することができます。理想的には、リソースや地理的な場所といった要件に応じて、最適なVMでコンテナーを起動します。
  • 構成スクリプト: スクリプトを利用すると、Juju Charms、Puppet Manifests、またはChefレシピを使用するのと同じような方法で、特定のアプリケーション構成をコンテナーにロードできます。通常、これらのスクリプトはYAMLまたはJSONで記述されます。
  • 監視: コンテナー管理ツールは、クラスター内のコンテナーの健全性とホストを追跡および監視します。適切に動作していれば、コンテナーがクラッシュすると、監視ツールが新しいインスタンスを起動します。サーバーに障害が発生すると、別のホスト上でコンテナーを再起動します。また、ツールはシステム健全性チェックを実行して、コンテナー、基盤となるVM、コンテナーが実行されているサーバーの異常をレポートします。
  • ローリングアップグレードとロールバック: コンテナー、またはコンテナー内で実行されているアプリケーションの新しいバージョンを展開すると、コンテナー管理ツールはコンテナークラスター全体で自動的に更新作業を行います。なんらかの問題が発生すると、既知の適切な構成にロールバックすることができます。
  • サービス検出: 古いスタイルのアプリケーションでは、実行する必要のある各サービスの場所を明示的に指定して、ソフトウェアが見つけることができるようにする必要があります。コンテナーではサービス検出を使用して、必要なリソースを検索します。

 

これまでの説明に思い当たることはありますか。そのはずです。アナリストのDan Kusnetzky氏が指摘するように、コンテナーの動作は、2000年代に大きな注目を集めていたサービス指向アーキテクチャ (SOA) とよく似ています。このテクノロジーを見逃した人のために説明すると、SOAでは、アプリケーションを個々のスタンドアロンサービスに分割していました。ただし、技術上の障害として、ネットワーク通信がプロセス間通信よりも1桁遅いという問題がありました。その点、コンテナーは同じサーバー上のリソースを使用する場合が多いため、SOAよりはるかに高速に動作します。これらのツールは、フロントエンドアプリケーション (たとえば、WordPressインスタンス) が対応するMySQLインスタンスをDNSまたはプロキシ経由で動的に検出するのに役立ちます。

  • コンテナーポリシー管理: コンテナーをどこで起動する必要があるでしょうか。CPUあたりいくつのコンテナーを割り当てる必要があるでしょうか。このような質問すべてに対応するには、適切なコンテナーポリシーをセットアップします。
  • 相互運用性: そしてもちろん、コンテナーは既存のIT管理ツールと連携して動作する必要があります。

 

最後に、これら3つのコンテナー管理ツールはすべて、OpenStack MagnumやAzure Container Servicesを含め、さまざまなクラウドプラットフォームと連携して動作します。

独自のコンテナー管理プログラムを作成することもできますが、車輪の再発明をする必要はないでしょう。また、これら3つのツールはどれもオープンソースを基盤として構築されているため、いつでも必要な機能を追加できます。ゼロから始めること自体に意味はありません。

一般論はこれくらいにして、具体的な詳細に移りましょう。

 

Docker swarm mode

コンテナーを初めて扱うのであれば、おそらくまずはDockerを使い始めたことでしょう。Dockerは多数のユーザーベースを引き付けた最初のコンテナープログラムでした。そうであれば自然に、コンテナーインフラストラクチャを設計したのと同じ開発者によって作成されたコンテナーマネージャー、つまりDocker Swarmに注目することになります。

Docker 1.12以降、Dockerの先進的なモデルは内蔵されるオーケストレーションに対応しました。これをswarm modeと呼びます。DockerのスタンドアロンオーケストレータであるDocker Swarmは、この内蔵機能に取って代わられることになりました。swarm modeでは、コンテナーのクラスタリングとスケジューリングだけでなく、アプリケーションライフサイクル全体をユーザーが管理できるようになります。

Docker Swarmとswarm modeの違いはなんでしょうか。Docker 1.12では、swarm modeがDocker Engineに組み込まれました。スケーリング、コンテナー検出、セキュリティはすべて、最小セットアップに含まれています。一方、Docker Swarmは古いスタンドアロン製品であり、複数のDockerホストをクラスター化するために使用されていました。swarm modeは、Dockerの内蔵クラスターマネージャーです。

swarm modeでは単一ノードのDockerの概念を採用しており、それをSwarmに拡張しています。たとえば、Dockerクラスターを実行するには、run docker swarm initコマンドを使用してswarm modeに切り替えます。さらに多くのノードを追加するには、docker swarm joinを実行します。

また、Docker 1.12以降とswarm modeでは、ローリングアップデート、ノード間でのトランスポート層セキュリティの暗号化、ロードバランシング、容易なサービス抽象化がサポートされています。

簡単に言えば、Docker swarm modeでは、コンテナーの負荷を複数のホストに分散させて、swarm (つまり、クラスター) を複数のホストプラットフォーム上にセットアップできるようにします。また、ホストプラットフォームではいくつかの項目をセットアップする必要があります。これには、統合 (異なるノードで実行されているコンテナーが互いに通信できます) や隔離 (異なるコンテナーワークロードを分離してセキュリティを確保します) などが含まれます。このようなニーズに対処するには、仮想ネットワークで作業する必要が生じるでしょう。

 

Kubernetes

Kubernetesは元々Googleによって開発されたオープンソースのコンテナーマネージャーです。Kubernetesが発表されると、AzureやDC/OS、さらに思いつく限りのほぼすべてのクラウドプラットフォームに移植されました。唯一の例外はAmazon Web Services (AWS) です。ただし、CoreOSを使用すると、AWS上にKubernetesクラスターを展開できるようになります。

現在、KubernetesはLinux FoundationのCloud Native Computing Foundationによって管理されています。また、さまざまな企業によるKubernetesディストリビューションが存在します。これには、Red Hat OpenShift、Canonical Distribution of Kubernetes、CoreOS Tectonic、IntelとMirantisによるソリューションなどがあります。

Kubernetesでは、高度な相互運用性だけでなく、自己修復、自動ロールアウトおよびロールバック、ストレージオーケストレーションも提供されます。ただし、Kubernetesを使用している場合、ロードバランシングは困難です。最終的には、Kubernetes Ingressにより、Kubernetes内から外部のロードバランサーを簡単に実行できるようになるでしょうが、そのための作業はまだ進行中です。

Kubernetesの優位性は、問題を自動修正できることにあります。ただし、この機能は非常に優れており、コンテナーがクラッシュしても迅速に再起動されるので、ユーザーは使用中のコンテナーがクラッシュしていることに気付きません。この問題に対処するには、集中型のログ収集システムを追加する必要があります。

 

Mesosphere Marathon

Marathonは、MesosphereのDC/OSおよびApache Mesos向けのコンテナーオーケストレーションプラットフォームです。DC/OSは、Mesos分散型システムカーネルを基盤とした分散オペレーティングシステムです。また、Mesosはオープンソースのクラスター管理システムです。Marathonは (そのパートナープログラムであるフォールトトレラントジョブスケジューラChronosを介して) 既存のステートフルアプリケーションとコンテナーベースのステートレスアプリケーションの間の管理統合を実現します。

Marathonはユーザーインターフェイスを備えているため、アプリケーションのように見えるかもしれませんが、コンテナー管理用のフレームワークと見なす方が簡単かもしれません。この点は、DevOpsの開発者側に関係します。コンテナーはREST APIを通じてMarathonと連携するためです。

Marathonは、高可用性、サービス検出、ロードバランシングといった豊富な機能を備えています。DC/OS上で実行すれば、アプリケーションでも仮想IPルーティングを利用できるようになります。

ただし、MarathonはMesosを使用したソフトウェア階層でのみ実行できます。また、特定の機能 (認証など) はDC/OS上で実行されるMarathonでのみ利用できます。この場合、抽象レイヤーがさらに1つスタックに追加されることになります。

最適なツールはどれでしょうか。

最終的には、ニーズによって決まります。MesosとKubernetesの主な目的は、クラスター化したアプリケーションの実行です。一方、Mesosでは、一般的なスケジューリングと、複数の異なるスケジューラの組み込みに重点を置いています。Googleは元々、コンテナーから分散アプリケーションを構築するための環境としてKubernetesを設計しました。

Docker swarm modeは既存のDocker APIを拡張し、マシンのクラスターを単一のDocker APIで使いやすくします。会社のスタッフにDockerのプロフェッショナルがいれば、おそらくすでにswarm modeが実行されているでしょう。swarm modeがうまく動作していれば、別のシステムに移行する必要はありません。Marathonには、コンテナーと古いアプリケーションの両方を扱う1つの方法 (ただし、複数層による方法) を提供できるという独自の利点があります。

幸い、これらのプログラムをうまく組み合わせて、会社のニーズに応じた独自の環境を構築できます。3つのプログラムは互いに連携して動作させることができます。簡単ではありませんが実現可能なので、おそらく、この選択肢を探るのが良い方法でしょう。

 

コンテナー管理: リーダーへのアドバイス

  • コンテナーを最大限活用するには、優れたコンテナー管理プログラムが必要です。主要な3つのアプリケーションは、Kubernetes、Mesosphere、Docker Swarmです。これらの機能はさまざまですが、どれもコンテナーのプロビジョニング、監視、および管理をサポートしています。
  • Mesosphereは、コンテナーの管理に加えて、データセンターの管理に役立つ機能を備えています。
  • Docker swarm modeは、コンテナーのスケジューリング管理を提供することで、Dockerのクラスタリングを容易にすることを目指しています。たとえば、コンテナーを起動できるノードを制限し、Docker Remote APIと連携し、新しいコンテナーをスケジュールする必要があるクラスター内のノードを決定できるようにします。
  • Kubernetesには、Intel、Microsoft、Red Hat、Mirantisなど、業界に幅広いパートナーがいます。

 

Mesosphere環境向けのワンストップソリューションをお探しですか。MesosphereのDC/OSテクノロジーとHPEのインフラストラクチャおよびサービス面でのリーダーシップを組み合わせることで、ハイブリッドITを活用して分散エンタープライズ環境をさらに効率的に実行、展開、管理できるようになります。

 

この記事/コンテンツは、記載されている特定の著者によって書かれたものであり、必ずしもHewlett Packard Enterpriseの見解を反映しているとは限りません。

ラクに学べる コンテナ dummies

ITインフラストラクチャのモダナイゼーション: 誰でもわかるコンテナー

enterprise.nxt

ITプロフェッショナルの皆様へ価値あるインサイトをご提供する Enterprise.nxt へようこそ。

ハイブリッド IT、エッジコンピューティング、データセンター変革、新しいコンピューティングパラダイムに関する分析、リサーチ、実践的アドバイスを業界の第一人者からご提供します。