GCPのCloud Load Balancingで任意のバックエンドを設定する

GCPではロードバランサーのバックエンドにVMインスタンスを配置する場合、インスタンスグループを使用するらしいです。
このインスタンスグループの作成には、インスタンステンプレートが必要です。
この方法ではスケーラビリティを確保する前提の構成になってしまいます。
（数年前に仕事で調べていたのにすっかり忘れていました。）
用途によってはバックエンドには単独のVMインスタンスだけいい場合もある、ロードバランサーをリバースプロキシとして使用したい場合もあるので、その設定方法です。

ちなみに図ではわかりにくいですが、IPアドレスは80と443で同じものを使っています。下線部はサービス名、太字は設定した名前です。
![gcp_lb001.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131218/76021393-2761-b6d9-e12b-9213b3381d14.png)

## VMをバックエンドに持つ構成
結論から言うと、ネットワークエンドポイントグループを作成し、そこにVMインスタンスを追加していく形になります。
Cloud Load Balancingのバックエンドにはネットワークエンドポイントグループというものを指定できるのです。

個人的にCloud Load Balanacingを理解するのに少しややこしい印象があるのですが、それでもなんとかはできました。
やったことの手順をまとめると以下のようになります。

1. VPCを作成
2. VMインスタンスをVPC内に作成。HTTPを有効化
    - なんでもいいのでウェブサーバーをセットアップ（今回はApache）
    - OKしか書いてない`hcheck.html`を設置。ヘルスチェックのエンドポイントにする
    - `index2.html`を配置して、ちゃんと設置したものにアクセスできるかを確認する
    - VMにSSHして`curl http://localhost/index2.html`なでHTTPが使えることを確認
3. ネットワークエンドポイントグループを作成
    - VMを指定する場合はゾーンを選択
    - GCP以外のサーバーを指定する場合はインターネットを選択
4. Cloud Load Balancingを作成
    - フロントエンドサービスを作成
    - バックエンドサービスを作成。このときにネットワークエンドポイントグループを指定。ヘルスチェックも作成する
    - ルーティングルールはデフォルトの状態で、作成したネットワークエンドポイントグループに設定する
5. IPアドレスによるアクセス制限をかける場合は、バックエンドサービス作成時に自動で作成されるバックエンドセキュリティポリシー（Cloud Armor）で行う

で、なんとかトライアンドエラーを繰り返してうまく動きました。

## 外部のサーバーをバックエンドに持つ構成
今度は自身が持っているウェブサイトをロードバランサー配下に設置してみようと考えました。

サイトは以下のようになっています。
- レンタルサーバーに設置
- DNS・ドメインはレンタルサーバーやGCPとは別のサービスで管理
- SSLはレンタルサーバーのサービスで[Let's Encrypt](https://letsencrypt.org/)を使用

目標はDNSをロードバランサーに向け、SSLもロードバランサーにインストールする構成です。

結果的にはネットワークエンドポイントグループをインターネットに設定することで外部のパブリックIPを指定することができるのでそれで解決可能です。
また、ネットワークエンドポイントグループでゾーンを指定した場合、ヘルスチェックは必須だったのですが、インターネットの場合は、ヘルスチェックは不要です。

### SSLの設定にハマる
ロードバランサーを設定するときにSSLの作成もすることができます。
通常SSLは業者から証明書を発行してもらって、それを設定します。
レンタルサーバーでは手軽に導入可能なLet's Encryptを使う感じになっていました。
パブリッククラウドでは、GoogleやAWSがSSLの認証局になってくれるので手軽に導入可能とも言えます。

ただちょっと困ったことに、ドメインが解決可能な状態になっていないといけないっぽい。
`PROVISIONING_FAILED`から変化がなかったので、色々試した結果、DNSをロードバランサーに向けて、SSLを再度作成し直しました。
15分ぐらいで`ACTIVE`になり、SSLは使えるようになります。

ただ証明書自体が変わってしまったため、ブラウザは`ERR_SSL_VERSION_OR_CIPHER_MISMATCH`となってしまい、サイトがまともに見られなくなります。
その日は次の日仕事があったので、一晩放置したところ、次の日の朝には見られるようになっていました。

~~Googleマネージド証明書はワイルドカードで発行できないため、サブドメインはそれぞれ指定が必要です。~~ （これはできるみたいです。そうだよなという感じですが）
これらの事情からSSLだけは自前で取得しようかなと思いました。

## 参考画像
ネットワークエンドポイントグループの設定内容。左がVM、右がレンタルサーバー。
![gcp_lb003.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131218/814b8b60-2c8e-cf27-8779-c6d562d3609a.png)

Cloud Load Balancing設定の一部
![gcp_lb002.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131218/a6cad723-fc4f-c3d9-adc7-dfb6f5104e09.png)

Cloud Load Balancing設定の一部（バックエンド部分）。上がVM、下がレンタルサーバー
![gcp_lb005.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131218/e1bb0578-428c-da4e-9a71-723f9dade8ae.png)

VMはHTTPを許可。ロードバランサーと80で喋れるようにしておく。
![gcp_lb004.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131218/0ea420c4-698a-3205-871b-dfee2bd37d4b.png)


## 参考リンク
[【Google Cloud】IAP×Cloud Load BalancingでWebアプリケーションを保護して公開しよう！ | Tech-Tech](https://tech-tech.nddhq.co.jp/2023/07/25/webapp-publish-with-iap/)
[SSL 証明書のトラブルシューティング  |  Load Balancing  |  Google Cloud](https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting?hl=ja)
[APIをダウンタイムなしでAWSからGCPに引越しました - JX通信社エンジニアブログ](https://tech.jxpress.net/entry/2023/03/09/112758)