16卒のエンジニアの徳田です。
今回、エンジニアブログ開設にあたって、ブログのインフラ環境をGoogle App Engine(以下GAE)上に構築してみました。
その際の経緯や環境の解説をしようと思います!
(この記事はGAEのクイックスタートを終えた、またDocker/コンテナについてある程度の知識がある方向けになっています)
GAE採用のわけ
単純な話ですが、運用する際の工数を落としたかったためです。VM上に構築するとなると、デプロイの処理や負荷分散対策、リソース監視などを考えなければならず、面倒です。
この辺りをマルっとやってくれるのがGAEです。(リソース監視は微妙ですが)
負荷の想定もそこまで厳しいものではなかったのと、オートスケールするので問題ないかなという判断でした。
次に、GAE上で動作させるアプリケーションですが、ブログサイトを見て分かる人には分かってしまいますがWordPressで動作しています。なのでGAEのRuntimeとしてはPHPとなります。
GAEには
の2種類の環境を使用することができます。
今回ブログの環境で採択したのは「Flexible Environment」でした。理由としてはPHP7が使用したい、というのが殆どです。
また、データストアで利用するDBにCloud SQLを選択し、メディアコンテンツについてはCloud StorageとCloud CDNを利用するようにしました。
ここから大きく分けて
- GAEのFlexible EnvironmentのPHP Runtimeについて
- GAEのFlexible EnvironmentとCloud SQLの設定
- メディアコンテンツ配信について
の3点を解説していこうと思います。
GAEのFlexible EnvironmentのPHP Runtimeについて
WordPressを動かすということでFlexible Environmentで使用するRuntimeはPHPになります。
Flexible EnvironmentでPHPが動作する最低限の設定ファイルが以下のようになります。
runtime: php
env: flex
シンプルですね。このファイルと同じ位置にindex.phpでも置いておけばそれが表示されるようになります。
そして「gcloud app deploy」コマンドでデプロイすることができます。
これで、アプリケーションとして動作する状態にはなっていますが、内部でどのように動いてるかがこれだけではさっぱりですね。
ということで、とりあえずデプロイしたときの動作を簡単に追って探ってみましょう。
「gcloud app deploy」をするとDockerのビルドが走るのが確認できると思います。このログを追うと、
- Cloud Container Builderを使用してイメージをビルド
- この際に使用するビルド環境はこちらのDockerfileでビルドされたイメージが使用される
- ベースイメージに「gcr.io/google-appengine/php:latest」を使用
- 作業フォルダ以下のファイルを全てコンテナ内の/appフォルダへコピー
- 所有権変更
- composer系の処理
- 環境変数「DOCUMENT_ROOT」を設定
- ビルドしたイメージをプッシュ
- GAEのアプリケーション更新処理
という流れで処理が実行されています。重要なのは2.と3.なのでここをピックアップして見てみます。
2.で使用されている「gcr.io/google-appengine/php:latest」のDockerfileはこちらになります。(ちょっと違いますが、流れとしてはこれです)
このDockerfile内で記述されているONBUILDディレクティブで2.a.から2.c.までの処理を実行させています。要はコード・リソースのコピーとcomposerを用いてのPHPと依存ライブラリの取得を行っています。
次に「gcr.io/google-appengine/php:latest」のベースイメージで何をやっているかですが、Dockerfileはこちらとなっており主には
- 依存パッケージのインストール
- 各環境変数の設定
- 設定用スクリプトのコピー
- デフォルト設定ファイルのコピー
- nginxのインストール
を行っています。そして、設定用スクリプトの一覧がこちらになります。設定用スクリプトの役割としては、
- PHPの要求バージョンの検出
- 設定ファイルの配置
- PHPの関数の呼び出し可能ホワイトリストの設定
- ファイルの権限設定
- nginxインストール
- php/php-fpmインストール
などです。これらのスクリプトをイメージビルド時、またはコンテナ作成・起動時に呼び出して設定をしています。
さらに、コンテナが起動された際にmove-config-files.shによって、/appフォルダの下にnginxやphp-fpmの設定ファイルがあった場合に適切な場所へ移動されるようになっています。
なので、app.yamlと同じ位置にnginx-app.confを用意することでnginxの設定をカスタマイズすることができます。
また、3.であった環境変数「DOCUMENT_ROOT」の設定ですが、これはapp.yamlに設定を追加することでnginxやphp-fpmのDocument rootを変更することができます。
例えばapp.yamlがある場所と同じ位置にあるwebrootフォルダをDocument rootにしたい場合はapp.yamlを以下のようにします。
runtime: php
env: flex
runtime_config:
document_root: webroot
これで、PHP Runtimeについてデプロイ時に起こっていることです。随分と掘り下げてしまいましたが、簡単な概要図は以下のようになっています。
こう見ると結構シンプルですね。
また、先程説明したmove-config-files.shによって置き換えられる設定ファイルの一覧と概要は以下のとおりです。
(デフォルトで存在するファイルはgithubへのリンクを貼っておきます)
ファイル名
|
概要
|
---|---|
nginx-http.conf | httpコンテキスト内で設定したい内容を記述 |
nginx-app.conf | serverコンテキスト内で設定したい内容を記述 |
nginx.conf | 既存のnginxの設定全てを書き直したい場合に使用 |
php-fpm.conf | デフォルトで置いてある設定ファイルの一番最後でincludeされる。既存の設定値を上書きするように使用 |
php.ini | PHPの追加設定ファイルとしてロードされる。既存の設定値を上書きするように使用 |
additional-supervisord.conf | supervisordの設定ファイルの一番最後でincludeされる |
supervisord.conf | 既存のsupoervisordの設定全てを書き直したい場合に使用 |
GAEのFlexible EnvironmentとCloud SQLの設定
実はココまできてあれですが、こちらのページを参考にすると環境構築できます(笑)
なのでここでは補足程度にします。
1つ目はメディアコンテンツについてです。上記ページの方法で環境構築を行うと「Google Cloud Storage plugin」というプラグインがインストールされます。
このプラグインはWordpressの管理画面から画像ファイルなどをアップロードした際にCloud Storageへ保存してくれる便利プラグインなのですが、ここの設定について全く触れられていません(笑)
サンプルのREADME.mdを読むと一応手順が書いてありますが、こちらでも簡単に紹介しておきます。
Cloud Storageにファイルを保存すると、特に設定してない場合は保存したユーザとプロジェクトに所属しているユーザのみファイルが閲覧できます。
これを、保存した段階で全てのユーザが閲覧できるようにバケットのデフォルトACLを変更する必要が有ります。コマンドは以下のとおりです。
gsutil defacl ch -u AllUsers:R gs://$PROJECT_ID.appspot.com
$PROJECT_IDを使用しているGCPのproject idに変更してください。
環境構築後、Wordpressの管理画面でプラグインを有効にし、Settingsから使用するバケット名を設定しましょう。
2つ目はWordpressのBatcacheプラグインについてです。上記のページで導入を進めていると、Standard Enviromentだと有効に、Flexible Environmentだと無効で設定されます。
というのも、Flexible EnvironmentだとMemcacheが現状利用できないためです。
一応alphaバージョンであればこちらのフォームから申請して使えるようです。また、別の手段としてサードパーティのサービスを利用する手段も有ります。
GAEで用意されているのはまだalphaバージョンですし、サードパーティのサービスを利用するとなると別コストもかかってくるので、特に厳しいアクセスがない限りは見送ったほうがよさそうです。
メディアコンテンツ配信について
ここまでで一応GAE上でWordpressが利用できるようになっていますが、遊び心でメディアコンテンツを配信しているCloud StorageにCloud CDNを付け加えてみました。
内容としてはHTTP(S) ロードバランサにバックエンドとしてバックエンドバケットを追加し、Cloud CDNを有効にする、というものです。
Cloud CDNを付けない状態での配信方法は以下ようになっていました。
Cloud CDNを付けた状態での配信方法は以下のようになりました。
お値段的にもフォワーディングルールの課金で無駄にお金を取られている感じになります。CDNからたくさん配信されるようになればフォワーディングルールの課金なんて目じゃない・・・!
完全にお遊び目的でした(笑)
最後に
- App Engine
- Cloud SQL
- Cloud Storage
- Cloud CDN
- HTTP(S) Load Balancer
を組み合わせてWordpressの環境を構築してみました。遊ばなければ下2つのCDNとLBは不要です。
公式ドキュメントにあるサンプルを利用した方法でしっかりとした環境が簡単に構築できますし、App Engine上で動作するのでデプロイ処理や負荷分散をあまり考える必要がなくとても素晴らしいですね!
また、設定変更などの対応もできるようになっているので、独自のルールやモジュール追加などが行なえます。(最悪Dockerコンテナなのでどうとでもできますが。)
今回はApp Engineをメインに使用しましたが、他にも魅力的なサービスが多くあるのでどんどん利用していこうと思います!