環境構築の際に行った工夫
以前、以下の記事でデータセンターからクラウドへ移行したことを書きました。
このとき、以前から利用していたDockerの適用範囲を広げ、Apache/Tomcat等もコンテナ化しました。 あわせて環境構築のためAnsibleの導入も行い、Nginxなどのミドルウェアの設定を環境ごとに定義して利用することにしました。 これにより、
- 環境構築が簡単になった
- 本番環境・検証環境・ステージ環境の構築手順を共通に出来た
- 本番環境と同一の手順で設定の反映の検証が行えるようになった
など、メリットがありました。
今回は、環境構築の際に行った工夫を書きたいと思います。
Ansibleでの環境構築
まずはインフラ設計を元に、必要なサーバ/ミドルウェアを洗い出します。 次に、セットアップするために必要な手順をAnsibleのplaybookへ書きます。 この時、環境ごとに共通する箇所と異なる箇所を確認して、各環境ごとに異なる箇所の設定をホストへ定義しました。 こうすることで、各環境ごとのセットアップの手順が同一となり、手間と失敗を防ぐことが出来ました。
Ansibleを利用したことで、設定をコードにすることが出来たこと、バージョン管理が出来たので後から変更履歴を把握することが出来たので作業がスムーズに進みました。 移行後に行った変更も同じ手順で作業することで、サーバの追加やミドルウェアのインストールも同様に行うことが出来ます。
環境ごとに異なる箇所は、主に以下の3つです。
サーバの名前とIPアドレス
各環境でサーバの接続手順を統一するため、IPアドレスではなく名前を利用するようにしました。 データベースに接続するにはdb01と指定すれば、各環境のdb01へ接続出来ます。 これにより、各種設定ファイルの定義を環境に応じて切り替える必要が無くなりました。
名前解決のため、内部向けにBINDでDNSサーバをセットアップして利用しています。セットアップ時に環境ごとのIPアドレスを設定ファイルへ反映します。 このセットアップにもAnsibleを利用し、DNSの設定も同様にホストで管理しています。 各環境のローカルIPを共通にするという方法もありますが、障害時やメンテナンス時にサーバを切り替えることも想定し、名前を利用を選択しました。。
サービスに利用するホスト名
もぐナビなら、mognavi.jp/mognavi.dev/mognaiv.stgのように、環境ごとに異なるホスト名があります。 環境ごとに異なる設定は環境変数を参照する方針をとりました。これはサーバ/Dockerともに共通します。 例えばホスト名は、環境変数"HOST_MOGNAVI"を参照して利用するようにしています。 ミドルウェアやDockerコンテナでは環境変数から設定を行うようにすることで、各環境で同一の設定ファイルを利用することが出来ました。
ミドルウェアのパラメータ
各環境で異なるハードウェアのスペックや外部要因を吸収しています。 本番環境ほどリソースに余裕が無い場合や処理能力が不要な場合、ミドルウェアが利用するメモリの量を減らしています。 また、本番環境以外で不要な設定を無効にしたりもしています。
リバースプロキシのセットアップ
リバースプロキシとしてNginxを導入し、コンテンツのキャッシュとSSLの処理に利用しています。 各環境で利用するにあたり、バックエンドの指定をIPアドレスではなく名前で行うようにしました。 念の為パフォーマンスのしましたが、IPアドレスに比べ低下することはありませんでした。
SSLの処理で利用する証明書は、ホスト名ごとのリポジトリで管理しています。 ホスト名は環境変数から環境ごとのものを参照して利用します。
Apacheのセットアップ
URLのリライトやUAに応じたリダイレクト等、アプリケーション固有の処理に利用しています。 ApacheはDockerコンテナで稼働するため、起動時にDockerホストから環境変数を通してホスト名を指定します。 Apacheのconfiでは、以下のように環境変数を参照して利用することが可能です。
# ${HOST_MOGNAVI}の部分がmognavi.jpになる
ServerName ${HOST_MOGNAVI}
# ${HOST_MOGNAVI_SP}の部分がs.mognavi.jpになる
RewriteCond %{ENV:device_type} sp [NC]
RewriteRule ^/$ https://${HOST_MOGNAVI_SP}/ [R=301,NE,L]
設定の中の環境に依存する箇所を環境変数から参照するようにすることで、各環境で共通の設定ファイルを利用出来るようになりました。
まとめ
移行に伴い環境構築で行った工夫を書きました。 Ansibleを利用することで設定のコード化/バージョン管理が出来たので、全体の把握が行いやすくなりました。 以前は環境ごとに設定ファイルを作成しており環境ごとに差異が出来てしまうことがありました。環境変数を利用することで、設定ファイルの共通化とバージョン管理を行うことが出来ました。