Clever Geek Handbook

5分でクラウドホスティングを所有できます。 パート2：サービスの発見

クラウドホスティング



こんにちはHabr！ 前の記事で、 Ansible 、 Docker 、 Docker Swarmを使用して5分でクラウドホスティングを構築する方法について説明しました。 このパートでは、クラウドで実行されているサービスがお互いを見つける方法、サービス間のロードバランシングが発生する方法、およびそれらのフォールトトレランスが保証される方法について説明します。



これは入門記事です。ここでは、クラウド内の「サービスの発見」の問題を解決するツールのレビューに焦点を当てます。 次のパートでは、練習を開始するので、それらをよりよく知るための時間をあなたに与えることにしました。



内容





問題



最も一般的な問題とその一般的な解決策を見てみましょう-Webアプリケーションがあり、負荷分散とフォールトトレランスを確保する必要があります。



Supervisorが監視するWebアプリケーションのコピーをいくつか実行できます。 スーパーバイザーは、エラーが発生するとWebアプリケーションを再起動し、そのようなイベントをログに追加します。 負荷分散の問題は、 Nginxをインストールすることで解決されます。 Nginxの構成は次のようになります。 



upstream app { server 192.168.1.2:8080 max_fails=3 fail_timeout=5s; server 192.168.1.2:8081 max_fails=3 fail_timeout=5s; server 192.168.1.2:8082 max_fails=3 fail_timeout=5s; } server { location / { proxy_pass http://app; health_check; } }


指定された構成は次のように機能します.5秒以内にWebアプリケーションの1つにアクセスしたときに失敗した試行回数が3に達すると、そのようなアプリケーションは5秒間動作不能としてマークされます（ エラーでクラッシュした場合、スーパーバイザーは再起動します ）。 したがって、負荷全体は、アプリケーションの作業コピー間でのみ均等に分散されます。



欠点



これは実際には適切な構成であり、アプリケーションがほとんどなく、負荷がほぼ均一である場合は、それを使用することをお勧めします。



ただし、このアプリケーションまたはそのアプリケーションを起動するクラウドを構築しています-わかりません。 負荷はサイト/ウェブアプリケーションごとに異なる場合があるため、状況に応じてアプリケーションの実行中のコピーの数を変更できると便利です。 言い換えれば、そのような構成のために事前にNginx / Apache /などを構成することはできません。



Nginxと他のサービスがクラウドの動的な性質に適応した場合、それはクールです。 この記事では、この特定の問題に対処します。



必要条件



サービスが自分自身を登録し、相互の情報を受信できる場所が必要です。 前回の記事で使用を開始したDocker Swarmは 、 etcd 、 Consul、およびZookeeperをそのまま使用できます。



上記のシステムからサービスを自動的に登録および削除する必要があります（ すべてのアプリケーションにこれを教えるわけではありません ）。 これらの目的のために、 Consul 、 etcd 、およびSkyDNS 2 （ Zookeeperのサポートが計画されています ）ですぐに使用できるRegistratorを使用します（ 以下で詳細に検討します）。



私たちのサービスは、DNSクエリを使用してお互いを見つけることができるはずです。 このタスクはConsulおよびSkyDNS 2 （ etcd と連携して動作します）で解決できます。



サービスの状態を監視することも必要です。 Consul （ これから使用します ）で「すぐに」 利用でき 、登録者によってサポートされています （ 特定のサービスの監視方法に関する情報を送信する必要があります ）。



最後になりましたが、コンポーネントを自動的に構成するサービスが必要です。 1つのWebアプリケーションのコピーを10個、別のWebアプリケーションのコピーを20個起動した場合、これを理解してすぐに応答する必要があります （ たとえば、Nginxの構成を変更する ）。 この役割は、Consulテンプレートによって実行されます（ 以下で詳細に検討します ）。



ご注意
ご覧のとおり、私たちの問題にはさまざまな解決策があります。 この記事を書く前に、私は1か月以上にわたって構成に取り組んでおり、問題は発生しませんでした。



領事



領事



上記のオプション（ Consul 、 Zookeeper 、 etcd ）のうち、 Consulは最も独立したプロジェクトであり、 すぐに使用できるサービスを見つけるという問題を解決できます。



Consul 、 Zookeeper 、 etcdは同じ列にあるという事実にもかかわらず、私はそれらを互いに比較しません。 3つのプロジェクトはすべて分散キー/バリューストレージを実装しており、ここで共通の機能が終了します。



Consulは、 ZookeeperやetcdにないDNSサーバーを提供します（ SkyDNS 2を使用して追加できます ）。 さらに、 Consulは、ヘルスモニタリング（ etcdもZookeeperも自慢できない ）を提供します。これは、完全なService Discoveryにも必要です。



Consulのロードでは、 Web UI （そのデモを見ることができます ）と高品質の公式ドキュメントを入手できます 。



ご注意
私が説明したのと同じ構成を使用する予定であり、 Zookeeperを使用し、 SkyDNS 2が計画に含まれていない場合でも、これらのプロジェクトに精通します。



登録者



登録者



登録者は、コンテナの開始/停止に関する情報を（ Docker APIを使用したソケット接続を介して） Dockerから受け取り、 Consul 'aに追加/削除します。



登録者は、公開されたポートに基づいて、 Dockerコンテナの環境変数から特定のサービスに関する情報を自動的に受け取ります。 つまり、これは所有しているすべてのコンテナーで機能し、自動的に受信したパラメーターをオーバーライドする必要がある場合にのみ追加の構成が必要です。



また、すべてのサービスはDockerコンテナー（ 登録者自身を含む ）でのみ機能するため、 Consulはクラウドで実行中のすべてのサービスに関する情報を常に保持します。



もちろんこれはすべてクールですが、さらにクールなのは、 登録者がConsulにサービスの状態を確認する方法を伝えることができることです。 これは、同じ環境変数を使用して行われます。



ご注意
Consulは、 Consul Service Catalog （ 使用している ） を使用して サービスに関する情報を保存している場合、サービスの正常性を確認できます。



Consul Key-Value Storeが使用されている場合 （ Registratorでもサポートされており、たとえばDocker Swarmを使用してDockerノードに関する情報を保存します ）、そのような機能はありません。



例を見てみましょう： 



 $ docker run -d --name nginx.0 -p 4443:443 -p 8000:80 \ -e "SERVICE_443_NAME=https" \ -e "SERVICE_443_CHECK_SCRIPT=curl --silent --fail https://our-https-site.com" \ -e "SERVICE_443_CHECK_INTERVAL=5s" \ -e "SERVICE_80_NAME=http" \ -e "SERVICE_80_CHECK_HTTP=/health/endpoint/path" \ -e "SERVICE_80_CHECK_INTERVAL=15s" \ -e "SERVICE_80_CHECK_TIMEOUT=3s" \ -e "SERVICE_TAGS=www" nginx


同様の開始後、 Consulのサービスのリストは次のようになります。 



 { "services": [ { "id": "hostname:nginx.0:443", "name": "https", "tags": [ "www" ], "address": "192.168.1.102", "port": 4443, "checks": [ { "script" : "curl --silent --fail https://our-https-site.com", "interval": "5s" } ] }, { "id": "hostname:nginx.0:80", "name": "http", "tags": [ "www" ], "address": "192.168.1.102", "port": 8000, "checks": [ { "http": "/health/endpoint/path", "interval": "15s", "timeout": "3s" } ] }, ... ] }


ご覧のとおり、 登録されたポートに基づいて、 登録者は2つのサービス（ httpおよびhttps ）を登録する必要があると結論付けました。 さらに、 Consul 'aには、これらのサービスの状態を確認する方法に関する必要な情報がすべて揃っています。



最初のケースでは、コマンド " curl --silent --fail our-https-site.com "が5秒ごとに実行され、テスト結果はこのコマンドの終了コードに依存します。



2番目の場合、15秒ごとに、Consulは渡されたURLをプルします。 サーバーの応答コードが2xxの場合、サービスは「正常」であり、 429 Too Many Requestsの場合、「緊急状態」にあり、他のすべてが存在する場合、「彼が休息するための土地」です。



公式ドキュメントからより多くの例と詳細情報を入手できます 。



領事テンプレート



領事テンプレート

クラウドのすべてのサービスに関する情報をどこに保存するか、どのようにそこに到達し、そこで自動的に更新されるかを決定しました。 しかし、そこから情報をどのように受け取り、将来どのようにそれをサービスに送信するのかはまだわかりません。 これがConsulテンプレートの機能です。



これを行うには、 HashiCorp Configuration Languageのルールに従って、アプリケーションの構成ファイル（ 構成する ） を取得し、そのファイルからテンプレートを作成します。



Nginx構成ファイルを使用した簡単な例を見てみましょう。 



 upstream app { least_conn; # list of all healthy services {{range service "tag1.cool-app" "passing"}}server {{.Address}}:{{.Port}} max_fails=3 fail_timeout=60s weight=1; {{else}}server 127.0.0.1:65535; # force a 502{{end}} } ...


与えられたテンプレートが置かれている場所、結果を配置する場所、実行するコマンド（ 彼も実行できます ）を変更する（ この場合はNginxを再起動する ） Consulテンプレートを説明すると、魔法が始まります。 この場合、 Consulテンプレートは「 cool-app 」アプリケーションのすべてのコピーのアドレスとポート番号を受け取ります。これらのタグは「 tag1 」タグでマークされ、「 正常 」な状態であり、構成ファイルに追加します。 そのようなアプリケーションがない場合は、ご想像のとおり、 {{else}}の後に残っているものはすべて残ります。



タグ「 tag1 」を使用して「 cool-app 」サービスを追加および削除するたびに、構成ファイルが上書きされ、その後Nginxがリロードされます。 これはすべて自動的に行われ、介入は不要です。必要な数のアプリケーションのコピーを起動するだけで、何も心配する必要はありません。



公式ドキュメントでより多くの例を見つけることができます。



おわりに



今日、サービス発見の問題を解決するのに十分な数のツールがありますが、すぐにこの問題を解決し、必要なものをすぐに提供できるツールは多くありません。



次のパートでは、上記のすべてのツールを構成するAnsibleのスクリプトセットを公開し、実際に使用を開始できます。



以上です。 ご清聴ありがとうございました。 あなたの雲と幸運に安定！



Twitterで私をフォローしてください。私はスタートアップでの仕事、私の間違いと正しい決断、Python、そしてWeb開発に関連するすべてについて話しています。



PS 会社で開発者を探しています 。詳細は私のプロフィールにあります 。


More articles:


All Articles