はじめに
この記事は「Rancherで構築するオンプレとクラウドのハイブリッド環境」の後編にあたります。
前編を読んでいることを前提にしていますので、まだ読んでいない方は覗いてみてください。
前編の復習
前編ではパブリックネットワーク（AWS）にホスト（EC2）を配置し、そこにVPNを構築しました。
このVPNにはまだホスト（EC2）が1台参加しているだけの状態です。
本記事ではこのVPNに残りのホストを追加し、Wordpressをデプロイします。
ホストのCATTLE_AGENT_IP書き換え
まず注目する点は、現在パブリックネットワークにいるホストがRancherサーバーにパブリックIPで登録されている点です。
前編でも述べましたが、ホスト間通信を実現する為には、全てのホストがUI上に表示されているIPで通信が可能でなければいけません。
ですので、このIPをVPNのIPに修正します。
これにはRancherOS上で動いている rancher/agent のコンテナの再起動が必要になります。
そして再起動時に-e CATTLE_AGENT_IP="＜VPN内のIP＞" オプションをつけて、明示的にこのホストのIPをRancherサーバーに教える必要があります。
この起動時のコマンドを知りたい場合は、Rancher UI上で「インフラストラクチャ＞ホストを追加」として、Custom のところで④にホストのVPN上のIPを入力して、⑤のコマンドをコピーして使用すれば大丈夫です。
agent の再起動が成功してしばらくすると下のようにRancher UI上でもVPNのIPが反映されているのが確認できます。
AWSにホストをもう1台追加
VPN構築＋Rancherサーバーに登録しているホストのIPの更新が完了したので、ここからはホストの量産を実施します。
まずはAWSにもう1台ホスト（EC2）を追加しましょう。これは上でやった手順と同じで大丈夫です。
同様に、VPNクライアント用のConfig（vpn-client-config.ovpn）を転送して↓を実行します。
sudo docker run -it --privileged --net=host \
--cap-add=NET_ADMIN --device /dev/net/tun \
--name vpn-client -v $(pwd):/etc/openvpn \
supersoftware/openvpn vpn-client-config.ovpnEC2としてホストを追加した場合は、自動的にEC2のパブリックIPでRancherサーバーに登録されてしまうので、上の手順と同じくCATTLE_AGENT_IP 付きでrancher/agent を再起動することをお忘れなく。
社内ネットワークのホスト2台を追加
クラウド側のホストの準備が完了したので、社内ネットワークのホストを2台クラスタに追加します。
基本的にはEC2を追加した場合と同じなのですが、手動でrancher/agent を立ち上げる必要があるので若干手順が異なります。
まずは、少し不思議な手順ではありますが、「インフラストラクチャ＞ホスト」の「ホストを追加」に表示されている⑤のコマンドで社内ネットワークのホストを追加します。
いきなりVPNのIPでホストを登録するとどうもcni 関連の初期化に失敗してipsec が正常に立ち上がらないようです（深く調査できていませんが、ipsec まわりで何やら競合してるのかも）。
この状態でRancher UIを確認すると恐らく会社のグローバルIPで登録されているのが確認できると思います。
パブリックネットワークのときの手順と同じで、ここからVPN参加して、rancher/agent を再起動します。
ここからの手順は今までと同様で、VPNクライアントのConfig（vpn-client-config.ovpn）を scp でホストに好きな方法で転送・作成します。
そしてVPNクライアントのコンテナを立ち上げてVPNに参加させます。
sudo docker run -it --privileged --net=host \
--cap-add=NET_ADMIN --device /dev/net/tun \
--name vpn-client -v $(pwd):/etc/openvpn \
supersoftware/openvpn vpn-client-config.ovpnVPNに参加できたことが確認できたところで、Rancher UIから「インフラストラクチャ＞ホスト」と進み、「ホストを追加」を選択します。
Custom を選択して、④のテキストフィールドにVPN内のIPを入力します。
そして⑤のdocker run をコピーします（CATTLE_AGENT_IPが追加される）。
ホスト内でこのコマンドを実行するので「閉じる」を押してしまって問題ありません。
それでは社内ネットワーク内のホストにて先程コピーした docker run を実行しましょう。
Rancher UIにてホストがVPN内のIPで追加されるのが確認できるはずです。
この手順を丸々もう1台分繰り返します。
これで4つのホストで構成されたクラスタが完成します。
Pingで疎通確認
クラスタが完成したので、それぞれのホストの healthcheck コンテナにでも入って、 ping を相互に実行してみましょう。
正常にクラスタが構築できていたら全てのホスト同士でPingが通るはずです。
WordPressをデプロイ
いよいよWebアプリをデプロイしましょう。
DBも一応使っているところを見るためにもWordpressを立ち上げたいと思います。
ロードバランサーでリクエストが振り分けられているのかが確認しづらいので、今回のテスト用にhostname を表示するWordpressのイメージ（supersoftware/unique-wordpress ）をあらかじめDockerhubに上げています。
手っ取り早く作ってしまいたいのでカタログからWordpressを探して起動します。
テスト用なので特に深く考えずに「起動」してしまいましょう。
デプロイが完了したら、デフォルトのwordpress イメージではなく、supersoftware/unique-wordpress を使うようにしたいので早速サービスをアップグレードします。
イメージの部分をsupersoftware/unique-wordpress に変更します。
デプロイが完了したところでWordpressにアクセスしてみましょう。
サービスのリンクをクリックすると別タブでページを開いてくれるので便利です。
正常にデプロイできていれば、以下のようにWordpressのインストール画面が表示されるはずです。
そして、わかりづらいですが、一番下に hostname が表示されているのも確認できるはずです。
これがコンテナIDと一致します。ここまでできたらWordpressのデプロイはいったん完了です。
ロードバランサを追加
では、リクエストを分配するためにロードバランサを追加しましょう。
その前にWordpressの手前にロードバランサが配置されるので、Wordpressが外向け用にマッピングしているポート80は不要になります。サービスのアップグレードでポートマッピング（80->80）は消してしまいましょう。
そして、スタックにロードバランサを下図の設定で追加します。
しばらくすると全ホストにロードバランサがデプロイされているのが確認できます。
この状態でロードバランサのリンクをクリックして、正常にWordpressが表示されることを確認します。
これで準備が整いました。あとはWordpressをスケールさせるだけです。
ドキドキしますね！
WordPressをスケールアウト
いよいよクライマックスです。
それではWordpressサービスをスケールアウトさせましょう。
WordPressサービスの「編集」から、スケールを「4」に設定します。
うまくいけば全ホストにWordpressコンテナがデプロイされます。
ロードバランサにアクセスし、リロードしたタイミングでhostname が変わっていくのが確認できます。（ただし、単純なラウンドロビンでは無いようです）
WordPressに対してこのような構成をとることは無いでしょうけど、これでオンプレとクラウドでリソースがシームレスに使われているのが確認できたかと思います。
ハイブリッド環境のプロトタイプ完成です！
おわりに（そして課題）
「オンプレとクラウドのハイブリッド環境」は実現できました。
…が、課題は色々とあります。
- VPNのHAが考慮されていない（これを本気でやらないと実運用では話にならない。Single Point of Failureになってしまう。）
- というよりVPNを自分で構築するのに結構手間がかかる。プロビジョニングを自動化しないとホストが多いと大変。
- 性能面の劣化がないか検証が必要。
ともあれ、これらの課題を解決することで実運用に耐えうるレベルにもなります。
そうなれば自然とユースケースの幅も拡がるので面白いことになっていきそうですよね。
前編、後編と長丁場でしたがここまで読んでいただきありがとうございました！
