TOC

アンバサダーパターンを使用してCoreOSでサービスを動的に構成する方法

前書き

Dockerリンク機能を使用すると、コンテナ間のネットワーク接続を動的に構成することができます。これは、_ambassador pattern_と呼ばれます。 アンバサダーパターンは、_provider_コンテナと_consumer_コンテナ間のサービスの移植性を促進します。 CoreOSでは、「+ etcd +」を活用して、クラスター内の複数のマシンに分散されたアンバサダーパターンを実装できます。

このチュートリアルでは、 `+ etcd +`に登録されているApache HTTPコンテナのデプロイを示します。 Apacheコンテナーはプロバイダーコンテナーを表し、HAProxyをコンシューマコンテナーとして使用します。 アンバサダーコンテナにhttps://coreos.com/blog/docker-dynamic-ambassador-powered-by-etcd/ [このCoreOSアンバサダーデモ]のDockerイメージを使用し、独自のApacheおよびHAProxy Dockerを作成します。ゼロからの画像。

前提条件

少なくとも3台のマシンで構成されるDigitalOceanにCoreOSクラスターが必要です。 設定方法のチュートリアルは次のとおりです。https://www.digitalocean.com/community/tutorials/how-to-create-and-run-a-service-on-a-coreos-cluster [作成方法] CoreOSクラスタでのサービスの実行]

CoreOS、etcdctl、fleetctlの使用、サービスの設定、Dockerコンテナの実行に関する基本的な知識が必要です。 これらのトピックは、https：//www.digitalocean.com/community/tutorial_series/getting-started-with-coreos-2 [Getting Started with CoreOS tutorial series]で説明されています。

Docker HubアカウントまたはプライベートDockerレジストリが必要です。 これはhttps://www.digitalocean.com/community/tutorials/how-to-create-and-run-a-service-on-a-coreos-cluster#creating-the-docker-container[Creating 「Dockerコンテナ」セクションの「_CoreOSクラスタでサービスを作成および実行する方法」チュートリアル。

アンバサダーパターンの動作の詳細については、Dockerのhttp://docs.docker.com/articles/ambassador_pattern_linking/ [アンバサダーコンテナーを介したリンク]の記事をご覧ください。 また、CoreOSブログ（https://coreos.com/blog/docker-dynamic-ambassador-powered-by-etcd/[Dynamic Dockerとetcdを使用した大使のリンク]）に投稿されたこの記事もご覧ください。

私たちの目標

このチュートリアルの最後に、2台のマシンで6つのコンテナを実行します。 このセクションでは、それぞれについて簡単に説明し、それらをどのようにグループ化するかを説明します。 この正確なセットアップは、ほとんどの人にとって有用ではありませんが、独自のサービスの動的なサービス検出を可能にするように適合させることができます。

マシンA

マシンAはプロバイダーコンテナーを実行します。 Apache Webサーバー、およびそれをサポートする他のいくつかのコンテナー。

  • * Apache Web Server *：https://www.digitalocean.com/community/tutorials/how-to-create-and-run-a-で説明されているものに似た、ゼロから作成する基本的なApacheコンテナーservice-on-a-coreos-cluster [CoreOSクラスタでサービスを作成および実行する方法]チュートリアル。 これが私たちの_プロデューサーです

  • * polvi / docker-register *：Docker APIを介してApacheのIPアドレスとポートを読み取り、 `+ etcd +`に書き込むhttps://github.com/polvi/docker-reg [登録コンテナー]

  • * polvi / simple-amb *：指定された場所にトラフィックを転送する単純な大使コンテナ。 この場合、トラフィックを `+ etcd `に転送し、それを ` docker-register `コンテナにリンクして、そのコンテナが ` etcd `にアクセスできるようにします。 CoreOSでは、 ` etcd `の場所は静的であるため、 ` etcd `に直接アクセスするように ` docker-register +`が変更された場合、これを削除できます。

マシンB

マシンBは、コンシューマコンテナを実行するCoreOSマシンです。 HAProxy、およびメインアンバサダーコンテナー。

  • * HAProxy Reverse Proxy *：_consumer_を表す、最初から作成する基本的なHAProxyコンテナー。 これは、アンバサダーのセットアップが機能することを示すために使用されます

  • * polvi / dynamic-etcd-amb *：メインアンバサダーコンテナ。 プロバイダーコンテナーのIPアドレスとポートの指定された「+ etcd +」キーを監視し、すべてのトラフィックをプロバイダーコンテナーにルーティングする動的プロキシ。 キーの値は更新でき、プロキシはそれ自体を更新します

  • * polvi / simple-amb *：他のマシンで使用されているのと同じコンテナですが、 `+ dynamic-etcd-amb `を ` etcd +`にリンクするために使用されます

Apache Dockerイメージを作成する

CoreOSマシンの1つにSSHで接続し、SSHエージェントを渡します（パブリックIPアドレスで置き換えます）。

ssh -A core@

次に、Dockerにログインします。

docker login

プロンプトが表示されたら、パスワード、メールアドレスを入力します。

次に、Apache Dockerfileを書き込む新しいディレクトリを作成します。

mkdir -p ambassador/apache

ここでディレクトリに移動し、編集のために `+ Dockerfile +`を開きます。

cd ambassador/apache
vi Dockerfile

CoreOSクラスタでサービスを作成および実行する方法、次のDockerfileを作成できます（ `+ user_name +`を独自のDockerユーザー名に置き換えます）：

FROM ubuntu:14.04
MAINTAINER

RUN apt-get update && \
   DEBIAN_FRONTEND=noninteractive apt-get -y install apache2 && \
   echo "<h1>Running from Docker on CoreOS</h1>" > /var/www/html/index.html

EXPOSE 80

ENTRYPOINT ["/usr/sbin/apache2ctl"]
CMD ["-D", "FOREGROUND"]

保存して終了します。

Apacheをインストールし、index.htmlを基本メッセージに置き換えるDockerfileができたので、Dockerイメージをビルドし、次のコマンド（「独自のユーザー名」を使用）で「apache」という名前を付けます。

docker build --tag="/apache" .

ここで、他のCoreOSマシンでイメージを使用できるようにするには、次のコマンドを使用してDockerレジストリに「+ push +」します。

docker push /apache

これで、Apacheイメージを使用する準備が整いました。 HAProxyイメージの作成に進みましょう。

HAProxy Dockerイメージを作成する

https://github.com/dockerfile/haproxy [信頼できる自動化されたDockerビルド用のHAproxy Dockerfile]に基づいて、HAProxy Dockerイメージを作成します。 提供されている `+ haproxy.cfg `および ` start.bash +`ファイルを少し変更します。

`+ ambassador `ディレクトリで、 ` git +`を使用してHAProxyリポジトリを複製します。

cd ~/ambassador
git clone https://github.com/dockerfile/haproxy.git

これにより、「+ Dockerfile 」、「 haproxy.cfg 」、および「 start.bash 」ファイルを含む「 haproxy +」ディレクトリが作成されます。

Dockerfileは基本的にHAProxyをインストールし、ポート80と443を公開するため、そのままにしておくことができます。

`+ haproxy.cfg `ファイルを変更して、 ` frontend `と ` backend `を追加します。 編集のために ` haproxy.cfg +`を開きます：

cd haproxy
vi haproxy.cfg

次の行を見つけて削除します。

listen stats :80
 stats enable
 stats uri /

次に、ファイルの最後に次の行を追加します。

frontend www-http
       bind :80
       default_backend www-backend

backend www-backend
       server apache :80 check

これにより、ポート80でリッスンし、着信トラフィックを単一サーバーで構成される「+ www-backend」に転送するようにHAProxyが設定されます。 HAProxyコンテナの起動時に、このコンテナが実行されるCoreOSマシンのプライベートIPアドレスで「+ private_ipv4 」を「 start.bash +」スクリプトに置き換えます。 HAProxyがトラフィックをApacheコンテナーに転送する動的な大使コンテナーは、同じマシン上で実行されます。

編集のために `+ start.bash +`ファイルを開きます：

vi start.bash

ファイルの下部に、このコンテナでHAProxyプロセスを開始する行があります。 それはこのように見えます：

haproxy -f /etc/haproxy/haproxy.cfg -p "$PIDFILE"

この行のすぐ上に、次の行を挿入します。

# Set backend IP address to machine's private IP address
PRIVATE_IPV4=$(curl -sw "\n" http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address)
sed -i -e "s/server apache private_ipv4:80 check/server apache ${PRIVATE_IPV4}:80 check/g" $HAPROXY/$CONFIG

保存して終了。 `+ curl `コマンドは、コンテナがDigitalOceanメタデータサービスを介して実行されるマシンのプライベートIPアドレスを取得します。 「 sed 」コマンドは、「 haproxy.cfg 」の「 private_ipv4 +」文字列を、メタデータから取得した実際のIPアドレスに置き換えます。 このスクリプトはHAProxyコンテナー内から実行されるため、実行時にプライベートIPアドレスが構成されます。

これで、HAProxyドッカーイメージを作成する準備ができました。 Dockerイメージをビルドし、次のコマンドを使用して「haproxy」という名前を付けます（独自のユーザー名に置き換えます）。

docker build --tag="/haproxy" .

ここで、他のCoreOSマシンでイメージを使用できるようにするには、次のコマンドを使用してDockerレジストリに「+ push +」します。

docker push /haproxy

HAProxyイメージを使用する準備が整いました。 フリートサービスユニットファイルを作成する準備ができました！

フリートサービスユニットファイル

必要なすべてのDockerイメージがCoreOSクラスターで利用できるようになったので、コンテナーの展開に必要なファイルの作業を始めましょう。 CoreOSクラスターを使用しているため、1台のCoreOSマシンからすべてのフリートサービスユニットファイルを作成およびスケジュールできます。

以前に作成した `+〜/ ambassador +`ディレクトリにすべてのサービスファイルを作成するので、ここでそのディレクトリに変更します。

cd ~/ambassador

apache.service

`+ apache.service +`ユニットは_Host A_で実行されます。

最初に作成するサービスファイルは、Apache Webサーバーコンテナ用の `+ user_name / apache `です。 今すぐ編集するために ` apache.service +`というファイルを開きます：

vi apache.service

次の行を追加します（両方の場所でDockerユーザー名を置き換えます）。

[Unit]
Description=Apache web server service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre=/usr/bin/docker pull /apache
ExecStart=/usr/bin/docker run --rm --name %n -p ${COREOS_PRIVATE_IPV4}::80 /apache
ExecStop=/usr/bin/docker stop -t 3 %n
保存して終了。 これは、Apacheをフォアグラウンドモードで起動する非常に簡単なサービスファイルです。 特に注意すべきは、コンテナ内のポート80をプライベートネットワークインターフェイスの動的ポートにバインドしていることです（ `+ -p $ {COREOS_PRIVATE_IPV4}

80 +`）。

etcd-amb-apache.service

`+ etcd-amb-apache.service +`ユニットは_Host A_で実行されます。

次に、Apache登録コンテナーが + etcd +`にアクセスできるようにする単純なアンバサダーコンテナー（ `+ simple-amb +）のサービスファイルを作成します。 今すぐ `+ etcd-amb-apache.service +`というファイルを開きます：

vi etcd-amb-apache.service

次の行を追加します。

[Unit]
Description=Simple Apache ambassador
After=apache.service
BindsTo=apache.service

[Service]
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStart=/usr/bin/docker run --rm --name %n polvi/simple-amb 172.17.42.1:4001
ExecStop=/usr/bin/docker stop -t 3 %n

[X-Fleet]
X-ConditionMachineOf=apache.service

保存して終了。

+ simple-amb +`コンテナは、ポート10000で受信したすべてのトラフィックを、起動時に指定された引数に転送します。 `+172.17.42.1：4001 +、これはCoreOSの `+ etcd +`の標準の場所です。

+ X-ConditionMachineOf = apache.service +`は、ApacheがIPアドレスとポートを登録するために `+ docker-register +`コンテナによって使用されるため、Apacheコンテナと同じマシンでこれをスケジュールするよう艦隊に指示します。使用して `+ etcd +。

apache-docker-reg.service

`+ apache-docker-reg.service +`ユニットは_Host A_で実行されます。

ApacheのIPアドレスとポートを「+ etcd 」、「 docker-register 」に登録するコンテナのサービスファイルを作成しましょう。 今すぐ ` apache-docker-reg.service +`というファイルを開きます：

vi apache-docker-reg.service

次の行を挿入します。

[Unit]
Description=Register Apache
After=etcd-amb-apache.service
BindsTo=etcd-amb-apache.service

[Service]
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStart=/usr/bin/docker run --link etcd-amb-apache.service:etcd -v /var/run/docker.sock:/var/run/docker.sock --rm polvi/docker-register apache.service 80 apache-A

[X-Fleet]
X-ConditionMachineOf=etcd-amb-apache.service

保存して終了。 `+ docker run +`コマンドの注目すべき部分の内訳は次のとおりです。

  • `-link etcd-amb-apache.service：etcd +`は、このコンテナを単純な大使にリンクします。これは、Apacheの接続情報を ` etcd +`に渡すために使用されます

  • `+ -v /var/run/docker.sock：/ var / run / docker.sock +`を使用すると、このコンテナは、実行するマシンのDocker APIを介してApacheがバインドしている動的ポートを決定できます。

  • `+ apache.service 80 apache-A `はこれらの引数をコンテナに渡します。 最初の2つの引数はルックアップするdockerコンテナの名前とポートを指定し、3番目の引数は書き込み先の ` etcd `キーの名前を指定します。 このコンテナが起動すると、 ` apache.service `の動的ポートとIPアドレスを ` / services / apache-A / apache.service +`キーに書き込みます。

`+ X-ConditionMachineOf = etcd-amb-apache.service +`は、Dockerリンクにリンクされているため登録コンテナーに ` + etcd + `。

etcd-amb-apache2.service

`+ etcd-amb-apache2.service +`ユニットは_Host B_で実行されます。

2番目のシンプルなアンバサダーコンテナ（ + simple-amb +）のサービスファイルを作成します。これにより、ダイナミックアンバサダーコンテナが `+ etcd `にアクセスできるようになります。 今すぐ ` etcd-amb-apache2.service +`というファイルを開きます：

vi etcd-amb-apache2.service

次の行を追加します。

[Unit]
Description=Simple Apache ambassador 2

[Service]
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStart=/usr/bin/docker run --rm --name %n polvi/simple-amb 172.17.42.1:4001
ExecStop=/usr/bin/docker stop -t 3 %n

[X-Fleet]
X-Conflicts=apache.service

保存して終了。

これは `+ etc-amb-apache.service `とほぼ同じサービスファイルです。ただし、 ` X-Conflicts = apache.service `は、Apacheコンテナとは異なるマシン上でスケジュールするように艦隊に指示します。ダイナミックアンバサダーを ` etcd +`にリンクします。

apache-dyn-amb.service

`+ apache-dyn-amb.service +`ユニットは_Host B_で実行されます。

ダイナミックアンバサダーコンテナが + etcd +`にアクセスできるようにするダイナミックアンバサダーコンテナ（ `+ dynamic-etd-amb +）のサービスファイルを作成します。 今、 `+ apache-dyn-amd.service`というファイルを開きます：

vi apache-dyn-amb.service

次の行を追加します。

[Unit]
Description=Dynamic ambassador for Apache
After=etcd-amb-apache2.service
BindsTo=etcd-amb-apache2.service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre=/usr/bin/docker pull polvi/dynamic-etcd-amb
ExecStart=/usr/bin/docker run --link etcd-amb-apache2.service:etcd --rm --name %n -p ${COREOS_PRIVATE_IPV4}:80:80 polvi/dynamic-etcd-amb apache-A 80
ExecStop=/usr/bin/docker stop -t 3 %n

[X-Fleet]
X-ConditionMachineOf=etcd-amb-apache2.service

保存して終了。 `+ docker run +`コマンドの注目すべき部分の内訳は次のとおりです。

  • `-link etcd-amb-apache2.service：etcd +`は、このコンテナを2番目の単純な大使にリンクします。これは、Apacheの接続情報を ` etcd +`から取得するために使用されます

  • `+ -p $ {COREOS_PRIVATE_IPV4}：80：80 +`は、コンテナとマシンのプライベートネットワークインターフェイスのポート80を公開します

  • `+ apache-A 80 `は、ポート80のトラフィック（つまり、 プライベートネットワークインターフェイスのポート80）は、「 etcd 」で「 apache-A +」として登録されているサービスにプロキシする必要があります

`+ X-ConditionMachineOf = etcd-amb-apache2.service `は、2番目のシンプルなアンバサダーコンテナと同じマシンでこれをスケジュールするよう艦隊に指示します。 ` etcd +`を見つけます。

haproxy.service

`+ haproxy.service`ユニットは_ Host B_で実行されます。

HAProxyコンテナのサービスファイル（ + haproxy +）を作成します。これは、動的なアンバサダーコンテナを介してApacheコンテナに接続するために使用されます。 今すぐ `+ haproxy.service +`というファイルを開きます：

vi haproxy.service

次の行を追加します（両方の場所でDockerユーザー名を置き換えます）。

[Unit]
Description=HAProxy consumer

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill %n
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre=/usr/bin/docker pull /haproxy
ExecStart=/usr/bin/docker run --name %n -p ${COREOS_PUBLIC_IPV4}:80:80 /haproxy
ExecStop=/usr/bin/docker stop -t 3 %n

[X-Fleet]
X-ConditionMachineOf=apache-dyn-amb.service

保存して終了。 これは簡単なサービスファイルで、HAProxyを起動し、ホストマシンのパブリックIPアドレスでポート80を公開します。 バックエンドサーバーは、ポート80でホストマシンのプライベートIPアドレスに設定されることに注意してください。これは、たまたまダイナミックアンバサダーがApacheサービスへのプロキシへのトラフィックをリッスンしている場所です。

`+ X-ConditionMachineOf = apache-dyn-amb.service +`は、ダイナミックアンバサダーがHAProxyコンテナにApacheコンテナに到達するためのルートを提供するため、ダイナミックアンバサダーコンテナと同じマシンでこれをスケジュールするよう艦隊に指示します。

フリートでデプロイする

必要なすべてのフリートサービスファイルが用意できたので、ようやくアンバサダーのセットアップを展開できます。 すべてのサービスファイルを含むディレクトリで、次のコマンドを実行します。

fleetctl start apache.service
fleetctl start etcd-amb-apache.service
fleetctl start apache-docker-reg.service
fleetctl start etcd-amb-apache2.service
fleetctl start apache-dyn-amb.service
fleetctl start haproxy.service

各サービスがロードされたことを示すメッセージが表示されます。 フリートユニットのステータスを確認するには、次のコマンドを実行します。

fleetctl list-units

次のような出力が表示されます。

UNIT                       MACHINE                      ACTIVE   SUB
apache-docker-reg.service  ceb3ead2.../10.132.233.107   active   running
apache-dyn-amb.service     3ce87ca7.../10.132.233.106   active   running
apache.service             ceb3ead2.../10.132.233.107   active   running
etcd-amb-apache.service    ceb3ead2.../10.132.233.107   active   running
etcd-amb-apache2.service   3ce87ca7.../10.132.233.106   active   running
haproxy.service            3ce87ca7.../10.132.233.106   active   running

すべての彫像は「+アクティブ」および「+ランニング」である必要があります。 もう1つの注意点は、「マシンA」ユニットは同じマシン上にあり、「マシンB」ユニットは異なるマシン上にある必要があることです。各ユニットのIPアドレスを確認して確認してください。

セットアップのテスト

HAProxyがApacheに到達できることを確認する

HAProxyコンテナを特定のマシンで実行するように指定しなかったため、実行場所を見つける必要があります。 これを行う簡単な方法は、 `+ fleetctl ssh +`コマンドを使用することです：

fleetctl ssh haproxy.service

これにより、 `+ haproxy.service `コンテナを実行しているマシンに接続されます。 これで、 ` / etc / environment +`ファイルを取得して、HAProxyを実行しているCoreOSマシンのパブリックIPアドレスを取得できます。

. /etc/environment
echo $COREOS_PUBLIC_IPV4

結果のIPアドレスを取得し、Webブラウザーを使用してアクセスします。 次の画像が表示されます。

image：https：//assets.digitalocean.com/articles/coreos_basic/web_page.png [CoreOS上のDockerからの実行]

HAProxyにアクセスしており、HAProxyは動的アンバサダープロキシを介してApacheにアクセスしていることに注意してください。

現在のSSHセッションを終了して、元のSSHセッションに戻ることができます。

exit

テストフェールオーバー

アンバサダーのセットアップが機能することを確認したので、プロバイダーサービス（ + apache.service +）がIPアドレスとポートを変更するとどうなるか見てみましょう。

+ aple.service ie`を実行しているマシンに接続するには、 + fleetctl`を使用します。

fleetctl ssh apache.service

次に、Apacheが実行されているマシンを再起動します。

sudo reboot

*注意：*最初にSSH経由で接続したマシンで `+ apache.service`が実行されていた場合、切断されます。 この場合、同じCoreOSクラスター内の別のマシンにSSHで接続します。

少し待って、実行中のユニットを確認します。

fleetctl list-units

待機時間に応じて、「ホストA」に関連する3つのユニット（ + apache.service +、 + etcd-amb-apache.service +、および `+ apache-docker-reg.service +`が表示される場合があります。 ）再起動中またはアクティブです。 最終的に、それらはすべて_active_状態に戻る必要があります。 実行したら、以前とは異なるマシンで実行されていることに注意してください。

ここで、HAProxyに接続していたWebブラウザーに戻り、更新をクリックします。 以前と同じテストページが表示され、HAProxyが動的なアンバサダーを介してApacheに接続できることを示しているはずです。

結論

独自のアンバサダーパターンを設定したので、このチュートリアルで提示した概念を独自のサービスに適合させることができるはずです。 これは、実行時にコンシューマーサービスを構成する独自の方法であり、バックエンドプロバイダーサービスをマシン間で簡単に移動できます。 より現実的な設定では、Apacheサービスを1つ以上のアプリケーションコンテナーに置き換え、複数のバックエンドサーバーでHAProxyを構成する（またはまったく異なるコンシューマサービスを使用する）可能性があります。

Related