GCP managed SSL(β版)を利用したhttpsサーバ構築

ここ数年、AWS環境の案件ばかりだったが、最近GCP案件に携わる機会が増えてきて、
GCPの勉強しながら対応している。

この記事では、独自ドメインで　http/httpsを受け付けられる「Webサーバ＋LB」の環境構築のやり方を
できる限り一般化した例で備忘する。

## 作る環境について

作る環境のイメージ図は以下。
![ssl-communication-lb.png](https://qiita-image-store.s3.amazonaws.com/0/51734/df5d4b56-f3d0-058b-641a-416251ffb64d.png)
（画像は [こちら](https://geekflare.com/google-load-balancer-enable-ssl/) より拝借）

その他、ありがちなリダイレクトルールの設定をする。

-　`https://独自ドメイン` は https証明書OKでWebコンテンツを表示する
-　`http://独自ドメイン` は https のURLにリダイレクトさせる。
-　`http(s)://www.独自ドメイン` は https のURLにリダイレクトさせる。

## 利用したGCPサービス

- インスタンス: GCE
- ロードバランサー: [HTTP(S) Load Balancing Concepts](https://cloud.google.com/load-balancing/docs/https/?hl=ja)
- 証明書管理: [Google-managed SSL certificates](https://cloud.google.com/load-balancing/docs/ssl-certificates#managed-certs)
- DNS管理: CloudDNS

## STEP1. GCEインスタンスを立てる

デフォルトのDebian9イメージを選択してnginxサーバを立てる。
ファイアーウォールはhttpアクセスはグローバルからアクセスできるようにチェックしておく。

```
# nginxインストール・自動起動設定・起動
$ sudo apt-get install nginx
$ sudo /lib/systemd/systemd-sysv-install enable nginx
$ sudo nginx
```
お名前.comで1円で売出し中の「.work」ドメインで検証。
ドメインは`koshilife.work`とした。nginx設定として以下ファイルを作成。

- 設定内容: 
  - server_nameに該当しないものはリクエストを返却しない [参考記事](https://yoshinorin.net/2018/06/05/nginx-block-ip-access/)
  - www無リクエストでかつ、httpsではないhttpリクエストはhttpsのURLにリダイレクトさせる。
  - www有リクエストはwww無へリダイレクトさせる。

```/etc/nginx/conf.d/koshilife-work.conf
server {
   listen       80 default_server;
   server_name  _;
   return       444;
}

server {
  listen 80;
  server_name koshilife.work;
  root /var/www/public_html;

  if ($http_x_forwarded_proto = 'http') {
    return 301 https://$server_name$request_uri;
  }
}

server {
  listen 80;
  server_name www.koshilife.work;
  return 301 https://koshilife.work$request_uri;
}
```

## STEP2. インスタンスグループを作る

シンプルな検証目的なので「Single zone/非マネージド インスタンスグループ」で作成し、
STEP1で作成したインスタンスを紐づけた。

<img width="648" alt="1_ig1.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/ef95812e-5de8-9d89-4728-979eecc94142.png">


## STEP3. LBを作る

GCPコンソールの「負荷分散」の設定画面で新規作成を選び「HTTP(S) 負荷分散」を選び、
ざっくりの設定内容は以下。

- バックエンドサービス設定
  - STEP2で作成した「インスタンスグループ」を指定し、デフォルト値を選択して進む。
  - ヘルスチェック設定も新規作成しデフォルト値で作成した。
- ホストとパスのルール設定: 設定なしでOK
- フロントエンドの設定
  - http:　<img width="465" alt="front-1.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/53530607-6b69-7183-421e-98f9b7cc6451.png">  
※IPアドレス設定プルダウンで「エフェメラル」のままだと、https通信時と同じIPでの設定ができないので注意。ハマったポイント。IPアドレスを作成を選ぶ。
  - https:<img width="464" alt="front-2.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/32af36fa-ec63-58b5-433b-aaa60efcfa6c.png">  
※SSL証明書は　google　managedを選択した(この時点でベータ版)。9個まで証明書を指定できるが、今回は２つのSSL証明書を作成した。

## STEP4. DNSのAレコードを更新する。

STEP3で発行したSSL証明書が有効になる条件に証明書で指定したドメインの名前解決をした時
LBのIPが弾けることが有効化条件に含まれるのでDNSゾーン情報を更新する。

更新イメージ:
<img width="452" alt="スクリーンショット 2018-12-30 1.06.18.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/a57735e0-76e2-ecf9-572c-318d84fc8a38.png">

## STEP5. 証明書有効化待ち

SSL証明書が有効になるまで30分程度待つ。

- LB作成後の状態では証明書ステータスは無効。
<img width="719" alt="スクリーンショット 2018-12-30 1.23.31.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/068c32dc-78f4-36bd-4ec3-f61b40047d43.png">

- 20分くらいで証明書がアクティブに変わった。
<img width="499" alt="スクリーンショット 2018-12-30 1.06.33.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/5d7d54c1-995b-160f-cc9a-88cca24289a6.png">

- ドメインにアクセスし、リダイレクト設定、https鍵マークが問題なければ終わり。
<img width="381" alt="スクリーンショット 2018-12-30 1.03.14.png" src="https://qiita-image-store.s3.amazonaws.com/0/51734/56a1dd5d-b1ad-6d03-9e74-e87aa7ffb1ae.png">


## 参考記事

- [GCPのHTTPロードバランサ用のマネージドSSL証明書がリリースされたので試してみた](https://blog.jicoman.info/2018/10/gcp-managed-ssl-certificates/)
- [コマンドラインでGCP Autoscaler（GCE + GCLB）を設定する](https://blog.jicoman.info/2018/10/configure-gcp-autoscaler-by-cli/)
- [HTTP Load Balancerを使って、Host名やURIによって接続するインスタンス(群)を切り替える](https://qiita.com/soundTricker/items/4d4fd9c9b74942f7aa7e)
- [【AWSしかやったことない人向け】AWSとGCPのネットワークの違いを理解してみよう](http://www.mpon.me/entry/2017/04/22/020428)