■目次
KUSANAGI for AWSKUSANAGI for AWS(2台構成)メモ
■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の証明書を選択しているので、サーバ設定を変更しませんでした。 完了しました。