メモ > 技術 > 開発: KUSANAGI > KUSANAGI for AWS（2台構成）
■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...
/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からのデプロイ