HTTPS の Wordpress を AWS LightSail に移行

経緯

弊社で運用している一部のサーバはクラウド事業者の VPSWordPress 環境を構築し、そこに証明書を入れて HTTPSWordPress を運用していました。 ただ、VPS の月額料金や証明書の更新に関わる購買や更新手続きといったコストといった点が問題視されていました。

無料の証明書である Let's Encrypt も考えましたが、できるだけ仕掛けを作らずに証明書の更新作業を自動化したいと考えました。 VPS の月額コスト見直しのタイミングもあったので、AWS LightSail に移行し証明書を自動更新する仕組みに切り替えました。

AWS LightSail とは

LightSail とは、AWS が提供する VPS サービスで、SSL アクセラレータ機能のあるロードバランサー(以下 LB )も使えます。 この LB には DNS 認証による無料の SSL/TLS 証明書を簡単に組み込むことができます。

SSL アクセラレータとは

SSL アクセラレータとは通信を TLS/SSL で暗号化する際に、暗号化や複合化の処理を専門に行う機能のことです。

  • 証明書管理の一元化
  • 負荷分散

といった効果があります。

今回の通信経路を図にすると以下のようになります。

f:id:kobayashi-ryotaro:20181127155450j:plain

LightSail ロードバランサー 作成

  1. AWS のコントロールパネルから LightSail のホーム画面に入ります。 f:id:kobayashi-ryotaro:20181127163621p:plain
  2. 「ネットワーク」→「ロードバランサーの作成」と進みます。 f:id:kobayashi-ryotaro:20181127164020p:plain
  3. 作成画面でリージョンや名前を設定して「ロードバランサーの作成」を押下します。HTTPS の設定は後で行います。 f:id:kobayashi-ryotaro:20181127164345p:plain
  4. ロードバランサー管理画面の「インバウンドトラフィック」で証明書の設定を行います。必要な項目を設定してください。 f:id:kobayashi-ryotaro:20181127165554p:plain
  5. ドメインの認証が終われば証明書の組み込みが完了します。 f:id:kobayashi-ryotaro:20181127165948p:plain

LightSail インスタンス作成

  1. ホーム画面から「インスタンス」→「インスタンスの作成」を押下します。 f:id:kobayashi-ryotaro:20181127170755p:plain
  2. 今回はWordPressの移行ということでバージョンの差異を懸念し、インスタンスイメージは「 OS のみ」「Amazon Linux」にしました。 f:id:kobayashi-ryotaro:20181127171149p:plain
  3. インスタンスプランを選んで名前を設定し、「インスタンスの作成を」押下してしばらくお待ちください。 f:id:kobayashi-ryotaro:20181127171316p:plain
  4. 作成が完了したら、先ほど作成したロードバランサーのターゲットインスタンスとして設定してください。 f:id:kobayashi-ryotaro:20181127172335p:plain
  5. 作成されたインスタンスにはパブリック IP で SSH 接続ができます。 f:id:kobayashi-ryotaro:20181127172544p:plain

WordPress の移行

WordPress はデフォルトだと ApachephpMySQL ですが、今回の環境は nginx+php-fpm + MySQL です。 各ミドルウェアのインストールや設定は割愛します。

移行に関しては基本的に

を移行すれば大丈夫です。

WordPressHTTPS

設定を間違えるとリダイレクトループしたりレイアウトが崩れるので注意してください。

リダイレクトループ対策

リダイレクトループとは、以下のようなループ現象です。

  1. LB が http で受ける
  2. LB が Web サーバに http で渡す
  3. Web サーバが301を返して https にリダイレクト
  4. LB が https で受ける
  5. LB が Web サーバに http で渡す
  6. Web サーバが301を返して https にリダイレクト
  7. 4に戻る

これを避けるために、nginx のコンフィグの server ディレクティブに以下の設定を追記します。 証明書に関する記述があれば削除してください。

   if ($http_x_forwarded_proto != https) {
      return 301 https://$host$request_uri;
    }

世の多くの LB や CDN は、自身を通過したときに http の拡張ヘッダである http_x_forwarded_proto に値を入れます。 これは配下のサーバが、もともとのアクセスが http なのか https なのかを判断可能にするためです。

この値を利用することで以下のような流れになり、ループを回避できます。

  1. LB が http でリクエストを受ける
  2. LB が http_x_forwarded_proto に http を入れて Web サーバに http で渡す
  3. Web サーバが http_x_forwarded_proto を評価し、http なので301を返して https にリダイレクト
  4. LB が https でリクエストを受ける
  5. LB が http_x_forwarded_proto に https という値を入れて、Web サーバに http で渡す
  6. Web サーバが http_x_forwarded_proto を評価し、 https なのでバックエンドにリクエストを渡す

WordPress の設定

こちらは設定を間違えるとレイアウトが崩れたりします。

wp-config.php に以下の設定を追記します。 php のアプリケーションは $_SERVER['HTTPS'] を評価してプロトコルを判定していることが多いためです。WordPress も例外ではありません。

  if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
      $_SERVER['HTTPS'] = 'on';

WordPressCSS の作成で自己参照することがあるのですが、こうすることでレイアウト崩れを防ぐことができます。

効果

証明書の自動更新機能で運用コストの削減ができました。 また DNS サービスである Route 53 を使えば AWS アカウントですべて管理でき、とても便利です。

まとめ

nginx や wordpress の移行作業が手間ではありますが、今回の移行により証明書の管理から解放されました。 手軽に HTTPSWordPress を作成したい場合は LightSail を検討してはいかがでしょうか。