さくらのクラウドに、普通のAPP+DBサーバ環境を構築してみた


「さくらのクラウド」でクーポンをいただいていたので、商用でも使えるようなふつーのサービス環境をつくるのにどういうことをやればいいのか、ということを試してみた. そのログ.

注1: 実験レベルの設計＆設定なので、とくにネットワーク設定周りは丸パクリしない方がいいかも.
注2: 料金や機能などは投稿当時のものです.

# 環境の概要

* ひとまずWordPressを動かしてみる
* APPサーバx2(app1, app2), DBサーバx1(db1), HTTPロードバランサ(www)
* APPサーバとDBサーバではセグメントをわける(APP:192.168.0.0/24, DB:192.168.1.0/24)
* ミドルウェアから上は面倒なので、全ホストCoreOSで構成して、あとはDockerでゴニョる
	* fleet を使ったり、Docker のマルチホストネットワーク機能とかは、ここでは扱わない
	* Blue-Green Deployment どうすんの、とかもまったく扱わない

# 完成イメージ

![スクリーンショット 2016-03-24 16.25.52.png](https://qiita-image-store.s3.amazonaws.com/0/1329/f4397092-19f7-d7d0-29e3-b12113692eb7.png "スクリーンショット 2016-03-24 16.25.52.png")

# 作業の概要

* VPCルータを作成＆設定
* サーバを作成
* ロードバランサを作成＆設定
* サーバ設定
* 動作確認
* APPサーバの増設
* DNSの設定
* 監視の設定

# 作業手順

## VPCルータを作成＆設定

### 作成

ダッシュボードのメニューから、VPCルータを起動する.
ここでは、 wp_vpc という名前を指定.

![スクリーンショット 2016-03-24 18.01.51.png](https://qiita-image-store.s3.amazonaws.com/0/1329/65e71c59-83d2-4424-ccec-43befac3d681.png "スクリーンショット 2016-03-24 18.01.51.png")

### インタフェース設定

プライベートネットワークの設定を入れる. それぞれの接続先として「新規スイッチを作成」を指定する.

ここでは、各セグメントを以下のように運用することとし、インタフェースには .1 を割り当てる.
接続先のスイッチを作成した後、それぞれに名前をつけておくと便利.

* 192.168.0.0/24 → APPサーバのあるpublicセグメント(wp_vpc_public)
* 192.168.1.0/24 → DBサーバのあるprivateセグメント(wp_vpc_private)

![スクリーンショット 2016-03-24 18.15.54.png](https://qiita-image-store.s3.amazonaws.com/0/1329/cddae315-5407-a620-59e4-ed94659d9123.png "スクリーンショット 2016-03-24 18.15.54.png")

### NAT設定

グローバル側80番ポート(HTTP)への接続を、このあと作成するロードバランサのVIPである 192.168.0.10:80 へ変換する設定を入れる.

![スクリーンショット 2016-03-24 18.16.07.png](https://qiita-image-store.s3.amazonaws.com/0/1329/869f4092-e8b9-3790-20c5-ca5fd6be6e4e.png "スクリーンショット 2016-03-24 18.16.07.png")

### ファイアウォール設定

Inbound トラフィックについて、以下の通信のみ許容し、それ以外は拒否する設定を入れる.

* publicセグメントへのTCP80
* public <-> private 間のIPトラフィック

![スクリーンショット 2016-03-24 18.32.41.png](https://qiita-image-store.s3.amazonaws.com/0/1329/7a04a8c5-1c1a-e5f4-1e24-6a639be767c3.png "スクリーンショット 2016-03-24 18.32.41.png")

## サーバを作成

適当なサイズで、app1 と db1 を作成する. app2 はあとで app1 をクローンすることにする.

![スクリーンショット 2016-03-24 17.32.08.png](https://qiita-image-store.s3.amazonaws.com/0/1329/e9b2be63-5414-7028-b087-369cda64385f.png "スクリーンショット 2016-03-24 17.32.08.png")

作成時のディスクイメージとして CoreOS を指定する.

![スクリーンショット 2016-03-24 17.32.30.png](https://qiita-image-store.s3.amazonaws.com/0/1329/81d75493-8d47-76a7-1d28-e7c34bd223fa.png "スクリーンショット 2016-03-24 17.32.30.png")

接続先には、先ほどつくったそれぞれのセグメントのスイッチを指定し、ホストのIPアドレスにはそれぞれ .11 を指定する.
管理ユーザのパスワードは、後でコンソールから設定するときに使う.

![スクリーンショット_2016-03-24_19_27_06.png](https://qiita-image-store.s3.amazonaws.com/0/1329/4f2be8ae-302e-038a-624d-b637cc584d27.png "スクリーンショット_2016-03-24_19_27_06.png")

## ロードバランサを作成＆設定

### 作成

接続先スイッチとして、VPCルータ配下につくったpublicセグメントのスイッチを指定する.
ここで指定するIPv4アドレスは、VIPではなく、ロードバランサ自体に割り当てるものなので、 .2 を指定しておく.
名前は www とか適当につけておく.

![スクリーンショット_2016-03-24_19_18_06.png](https://qiita-image-store.s3.amazonaws.com/0/1329/1054ff72-1013-76c7-bd95-d76fe36abd95.png "スクリーンショット_2016-03-24_19_18_06.png")

### VIP設定

ここで、先ほどVPCルータにNAT設定した VIP = 192.168.0.10 を指定する.

![スクリーンショット 2016-03-24 19.24.13.png](https://qiita-image-store.s3.amazonaws.com/0/1329/ec858e38-81c9-fbf4-2481-a5ff4342f904.png "スクリーンショット 2016-03-24 19.24.13.png")

### 実サーバ設定

192.168.0.10:80 へのトラフィックのバランシング先を指定する.
ひとまず、192.168.0.11 の1台のみ追加しておく.

![スクリーンショット 2016-03-24 19.24.30.png](https://qiita-image-store.s3.amazonaws.com/0/1329/c61ed57c-e54e-8f7a-b9b7-e1eae956eb0d.png "スクリーンショット 2016-03-24 19.24.30.png")

## サーバ設定

### Dockerのアップデート

コンソールからログインし、以下のコマンドで Docker を最新版にする.

```
$ update_engine_client -update
```

### cloud-config.yml を編集

app1 には wordpress:latest を、db1 には mysql:latest をそれぞれセットアップする.
CoreOS 起動時の設定は `/usr/share/oem/cloud-config.yml` にあるので、これを編集する.

#### DBサーバの起動設定

APPサーバ起動時にDBホストを指定する必要があるので、まずは db1 から.
(コピペしたい場合は、ブラウザのコンソールからだとできないかもなので、適当にグローバルIPからNATさせるなり、sshの穴あけるなどしてください.)

iptables を更新する設定も入れておく.

```cloud-config.yml
# デフォルトのものに、下記を追記.

coreos:
  units:
    -
      name: mysql.service
      command: restart
      content: |
        [Unit]
        Description=mysql
        After=mysql.service
        Require=mysql.service
        
        [Service]
        ExecStart=/usr/bin/docker run -it -e MYSQL_ROOT_PASSWORD=secret -p 3306:3306 -d wordpress
        
        [Install]
        WantedBy=multi-user.target
```

`reboot` して再起動してきた後に `docker ps` して MySQL のコンテナが立ち上がっていることを確認する.

#### APPサーバの起動設定

app1 は、VIP:192.168.0.10 のバランシング先となる.
[マニュアルにはDSR構成の設定方法が紹介されていた](https://help.sakura.ad.jp/app/answers/detail/a_id/2517)ので、これに則る. が、CoreOS でのループバックアドレス追加設定が、よくわからなかった＆なんかうまくいかなかったので、iptables に NAT の PREROUTING 設定を入れ、VIP 向けの通信を受け入れるように設定しておく.

```cloud-config.yml
# デフォルトのものに、下記を追記.

coreos:
  units:
    - 
      command: iptables-restore.service
      enable: true
    -
      name: wordpress.service
      command: restart
      content: |
        [Unit]
        Description=wordpress
        After=wordpress.service
        Require=wordpress.service
        
        [Service]
        ExecStart=/usr/bin/docker run -it -e WORDPRESS_DB_HOST=192.168.1.11:3306 -e WORDPRESS_DB_USER=root -e WODPRESS_DB_PASSWORD=secret -p 80:80 -d wordpress
        
        [Install]
        WantedBy=multi-user.target

write_files:
  - 
    path: /var/lib/iptables/rules-save
    permissions: 0644
    owner: root:root
    content: |
      *nat
      -A PREROUTING -d 192.168.0.10 -j REDIRECT
      COMMIT  
```

`reboot` して再起動してきた後に `docker ps` して WordPress のコンテナが立ち上がっていることを確認する.

## 動作確認

Webブラウザを使って、VPCルータに割り当てられているグローバルIPアドレスをアクセスしてみる.
WordPress の初期設定画面が出てくれば成功.

## APPサーバの増設

### app1 を複製

ダッシュボードのサーバ詳細画面上部にある「クローン」を選択し、public セグメントに app1 のクローン app2 を作成する. IPアドレスは 192.168.0.12 とする. あとは app1 と同じ.

### ロードバランサの実サーバに追加

作成した app2 をロードバランサの実サーバとして追加する.
追加設定後は「反映」する.
Webブラウザで再度アクセスやリロードなどしてみて、疎通確認.

## DNSの設定

ゾーン持ち込むの面倒だったので、今回はやってない.
左にメニューがあるので、そこからできるぽい.

## 監視の設定

「シンプル監視」を使って、VPCルータのグローバルIPアドレスに対してHTTP監視の設定を入れる.

![スクリーンショット_2016-03-25_10_31_53.png](https://qiita-image-store.s3.amazonaws.com/0/1329/fda5a4f4-1ed3-511c-e9ec-12c3e44352c8.png "スクリーンショット_2016-03-25_10_31_53.png")

# でも、お高いんでしょう？

この構成で、月額18,037円(税込)(東京リージョンの場合).

WordPress ってサンプルがよくないか. それなりにスケールさせていきたい、ふつーのAPP+DBなサービスをつくると考えれば、うーん、うーん、迷う値段. データ転送料がかからないっていうのはいいですね.

![スクリーンショット 2016-03-25 10.40.41.png](https://qiita-image-store.s3.amazonaws.com/0/1329/5910819f-1bbf-47ef-cfa2-bb9fa935efe7.png "スクリーンショット 2016-03-25 10.40.41.png")

# 所感

楽しかったです. クーポンありがとうございました.
AWSよりも、ネットワーク機器周りいじってる感覚あるかな.
「スイッチ」「ルータ」とかそういう名称がメニュー内にあるからってのもあるか.

ちなみに、WordPress がやりたいんであれば、起動時のインストールスクリプトも使えるし、 [KUSANAGI for さくらのクラウド | KUSANAGI](https://kusanagi.tokyo/cloud/kusanagi-for-sakuracloud/) というパッケージがとても簡単に使えそうなので、わざわざ CoreOS でこんなことやらなくて良いです(やってみたかっただけ).

# 参考

* [さくらのクラウド｜さくらインターネット公式サポートサイト](https://help.sakura.ad.jp/app/cloud)
* [クラウドサービス仕様・料金 | さくらのクラウド](http://cloud.sakura.ad.jp/specification.php)
* [さくらのクラウドの料金シミュレーション｜さくらのクラウド](http://cloud.sakura.ad.jp/payment/simulation.php)