Google CloudでLBを通してWebページを公開する

## やりたいこと
- AWSでよくみられるような下記のアーキテクチャをGCPで作りたい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/8ed32668-84d9-f809-8a21-3752d7fa1984.png)

- 最終的に下記のようになった
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/3a9c4b45-5440-97b6-3363-b885e6c90539.png)

:::note warn
警告
筆者はGoogle Cloudの実務経験はなく、お試しで勉強のために触っているレベルなので、ベストプラクティスから外れた事をしている可能性や、脆弱な設定を行っている可能性があります。ご了承下さい。
:::

## VPC・サブネットの作成
- VPCがGCPではグローバルサービスなので、ここでリージョンは選ばない
- さらにVPCはIPアドレスを持たない
    - これらはサブネットの設定で設定することになる
- まず、VMが立つためのサブネットを2つ作成した
    - 何も考えずに作っていたが、サブネットは今回1つでいいです
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/4fc680dd-24ba-0295-5cf6-bd2c03448b16.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/3ea6f88b-c2ea-b351-a756-24d36776d608.png)
- FWルールはいったんここでは作成しない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/0e2d9caa-8692-6f10-516c-08f889250d3c.png)

- LB用に予約されているプロキシ専用サブネットを作成する
    - リージョン外部Application Load Balancerを作成するため、プロキシ専用サブネットを作成する
        - やっぱりこれも今回は2つ作る必要なかったです
        - LBを作成すると、このサブネット内のIPからVMへのアクセスが行われる
        > クライアントは、ロードバランサの IP アドレスとポートを使用してロードバランサに接続します。クライアント リクエストは、クライアントと同じリージョン内のプロキシ専用サブネットに転送されます。ロードバランサは、クライアント リクエストを終了して、プロキシ専用サブネットからバックエンドへの新しい接続を開きます。したがって、ロードバランサから送信されたパケットには、プロキシ専用サブネットからの送信元 IP アドレスがあります。
        https://cloud.google.com/load-balancing/docs/https?hl=ja#regional-connections
    
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/c2f7e716-bcc6-2e45-ec52-1d9ef7f35e3e.png)


## Cloud NAT、Firewallの作成
### Cloud NAT
サーバを立てた際にhttpdをインストールするためのNATを作成する
- Cloud NATにはCloud Routerが必要
> Cloud NAT は、NAT 構成情報（コントロール プレーン）のグループ化にのみ Cloud Router を使用します。Cloud NAT から、Cloud Router に BGP の使用またはルートの追加を指示することはありません。NAT トラフィックは、Cloud Router（データプレーン）を通過しません。
https://cloud.google.com/nat/docs/set-up-manage-network-address-translation?hl=ja

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/aa9fcbc1-fec8-2b4a-6d55-95fcc37b3d59.png)

Cloud NATを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/9b51930f-2ad0-0f9c-b669-94fc510176b2.png)

## Firewall Rules
- デフォルトで作成されているらしいが、不安なので一応外部からのインバウンド拒否、外部へのアウトバウンド許可を設定しておく
- IAP経由のSSH(ブラウザからインスタンスにSSH接続する)のためのインバウンド通信を許可する

> IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
IAP を使用してアクセス可能にするすべての VM インスタンスに対して適用します。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
IAP TCP 転送を使用してアクセス可能にするすべてのポートへの接続を許可します。たとえば、SSH のポート 22 と RDP のポート 3389 です。
https://cloud.google.com/iap/docs/using-tcp-forwarding?hl=ja#preparing_your_project_for_tcp_forwarding


- ターゲットタグ : vmは、このあとVMに付与する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/1fe5d70f-06d1-e27d-5eae-bb47668fefc0.png)


## Webサーバの構築
- ブートディスクでOSを選択する。今回はRocky Linuxにする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/7bc4597e-86ec-67a7-772d-bdcdf506c77e.png)
- 詳細オプション内、ネットワーキングで「vm」タグを付与する
    - FWルールで設定したタグと一緒であればvmでなくてもよい
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/877d9249-4c20-2a07-2d48-0cada5a8158a.png)
- 詳細オプション内、ネットワークインタフェースでIPアドレスを設定する
    - NAT経由させるため、パブリックIPアドレスは付与しない(デフォルト付与)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/eb72a497-a096-8db9-fcbf-5f62d82baa1a.png)
- インスタンスが作成されたら、ブラウザでSSH接続する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/9a775999-0fb9-c929-eef0-89506ad81c92.png)
- 下記コマンドでhttpdをインストールし、起動させ、firewalldのインバウンド80番ポートを許可する

```bash:コマンド
sudo yum install httpd
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --reload
sudo systemctl poweroff
```




## インスタンスグループの作成
- LBのバックエンドに設定するインスタンスグループを作成する
    - 先ほど作成したサーバのディスクを持つVMを起動させるようにする

- まずは、先ほどのVMのディスクからイメージを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/8f3811e9-48e1-ce24-5a68-c1148d4a4f96.png)
- イメージを使って、インスタンステンプレートを作成する
    - ブートディスク以外は、先ほどのVM作成の時とかわらない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/4067e84c-4df6-85c5-304f-cf61bee623e8.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/0aceb860-fbb1-6413-ace1-50269c43eb89.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/eb0caf94-e2e5-8e5d-3576-6d3be7cd7e66.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/a484651b-1835-379a-7c4d-3f88232f5c4c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/b772a8d9-2792-0ed0-e9ea-1ae34a8f8753.png)





## Application Load Balancerの作成
- LBから行われるヘルスチェック・プロキシ専用サブネットからの通信を受け入れるFWルールを作成する
    - 下記に記載のCIDRと、プロキシ専用サブネットのIP→vmタグへのHTTPを許可
        https://cloud.google.com/load-balancing/docs/health-check-concepts?hl=ja#ip-ranges
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/1c7b49e3-da44-e2be-ab6a-ebff9cbaf4eb.png)
- LBを作成する
    - 80番でのLBへのリクエストをVMの80番に転送する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/2ccb917a-5686-5ad0-1e9e-30a11b9f3f2f.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/53d6e49e-829c-6e7a-45cd-2436e1f8c87d.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/3ceef28e-3770-5635-0242-53957a734a65.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/7929fffe-4015-9193-2574-16d537a16006.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/43922e88-80ba-430e-f747-194457345fa4.png)
- 作成されると、「フロントエンド」のところにLBのグローバルIPが表示される
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/5de4980e-e752-c8cb-9085-dd55d134171e.png)

## 動作確認
- LBのグローバルIPにアクセスして、Rocky Linuxのhttpdデフォルトページが表示されることを確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3759447/c9d7b25f-2c0f-ac37-b823-69dc9af5ee4d.png)

## 感想
- VM
    - 初めてGCPでサーバを作成したが、SSH接続するための設定でインバウンドをあけないといけないのは、AWSとの相違点
        - AWSであれば、SSM,EC2,EC2Messagesのエンドポイントへのへのアウトバウンド通信ができればSession Managerで接続できるため
- NW
    - FWの考え方もAWSとは大きく違う
        - AWSであれば最小では各サーバ単位でFWルールを設定するイメージ(Security Group)だが、GCPではVPC単位のFirewall Ruleでまとめて設定
        - 慣れれば、GCPのほうが楽そうではある
    - マルチリージョンの設計はAWSよりしやすそう。
        - VPCがマルチリージョンで、LBもグローバル構成と選べる