前回の記事にも書きましたがsystemd-nspawnを使ってサーバー内を思いっきりやり変えちゃいました。
「時間も増えたし、いい機会かな」とコンテナをコツコツ準備してOSインストールから一気にサイト稼働開始までやったので、結構書きたいことがいっぱいです。
てかsystemd-nspawnって名前長いし打つのダルい！改名を求む！
それともRocketに期待しようかしら。
今回行ったVPSの構成内容
通常はキャッシュサーバー専用のコンテナを設けるかホスト側に直接キャッシュさせたりするのが一般的かと思います。
いわゆるプロキシキャッシュですね。
が、今回はそのどちらでもなくFastCGIキャッシュをコンテナ内で行って、プロキシは本当にルーティングだけです。
HHVMが3本も動いてるのでメモリが心配ですね〜。
これは無駄なんです。
無駄なんですけどもともとコンテナ1しかHHVMを使う気なかったんです。
けど他のサイトも予想外にあっさり動いちゃって、でも今からやり変えるのめんどくさくて、とりあえず一旦上げてしまおうって思って・・・今組み替えてる最中です。
間違ってもメモリが1GBのVPSなんかではやめておいたほうがいいと思います。
今契約してるVPSならなんとかスワッピングも発生してません。
MariaDBはもともと一本しか動いてないですがこれも同じく分離させた方がいいでしょう。
この辺はまぁいいんです。
今回はNginxを分ける事が目的でしたから。
ホストNginx→コンテナ内Nginx間の接続はlocalhost接続をしておりますが、systemd-nspawnにはbindオプションがありますので、Unixドメインソケットで接続することも可能です。
詳しいことは前回の記事を参照して下さい。
ソケットの方が速いし負荷も少ないでしょう。
なぜこの構成にしたのか
- PHP実行環境をHHVMに移行したかった
- 気軽に色々試せる環境が欲しかった
- 開発機と本番機で環境を合わせるのが面倒
- まっさらな状態から構成し直したい時にOSインストールからやるのは面倒
- ホストが汚染されるとメンテする気すら起きなくなる
だいたいこんな感じ。
プロキシの設定を変えて即座に環境をスワップできるってのがミソ。
イメージとしてはこんなん。
WordPress高速化の為などにNginxの設定を弄くり回すと、結構設定ファイルの管理が面倒になってきます。
実際はプラグイン用の設定書き足しやサイトごとの個別設定なども入ってきますので、結局そのサイト専用の設定になることが多いはずです。
当然試行錯誤も繰り返して、「あれこれ要るんだっけ」とかなります。
他にもキャッシュ機構なんかが絡んでくるので、もういっそキャッシュ動作まで設定したNginx環境を丸ごとコンテナ化した方が楽かなと。
例えばWordPressとLaravelなんかじゃ全然違う設定になるよねって話。
え〜っとつまり「複数サイトの運用時にこんがらがる」って事です。
設定ファイル分けるだけってのはやっぱダメ。
だってhttpブロックも結構違ってたりするし。
それにこれならキャッシュごとスワップできるので何か新しいことを行ってマズい時は元のコンテナに戻せばいいだけ。
随分気が休まります。
しかもサーバーの移行にも備えられるので現VPSのスペックが気に入らなければ気兼ねなく移れます。
Nginxの設定ファイルの中身
ホスト側とコンテナ側で中身違います。
ホスト側が行うのはルーティングです。
対してコンテナ側はFastCGIキャッシュで構成しなければいけません。
ホスト側
http {
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto http;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
server {
listen 80;
server_name www.geeks-dev.com;
location / {
proxy_pass http://localhost:8081;
}
}
server {
listen 80;
server_name demo.geeks-dev.com;
location / {
proxy_pass http://localhost:8082;
}
}
}
コンテナ内 (WordPress)
server {
listen 8081;
server_name localhost;
charset utf-8;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
#〜〜〜〜以下省略〜〜〜〜
コンテナ内のserver_nameがlocalhostになってますが、これで問題なくキャッシュできるようです。
なのでこのコンテナを複製してまた別のWordPressを動かす時はlistenのとこさえ変えてあげればOK。
それぞれのドメインをどのコンテナに割り振るかはホスト側で指定します。
ドメインが増えてもserverブロックを追加するだけです。
ゲスト側は普通にFastCGIキャッシュを有効にしたオーソドックスな設定です。
WordPressに関してですが、FastCGIキャッシュの時ってWP Super Cacheは入れる意味あるんですかね？
というよりHHVMの場合プラグインがエラー吐いてるみたいなんで、入れませんでした。
オブジェクトキャッシュも問題なく使えるのはRedis系のプラグインだけみたいです。
一見普通に動いてるような振る舞いですけど、ログ見たら止まってる。
まとめ
冒頭でも述べた通り、このままだとHHVMのメモリ圧迫が不安になってきました。
とりあえず次回は、
- Nginx(ホスト)
- HHVM + Redis (コンテナ1)
- MariaDB (コンテナ2)
- Nginx:domainA (コンテナ3)
- Nginx:domainB (コンテナ4)
- Nginx:domainC (コンテナ5)
この5つのコンテナで、かつ全てソケット通信で構成してみます。
余裕があったらメールサーバーもやりたいなぁ。
※2015/02/11追記
全て書くのは億劫だったので、WordPressに話を絞って記事を書いてみました。