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

# はじめに
この記事は「[簡単にopenstfの環境をMac上にゼロから構築する方法](http://qiita.com/k_keisuke/items/77144fc47951a6adf697)」にておこなっている細かな設定や課題を全て吸収したものになります。
**多分これが一番楽だと思います**。

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

- 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をインストールする
変更なしです。
[元記事](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#virtualboxvirtualbox-extension-packvagrantfleet%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B)を参考にしてください

# RethinkDBを構築する(変更あり)
service起動の修正が不要になりました。そのため、```vagrant up```を実行するだけで良くなっています

```text:cmd
$ cd stf-setup-examples
$ cd db
$ vagrant up
```

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

## Vagrantfileを修正する(一部変更あり)
手順として、「[接続予定のデバイスを登録する](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#%E6%8E%A5%E7%B6%9A%E4%BA%88%E5%AE%9A%E3%81%AE%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%82%92%E7%99%BB%E9%8C%B2%E3%81%99%E3%82%8B)」のみでOKです。なお、メモリは今回1Gに増やしています。

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

```text:cmd
$ cd coreos
$ vagrant up
```

## fleetの設定と確認
変更なしなので、[前回の記事](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#fleet%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8%E7%A2%BA%E8%AA%8D)を参考に。

## STF関連のサービスをデプロイする(変更あり)
１カ所を除いて[前回](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#stf%E9%96%A2%E9%80%A3%E3%81%AE%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%92%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%81%99%E3%82%8B)と同じ。

違うのは**[nginx.confを修正する](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#nginxconf%E3%82%92%E4%BF%AE%E6%AD%A3%E3%81%99%E3%82%8B)の手順がまるまる不要になっている。**ここで必要な変更は全てgithubにて更新済みになっている。

# openstfのページを開く
変更なし

# オリジナルからの変更点詳細
2017/3/6現在の、オリジナルとの修正差分

## rethinkdbが正しく起動しない問題に対応
前回の[「Vagrantfileを修正する」の変更](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#vagrantfile%E3%82%92%E4%BF%AE%E6%AD%A3%E3%81%99%E3%82%8B)を反映

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

## coreosのメモリを512->1024に変更
前回の[coreOSのメモリを増やす(任意)の変更](http://qiita.com/k_keisuke/items/77144fc47951a6adf697#coreos%E3%81%AE%E3%83%A1%E3%83%A2%E3%83%AA%E3%82%92%E5%A2%97%E3%82%84%E3%81%99%E4%BB%BB%E6%84%8F)を反映

```text: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: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: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**を追加している。

```text: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」という値が付与される
<img width="421" alt="スクリーンショット 2017-03-06 12.15.49.png" src="https://qiita-image-store.s3.amazonaws.com/0/76726/57e5457e-0f20-c7e2-2791-26c8b5f23546.png">

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

```text:stf-provider@.service
 [X-Fleet]
-Conflicts=stf-provider@*.service
+MachineMetadata=index=%i
```

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

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

```nginx: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アドレスを固定できるようになっている。