Serverless Wordpress Blog #3
2021 年に書いた記事の再掲です。ここで解説している構成はすでに使っておらず、記録として残しています。
// 前ブログからの移行です
前回 は WordPress 用の MySQL 5.7 を Google Cloud SQL で構成しました。今回は WordPress を Cloud Run で動かし、Serverless VPC Access を使って Cloud SQL の Private IP に接続します。最終的にこのブログのフロント UI で React を使いたかったので、中間の WordPress 部分はあまり手をかけずに済むよう Docker Community がメンテナンスしている、Docker “Official Image” for wordpress を使っています。
Design Considerations
WordPress 部分についてもとりあえず簡潔に素早く MVP をリリースしたいのであまり考慮するところはありません。
- 知見のない PHP 部分はできるだけ省力化したい
今回の作業終了時点のイメージ図はこんな感じです。
How to set up WordPress app on Google Cloud Run
公式ドキュメントを参照して進めます。記録に残すためとおかしなことをしていないかのチェックのために gcloud コマンドを使って作業します。GCP console から Cloud Shell が便利ですが、手元のマシンから (vscode のターミナルとか) からでも問題ありません。Serverless Access の準備をしてから Cloud Run をデプロイしてカスタムドメインのマッピングまでやります。ローカルマシンのシェルから実行する手順になっていますので、ローカルマシンに Cloud SDK と Docker Engine が必要になります。
Serverless VPC Access の設定
Serverless VPC Access のコネクタを作成します。Cloud Run はこれを使って Cloud SQL の Private IP に接続します。デフォルトだとマシンが e2-micro になるので、--machine-type フラグ をつかって、f1-micro に変更します。こちらのマシンタイプによってスループット範囲が変わるので大きな帯域幅が必要な場合は強いやつにします。それぞれ任意の値に変更します。
CONNECTOR_NAME— 作成するコネクタの名前REGION— 作成するコネクタのリージョン。サーバーレスサービスのリージョンと一致させます。IP_RANGE— 予約されていない内部 IP ネットワーク。未割り振りスペースの /28 が必要。(ドキュメントの例: 10.8.0.0/28)
bashgcloud compute networks vpc-access connectors create CONNECTOR_NAME \ --network VPC_NETWORK \ --region REGION \ --range IP_RANGE --machine-type f1-micro
WordPress イメージの準備
Docker Hub から WordPress イメージを取得して Artifact Registry に push します。Artifact Registy API が有効にしてから作業します。
Docker リポジトリを作成する
WordPress イメージを保存する Docker リポジトリを作成します。
REPOSITORY_NAME— 作成する Docker image 用のリポジトリ名REGION— リポジトリを作成するリージョン (例: asia-northeast1)DESCRIPTION— リポジトリの説明
bashgcloud artifacts repositories create REPOSITORY_NAME \ --repository-format=docker \ --location=REGION \ --description=DESCRIPTION
認証を構成する
gcloud コマンドで Artifact Registry へのリクエストを認証するように Docker を構成します。その他の Docker に対する認証の設定についてはこちらのドキュメントを参照ください。この例では asia-northeast1 (東京) リージョンの Docker リポジトリに対する認証を設定しています。環境セットアップについてはこちらのドキュメントにも記載があります。
bashgcloud auth configure-docker asia-northeast1-docker.pkg.dev
push** するイメージを取得する**
Docker Hub からダウンロードする WordPress イメージを保存するディレクトリを作成/移動します。
bashmkdir foo cd foo
Docker Hub から WordPress イメージをダウンロードします。
bashdocker pull wordpress
リポジトリにイメージを追加する
Docker イメージを Artifact Registry に push する前に、イメージにリポジトリ名でタグ付します。
PROJECT_NAME— GCP プロジェクト名REPOSITORY_NAME— さっき作ったリポジトリ名IMAGE_NAME— イメージ名 (wordpress, wp-image 等)TAG— タグ (指定しなかったら latest がつきます)
bashdocker tag docker.io/library/wordpress:latest asia-northeast1-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:TAG
イメージを Artifact Registry に push します。
bashdocker push asia-northeast1-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:TAG
これで準備ができました。
VPC コネクタを使用するように Cloud Run を構成する
Cloud SQL の Private IP に接続するため、Cloud Run サービスを構成するようにします。service.yaml を作成してコネクタを指定します。
SERVICE_NAME— Cloud Run サービス名PROJECT_NAME— GCP プロジェクト名LOCATION— コネクタのあるリージョン名 (例: asia-northeast1)CONNECTOR_NAME— VPC コネクタ名
bashapiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE_NAME spec: template: metadata: annotations: run.googleapis.com/vpc-access-connector: projects/PROJECT_NAME/locations/LOCATION/connectors/CONNECTOR_NAME
Cloud Run をデプロイする
WordPress イメージのドキュメントを参考に、環境変数などを設定して Cloud Run をデプロイします。
SERVICE_NAME— Cloud Run サービス名PROJECT_NAME— GCP プロジェクト名DB_LOCATION— Cloud SQL インスタンスの場所INSTANCE_NAME— Cloud SQL インスタンス名LOCATION— コネクタのあるリージョン名 (例: asia-northeast1)CONNECTOR_NAME— VPCコネクタ名REPOSITORY_NAME— さっきのリポジトリ名IMAGE_NAME— さっきのイメージ名TAG— タグPRIVATE_IP— Cloud SQL のプライベート IP アドレスWORDPRESS_DB_USER_NAME— 前回作った WordPress 用のユーザー名PASSWORD— ↑ のパスワードDB_NAME— 前回作った WordPress 用のデータベース名
bashapiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE_NAME spec: template: metadata: annotations: run.googleapis.com/cloudsql-instances: PROJECT_NAME:DB_LOCATION:INSTANCE_NAME run.googleapis.com/vpc-access-connector: projects/PROJECT_NAME/locations/LOCATION/connectors/CONNECTOR_NAME spec: containers: - image: asia-northeast1-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:TAG ports: - containerPort: 80 env: - name: WORDPRESS_DB_HOST value: PRIVATE_IP:3306 - name: WORDPRESS_DB_USER value: WORDPRESS_DB_USER_NAME - name: WORDPRESS_DB_PASSWORD value: PASSWORD - name: WORDPRESS_DB_NAME value: DB_NAME
gcloud コマンドでデプロイします。
bashgcloud beta run services replace service.yaml
続いて、サービスの公開設定をします。デフォルトでは、プロジェクトのオーナーと編集者のみがサービスの作成、更新、削除、呼び出しを行うことができる状態です。gcloud コマンドを使って、allUsers をサービスに追加して、roles/run.invoker ロールを付与します。
SERVICE_NAME— Cloud Run サービス名
bashgcloud run services add-iam-policy-binding SERVICE_NAME \ --member="allUsers" \ --role="roles/run.invoker"
これでブラウザから WordPress にアクセスできるようになりました。
WordPress の初期設定
ブラウザからアクセスすると初期設定の画面が表示されますので、WordPress のインストールを行います。
Continue…
“WordPress をインストール”!!
そして、Frontity がちゃんとデータを読み込めるように、Permalink Settings が Plain 以外の設定に変更します。理由等についてはこの投稿 <Frontity not working with plain permalinks> が参考になります。
あとは General Settings の WordPress Address (URL) のところが Cloud Run のデフォルトの URL になっていたら、カスタムドメインのものにお好みで変更します。
Frontity から接続するための WordPress 側の設定は以上です。
カスタムドメインのマッピング
この WordPress には基本的にはフロント UI である Frontity (GAE) からしか接続するつもりがないので、このままのアドレスでも問題ないのですが、すっきりした URL にしたいので自分のドメインをマッピングします。
その際に、ベースドメイン (このブログだと tokiwaya.dev) で設定してしまうと、例えばwww.tokiwaya.dev は Google Cloud 以外の別のサービスでホストしたいといった場合に面倒が起きそうなので、図のように、’Verify a new domain …’ – Base domain to verify のところにサブドメインをいれます。例えば (wordpressapp.tokiwaya.dev)
CONTINUE を押すと、Webmaster Central でドメインを検証することに。
Webmaster Central で自身のドメインネームプロバイダーを選択 (私の例は Google Domains です) して、TXT レコードをドメインネームプロバイダーの DNS のところに登録します。おそらく登録してすぐ確認できると思います。
ドメインネームプロバイダーを選んだら・・・
この TXT レコードを DNS に登録・・・
おそらくすぐ VERIFY できると思います・・・
Cloud Run の画面に戻って・・・
その後表示される A 及び AAAA レコードをドメインネームプロバイダーの DNS に登録して完了です。ちゃんと登録されているかは Dig などのツールで確認することができます。
これで自分のドメイン名で WordPress にアクセスできるようになりました。yay 👍
おわり
WordPress on GCP ができました。次回は WordPress 用の React Framework である Frontity を使って UI を作って Google App Engine で公開します。別に React で UI 作りたいわけじゃないし、そのままテーマとか使えればいいし、という場合はこれで終了かもしれません。あ、でも WordPress の php コードに手を入れないといけない Plugins とかはこのままだとだめかもしれないですね。Cloud Run は Stateless なので。