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

注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 どうすんの、とかもまったく扱わない

完成イメージ

作業の概要

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

作業手順

VPCルータを作成＆設定

作成

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

インタフェース設定

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

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

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

NAT設定

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

ファイアウォール設定

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

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

サーバを作成

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

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

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

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

作成

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

VIP設定

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

実サーバ設定

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

サーバ設定

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構成の設定方法が紹介されていたので、これに則る. が、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監視の設定を入れる.

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

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

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

所感

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

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