本日の投稿では、TraefikとHAProxyの2つのロードバランサーの使用について説明します。 これらのロードバランサーには、オーケストレーションツールの印象的なリストを操作する機能があります。 例では、Nomadオーケストレーションシステムの使用方法について説明します。
前回の投稿では、ロードバランサーの例としてFabioを既に紹介しました。 その制限：http / httpsプロトコルでのみ機能し、Consulでのみ機能します。 Fabioとは異なり、Load Balancers Traefikは非常に多くの異なるシステムで動作します。 開発者のサイトから抜粋したリストの一部を次に示します。Docker、Swarmモード、Kubernetes、Marathon、Consul、Etcd、Rancher、Amazon ECS、...
前回の投稿の例では、djangoサービスのレプリカがいくつか作成されました。
Traefikは、最も一般的なオペレーティングシステムの実行可能ファイルとして開発者のサイトからダウンロードできます。 Nomad（実際にはConsulと）と統合するには、構成ファイルを作成する必要があります。
[entryPoints] [entryPoints.http] address = ":5001" [web] address = ":8080" [consulCatalog] endpoint = "127.0.0.1:8500" domain = "consul.localhost" exposedByDefault = false prefix = "traefik"
そして、指定された設定ファイルでコマンドを実行します：
traefik -c nomad/traefik.toml
その後、UI Traefikはポート8080で利用できるようになりますが、ポートはまだサービスを公開していません。 サービスを公開する方法はいくつかありますが、最終的には同じことを行います-キー/値データをTraefikシステムにロードします。 サービスタグを介してキー/値のペアを設定する機会を利用します。 tagsパラメーターを使用してdjangoサービス構成ファイルを展開しましょう。
job "django-job" { datacenters = ["dc1"] type = "service" group "django-group" { count = 3 restart { attempts = 2 interval = "30m" delay = "15s" mode = "fail" } ephemeral_disk { size = 300 } task "django-job" { driver = "docker" config { image = "apapacy/tut-django:1.0.1" port_map { lb = 8000 } } resources { network { mbits = 10 port "lb" {} } } service { name = "django" tags = [ "traefik.enable=true", "traefik.frontend.entryPoints=http", "traefik.frontend.rule=Host:localhost;PathStrip:/test", "traefik.tags=exposed" ] port = "lb" check { name = "alive" type = "http" path = "/" interval = "10s" timeout = "2s" } } } } }
この例では、サービスはローカルホストで公開され、/テストルートにマウントされます。 Traefikは、正規表現の操作を含む、ルートを構成するための柔軟で完全なルールシステムを開発しました。 開発者向けドキュメントのルールのパラメーターのリスト。
nomad job run nomad/django.conf
ルールが適用され、ロードバランサーからのトラフィックがサービスに向けられます。 したがって、これらのパラメーターを変更し、
nomad job run nomad/django.conf
して新しいサービスオプションを展開すると、迷惑なトラフィックを停止することなくすべての変更が適用されます。
Traefikの欠点は、http / httpsファミリのプロトコルで動作することです（念のため、このファミリにはWebソケットも含まれています）。 ただし、他のプロトコルを使用する必要がある可能性はまだあります。 したがって、HAProxyに基づく次のより広いソリューションに進みます。 しばらく前、HAProxyはソフトオーバーロードに問題があり、オーケストレーションシステムでの使用が困難になりました（再起動中、ネットワークレベルでパケットの移動を停止する必要がありました）。 これで問題はなくなりました。
まず、コンピューターにhaproxyをインストールする必要があります。 ここでは、コンテナ内にインストールするオプションは機能しません。 haproxyでは、ごく最近になって「ソフト」モードでプロセスを再起動できましたが、同時に、2番目のプロセスがhaproxyで開始されるため、Dockerコンテナが停止します。これは、待機モードで変更されます。 -コンテナは1つのプロセスです。」
haproxyが機能するには、必要なルールを含む構成ファイルが必要です。 Nomad（実際にはConsul）は、構成を生成できるテンプレートシステムを使用します。
global debug defaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 frontend http_front bind *:5001 stats uri /haproxy?stats default_backend http_back backend http_back balance roundrobin{{range service "django"}} server {{.Node}} {{.Address}}:{{.Port}} check{{end}}
この場合の
range
キーワードは反復子として機能します。 3つの「django」サービスについて、次の構成ファイルが生成されます。
global debug defaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 frontend http_front bind *:5001 stats uri /haproxy?stats default_backend http_back backend http_back balance roundrobin server 228.195.86.224 127.0.0.1:21469 check server 228.195.86.224 127.0.0.1:25872 check server 228.195.86.224 127.0.0.1:25865 check
ライブラリhttps://github.com/hashicorp/consul-templateは、その場でテンプレートに従って生成プロセスを開始するために使用されます。 開発者のリソースから、すべての一般的なオペレーティングシステムの実行可能ファイルをダウンロードし、次のコマンドを使用して、権限のないユーザーに代わってプロセスを開始できます。
consul-template -template="haproxy/haproxy.cfg.tmpl:haproxy/haproxy.cfg:./haproxy/haproxy.reload.sh"
-template
パラメーターには、コロンで区切られたパラメーター1）テンプレートの名前、2）結果の構成ファイルの名前、3）ファイルの生成後に実行されるコマンドが含まれます。 テンプレートに含まれる変数が変更された場合（たとえば、djangoサービスのレプリカの数が変更された場合）、ファイルは自動的に生成されます。
最初の構成を生成するテンプレートエンジンを起動した後、haproxyを実行できます。
haproxy -D -f haproxy/haproxy.cfg -p `pwd`/haproxy.pid
「ソフト」haproxyオーバーロードにシグナルを送信できるように、pidファイルを明示的に指定します。
haproxy -D -f ./haproxy/haproxy.cfg -p `pwd`/haproxy.pid -sf $(cat `pwd`/haproxy.pid)
この例では、サービスはポート5001で公開されています。同じポートで、アドレス
/haproxy?stats
でhaproxy自体の統計を表示できます。
2019年2月24日更新10:43 PM
@usegoのコメントによると、特にドキュメントgithub.com/neo4j/docker-library-docs/tree/master/haproxy#reloading-configのフラグメントに従って、dockerコンテナ内のhaproxyの操作がさらに改良されました。
設定の再読み込み
構成にバインドマウントを使用し、haproxy.cfgファイルを編集した場合、コンテナにSIGHUPを送信してHAProxyのグレースフルリロード機能を使用できます。
$ docker kill -s HUP my-running-haproxy
イメージのエントリポイントスクリプトは、コマンドhaproxyの実行を確認し、HAProxyアップストリームからhaproxy-systemd-wrapperに置き換えます。これは、グレースフルリロードを行うための信号処理を処理します。 内部では、haproxyの-sfオプションを使用するため、「高負荷時にいくつかの接続障害が発生する可能性のあるそれぞれ数ミリ秒の小さなウィンドウが2つあります」（HAProxyの停止と再起動を参照）。
このアプローチでは、設定は実際にリロードされますが、現在のプロセスの中断の結果です。 これは、サービスが非常に重要ではないものの、アクセスできない期間があり、一部のお客様がエラーメッセージを確認する可能性があることを意味します。 しかし、これは主な選択基準ではない場合があります。 したがって、dockerでhaproxyを起動するためのdocker-compose.yml設定を追加で提供します。
version: '3' services: haproxy_lb: image: haproxy volumes: - ./haproxy:/usr/local/etc/haproxy network_mode: host
haproxy設定をオーバーロードするコマンドも変更されます。
consul-template -template="haproxy/haproxy.cfg.tmpl:haproxy/haproxy.cfg:docker kill -s HUP $(docker-compose ps -q haproxy_lb)"
この実装の利点には、haproxyをインストールせずに機能することが含まれます。
リポジトリにはサンプルコードがあります。
便利なリンク：
1.www.haproxy.com/blog/haproxy-and-consul-with-dns-for-service-discovery
2.m.mattmclaugh.com/traefik-and-consul-catalog-example-2c33fc1480c0
3. www.hashicorp.com/blog/load-balancing-strategies-for-consul
apapacy@gmail.com
2019年2月24日