私のプロジェクトは、ユーザーがアカウントを登録できるメインのウェブサイトで構成されています。登録後、ユーザーはそれぞれウェブサイト（自分のドメインのサブドメイン）を取得し、そこで私のメインサイト（ユーザーが登録したサイト）でホストされているプラットフォームによって管理される電子商取引ショップを運営します。
example1.com -> メインウェブサイト（ログイン、登録など）
example1.com/platform -> 管理プラットフォーム
store1.example1.com -> ユーザー1のストア
store2.example1.com -> ユーザー2のストア
ハードウェアに関して言えば、現在の私のセットアップは次のようになっています: GCP に Apache を搭載した VM インスタンス 1 つ、要求されたドメインを適切なフォルダーにマップできるワイルドカードがいくつか設定された仮想ホストが 2 つ。
また、メイン ドメインにワイルドカード証明書を生成し、すべての顧客ストアを SSL で保護しています。
さて、私は時間の経過とともにサーバーの過負荷を防ぎたかったので、上で説明したマシンから複製されたマシンのインスタンス グループにロード バランサーを接続すると問題が解決すると考えました。理論的には機能しますが、問題があります。
各ユーザーは独自のドメイン名を購入し、それを自分の IP (LB または VM) にリダイレクトして、ストアが次のようになるようにすることができます。
store1.com -> ユーザー1のストア
store2.com -> ユーザー2のストア
また、希望する場合は、私のプラットフォームで SSL 証明書を「購入」してドメイン名を保護することもできます。SSL 証明書の作成は、API の certbot と letsencrypt を使って簡単に処理できますが、VM はインスタンス グループで実行されるため、現在動作している VM に保存した証明書ファイルは他の VM (存在する場合) に複製されず、インスタンス グループが現在の VM が不要になったと判断すると失われる可能性もあります。ロード バランサーがインスタンス グループ内の複数の VM にトラフィックを送信し、証明書フォルダーまたはディスク全体を何らかの方法で「共有」できるように、すべて (LB、インスタンス グループ、VM、Apache) をどのように配置すればよいでしょうか。
ちなみに、VM 上の永続ディスクは、読み取り専用モードの場合のみ複数の VM にマウントできます (動作しません)。また、ファイルストアも試しましたが、月額 200 ドルの費用がかかり、これだけでは少し高すぎます。
答え1
@JohnHanley が指摘したように:
LB セットアップで証明書を管理し、Web サーバーから certbot を削除します。Google ドメイン検証では多少のオーバーヘッドが発生しますが、試してみる価値は間違いなくあります。
LB 構成と証明書について:
- LB で構成された証明書を変更することはできません
- ただし、新しい証明書（たとえば、追加のホスト名を含む）を追加して既存のLBに追加し、後で古い証明書の設定を削除することができます。
サポートできる Terraform モジュールはいくつかありますが、もちろん、学習と管理の労力も必要になります。