🍕

GCPの開発環境でPrivateなCloud SQLを直接触る為に踏み台を作った

いばらき

2022/10/20に公開

今回は、Google Cloud（GCP）のDBの話です。

はじめに

やりたいこと

開発時にGPC上のprivateなCloud SQL(PostgreSQL)のデータを直接操作したい

前提となる状況

開発環境を作る時にセキュリティの教科書的な設定によりDBアクセスはprivate接続のみにしてしまったため、ローカルのPCからDBに直接アクセスができない状況

やること

開発時にDBを直接触れないのはツライので、踏み台を立ててOverSSHでDBを操作できるようにする

必要なもの

踏み台用のGCEのVMインスタンス
Cloud SQL Auth Proxy
- https://cloud.google.com/sql/docs/postgres/sql-proxy?hl=ja
- VMインスタンス上に普通にインストールしてもよいのですが、今回はDockerコンテナーを使用しました
  - https://cloud.google.com/sql/docs/sqlserver/connect-docker?hl=ja

GCP側のインフラ構築手順

前提

VPC及びCloud SQLは作成済とし、Cloud SQLはprivate接続のみができる設定とします

GCEのインスタンスの作成及び設定

GCEのVMインスタンス用に`サービスアカウント`を作る

まずは、GCEのVMインスタンス用のサービスアカウントを作ります。

IAM と管理　-> サービスアカウント -> サービスアカウントの作成
適当にロールをつけて作成すればOK

VPCのFirewallの設定

VPCのFIrewall設定で、上記で作成したサービスアカウント向けの22ポートを許可します。
- ターゲットタイプをサービスアカウントにして、ターゲットサービスアカウントに上記で作成したサービスアカウントを指定します
- 今回作るVMインスタンスのみに対するFirewallのルールを作りたかったので、先ほど個別にサービスアカウントを作成しました

GCEのVMインスタンスを作る

続いて、Cloud SQLと同じVPC上にVMインスタンスを立てます。
先程作成したサービスアカウントを紐付けてください。
普通に作ればいいだけなので詳細は省略しますが、1点だけ注意点として、使用するイメージはContainer Optimized OSにします。Cloud SQL Auth ProxyをDockerで動かす為です。

GCEのVMインスタンス上で、`Cloud SQL Auth Proxy`のコンテナを動かす

公式手順はこちら

下記にざっくりとした手順を記載しますが、詳細は公式手順を参照してください

ローカルPCから、gcp-cliを使ってVMに接続する

gcloud compute ssh --zone=asia-northeast1-b (インスタンス名)

公式の手順の6を参照し、Cloud SQL Auth Proxy用のサービスアカウントを作成し鍵のjsonをVMのインスタンス上に保存する
ブラウザからGCEのVMのインスタンス設定に戻り、自動化の起動スクリプトに鍵のjsonを指定してdockerの起動コマンドを書く

docker run -d \
  -v (VM上の鍵のjsonのpath):/config \
  -p 127.0.0.1:5432:5432 \
  gcr.io/cloudsql-docker/gce-proxy:1.32.0 /cloud_sql_proxy \
  -instances=(cloud SQLインスタンスの接続名) -credential_file=/config

再起動すれば、コンテナーが起動している

以上で設定は完了です

SQLに接続したい開発者がやること

踏み台のIPアドレスを確認する

GCPコンソールに入って、GCEのVMのインスタンスのPublic IP(外部IP)を確認する

sshで踏み台へアクセスするための鍵を作る

GCPのcliをインストールする
https://cloud.google.com/sdk/docs/install-sdk
gcloud compute ssh コマンドでGCEのVMのインスタンスにログインする
https://cloud.google.com/compute/docs/instances/connecting-to-instance?hl=ja#gcetools
- 初回ログイン時に自動でsshの鍵が作られる
  - 今後この鍵を使うので取っておく
  - (初回にsshの鍵のパスワードを設定できるので、好きに設定する)
  - (ユーザー名が勝手に設定される？ので一応メモっておく)

適当なDBのクライアントツールでsshトンネリングでDBにアクセスする

主な設定情報は、以下のようになります。

HOST : 127.0.0.1
PORT : 5432
SSH Host : GCEのVMのIP
SSH PORT : 22
SSH Key : 上記の初回ログイン時に自動で作られたsshの鍵

HOSTが127.0.0.1になる点は注意しましょう。

教科書的には、セキュリティのためにDBはprivateにしましょうなんですけど、開発時はなんだかんだでDBを直接触りたいのでprivateにすると結構面倒くさいなぁと感じました。データの重要性次第では開発環境はpublicでも良いかもしれません。publicでも認証は必要なので最低限のセキュリティはありますし。
- ただし、何れにしても本番はprivateにするべきであり、ネットワーク的な環境差を作りたくないので開発もprivateにしておきたいという思いもあります。
GCPではAWSと違ってサブネットにpublicとprivateの概念がないことに最初混乱しました。AWSとGCPは似ている点が多いけどネットワーク周りはちょっと違いそうですね。勉強しないと。。。

NCDCエンジニアブログ

NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！ ※エンジニア以外も記事を投稿することがあります