■KUSANAGI for AWS
KUSANAGI - 超高速WordPress仮想マシン [高速化チューニング済みWordPressサーバ]
https://kusanagi.tokyo/
以下、実際にKUSANAGI+WordPress環境を構築してみる
■KUSANAGIインスタンスの作成
KUSANAGI for AWS - KUSANAGI
https://kusanagi.tokyo/cloud/kusanagi-for-aws/
・EC2は t2.medium 以上（メモリ4GiB以上）を推奨らしいが、お試しなので t2.micro を選択した
・自動割り当てパブリックIPは、お試しなので有効化した
・ネットワークとサブネットは、テスト用に作成済みのものを選択した
・セキュリティグループは、テスト用に作成済みのものを選択した
・キーペアは、テスト用に作成済みのものを選択した
・インスタンス作成後、Nameに「kusanagi_web1」を設定した（任意の名前）
・Elastic IP はお試しなので設定せず
以下の情報で接続
ホスト: 203.0.113.1
ポート: 22
ユーザ名: centos（KUSANAGIのデフォルトユーザ）
パスワード: （なし）
鍵: （EC2作成時に選択したもの）
■KUSANAGIの初期設定
KUSANAGIの初期設定 - KUSANAGI
https://kusanagi.tokyo/document/kusanagi-init/
# kusanagi init --tz tokyo
# kusanagi init --lang ja
を一つずつ実行して設定していく…のではなく、あくまでも
# kusanagi init
を実行するのみでひととおりの設定を行う
その際「--tz tokyo」や「--lang ja」のオプションがあれば、そのまま設定される…みたい
「2. TLS用ホスト鍵ファイルの生成」は、はじめて kusanagi init を実行した時に作成されるみたい
ユーザパスワード＆鍵パスワードとして以下を設定
Hr3y9BPa2Q
鍵ファイルが作成される
Your identification has been saved in /root/kusanagi.pem.
Your public key has been saved in /root/kusanagi.pem.pub.
MySQLパスワードとして以下を設定
Ke82MgqEaP
設定完了時、以下が表示された
innodb_buffer_pool_size = 384M
query_cache_size = 128M
monit is already on. Nothing to do.
以下の情報で同サーバにログインできる
ユーザ名: kusanagi
パスワード: Hr3y9BPa2Q
鍵: kusanagi.pem
※kusanagiユーザはrootになれないみたい
■KUSANAGIのプロビジョニング
KUSANAGIのプロビジョニング - KUSANAGI
https://kusanagi.tokyo/document/kusanagi-provision/
centosユーザからrootになった状態で、引き続き設定
# kusanagi provision wordpress
… ★www よりも wordpress や refirio など、プロジェクト名を設定するほうが自然かも
ホスト名は以下を設定するものとする
… ★www.example.com はCloudFrontのドメイン設定でエラーになるので、他のものにした方が良さそう
www.refirio.net
Let's Encrypt は使わない（ENTERを2回押して、メールアドレスの入力を飛ばした）
データベース名は以下を設定した
… ★WordPress用なのだから、データベース名は「wordpress」の方がいいかも
kusanagi
データベースのユーザ名は以下を設定した
kusanagi
データベースのパスワードは以下を設定した
rJg3e9BApQ
設定完了時、以下が表示された
wordpress のプロビジョニングは完了しました。www.refirio.net にアクセスし、WordPressをインストールしてください!
完了しました。
新しいメールが /var/spool/mail/root にあります
以下にアクセスするとnginxの画面が表示される
http://203.0.113.1/
以下にアクセスするとWordPressのインストール画面が表示される
http://www.refirio.net/
テストで仮のドメインを設定した場合、hostsファイルを編集してアクセスする
C:\Windows\System32\drivers\etc\hosts
203.0.113.1 www.refirio.net
公開フォルダは以下になる
/home/kusanagi/wordpress/DocumentRoot/
以下のようにすると、届いたメールを確認できる（Monitに関するメールが届いている）
# vi /var/spool/mail/root
■WordPressのインストール
WordPressのインストール - KUSANAGI
https://kusanagi.tokyo/document/wp-install/
手順通りにWordPressをインストール
必要に応じて、プラグインの設定なども行う
サイトのタイトル: KUSANAGI
ユーザ名: kusanagi
パスワード: u#M@dERCAo^8v62S*X
メールアドレス: refirio@example.com
ここまでで、設置自体はいったん完了
ダッシュボードの「セキュリティ状況」に推奨設定が表示されているので、可能なら調整する
■Gitからのデプロイに対応
★このタイミングで設定し、その後サーバを複製すると良さそう
git.txt をもとに、デプロイの仕組みを構築しておく
■KUSANAGI for AWS（2台構成）
■方針の確認
以下の方針で進めてみる
・KUSANAGIインスタンスを2台構成にする
・プログラムはrsyncで同期させる
・データベースはRDSを使わずに、MySQLをレプリケーションさせる
新規にKUSANAGIインスタンスを作るのではなく、既存のKUSANAGIインスタンスを複製する方が良さそう
新規に作ると、SSHアクセスの鍵ファイルが別々になる。後から調整はできるだろうけど、他にも何かと調整が必要になるかも
たった30分でWordPressを冗長化する方法 - (っ´∀｀)っ ゃー
https://nullpopopo.blogcube.info/2012/08/%E3%81%9F%E3%81%A3%E3%81%9F30%E5%88%86%E3%81%A7wordpress%E3...
■ホスト名の設定
※KUSANAGIに関係なく、ホスト名はピリオドがないと正しく動作しないことがあるらしい
hostnamectl set-hostname web1.kusanagi80
… 以降、CentOS7用の手順でホスト名を設定
hostnamectl
hostname
vi /etc/hosts
127.0.0.1 localhost web1.kusanagi80 localhost4 localhost4.localdomain4 web1.kusanagi80
vi /etc/sysconfig/network
HOSTNAME=web1.kusanagi80
なかなか変わらなかったが、「hostname」ではなく「hostnamectl set-hostname」で変更する必要があったのかも？
□補足1
以下はホスト名の設定に関係ないみたい
ホスト名変更方法-AWS-Kusanagi-CentOS7 - MacoTrip
https://makotoiwasaki.com/2015/11/%E3%83%9B%E3%82%B9%E3%83%88%E5%90%8D%E5%A4%89%E6%9B%B4%E6%96%B9%E6...
vi /etc/cloud/cloud.cfg
- set_hostname
- update_hostname
- update_etc_hosts
#- set_hostname
#- update_hostname
#- update_etc_hosts
□補足2
以下を設定すると、バーチャルホストの設定がおかしくなった
これはホスト名の設定には関係ないみたい
kusanagi status
… プロファイルを確認
kusanagi setting --fqdn web1.kusanagi80 wordpress
… kusanagiコマンドでホストを設定
kusanagi restart
… kusanagiを再起動
/etc/nginx/conf.d/wordpress_http.conf にある以下の設定が書き換わっている
server_name web1.kusanagi80 ;
以下を設定すると元に戻った
kusanagi setting --fqdn www.refirio.net wordpress
kusanagi restart
■インスタンスの複製
インスタンス「kusanagi_web1」から、AMI「kusanagi_web1-20171120」を作成する
AMI「kusanagi_web1-20171120」から、インスタンス「kusanagi_web2」を作成する
・ネットワークは同じもの、サブネットは kusanagi_web1 とは別のものを選択した（マルチAZ）
IPアドレス以外 kusanagi_web1 と同じで、kusanagi_web2 にログインできることを確認する
WordPressも動作していることを確認する（確認には、hostsファイルの編集が必要）
Web1: 203.0.113.1 / 10.0.1.145 [Master]
Web2: 203.0.113.2 / 10.0.0.116 [Slave]
■サーバ設定の調整
複製したインスタンスでは、ロケールの設定が元に戻っているので調整
# localectl status
# localectl set-locale LANG=ja_JP.UTF-8
■レプリケーションの設定
□Master
$ curl
http://10.0.0.116/ … 疎通テスト
# vi /etc/my.cnf
… レプリケーション設定
[mysqld]
log-bin=mysql-bin
server-id = 1001
# service mysql restart
… MySQLを再起動（CentOS6の場合）
# systemctl restart mysql
… MySQLを再起動（CentOS7の場合）
# mysql -u root -p
… MySQLに接続
Ke82MgqEaP
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@10.0.0.116 IDENTIFIED BY 'KeL38BarEm';
mysql> FLUSH PRIVILEGES;
… レプリケーション用ユーザ追加
mysql> SELECT host,user FROM mysql.user;
mysql> FLUSH TABLES WITH READ LOCK;
… データ手動コピー前にテーブルロック
mysql> SHOW MASTER STATUS;
… バイナリログの名前（File）と位置（Position）を確認
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000002 | 634 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
# cd /var/lib/mysql
… MySQLのデータをバックアップ
# ll
# tar czf kusanagi.tar.gz kusanagi
mysql> UNLOCK TABLES;
… データ手動コピー後にテーブルロック解除
/var/lib/mysql/kusanagi.tar.gz をSlaveサーバの同じ場所へ転送しておく
□Slave
$ curl
http://10.0.1.145/ … 疎通テスト
$ mysql -h 10.0.1.145 -u repl -p
… 疎通テスト
KeL38BarEm
# service mysql stop
… MySQLを停止（CentOS6の場合）
# systemctl stop mysql
… MySQLを停止（CentOS7の場合）
# cd /var/lib/mysql
… MySQLのデータをバックアップから復元
# mv kusanagi kusanagi.backup
# tar xvzf kusanagi.tar.gz
# vi /etc/my.cnf
… レプリケーション設定
[mysqld]
server-id=1002
# service mysql start
… MySQLを起動（CentOS6の場合）
# systemctl start mysql
… MySQLを起動（CentOS7の場合）
# mysql -u root -p
… MySQLに接続
Ke82MgqEaP
mysql> CHANGE MASTER TO
… Masterへの接続情報を設定
MASTER_HOST='10.0.1.145',
MASTER_USER='repl',
MASTER_PASSWORD='KeL38BarEm',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000002',
… 「SHOW MASTER STATUS」で確認した「File」
MASTER_LOG_POS=634;
… 「SHOW MASTER STATUS」で確認した「Position」
mysql> FLUSH PRIVILEGES;
mysql> START SLAVE;
… レプリケーションを開始
□いったん動作確認
Master側でテーブルを作成＆データを登録し、Slave側にも反映されていることを確認する
■WordPressの接続設定を調整
□Master＆Slave
mysql> GRANT ALL PRIVILEGES ON kusanagi.* TO kusanagi@10.0.1.145 IDENTIFIED BY 'rJg3e9BApQ';
… WordPress用ユーザ追加
mysql> GRANT ALL PRIVILEGES ON kusanagi.* TO kusanagi@10.0.0.116 IDENTIFIED BY 'rJg3e9BApQ';
… WordPress用ユーザ追加
mysql> FLUSH PRIVILEGES;
mysql> SELECT host,user FROM mysql.user;
□両方のサーバにHyperDBをインストール
HyperDB - WordPress Plugins
https://wordpress.org/plugins/hyperdb/
「HyperDB」WordpressでDBの冗長化・負荷分散を行うプラグイン | 株式会社ビヨンド
http://beyondjapan.com/blog/2016/05/hyperdb-wordpress
# cd
… rootのホームディレクトリで作業
# wget
http://downloads.wordpress.org/plugin/hyperdb.zip … HyperDBをダウンロード
# unzip hyperdb.zip
… ファイルを展開
# cd hyperdb
… 展開して作成されたディレクトリへ移動
# cp db-config.php /home/kusanagi/wordpress/DocumentRoot/
… db-config.phpをコピー
# chown kusanagi. /home/kusanagi/wordpress/DocumentRoot/db-config.php
… db-config.phpの所有者を調整
# cp db.php /home/kusanagi/wordpress/DocumentRoot/wp-content/
… db.phpをコピー
# chown kusanagi. /home/kusanagi/wordpress/DocumentRoot/wp-content/db.php
… db.phpの所有者を調整
# cd /home/kusanagi/wordpress/DocumentRoot/
… 公開ディレクトリへ移動
# vi db-config.php
217行目あたり
$wpdb->add_database(array(
'host' => DB_HOST, // If port is other than 3306, use host:port.
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
));
以下のように編集（「write」と「read」の指定を追加）
$wpdb->add_database(array(
'host' => DB_HOST, // If port is other than 3306, use host:port.
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 1,
'read' => 1,
));
228行目あたり
$wpdb->add_database(array(
'host' => DB_HOST, // If port is other than 3306, use host:port.
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 0,
'read' => 1,
'dataset' => 'global',
'timeout' => 0.2,
));
以下のように編集（「host」の指定を変更）
$wpdb->add_database(array(
'host' => DB_HOST_RO, // If port is other than 3306, use host:port.
'user' => DB_USER,
'password' => DB_PASSWORD,
'name' => DB_NAME,
'write' => 0,
'read' => 1,
'dataset' => 'global',
'timeout' => 0.2,
));
# cp -p wp-config.php wp-config.php.backup
… WordPressの設定ファイルをバックアップ
# vi wp-config.php
… WordPressの設定ファイルを編集
32行目あたり
define('DB_HOST', 'localhost');
以下のように編集
//define('DB_HOST', 'localhost');
define('DB_HOST', '10.0.1.145');
define('DB_HOST_RO', '10.0.0.116');
□動作確認
・Master側で記事を投稿し、Slave側にも記事が反映されていること
・Slave側で記事を投稿し、Master側にも記事が反映されていること
・Slave側のmysqldを止めても、サイト閲覧に問題がないこと
・Slave側のmysqldを止めても、記事の投稿ができること
・Master側のmysqldを止めても、サイト閲覧に問題がないこと
Slaveを止めても、問題なく投稿閲覧できた
Masterを止めても、問題なく閲覧できた…と思ったが、ページによってはDBの更新が走るので（？）エラーになる（下記のエラー）
管理画面にログイン中だと、操作履歴の記録処理などが走るからかも
管理画面からログアウト中なら、トップページにも個別画面にもアクセスできた
コメントを投稿しようとしたらエラーになった（下記のエラー）
Masterを再度起動させると、コメント投稿などもできるようになった
ERROR
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.
エラーは「CloudFrontからサーバに接続できませんでした」という内容
Post時にエラーコードが返されたためと思われる
■rsyncの設定
□準備
サーバメモ Etcetera.txt の「rsync（一方向同期）」「rsync（双方向同期）」をもとに、双方向同期の仕組みを構築しておく
□同期を停止させておく
web1&web2:
# sudo su -
# systemctl stop lsyncd.service
□コマンドで同期できることを確認しておく
web1:
# cd /var/www/html/rsync
# rsync -e "ssh -p 22" -avz --delete /var/www/html/rsync rsync@10.0.0.116:/var/www/html
web2:
# cd /var/www/html/rsync
# rsync -e "ssh -p 22" -avz --delete /var/www/html/rsync rsync@10.0.1.145:/var/www/html
□公開フォルダを退避
web1&web2:
# cd /home/kusanagi/wordpress
# mv DocumentRoot DocumentRootTmp
# mkdir DocumentRoot
# chown kusanagi. DocumentRoot
# chmod 0775 DocumentRoot
□上位ディレクトリのパーミッションを調整
# chmod 0775 /home/kusanagi
□公開フォルダで同期をテスト
web1:
# vi DocumentRoot/index.php
# rsync -e "ssh -p 22" -avz --delete /home/kusanagi/wordpress/DocumentRoot rsync@10.0.0.116:/home/kusanagi/wordpress
web2:
# vi DocumentRoot/test.php
# rsync -e "ssh -p 22" -avz --delete /home/kusanagi/wordpress/DocumentRoot rsync@10.0.1.145:/home/kusanagi/wordpress
□自動同期対象を変更
web1&web2:
# vi /etc/lsyncd.conf
/var/www/html/rsync
↓
/home/kusanagi/wordpress/DocumentRoot
※2箇所あるパスを修正
# systemctl start lsyncd.service
自動同期を確認後、また停止させておく
# systemctl stop lsyncd.service
□公開フォルダを戻す
web1で公開ディレクトリ内をWordPressに戻す
（web2では公開ディレクトリ内をカラにしておく）
# mv DocumentRoot DocumentRootTmp2
# mv DocumentRootTmp DocumentRoot
□グループを調整
★必要か？この設定でいいか？要検証＆テスト環境を要確認
# usermod -a -G kusanagi rsync
… これは必要そう。あとは不要そう
# gpasswd -d rsync kusanagi
# cat /etc/group
□ファイルの所有者を調整
web1&web2:
/home/kusanagi/wordpress 内で作られたファイルの所有者を kusanagi にする
# chown kusanagi. /home/kusanagi/wordpress
# chmod 0775 /home/kusanagi/wordpress
# chmod g+s /home/kusanagi/wordpress
web1:
# find /home/kusanagi/wordpress -type d -print | xargs chown kusanagi.
# find /home/kusanagi/wordpress -type f -print | xargs chown kusanagi.
□WordPressを同期
web1の公開ディレクトリ内はWordPress、
web2の公開ディレクトリ内はカラ、
という状態でweb1で以下を実行。同期テストする
# rsync -e "ssh -p 22" -avz --delete /home/kusanagi/wordpress/DocumentRoot rsync@10.0.0.116:/home/kusanagi/wordpress
完了したら、web2からも同期をテストする
# rsync -e "ssh -p 22" -avz --delete /home/kusanagi/wordpress/DocumentRoot rsync@10.0.1.145:/home/kusanagi/wordpress
どちらも大丈夫なら、自動同期を開始してテストする
# systemctl start lsyncd.service
自動同期も大丈夫なら、管理画面から記事の登録やメディアのアップロードなどをテストする
■ロードバランサーの導入
Application Load Balancer
ロードバランサーの名前: Kusanagi
スキーマ: インターネット向け（後から「内部」に変更する予定）
ターゲットグループの名前: Kusanagi
http://www.refirio.net/
http://203.0.113.1/
http://203.0.113.2/
http://Kusanagi-123456789.ap-northeast-1.elb.amazonaws.com/
□ロードバランサー経由でテストアクセス
hostsファイルでの対応はIPアドレスに対する紐付け
ロードバランサーはCNAMEでのアクセスなので、そのまま設定はできない
ロードバランサーのIPアドレスを調べて設定することは可能（ただしIPアドレスは時々変わる）
$ nslookup Kusanagi-123456789.ap-northeast-1.elb.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: Kusanagi-123456789.ap-northeast-1.elb.amazonaws.com
Address: 13.112.149.63
Name: Kusanagi-123456789.ap-northeast-1.elb.amazonaws.com
Address: 54.65.155.42
C:\Windows\System32\drivers\etc\hosts
54.65.155.42 www.refirio.net
■CloudFrontの導入
Origin Domain Name: Kusanagi-123456789.ap-northeast-1.elb.amazonaws.com
Object Caching: Customize
Minimum TTL: 0
Maximum TTL: 0
Default TTL: 0
Alternate Domain Names(CNAMEs): www.refirio.net
http://123456789.cloudfront.net/
ロードバランサー同様、CloudFrontのIPアドレスを調べてhostsファイルに設定してアクセス
…と思ったが、「The request could not be satisfied.」というエラーになった
# nslookup 123456789.cloudfront.net
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: 123456789.cloudfront.net
Address: 13.33.0.85
Name: 123456789.cloudfront.net
Address: 13.33.0.91
Name: 123456789.cloudfront.net
Address: 13.33.0.94
Name: 123456789.cloudfront.net
Address: 13.33.0.114
Name: 123456789.cloudfront.net
Address: 13.33.0.132
Name: 123456789.cloudfront.net
Address: 13.33.0.216
Name: 123456789.cloudfront.net
Address: 13.33.0.34
Name: 123456789.cloudfront.net
Address: 13.33.0.77
以下でアクセスできる…が、Welcome to nginx! の画面になる
CloudFrontに専用の設定を行わないと、バーチャルホストの設定が反映されない
C:\Windows\System32\drivers\etc\hosts
13.33.0.85 www.refirio.net
□バーチャルホストに対応
[新機能] Amazon CloudFrontでHostヘッダを転送する ｜ Developers.IO
https://dev.classmethod.jp/cloud/cloudfront-host-header-forward/
CloudFront → 対象を選択 → Behaviors → 対象を選択 → Edit
「Cache Based on Selected Request Headers」を「Whitelist」に変更
「Accept」「CloudFront-Forwarded-Proto」「Host」「Referer」を追加
（バーチャルホストには「Host」が必要。他にも必要なものがあれば追加する）
■セッションを維持させる
EC2 → ターゲットグループ → 設定したいグループを選択して → 説明 → 属性の編集
維持設定
を
「ロードバランサーによって生成された Cookie の維持を有効化」
※設定しなくても、何故か管理画面のセッションは切れなかった？
KUSANAGIはセッションをデータベースで持っているとか？要調査
■引き続き
チュートリアル: 一般的な攻撃に対する保護のための AWS WAF の迅速な設定 - AWS WAF と AWS Shield アドバンスド
http://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/tutorials-common-attacks.html
・WAFを設定してWordPressを動作確認する
・CloudFrontのキャッシュ機能を確認する（メディアのみ？）
以下は試していないが、別案件で導入しているので省いていいかも？
・rsyncでの同期
・Gitからのデプロイ
■メモ
■ドメインを変更する
ConoHa KUSANAGI のドメインを変更したい | くらげさんの思考回路
https://www.kurage.net/tech/296
以下のように表示されたが、設定自体は完了しているみたい
# kusanagi setting --fqdn www.refirio.net
あなたは/etc/pkiの証明書を選択しているので、サーバ設定を変更しませんでした。
完了しました。