サイトのお引越し
閲覧数:
28(0)
このサイトは2014年からAWS EC2上の「Amazon Linux」インスタンスで稼働していましたが、この度、同じEC2上ではありますが「Amazon Ubuntu」で稼働するインスタンスへ引越しました。Linux OSとしてはRedHat系からDebian系への移行です。従って見た目は変わりませんが稼働環境は「APACHE(+PHP) + MySQL」から「NGINX + HHVM + MariaDB」へと大きく変わりました。TLS(SSL)は従来通り「Let’s Encrypt」のサービスを利用しています。
手順としては「Amazon Ubuntu」の別インスタンスをEC2上に作成し、MediawikiやWordPressなどのベースソフトウェアを構築していきます。データベースはネットワークを介してmysqldump/mysqlでダンプ/リストアすることで移行します。画像は対象フォルダを一旦zip等で圧縮ファイル化しwgetで新しいサーバーからzipファイルを取得する方法で行いました。データの移行が完了したら、プライベートホストで稼働確認を行った後、新旧のインスタンスを停止、Elastic IPを一旦開放しDNS登録されているIPアドレスを新インスタンスへ切替て再起動後、TLS設定を行えば引越は完了です。
NGINXはApacheと違い.htaccessが使えないので「ReWrite」などのやり方で随分と悩みました。特にLet’s Encryptの「certbot-auto」で「ドメインのルートをルートフォルダにしているが、ルートアクセスをサブフォルダへリダイレクトしている」状況では「webroot」認証が使えず困りました。解決策としては、証明するドメインはルートだけど、サブフォルダを「webroot」に指定することで回避出来ました。
WordPressではメディアのアップロードサイズの指定が「upload_max_filesize=5M」だけでは有効にならず困りました。結論としてはhhvmの設定のみでOKでした。必要だったのは「hhvm.enable_zend_ini_compat = false」という設定です。これでメディアのアップロード画面で最大サイズが表示されるようになりました。それまでは「0B」となっていてアップロードは出来るのですが制限がかかるのかかからないのか分からない状態でした。現在は「5MB」と指定したサイズが表示されます。
; php options date.timezone='Asia/Tokyo' upload_max_filesize=5M ; hhvm specific hhvm.log.level = Warning hhvm.log.always_log_unhandled_exceptions = true hhvm.log.runtime_error_reporting_level = 8191 hhvm.mysql.typed_results = false hhvm.enable_zend_ini_compat = false
アップロードされた画像ファイルなどを「直リンク」出来ないようにするには、以下の設定を追加します。「server_names」は「server_name」ディレクティブに書かれたサーバーが有効なリファラーになるという意味です。この設定では403を返していますが、トップページへ飛ばすなどの指定も可能です。
location ~* \.(png|jpg|jpeg|gif|ico)$ {
valid_referers server_names;
if ( $invalid_referer) {
return 403;
}
}
「HHVM」ではWordPressのプラグインで対応していないモノがあり管理画面の「投稿一覧」などが白紙となってしまいました。原因となったプラグインは「Related Post」でプラグイン側の設定で拡張機能を制限することで回避出来ました。最初はNGINXのアクセス設定では無いかと思い無駄な時間を使いました。HHVMとPHPの互換性は現在がMAXで今後はどんどん離れて行くようです。「FaceBook」と「Mediawiki(Wikipedia)」はHHVM移行を明言していますが「WordPress」はどうなるやら。本体はHHVM対応するのでしょうがプラグイン達は全部対応出来るとは思えません。MediawikiもエクステンションのHHVM対応は怪しい感じです。
超高速Webサイト構築を目指した「NGINX ＋ HHVM」化ですが、サーバー自体のパフォーマンス(t2.nano)がプアだとその「高速度」は実感出来ませんねw
