Google Cloudによる静的サイトホスティング: Cloud Storage、Cloud Load Balancing、Cloud DNSで構築

Google Cloud

2024.3.26

Topics

はじめに

こんにちは、Shunです。

今回は、Google CloudのCloud Storage、Cloud Load Balancing、およびCloud DNSを使用して静的サイトをホスティングする方法についてご紹介します。

この構成は、AWSのS3、CloudFront、Route53を使用する場合と似ています。以前解説したAWSでの静的サイトホスティングの記事も参考にしてください。

関連記事
OACによるCloudFrontからS3への接続制御: Route53とACMを用いて、独自ドメインで静的サイトをホストする

構成図

本記事で説明する構成は以下の通りです。

前提

  • 独自ドメインを保有していること
  • Cloud DNSで独自ドメインが登録済みであること

環境構築

1. Cloud Storageの作成

まず、Cloud Storageをデフォルト設定で作成し、index.html404.htmlをアップロードします。

これらのファイルには、訪問者が意図したパスに正しくアクセスしたかを識別できるような内容を含めてください。

ファイルのアップロードが完了後、外部からのアクセス許可を付与します。「権限」を選択します。

「公開アクセス防止を削除」を選択します。

次に、Cloud Storageへのアクセス権をユーザーに付与します。

以下の設定を行います。

  • 新しいプリンシパル: allUsers
  • ロール: Storage オブジェクト閲覧者

これでCloud Storageが一般公開されるようになります。

次に、デフォルトルートとエラーページの設定を行います。バケット選択画面へ戻り、右側の「︙」を選択し、「ウェブサイトの構成を編集」を押します。

「ウェブサイトの構成」でindex.html404.htmlをそれぞれデフォルトルートとエラーページとして指定します。

これでCloud Storageの設定は完了です。

2. Cloud Load Balancingの設定

続いて、Cloud Load Balancingの設定を行っていきます。

以下の設定を行い、「構成」を選択します。

  • ロードバランサのタイプ: アプリケーション ロードバランサ(HTTP / HTTPS)
  • インターネット接続または内部: インターネット接続(外部)
  • グローバルまたはシングル リージョンのデプロイ: グローバル ワークロードに最適
  • ロードバランサの生成: グローバル外部アプリケーション ロード バランサー

構成では、フロントエンド/バックエンドの構成を行います。

フロントエンドでは、以下の構成を設定します。

  • プロトコル: HTTPS(HTTP/2 を含む)
  • IP バージョン: IPv4
  • IP アドレス: 新規作成(名前は任意のものをつけてください。)
  • 証明書: 新しい証明書を作成
  • 証明書の作成: Google マネージドの証明書を作成する
  • ドメイン: www.[独自ドメイン名]

バックエンドでは、以下の構成を設定します。

  • バックエンド サービスとバックエンド バケット: バックエンドバケットを作成
  • Cloud Storageバケット: 先ほど作成したCloud Storageバケット
  • Cloud CDN: Cloud CDNを有効にする

ルーティングルールの設定は行わないので、これで設定は完了です。

3. Cloud DNSの設定

Cloud DNSでは、レコードセットを追加します。

レコードセットの設定は以下です。

  • DNS名: www.[独自ドメイン名](証明書を発行したものと同一である必要があります)
  • IPv4アドレス: Cloud Load Balancingへ割り当てたIPアドレス
    ※確認手順を下記に掲載

Cloud Load Balancingへ割り当てたIPアドレスは、以下から確認できます。

4. 静的サイトの確認

静的サイトへのアクセスができるようになるには、証明書の発行が完了する必要があります。以下からステータスを確認することができます。

ステータスがACTIVEになるまで待ちます。40分ほど時間がかかります。

ステータスがACTIVEになると、以下のようにコンテンツにアクセスができるようになります。

パスを変更してみると、404.htmlが表示されました。

証明書は、Googleが発行するものを利用していました。

さいごに

何度も証明書がACTIVEになる前に、アクセスをしてしまい、なぜアクセスできない。となりました。

AWSでやった時も同じことやったなぁと反省のしてなさに気づいてしまいました。

全体的な設定に関しては、AWSと比較してグローバルな利用を念頭に置いた設計になっているんだろうなぁと感じました。

最後まで読んでいただきありがとうございます!

テックブログ新着情報のほか、AWSやGoogle Cloudに関するお役立ち情報を配信中!

Shun

Google Cloud Partner Top Engineer 2025、2024 AWS All Cert、ビール検定1冠

Recommends

こちらもおすすめ

Special Topics

注目記事はこちら