BETA

GCP上でのロードバランサとmanaged SSLを使用しての独自ドメインでのアクセス

投稿日:2019-08-18
最終更新:2019-08-18

ロードバランサとmanaged SSLの使用

以前、GoとNginxの構成で独自ドメインを利用してのアクセスについて
書きましたが、今回はGCPのロードバランサとmanaged SSLを使用して、
独自ドメインでのアクセスをしてみます。以下を前提とします

  • 独自ドメインを取得済み。
  • GCEのインスタンス作成済み。
  • インスタンスにGoとNginxをインストール済み。
  • CloudDNSでの独自ドメインのレコード作成済み。

インスタンスグループの作成

  • メニューのCompute Engine→インスタンスグループを選択し、インスタンスグループを作成を選択します。
  • 新しいマネージドインスタンスグループと新しい非マネージドインスタンスグループがあります。
  • 新しい非マネージドインスタンスグループを選択します。
  • ロケーションから該当するインスタンスがあるリージョンとゾーンを選択します。
  • GCEのインスタンスがないリージョンとゾーンを選択していると、VMインスタンスの項目がアクティブになりません。
  • GCEのインスタンスがあっても追加したいインスタンスがあるリージョンとゾーンを選択する必要があります。
  • ロケーションの設定後に該当インスタンスを追加し、それ以外はデフォルトのままで、作成を選択します。

ロードバランサの作成

  • メニューのネットワークサービス→負荷分散を選択し、ロードバランサを作成を選択します。
  • HTTP(S)負荷分散、TCP 負荷分散、UDP 負荷分散が表示されます。
  • HTTP(S)負荷分散を選択し、設定の開始を選択します。
  • インターネット接続または内部専用が表示されるので、デフォルトのままで、続行を選択します。
  • バックエンドの設定、ホストとパスのルール、フロンドエンドの設定、確認と完了の項目が表示されます。
  • 確認と完了はスキップして、残りの3つの項目について作業をします。

バックエンドの設定

  • バックエンドの設定を選択すると、バックエンドサービスとバックエンドバケットが表示されます。
  • バックエンドサービスとバックエンドバケットの作成または選択で、バックエンドサービスを選択します。
  • バックエンドサービスを作成が表示されるので、バックエンドサービスを作成を選択します。

バックエンドサービスの作成について

  • 新しいバックエンドにあるインスタンスグループで、先ほど、作成したインスタンスグループを選択します。
  • ヘルスチェックからヘルスチェックの作成を選択します。
  • デフォルトのままで、保存して次へを選択します。
  • 以上で、作成を選択します。

ホストパスのルールについて

  • デフォルトのままで設定します。

フロントエンドの設定について

  • フロントエンドの設定における注意点

    • フロントエンドは2つ、設定する必要があります。2つの内訳はhttpとhttpsとなります。
    • これらのフロントエンドで、重要となるのはIPアドレスと証明書の項目です。
  • 1つ目のフロントエンドの設定における注意点

    • フロントエンドの1つめはhttpの設定となります。
    • IPアドレスを選択して、IPアドレス作成を選択します。
    • 注意点として、GCEのインスタンスのIPアドレスではありません。
    • 作成したIPアドレスはメニューのVPCネットワーク→外部IPアドレスを選択して、確認することができます。
    • このIPアドレスは静的なIPアドレスとなります。
    • 以上で、完了を選択し、1つ目のフロントエンドの設定は終了です。
  • 2つ目のフロントエンドの設定における注意点

    • フロントエンドのIPとポートを追加を選択し、2つめのフロントエンドであるhttpsの設定をします。
    • プロトコルはHTTPS(HTTP/2を含む)を選択し、ポート番号は443を選択します。
    • IPアドレスは1つの目のフロントエンドで、作成したIPアドレスを設定します。
    • 証明書の項目が出現しているので、新しい証明書の作成を選択します。
    • 新しい証明書の作成で、作成モードにあるGoogle管理の証明書を選択します。
    • ドメインにドメイン名を入力し、作成を選択します。
    • 複数の証明書が必要なら、証明書を追加します。
    • 今回、証明書はサブドメインがない独自ドメインとwww付きの独自ドメインの両方を作成しておきます。
    • example.co.jpなら、example.co.jpwww.example.co.jpになります。
    • 以上で、完了を選択します。
  • 証明書について

    • 2つの証明書を作成した理由はブラウザによって警告が出るからです。
    • www.example.co.jpのアクセスでも最終的なアクセスはexample.co.jpにリダイレクトしています。
    • ですが、ブラウザ(例:IE)によっては、www.example.co.jpでのアクセスだとサーバ証明書についての警告が出るようです。
    • これはwww.example.co.jpのサーバ証明書がないためです。

CloudDNSの設定について

  • 独自ドメインとwww付きの独自ドメインのAレコードには 外部IPアドレスを設定します。
  • 外部IPアドレスはフロントエンドで作成したIPアドレスを設定します。
  • この時、独自ドメインとwww付きの独自ドメインのAレコードには 同じ外部IPアドレスを設定します。

サーバ証明書の有効化について

  • メニューのネットワークサービス→負荷分散を選択し、先ほど作成したロードバランサを選択します。
  • フロントエンドにあるHTTPSで、先ほど作成したサーバ証明書を選択します。
  • サーバ証明書のステータスがACTIVEになるのを確認します。
  • ACTIVEになるのは10分程でなります。

Goのリクエスト待ち

    package main  

    import (  
            "fmt"  
            "net/http"  
           )  

    func handler(writer http.ResponseWriter, request *http.Request) {  
        fmt.Fprintf(writer, "My Domain Access Success With Managed SSL %s", request.URL.Path[1:])  
    }  

    func main () {  
        http.HandleFunc("/", handler)  
        http.ListenAndServe(":9090", nil)  
    }  
  • 上記の内容で、main.goを作成します。
  • なお、main.goの保存場所はNginxのドキュメントルートになります。
  • go run main.goを実行して9090のポートで、リクエストを待ちます。

Nginxの設定

    server {  
        listen       80 default_server;  
        server_name  _;  
        return       444;  
    }  

    server {    
        listen       80;    
        server_name  www.example.co.jp;    
        return       301 http://example.co.jp$request_uri;    
    }  

    server {  
        listen 80;  
        server_name  example.co.jp;  
        if ($http_x_forwarded_proto = 'http') {  
            return 301 https://$server_name$request_uri;  
        }  

        # Load configuration files for the default server block.  
        include /etc/nginx/default.d/*.conf;  

        location / {  
            root         /home/example/go/src/www/html/public_html/web;  
            index index.html index.htm;  
            proxy_set_header Host $host;  
            proxy_set_header X-Real-IP $remote_addr;  
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
            proxy_set_header X-Forwarded-Proto $scheme;  
            proxy_pass   http://example.co.jp:9090;  
            proxy_read_timeout 90;  
            proxy_redirect off;  
            proxy_buffering off;  
            chunked_transfer_encoding off;  
        }  

        error_page 404 /404.html;  
            location = /40x.html {  
        }  

        error_page 500 502 503 504 /50x.html;  
            location = /50x.html {  
        }  
    }  
  • 上記のようにnginx.confに複数のserverコンテキストを設定します。
  • www付きの独自ドメインはwwwがない独自ドメインへとリダイレクトします。
  • example.co.jpですとhttp://www.example.co.jphttp://example.co.jpにリダイレクトします。
  • ここで注意するのは、ポート番号についてで、httpsでは443を使用します。
  • ですが、GCPのロードバランサ + GCEではnginx.confに443を設定するとサーバ側でエラーとなります。
  • どうも、ロードバランサとGCE間はhttpで通信しているようです。
  • セキュアな通信の終端はロードバランサで、その後はGCPの内部でhttpに切り替えているようです。
  • なので、$schemeの中身がhttpで、ポート番号の80を使用しないといけないのはこのためと思われます。

独自ドメインでのアクセス

Webブラウザで独自ドメインでアクセスします。example.co.jpだとhttps://example.co.jpになります。
WebブラウザにMy Domain Access Success With Managed SSLの表示を確認します。

アクセスの流れについて

  • X-Forwarded-ForのIPアドレスからすると以下の流れでのアクセスになると思われます。
  • ISP→フロントエンド(http or https)→ロードバランサ
  • ロードバランサのIPアドレスは動的のようです。

AWSとGCPにおける違い

AWSでもELB、ACM、Route53、EC2を使用してセキュアな通信を
実際に設定してみた私としては、AWSの方がしやすい感じはあります。

最もこれはシステムの構成によって左右される部分も大きいと思いますが、
今回の場合はロードバランサ、マネージドなサーバ証明書、DNSサービス、仮想サーバ
での比較となります。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@fubukiの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!