【SRE/GCE】あっちはWordpressでー、こっちはNuxtにトラフィックを飛ばしたい

WordpressとNuxt

HTTPS ロードバランサ(L7)を通して、ディレクトリのパスによって、アクセス先を変えようとします。
Nuxtで構築したものだったり、wordpressで構築したものだったりを別々のドメインで管理していて、なんかのタイミングで「一緒にしたいんだけど」って時に実施したことを書いていきます。

流れ

• Wordpress構築
• Nuxt用のVM構築
• HTTPS ロードバランサの設定
• 動作確認

使用する環境

GCP

Wordpress構築

GCPでWordpressを構築するのなら、Marketplace から構築することをおすすめします。
GCPで爆速なWordPressを爆速で構築しSSL化する9手順 - SSL代行ラボ

dashboard から Marketplaceに遷移

Marketplaceの画面

構築後の画面

注意

今回、/mediaでアクセスしたらwordpressにトラフィックが飛ぶように設定するので、wordpressのVMインスタンス内でapacheの設定やドキュメントルートを変更しています。
ですが、書いていないことを後から気づいて、面倒臭くなったので割愛します、、、スンマソン。

Nuxt用のVM構築

VMインスタンスを構築していきます。
VMインスタンス内でdockerを使用したいので、まず簡単なNuxtの実装をしてからdockerでビルドし、GCRにプッシュしていきます。

プロジェクト作成

npx create-nuxt-app helloworldコマンドで、簡単なNuxtのプロジェクトを作成します。
【今日からはじめるNuxt.js】Nuxt.jsのはじめのいっぽ(プロジェクトの作成～簡単なページ遷移まで)

nuxt.configの実装修正

nuxt.configに下記の実装を追加します。

server: {
  port: 80,
  host: '0.0.0.0'
},

Dockerfile作成

下記のDockerfileを作成します。

FROM node:10.15.1-alpine as builder
WORKDIR /app
COPY . /app

RUN apk update && \
    apk add git

RUN yarn install --production
RUN yarn build

FROM node:10.15.1-alpine
WORKDIR /app
COPY --from=builder /app /app

EXPOSE 80

CMD ["yarn", "start"]

ビルド、プッシュ

下記コマンドをそれぞれ実行します。
タグは任意で設定してください。

ビルド
docker build -t gcr.io/{プロジェクトID}/{ディレクトリ名}:{タグ名} .
プッシュ
docker push gcr.io/{プロジェクトID}/{ディレクトリ名}:{タグ名}

VMの構築

次にVMインスタンスを構築していきます。
ここで気をつけるのは、コンテナにプッシュするところにチェックをし、
先ほどプッシュしたGCRの情報を入力します。

またこの時注意が必要なのは、dockerを使用するにチェックをした際、使用されるOSが、「Container-Optimized OS from Google」というOSに変わります。
これはコンテナ専用にGoogleが用意してくれたOSのようです。

Container-Optimized OS from Google は、Docker コンテナの実行に対して最適化された Compute Engine VM 用のオペレーティング システム イメージです。Container
Container-Optimized OS の概要  |  Google Cloudより引用

ファイアーウォールルールの設定

VPCのファイアウォール ルールを設定していきます。
※今回はdefaultのVPCを使用します。

ターゲットタグ、ソースIPの範囲、指定したプロトコルとポートを設定すればOKです。
「指定したプロトコルとポート」は、tcpで80を設定します。

HTTPS ロードバランサの設定

/mediaにアクセスで、wordpressに
/ルートでディレクトリで、Nuxtにアクセスを飛ばすことにします。

HTTPS ロードバランサの構築

「HTTP(S) 負荷分散」を選択し、構築していきます。

バックエンドサービスの構築

受信トラフィック用のバックエンド サービスを作成します。
バックエンド サービスとは、アクセスをVMインスタンスに振り分けてくれる役割を持ちます。

バックエンドサービスを構築する際、インスタンスグループとヘルスチェックを適応する必要があります。

インスタンスグループは、GCEと検索し、左サイドバーから「インスタンスグループ」を作成します。
この時当たり前ですが、VMを構築したリージョンを指定しないと選択したいVMインスタンスは出てきませんw

ヘルスチェックはそのバックエンドサービスの構築画面で、作成できるので作成してしまいましょう。

パスのルールの設定

/mediaにアクセス　→　wordpress
その他は、Nuxtにアクセスを飛ばすような設定にしていきます。

面倒なので、結果だけ貼っておきます。

フロントエンドの設定

名前を入力して、作成しましょう。
httpsの場合は、ここで証明書を設定します。

HTTPS ロードバランサの全体図

構築し終わってなんですが、構築したHTTPS ロードバランサについて見ていきます。
下記がHTTPS ロードバランサの全体図になっています。

HTTPS ロードバランサの設定  |  負荷分散  |  Google Cloudより引用

アクセスの流れで行くと、下記の3つをへてVMインスタンスにトラフィックが流れていきます。

1. リクエストをターゲット HTTP プロキシで受け取る
2. URL マップによって、バックエンド サービスを決定
3. バックエンド サービスによって、インスタンスを決定

VMインスタンスは下記に基づいて選ばれます。

• バックエンドの処理能力
• ゾーン
• インスタンスの健全性

そしてインスタンスの健全性は、ヘルスチェックによって検証されます。

転送ルールの概要  |  負荷分散  |  Google Cloud

最後に、動作確認

/mediaで、wordpressの画面が、
/ルートでディレクトリで、Nuxtの画面が見えているはずです。