もーっと簡単にopenstfの環境をMac上にゼロから構築する方法

11466 ワード
CoreOS Vagrant OpenSTF Android fleet Android テキストリンク

はじめに

この記事は「簡単にopenstfの環境をMac上にゼロから構築する方法」にておこなっている細かな設定や課題を全て吸収したものになります。
多分これが一番楽だと思います。

やらなくて良くなったこと、対応した課題は以下の通りです

  • rethinkdbが正しく起動しない問題に対応
  • coreosのメモリを512->1024に変更
  • nginx.confの初回設定が不要になりました
  • fleetの自動IP割り当てによる、nginx.confの再設定が不要になるよう修正

なお、前回の記事と共通の部分は今回はタイトルのみで説明は省きます。

構築環境

OS: Max OS X El Capitan
※前回から変更なし

setup-examplesをGit cloneする(変更あり)

クローン先が変わっています
https://github.com/kiuchikeisuke/setup-examples

大元のsetup-examplesをforkして諸々の問題に対応したのが上のやつになります

VirtualBox,VirtualBox Extension Pack,Vagrant,fleetをインストールする

変更なしです。
元記事を参考にしてください

RethinkDBを構築する(変更あり)

service起動の修正が不要になりました。そのため、vagrant upを実行するだけで良くなっています

cmd
$ cd stf-setup-examples
$ cd db
$ vagrant up

STF Clusterを構築する(一部変更あり)

Vagrantfileを修正する(一部変更あり)

手順として、「接続予定のデバイスを登録する」のみでOKです。なお、メモリは今回1Gに増やしています。

変更が終わったらvagrant upで。

cmd
$ cd coreos
$ vagrant up

fleetの設定と確認

変更なしなので、前回の記事を参考に。

STF関連のサービスをデプロイする(変更あり)

１カ所を除いて前回と同じ。

違うのはnginx.confを修正するの手順がまるまる不要になっている。ここで必要な変更は全てgithubにて更新済みになっている。

openstfのページを開く

変更なし

オリジナルからの変更点詳細

2017/3/6現在の、オリジナルとの修正差分

rethinkdbが正しく起動しない問題に対応

前回の「Vagrantfileを修正する」の変更を反映

db/Vagrantfile
       # Start rethinkdb
-      service rethinkdb start;
+      /etc/init.d/rethinkdb start;

coreosのメモリを512->1024に変更

前回のcoreOSのメモリを増やす(任意)の変更を反映

coreos/Vagrantfile
 update_channel = 'alpha'
 image_version = 'current'
-vm_memory = 512
+vm_memory = 1024

nginx.confの修正を不要にした

今回のメインの修正。

原因

そもそもの原因はfleet側の仕様と、nginx.confの設定がかみ合っていないことに起因している。

fleet側は「サービスを重複なしでマシン上に起動してね」という設定になっている。そのため、例えばAというサービスがどのIPに割り振られるかはランダムだった(一部のサービスは起動先が指定されているが)。
一方でnginx側は「Aサービスは指定したIPでXXXXポートでアクセスしてね」という設定になってる(意訳してます)。
そのため、fleet側でIPアドレスの割り当てが行われた場合、nginx側はそれに合わせて設定する必要があった。さらにfleet側は自動でIPをいい感じに再割り当てしてくれる仕様？のため、その度にnginx.confを修正する必要が出てきていた。

対応

対応方針は大まかに２つ。
一つはnginx.confのupstreamをロードバランサーとして使い、どのIPに割り当てられたとしても接続できるようにした。以下のようなパターンがそれに該当する。

nginx.conf
   upstream stf_app {
     # PLEASE UPDATE IP ADDRESS WITH APPROPRIATE ONE
-    server 172.17.8.10{1|2|3}:3100 max_fails=0;
+    server 172.17.8.101:3100 max_fails=1;
+    server 172.17.8.102:3100 max_fails=1;
+    server 172.17.8.103:3100 max_fails=1;
   }

ほとんどはこれで対処できるが、stf-provider.serviceだけこの対処ができない。
その理由は、ポート番号が可変になっているため。

nginx.conf
     location ~ "^/d/1/([^/]+)/(?<port>[0-9]{5})/$" { #ここでlocationからport番号を変数に格納してる
       # PLEASE UPDATE IP ADDRESS WITH APPROPRIATE ONE
       proxy_pass http://172.17.8.10{1|2|3}:$port/;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection $connection_upgrade;

さらにnginxの仕様としてupstream内ではポート番号を可変にすることができない(と思う。仮にポート番号を指定しないと自動で80番ポートが割り当てられる)。

なので、別の対処が必要になる。
で、行ったのは「IPアドレスを固定させる」方法。
そのためにまず、仮想マシンのメタデータとしてindexを追加している。

coreos/Vagrantfile
 cluster = [
-  { name: 'core-01', hostname: 'core-01', ip: '172.17.8.101', metadata: 'role=nginx'   },
-  { name: 'core-02', hostname: 'core-02', ip: '172.17.8.102', metadata: 'role=appside' },
-  { name: 'core-03', hostname: 'core-03', ip: '172.17.8.103', metadata: 'role=devside' }
+  { name: 'core-01', hostname: 'core-01', ip: '172.17.8.101', metadata: 'role=nginx' , indexmeta: 'index=1' },
+  { name: 'core-02', hostname: 'core-02', ip: '172.17.8.102', metadata: 'role=appside' , indexmeta: 'index=2' },
+  { name: 'core-03', hostname: 'core-03', ip: '172.17.8.103', metadata: 'role=devside' , indexmeta: 'index=3' }

~~~略~~~

       # Add metadata
-      data['coreos']['fleet']['metadata'] = node[:metadata]
+      data['coreos']['fleet']['metadata'] = node[:metadata] + ',' + node[:indexmeta]

これでメタデータに「index=1~3」という値が付与される

このメタデータは仮想マシンに紐づくため、IPアドレスと1対1対応になり、「IPアドレスが172.17.8.101なら必ずindex=1」となる。
でこれに合わせて、stf-provider.serviceの起動条件を書き換えれる。

[email protected]
 [X-Fleet]
-Conflicts=stf-provider@*.service
+MachineMetadata=index=%i

もともとの記載は、「stf-providerサービスはマシン重複しないで起動する」という設定、今回の記載は「stf-serviceはサービスNo.iとメタデータのindexが一致したマシン上に起動する」にしている。
これにより、IPアドレスとサービスNoが1対1で紐づく。

最後にnginx.confの設定を修正すればOK

nginx.conf
     location ~ "^/d/1/([^/]+)/(?<port>[0-9]{5})/$" {
       # PLEASE UPDATE IP ADDRESS WITH APPROPRIATE ONE
-      proxy_pass http://172.17.8.10{1|2|3}:$port/;
+      proxy_pass http://172.17.8.101:$port/;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection $connection_upgrade;

メタデータのおかげで「サービスNo.1のサービスは必ずIPアドレスが172.17.8.101のマシン上で動いている」ことが保証されるため、nginx.conf側のIPアドレスを固定できるようになっている。