🚓 🚥 🖼️ メソス。コンテナクラスタ管理システム 🔢 📺 🚨

Apache Mesosは、集中型フェールオーバークラスター管理システムです。リソースを分離し、下位ノード（メソスレーブ）のクラスターを便利に管理することを目的とした分散コンピューティング環境向けに設計されています。これは、サーバーインフラストラクチャを管理するための新しい効果的な方法ですが、技術的なソリューションと同様に、「特効薬」ではありません。

ある意味で、彼の仕事の本質は、従来の仮想化の反対です-物理マシンを多数の仮想マシンに分割する代わりに、Mesosはそれらを1つの仮想リソースに結合することを提案します。

Mesosは、Linuxカーネルがローカルプロセス間でハードウェアリソースを割り当てる方法と同様の方法で、タスクのクラスター内のCPUおよびメモリリソースを割り当てます。

さまざまな種類のタスクを実行する必要があると想像してください。これを行うには、タイプごとに個別の仮想マシン（個別のクラスター）を選択できます。これらの仮想マシンはおそらく完全にロードされておらず、しばらくアイドル状態になります。つまり、最大効率で動作しません。すべてのタスクのすべての仮想マシンを単一のクラスターに結合すると、リソースの使用効率を向上させると同時に、実行速度を向上させることができます（タスクが短期的であるか、仮想マシンが常に完全にロードされていない場合）。次の図は、うまくいけば言われたことを明確にするでしょう：

しかし、それはすべてとは程遠い。 Mesosクラスター（フレームワークを使用）は、個々のリソースが落ちた場合に再作成し、特定の条件下でリソースを手動または自動でスケーリングすることができます。

Mesosクラスターのコンポーネントを見ていきましょう。

Mesosマスター

クラスターのメイン監視サーバー。実際、彼らはリソースを提供し、既存のMesosスレーブ間でタスクを分配します。高いレベルのアクセス可能性を確保するために、いくつか、できれば奇数が必要ですが、確かに1以上です。これは、クォーラムのレベルによるものです。特定の時点でアクティブなマスター（リーダー）は、1台のサーバーのみです。

メソス奴隷

タスクを実行するパワーを提供するサービス（ノード）。タスクは、独自のMesosコンテナとDockerの両方で実行できます。

フレームワーク

Mesos自体はクラスターの「中心」にすぎず、タスクの作業（実行）のための環境のみを提供します。タスクの起動、作業の監視、スケーリングなどのロジック全体。フレームワークを実行します。 Linuxと同様に、これはプロセスを開始するためのinit / upstartシステムです。恒久的なタスク（サーバーの長期運用など）または短期タスクを実行するように設計されたMarathonフレームワークの作業を検討します。スケジュールに従ってタスクを実行するには、別のフレームワーク-Chronos （cronに似ています）を使用する必要があります。

一般に、かなり多数のフレームワークがあり、ここで最も有名なものがあります。

Aurora （スケジュールに従ってタスクを実行する方法、および長期タスクを実行する方法を知っています）。 Twitterによって開発されました。

Hadoop

ジェンキンス

スパーク

トルク

飼育係

Mesos Mastersノードの調整を担当するデーモン。彼は定足数を持つマスターの選挙を開催します。クラスタの他のノードは、タイプzk：// master-node1：2138、master-node2：2138、master-node3：2138 / mesosのノードのzookeeperグループを要求することにより、現在のマスターのアドレスを受け取ります。同様に、Mesos Slavesも同様の要求を使用して、現在のマスターにのみ接続します。チュートリアルでは、これらはMesosマスターのあるノードにもインストールされますが、別々に存在することもできます。

この記事は、より実用的です：私の後に繰り返すと、出力で動作するMesosクラスターを取得することもできます。

将来のノードでは、次のアドレスを選択しました。

mesos-master1 10.0.3.11 mesos-master2 10.0.3.12 mesos-master3 10.0.3.13 --- mesos-slave1 10.0.3.51 mesos-slave2 10.0.3.52 mesos-slave3 10.0.3.53

つまり 3つのマスターと3つのスレーブ。マスターにはMarathonフレームワークもあり、必要に応じて別のノードに配置できます。

テスト段階では、ハードウェア仮想化プラットフォーム（VirtualBox、XEN、KVM）で実行されている仮想マシンを選択することをお勧めします。たとえば、DockerをLXCコンテナーにインストールすることは、まだ非常に困難であるためです。 Dockerを使用して、Mesosスレーブで実行されているタスクを分離します。

したがって、Ubuntu 14.04を備えた6つの既製サーバー（仮想マシン）があれば、戦いの準備ができています。

MESOS MASTERS / MARATHONのインストール

3つのMesosマスターサーバーすべてで、まったく同様のアクションを実行します。

 apt-get install software-properties-common

Mesos / Marathonリポジトリを追加します。

 apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E56151BF DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') CODENAME=$(lsb_release -cs) echo "deb http://repos.mesosphere.com/${DISTRO} ${CODENAME} main" | \ sudo tee /etc/apt/sources.list.d/mesosphere.list

MesosとMarathonを使用するには、Javaマシンが必要です。したがって、後者をOracleからインストールします。

 add-apt-repository ppa:webupd8team/java apt-get update apt-get install oracle-java8-installer

Javaが機能するかどうかを確認します。

 java -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

OpenJDKも適しているようですが。

将来のマスターのそれぞれに対して、MesosとMarathonをインストールします。

 apt-get -y install mesos marathon

ところで、MarathonフレームワークはScalaで書かれています。

依存関係により、Zookeeperもインストールされます。彼にマスターノードのアドレスを提供します。

 vim /etc/mesos/zk zk://10.0.3.11:2181,10.0.3.12:2181,10.0.3.13:2181/mesos

2181 -Zookeeperが機能するポート。

ウィザードの各ノードに対して、一意のIDを選択します。

 vim /etc/zookeeper/conf/myid 1

2番目と3番目のサーバーでは、それぞれ2と3を選択しました。番号は1〜255から選択できます。

/etc/zookeeper/conf/zoo.cfgの編集：

 vim /etc/zookeeper/conf/zoo.cfg server.1 = 10.0.3.11:2888:3888 server.2 = 10.0.3.12:2888:3888 server.3 = 10.0.3.13:2888:3888

1,2,3-各サーバーの/ etc / zookeeper / conf / myidで指定したID。

2888は、Zookeeperを使用して選択されたマスターと通信するポートであり、 3888は、現在のマスターに何かが発生した場合の新しい選挙用です。

クォーラムの設定に移りましょう。クォーラムは、新しいリーダーを選択するために必要な作業ノードの最小数です。このオプションは、スプリットブレインクラスターを防ぐために必要です。クラスターが2つのサーバーで構成され、クォーラムが1であるとします。この場合、新しいリーダーを選択するには、稼働中のサーバーが1つあれば十分です。実際、各サーバーは独自のリーダーを選択できます。サーバーの1つがクラッシュした場合、この動作は論理的ではありません。ただし、それらの間のネットワーク接続のみが切断された場合はどうなりますか？そうです：おそらく、各サーバーがメイントラフィックをそれ自体にプルするオプションです。このようなクラスターがデータベースで構成されている場合、参照データが失われる可能性があり、回復する理由さえ明確ではありません。

したがって、高可用性を確保するには、3台のサーバーが最低限必要です。この場合のクォーラム値は2です。1台のサーバーのみが使用できなくなると、残りの2台は自分の中から誰かを選択できます。 2つのサーバーが故障している場合、またはノードがネットワーク上で相互に認識されていない場合、データの安全性のために、グループは必要なクォーラムに達するまで新しいマスターの選択をまったく行いません（サーバーの1つがネットワークに表示されます）。

4（偶数）台のサーバーを選択するのがあまり意味がないのはなぜですか？この場合、3台のサーバーの場合のように、クラスターが機能するために重要なのは1台のサーバーがないだけです。2番目のサーバーの落下は、スプリットブレインの可能性があるため、クラスターにとって致命的です。ただし、5台のサーバー（およびクォーラムレベル3）の場合、2台のサーバーの低下は重要ではありません。行くぞしたがって、5つ以上のノードを持つクラスターを選択し、そのうちの1つでメンテナンス中に何が起こるかを誰が知っているのが最善です。

Zookeeperが個別に発行される場合、Mesosマスターを含むことができます。そして、倍、量。

マスターに同じクォーラムレベルを指定します。

 echo "2" > /etc/mesos-master/quorum

各ノードにそれぞれIPを指定します。

 echo 10.0.3.11 | tee /etc/mesos-master/ip

サーバーにドメイン名がない場合は、IPアドレスをコピーしてホスト名として使用します。

 cp /etc/mesos-master/ip /etc/mesos-master/hostname

10.0.3.12および10.0.3.13についても同様です。

Marathonフレームワークをカスタマイズします。構成ファイル用のディレクトリを作成し、ホスト名をその中にコピーします。

 mkdir -p /etc/marathon/conf cp /etc/mesos-master/hostname /etc/marathon/conf

MarathonのZookeeper設定をコピーします。

 cp /etc/mesos/zk /etc/marathon/conf/master cp /etc/marathon/conf/master /etc/marathon/conf/zk

最後のいくつかを編集します。

 vim /etc/marathon/conf/zk zk://10.0.3.11:2181,10.0.3.12:2181,10.0.3.13:2181/marathon

最後に、ウィザードでのmesos-slaveデーモンのダウンロードを禁止します。

 echo manual | sudo tee /etc/init/mesos-slave.override stop mesos-slave

すべてのノードでサービスを再起動します。

 restart mesos-master restart marathon

ポート5050でMesos Webパネルを開きます。

別のサーバーがリーダーとして選択された場合、別のサーバーへのリダイレクトが行われます。

Marathonには素敵な暗いインターフェイスがあり、ポート8080で動作します。

MESOSスレーブのインストール

Mesosウィザードのインストールに関しては、リポジトリを追加し、必要なパッケージをインストールします。

 apt-get install software-properties-common apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv E56151BF DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') CODENAME=$(lsb_release -cs) echo "deb http://repos.mesosphere.com/${DISTRO} ${CODENAME} main" | \ tee /etc/apt/sources.list.d/mesosphere.list add-apt-repository ppa:webupd8team/java apt-get update apt-get install oracle-java8-installer

Javaが正しくインストールされているかどうかを確認します。

 java -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

また、ZookeeperおよびMesos-masterプロセスの起動を禁止する必要もあります。ここでは必要ありません。

 echo manual | sudo tee /etc/init/zookeeper.override echo manual | sudo tee /etc/init/mesos-master.override stop zookeeper stop mesos-master

スレーブのドメインとIPアドレスを指定します。

 echo 10.0.3.51 | tee /etc/mesos-slave/ip cp /etc/mesos-slave/ip /etc/mesos-slave/hostname

10.0.3.52および10.0.3.53についても同様のアクションを実行する必要があります（もちろん、サーバーごとに個別のアドレスを使用します）。

そして/ etc / mesos / zkのすべてのウィザードを説明してください：

 vim /etc/mesos/zk zk://10.0.3.11:2181,10.0.3.12:2181,10.0.3.13:2181/mesos

スレーブは、時折、現在のリーダーのテーマについてZookeeperに問い合わせて、彼に接続し、リソースを提供します。

スレーブの起動中に、次のエラーが発生する場合があります。

 Failed to create a containerizer: Could not create MesosContainerizer: Failed to create launcher: Failed to create Linux launcher: Failed to mount cgroups hierarchy at '/sys/fs/cgroup/freezer': 'freezer' is already attached to another hierarchy

この場合、 / etc / default / mesos-slaveを変更する必要があります。

 vim /etc/default/mesos-slave ... MESOS_LAUNCHER=posix ...

そして、mesos-slaveを再度実行します。

 start mesos-slave

すべてが正しく行われると、スレーブは現在のリーダーのリソースとして接続します。

クラスターの準備ができました！ Marathonで何らかのタスクを実行します。これを行うには、マスターノードでMarathonを開き、青い[ アプリケーションの作成 ]ボタンをクリックして、図のようにすべてを入力します。

タスクが完了し始めました：

フレームワークが設定したアクティブなタスクと完了したタスクの履歴は、Mesos Webパネルにすぐに表示されます。実際には、このタスクは短期的であるため、このタスクが完了して再び開始されます。これが、 完了したタスクがすべての古いタスクの完全なリストを提供する理由です。

Marathon APIを使用して同じタスクを実行し、JSON形式で記述できます。

 cd /tmp vim hello2.json { "id": "hello2", "cmd": "echo hello; sleep 10", "mem": 16, "cpus": 0.1, "instances": 1, "disk": 0.0, "ports": [0] }

 curl -i -H 'Content-Type: application/json' -d@hello2.json 10.0.3.11:8080/v2/apps HTTP/1.1 201 Created Date: Tue, 21 Jun 2016 14:21:31 GMT X-Marathon-Leader: http://10.0.3.11:8080 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Location: http://10.0.3.11:8080/v2/apps/hello2 Content-Type: application/json; qs=2 Transfer-Encoding: chunked Server: Jetty(9.3.z-SNAPSHOT) {"id":"/hello2","cmd":"echo hello; sleep 10","args":null,"user":null,"env":{},"instances":1,"cpus":0.1,"mem":16,"disk":0,"executor":"","constraints":[],"uris":[],"fetch":[],"storeUrls":[],"ports":[0],"portDefinitions":[{"port":0,"protocol":"tcp","labels":{}}],"requirePorts":false,"backoffSeconds":1,"backoffFactor":1.15,"maxLaunchDelaySeconds":3600,"container":null,"healthChecks":[],"readinessChecks":[],"dependencies":[],"upgradeStrategy":{"minimumHealthCapacity":1,"maximumOverCapacity":1},"labels":{},"acceptedResourceRoles":null,"ipAddress":null,"version":"2016-06-21T14:21:31.665Z","residency":null,"tasksStaged":0,"tasksRunning":0,"tasksHealthy":0,"tasksUnhealthy":0,"deployments":[{"id":"13bea032-9120-45e7-b082-c7d3b7d0ad01"}],"tasks":[]}%

この（および前の）例では、helloが表示され、その後10秒の遅延があり、これらすべてが円で囲まれています。タスクには16MBのメモリと0.1 CPUが割り当てられます。

実行中のタスクの出力を確認するには、現在のMesosウィザードのメインパネルの最後の列にある[ サンドボックス]リンクをクリックします。

ドッカー

より優れた分離レベルと追加機能のために、DockerサポートがMesosに統合されました。誰が彼に慣れていない-最初にそれを行うことをお勧めします。

MesosでDockerをアクティブにすることも大したことではありません。最初に、クラスターのすべてのスレーブにDocker自体をインストールする必要があります。

 apt-get install apt-transport-https ca-certificates apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D echo "deb https://apt.dockerproject.org/repo ubuntu-precise main" | tee /etc/apt/sources.list.d/docker.list apt-get update apt-get install docker-engine

インストールを確認するには、テストコンテナーhello-worldを実行します。

 docker run hello-world

Mesosスレーブの新しいコンテナ化タイプを指定します。

 echo "docker,mesos" | sudo tee /etc/mesos-slave/containerizers

まだローカルキャッシュにない新しいコンテナの作成には時間がかかる場合があります。したがって、フレームワークに新しいコンテナを登録するためのタイムアウトの値を上げます。

 echo "5mins" | sudo tee /etc/mesos-slave/executor_registration_timeout

さて、いつものように、このような変更の後にサービスをリロードします。

 service mesos-slave restart

Marathonで新しいタスクを作成し、Dockerコンテナーで実行します。 JSONは次のようになります。

 vim /tmp/Docker.json { "container": { "type": "DOCKER", "docker": { "image": "libmesos/ubuntu" } }, "id": "ubuntu", "cpus": 0.5, "mem": 128, "uris": [], "cmd": "while sleep 10; do date -u +%T; done" }

つまり、現在の日付の出力を使用して、コンテナー内で永遠のwhileループが起動されます。簡単ですね。

Docker.jsonは、新しいタスクを作成するときにJSONスイッチをアクティブにすることで、Marathon Webパネルから直接注ぐことができます。

または、オプションで個別のフィールドにデータを入力します。

しばらくすると、インターネット接続の速度に応じて、コンテナが起動します。その存在は、実行タスクを受け取ったMesosスレーブで確認できます。

 root@mesos-slave1:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 81f39fc7474a libmesos/ubuntu "/bin/sh -c 'while sl" 2 minutes ago Up 2 minutes mesos-4e1e9267-ecf7-4b98-848b-f9a7a30ad209-S2.5c1831a6-f856-48f9-aea2-74e5cb5f067f root@mesos-slave1:~#

もう少し複雑なMarathonタスクを作成しましょう。すでにヘルスチェックがあります。コンテナの検証が不十分な場合、フレームワークによって後者が再作成されます。

 { "cmd": "env && python3 -m http.server $PORT0", "container": { "docker": { "image": "python:3" }, "type": "DOCKER" }, "cpus": 0.25, "healthChecks": [ { "gracePeriodSeconds": 3, "intervalSeconds": 10, "maxConsecutiveFailures": 3, "path": "/", "portIndex": 0, "protocol": "HTTP", "timeoutSeconds": 5 } ], "id": "python-app", "instances": 2, "mem": 50, "ports": [ 0 ], "upgradeStrategy": { "minimumHealthCapacity": 0.5 } }

これで、2つのpython-appインスタンス、つまりポート転送を備えた2つのPython Webサーバーが起動します。

Marathon Webパネルからも追加します。

これで、Marathonパネルで、動作チェックのインスタンスがあることがわかります。

Mesos-masterには新しい長期タスクがあります：

また、実行するように設定されているフレームワークを確認することもできます。

しかし、新しいPython Webサーバーに割り当てられているポートをどのようにして知るのでしょうか？いくつかの方法があり、そのうちの1つはMarathon APIへのリクエストです。

 curl -X GET -H "Content-Type: application/json" 10.0.3.12:8080/v2/tasks | python -m json.tool ... { ... { "appId": "/python-app", "healthCheckResults": [ { "alive": true, "consecutiveFailures": 0, "firstSuccess": "2016-06-24T10:35:20.785Z", "lastFailure": null, "lastFailureCause": null, "lastSuccess": "2016-06-24T12:53:31.372Z", "taskId": "python-app.53d6ccef-39f7-11e6-a2b6-0800272ca725" } ], "host": "10.0.3.51", "id": "python-app.53d6ccef-39f7-11e6-a2b6-0800272ca725", "ipAddresses": [ { "ipAddress": "10.0.3.51", "protocol": "IPv4" } ], "ports": [ 31319 ], "servicePorts": [ 10001 ], "slaveId": "4e1e9267-ecf7-4b98-848b-f9a7a30ad209-S2", "stagedAt": "2016-06-24T10:35:10.767Z", "startedAt": "2016-06-24T10:35:11.788Z", "version": "2016-06-24T10:35:10.702Z" }, { "appId": "/python-app", "healthCheckResults": [ { "alive": true, "consecutiveFailures": 0, "firstSuccess": "2016-06-24T10:35:20.789Z", "lastFailure": null, "lastFailureCause": null, "lastSuccess": "2016-06-24T12:53:31.371Z", "taskId": "python-app.53d6a5de-39f7-11e6-a2b6-0800272ca725" } ], "host": "10.0.3.52", "id": "python-app.53d6a5de-39f7-11e6-a2b6-0800272ca725", "ipAddresses": [ { "ipAddress": "10.0.3.52", "protocol": "IPv4" } ], "ports": [ 31307 ], "servicePorts": [ 10001 ], "slaveId": "4e1e9267-ecf7-4b98-848b-f9a7a30ad209-S2", "stagedAt": "2016-06-24T10:35:10.766Z", "startedAt": "2016-06-24T10:35:11.784Z", "version": "2016-06-24T10:35:10.702Z" } ] }

アドレスhttp://10.0.3.52:31307およびhttp://10.0.3.51 { 1319の新しく作成されたサーバーは、接続を待機します。

同様に、ポート番号はMarathonパネルで確認できます。

エンドホスト上の新しいコンテナ：

 root@mesos-slave1:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d5e439d61456 python:3 "/bin/sh -c 'env && p" 2 hours ago Up 2 hours mesos-4e1e9267-ecf7-4b98-848b-f9a7a30ad209-S2.150ac995-bf3c-4ecc-a79c-afc1c617afe2 ... root@mesos-slave2:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1fa55f8cb759 python:3 "/bin/sh -c 'env && p" 2 hours ago Up 2 hours mesos-4e1e9267-ecf7-4b98-848b-f9a7a30ad209-S2.9392fec2-23c1-4c05-a576-60e9350b9b20 ...

新しいMarathonジョブごとに静的ポートを指定することもできます。これは、 ブリジットネットワークモードを通じて実装されます。タスクを作成するための正しいJSONは次のようになります。

 { "id": "bridged-webapp", "cmd": "python3 -m http.server 8080", "cpus": 0.5, "mem": 64, "disk": 0, "instances": 1, "container": { "type": "DOCKER", "volumes": [], "docker": { "image": "python:3", "network": "BRIDGE", "portMappings": [ { "containerPort": 8080, "hostPort": 31240, "servicePort": 9000, "protocol": "tcp", "labels": {} }, { "containerPort": 161, "hostPort": 31241, "servicePort": 10000, "protocol": "udp", "labels": {} } ], "privileged": false, "parameters": [], "forcePullImage": false } }, "healthChecks": [ { "path": "/", "protocol": "HTTP", "portIndex": 0, "gracePeriodSeconds": 5, "intervalSeconds": 20, "timeoutSeconds": 20, "maxConsecutiveFailures": 3, "ignoreHttp1xx": false } ], "portDefinitions": [ { "port": 9000, "protocol": "tcp", "labels": {} }, { "port": 10000, "protocol": "tcp", "labels": {} } ] }

したがって、コンテナ8080 （containerPort）のtcpポートは、スレーブマシンのポート31240 （hostPort）に転送されます。同様にudp- 31241の 161番目 。もちろん、この場合、udp転送を行う理由はまったくなく、この機能は例としてのみ提供されています。

MESOS-DNS

明らかに、IPアドレスへのアクセスは完全に便利というわけではありません。さらに、タスクを含む次の各コンテナが起動されるスレーブがランダムに選択されます。したがって、DNS名をコンテナに自動的にバインドできるようにすることは場違いではありません。

Mesos-DNSはこれに役立ちます。これはMesosクラスターのDNSサーバーです。MesosウィザードAPIを使用して、実行中のタスクの名前と、タスクが実行されているスレーブのIPアドレスを取得します。

デフォルトのドメイン名は、Mesosのタスク名+ .marathon.mesosのように形成されます。 MESOS-DNSはこのゾーンのみに対応し、他のすべては標準のDNSサーバーにリダイレクトされます。

Mesos-DNSはGoで記述され、既製のコンパイル済みバイナリとして配布されます。理想的には、initまたはsystemdスクリプト（ディストリビューションのバージョンに応じて）を記述する必要がありますが、ネットワークhttps://github.com/mesosphere/mesos-dns-pkg/tree/master/commonには既成の推奨事項があります。

Mesos-DNSをテストするために、アドレス10.0.3.60の別のサーバーを作成しましたが、Marathonを使用して同じ成功を収めることができます。

最新のMesos-DNSリリースを新しいサーバーの/ usr / sbinディレクトリにダウンロードし、バイナリの名前を変更します。

 cd /usr/sbin wget https://github.com/mesosphere/mesos-dns/releases/download/v0.5.2/mesos-dns-v0.5.2-linux-amd64 mv mesos-dns-v0.5.2-linux-amd64 mesos-dns chmod +x mesos-dns

構成ファイルを作成します。

 vim /etc/mesos-dns/config.json { "zk": "zk://10.0.3.11:2181,10.0.3.12:2181,10.0.3.13:2181/mesos", "masters": ["10.0.3.11:5050","10.0.3.12:5050","10.0.3.13:5050"], "refreshSeconds": 60, "ttl": 60, "domain": "mesos", "port": 53, "resolvers": ["8.8.8.8","8.8.4.4"], "timeout": 5, "email": "root.mesos-dns.mesos" }

つまり、Mesos-DNSはZookeeper（zk）へのリクエストの助けを借りて、現在のマスターに関する情報を検索し、1分に1回の頻度（ refreshSeconds ）でポーリングします。 mesosゾーンを除く他のすべてのドメインに対するリクエストの場合、リクエストはGoogle DNSサーバー（パラメーターリゾルバー ）にリダイレクトされます。このサービスは、他のDNSサーバーと同様に、標準ポート53で機能します。

mastersパラメーターはオプションです。最初に、Mesos-DNSはZookeeperサーバーへの要求を使用してリーダーを探し、それらが利用できない場合、マスターで指定されたサーバーのリストを調べます。

すべての可能なオプションを説明する良い記事がありますhttp://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html

これで十分なので、Mesos-DNSを実行します。

 /usr/sbin/mesos-dns -config=/etc/mesos-dns/config.json 2016/07/01 11:58:23 Connected to 10.0.3.11:2181 2016/07/01 11:58:23 Authenticated: id=96155239082295306, timeout=40000

もちろん、Mesosクラスターのすべてのノード（およびコンテナーでサービスにアクセスする他のノード）にも、Mesos-DNSサーバーアドレスをメインアドレスとして/etc/resolv.confの最初の位置に追加する価値があります。

 vim /etc/resolv.conf nameserver 10.0.3.60 nameserver 8.8.8.8 nameserver 8.8.4.4

resolv.confの変更後、すべての名前が10.0.3.60で解決されることを確認する必要があります。

 dig i.ua ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> i.ua ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24579 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;i.ua. IN A ;; ANSWER SECTION: i.ua. 2403 IN A 91.198.36.14 ;; Query time: 58 msec ;; SERVER: 10.0.3.60#53(10.0.3.60) ;; WHEN: Mon Jun 27 16:20:12 CEST 2016 ;; MSG SIZE rcvd: 49

Mesos-DNSの動作を実証するには、Marathonで次のタスクを実行します。

 cat nginx.json { "id": "nginx", "container": { "type": "DOCKER", "docker": { "image": "nginx:1.7.7", "network": "HOST" } }, "instances": 1, "cpus": 0.1, "mem": 60, "constraints": [ [ "hostname", "UNIQUE" ] ] } curl -X POST -H "Content-Type: application/json" http://10.0.3.11:8080/v2/apps -d@nginx.json

このタスクは、コンテナにNginxをインストールし、 Mesos -DNSはそれに名前nginx.marathon.mesosを登録します。

 dig +short nginx.marathon.mesos 10.0.3.53

nginxタスクをスケーリングするとき（つまり、追加のインスタンスを作成するとき）、Mesos-DNSはこれを認識し、同じドメインの追加のAレコードを作成します。

 dig +short nginx.marathon.mesos 10.0.3.53 10.0.3.51

したがって、DNSレベルでの2つのノード間のバランスは機能します。

Mesos-DNSは、Aレコードに加えて、各タスク（コンテナ）のDNSにSRVレコードも作成することに注意してください。 SRVレコードは、サービスの名前とそれが利用可能なホスト名IPポートをバインドします。前に開始したnginxタスクのSRVレコードを確認します（2つのインスタンスにスケーラブルではありません）：

 dig _nginx._tcp.marathon.mesos SRV ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> _nginx._tcp.marathon.mesos SRV ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11956 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;_nginx._tcp.marathon.mesos. IN SRV ;; ANSWER SECTION: _nginx._tcp.marathon.mesos. 60 IN SRV 0 0 31514 nginx-9g7b9-s0.marathon.mesos. ;; ADDITIONAL SECTION: nginx-9g7b9-s0.marathon.mesos. 60 IN A 10.0.3.51 ;; Query time: 2 msec ;; SERVER: 10.0.3.60#53(10.0.3.60) ;; WHEN: Fri Jul 01 12:03:37 CEST 2016 ;; MSG SIZE rcvd: 124

各サーバーのresolv.conf設定を変更しないために、内部DNSインフラストラクチャを変更できます。 Bind9の場合、これらの変更は次のようになります。

 vim /etc/bind/named.conf.local zone "mesos" { type forward; forward only; forwarders { 192.168.0.100 port 8053; }; };

また、Mesos-DNS構成（現在192.168.0.100にあることを想像してください）で、次の変更を行う必要があります。

 vim /etc/mesos-dns/config.json ... "externalon": false, "port": 8053, ...

"externalon"：falseは、Mesos-DNSがmesosドメインから来ていない要求に対するサービスを拒否する権利を持っていることを示します。

変更後、バインドとMesos-DNSを再起動する必要があります。

Mesos-DNSには、自動化の問題を解決するのに役立つAPI https://docs.mesosphere.com/1.7/usage/service-discovery/mesos-dns/http-interface/もあります。

Mesos-DNSは、作業タスクのレコードの作成に加えて、Mesosスレーブ、Mesosマスター（およびそれらの間のリーダー用）、フレームワークのレコード（AおよびSRV）を自動的に作成します。すべて私たちの便宜のため。

マラソンLB

利点にもかかわらず、Mesos-DNSには次のような特定の制限もあります。

DNSは、コンテナでサービスが実行されているポートにバインドしません。タスクを設定するときに静的に選択する必要があります（その使用を監視することはそれほど簡単なタスクではない場合があります）。 Mesos-DNSは、DNSでSRVレコード（最終的なホスト名とポートを示す）を生成することもできますが、すべてのプログラムがそのまま使用できるわけではありません。
DNSにはクイックフェールオーバー（フェールオーバー機能）はありません。
ローカルDNSキャッシュ内のレコードは、長時間（少なくともTTL時間）保存できます。 Mesos-DNS自体はMesos Master APIを頻繁にポーリングしますが。
最終コンテナ内のサービスのヘルスチェックチェックはありません。つまり、複数のインスタンスの場合、Marsonフレームワークによって完全に再作成されるまで、Mesos-DNSの1つのインスタンスの落下は見過ごされます。
一部のプログラムおよびライブラリは、複数のAレコードで正しく動作しないため、スケーリングタスクに重大な制限が課されます。

つまり、ほとんどの問題はDNSの性質が原因で発生します。

Marathon-lbサブプロジェクトが開始されたのは、これらの欠点を解消するためでした。 Marathon-lbは、Marathon APIをポーリングし、HAproxy構成ファイルを作成し、受信したデータ（コンテナーが物理的に配置され、サービスポートがあるMesosスレーブのアドレス）に基づいてプロセスをリロードするPythonスクリプトです。

ただし、Meathos-DNSとは異なり、Marathon-lbはMarathonでのみ機能することに注意してください。したがって、別のフレームワークの場合、他のソフトウェアソリューションを探す必要があります。

この図は、内部（内部ネットワークからのアクセス用）および外部（インターネットからのアクセス用）の2つのバランサープールによる要求のバランスを示しています。バランサー（ELBを除く）はHAproxyおよびMarathon-lbです。ELBは、Amazon AWSインフラストラクチャのバランサーです。

Marathon-lbを構成するために、アドレス10.0.3.61を持つ別の仮想マシンを使用しました。公式ドキュメントには、Marathonから起動されたタスクとして、DockerコンテナでMarathon-lbを起動するオプションも示されています。

Marathon-lbとHAproxyのセットアップは難しくありません。HAproxyの最新の安定したリリースが必要です。Ubuntu14.04の場合、これはバージョン1.6です。

 apt-get install software-properties-common add-apt-repository ppa:vbernat/haproxy-1.6 apt-get update apt-get install haproxy

Marathon-lb:

 mkdir /marathon-lb/ cd /marathon-lb/ git clone https://github.com/mesosphere/marathon-lb .

python-:

 apt install python3-pip pip install -r requirements.txt

, - marathon-lb:

 cd /etc/ssl openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes cat key.pem >> mesosphere.com.pem cat cert.pem >> mesosphere.com.pem

marathon-lb:

 /marathon-lb/marathon_lb.py --marathon http://my_marathon_ip:8080 --group internal

— Marathon:

 { "id": "nginx-internal", "container": { "type": "DOCKER", "docker": { "image": "nginx:1.7.7", "network": "BRIDGE", "portMappings": [ { "hostPort": 0, "containerPort": 80, "servicePort": 10001 } ], "forcePullImage":true } }, "instances": 1, "cpus": 0.1, "mem": 65, "healthChecks": [{ "protocol": "HTTP", "path": "/", "portIndex": 0, "timeoutSeconds": 10, "gracePeriodSeconds": 10, "intervalSeconds": 2, "maxConsecutiveFailures": 10 }], "labels":{ "HAPROXY_GROUP":"internal" } }

Running , Marathon:

 /marathon-lb/marathon_lb.py --marathon http://10.0.3.11:8080 --group internal marathon_lb: fetching apps marathon_lb: GET http://10.0.3.11:8080/v2/apps?embed=apps.tasks marathon_lb: got apps ['/nginx-internal'] marathon_lb: setting default value for HAPROXY_BACKEND_REDIRECT_HTTP_TO_HTTPS ... marathon_lb: setting default value for HAPROXY_BACKEND_HTTP_HEALTHCHECK_OPTIONS marathon_lb: generating config marathon_lb: HAProxy dir is /etc/haproxy marathon_lb: configuring app /nginx-internal marathon_lb: frontend at *:10001 with backend nginx-internal_10001 marathon_lb: adding virtual host for app with id /nginx-internal marathon_lb: backend server 10.0.3.52:31187 on 10.0.3.52 marathon_lb: reading running config from /etc/haproxy/haproxy.cfg marathon_lb: running config is different from generated config - reloading marathon_lb: writing config to temp file /tmp/tmp02nxplxl marathon_lb: checking config with command: ['haproxy', '-f', '/tmp/tmp02nxplxl', '-c'] Configuration file is valid marathon_lb: moving temp file /tmp/tmp02nxplxl to /etc/haproxy/haproxy.cfg marathon_lb: No reload command provided, trying to find out how to reload the configuration marathon_lb: we seem to be running on a sysvinit based system marathon_lb: reloading using /etc/init.d/haproxy reload * Reloading haproxy haproxy marathon_lb: reload finished, took 0.02593827247619629 seconds

"HAPROXY_GROUP" . , .

haproxy.cfg 10001 10.0.3.52:31187 .

HAproxy :

 root@mesos-lb# netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... tcp 0 0 0.0.0.0:10001 0.0.0.0:* LISTEN 10285/haproxy ...

haproxy.cfg :

 cat /etc/haproxy/haproxy.cfg ... frontend nginx-internal_10001 bind *:10001 mode http use_backend nginx-internal_10001 backend nginx-internal_10001 balance roundrobin mode http option forwardfor http-request set-header X-Forwarded-Port %[dst_port] http-request add-header X-Forwarded-Proto https if { ssl_fc } option httpchk GET / timeout check 10s server 10_0_3_52_31187 10.0.3.52:31187 check inter 2s fall 11

, 2 Marathon — 2 nginx-internal_10001 .

, — . — virtual host mapping HAproxy. , HAproxy, .

 { "Id": "nginx-external", "Container" { "Type": "DOCKER", "Docker" { "Image": "nginx: 1.7.7", "Network": "BRIDGE", "PortMappings": [ { "HostPort": 0, "containerPort": 80, "servicePort" 10000} ], "ForcePullImage": true } } "Instances": 1, "Cpus": 0.1, "Mem": 65, "HealthChecks": [{ "Protocol": "HTTP", "Path": "/", "PortIndex": 0, "TimeoutSeconds": 10 "GracePeriodSeconds": 10 "IntervalSeconds": 2, "MaxConsecutiveFailures": 10 }], "Labels" { "HAPROXY_GROUP": "external", "HAPROXY_0_VHOST": "nginx.external.com" } }

, " HAPROXY_0_VHOST " , HAproxy.

, marathon_lb.py:

 /marathon-lb/marathon_lb.py --marathon Http://10.0.3.11:8080 --group external marathon_lb: fetching apps marathon_lb: GET http://10.0.3.11:8080/v2/apps?embed=apps.tasks marathon_lb: got apps [ '/ nginx-internal', '/ nginx-external'] marathon_lb: setting default value for HAPROXY_HTTP_FRONTEND_ACL_WITH_AUTH ... marathon_lb: generating config marathon_lb: HAProxy dir is / etc / haproxy marathon_lb: configuring app / nginx-external marathon_lb: frontend at * 10000 with backend nginx-external_10000 marathon_lb: adding virtual host for app with hostname nginx.external.com marathon_lb: adding virtual host for app with id / nginx-external marathon_lb: backend server 10.0.3.53:31980 on 10.0.3.53 marathon_lb: reading running config from /etc/haproxy/haproxy.cfg marathon_lb: running config is different from generated config - reloading marathon_lb: writing config to temp file / tmp / tmpcqyorq8x marathon_lb: checking config with command: [ 'haproxy "," -f "," / tmp / tmpcqyorq8x "," -c'] Configuration file is valid marathon_lb: moving temp file / tmp / tmpcqyorq8x to /etc/haproxy/haproxy.cfg marathon_lb: No reload command provided, trying to find out how to reload the configuration marathon_lb: we seem to be running on a sysvinit based system marathon_lb: reloading using /etc/init.d/haproxy reload * Reloading haproxy haproxy marathon_lb: reload finished, took 0.02756667137145996 seconds

HAproxy:

 cat /etc/haproxy/haproxy.cfg ... frontend marathon_http_in bind * 80 mode http acl host_nginx_external_com_nginx-external hdr (host) -i nginx.external.com use_backend nginx-external_10000 if host_nginx_external_com_nginx-external frontend marathon_http_appid_in bind *: 9091 mode http acl app__nginx-external hdr (x-marathon-app-id) -i / nginx-external use_backend nginx-external_10000 if app__nginx-external frontend marathon_https_in bind * 443 ssl crt /etc/ssl/mesosphere.com.pem mode http use_backend nginx-external_10000 if {ssl_fc_sni nginx.external.com} frontend nginx-external_10000 bind * 10000 mode http use_backend nginx-external_10000 backend nginx-external_10000 balance roundrobin mode http option forwardfor http-request set-header X-Forwarded-Port% [dst_port] http-request add-header X-Forwarded-Proto https if {ssl_fc} option httpchk GET / timeout check 10s server 10_0_3_53_31980 10.0.3.53:31980 check inter 2s fall 11

したがって、nginx.external.comドメインが要求された場合、最初にHAproxyサーバーにバインドする必要があり、要求はMesosスレーブ上のタスクのポートとホストにリダイレクトされます。

ブラウザで結果を確認します。

HAproxyショートカットはMarathonにも反映されます：

さらに、Marathon-lbはHAproxy、sticky SSLのSSL設定をサポートし、haproxy.cfgを構築するためのデータは通常、MarathonのAPIポーリングではなく、Event Busなどにサブスクライブすることで取得できます。

自動スケーリング

Amazon AWSプラットフォームで作業している人は誰でも、負荷に応じて仮想マシンの数を増減できるこの絶好の機会を知っています。Mesos Clusterにもこの機能があります。

— marathon-autoscale . API Marathon CPU/ .