📚

テスト環境を構築検討していく④【セキュリティーグループ&Webサーバー作成】

2024/05/31に公開

背景

ある程度NestJSでAPIの作成も進んできたので、Postmanによる単体テストではなく、アプリからのAPI呼び出しで動作を確認していきたいという思いも進めていくと出てくると思います。

ただなるべくコストを抑えていきたいため、本番環境よりもコストを抑えた類似環境でテスト環境を構築していきます。
※ECSなどはリソースだけで費用がかかるので、EC2などのインスタンスを止めながら開発コストを抑えたい。

https://zenn.dev/doshirote/articles/577d8bb31a152b

そのため本番環境を簡易で構築し、テストを行う環境を整備していきます。

セキュリティグループの作成

ファイル毎(yaml)の依存関係を減らすために、分割してセキュリティグループを作りました。

セキュリティーグループが必要なものの認識。
・踏み台サーバー
・webサーバー
・ロードバランサー
・Aurora(MySQL)

webサーバーの作成

作成自体は踏み台サーバーと同じような内容でcloudformationを作成できたので、そこまで問題ではありませんでした。

# 踏み台サーバーにファイルを転送する方法
scp -i 踏み台サーバーに認証したい認証ファイル 踏み台サーバーに渡したいファイル ec2-user@踏踏み台サーバーのIPアドレス:/home/ec2-user/(踏み台サーバーのユーザー名)

これで踏み台サーバーに接続し、その後踏み台サーバー経由でwebサーバーにアクセスできました。

途中まで実施していて良かったこと

今後の事を考えるとcloudformationで、新たにシステムを作れるように、yamlは分割した方が使い勝手がいい気がしています。

以下のファイルに分割したらいいのではないかとの現状の構成です。

①仮想ネットワーク
②セキュリティグループ
③踏み台サーバー
④webサーバー
⑤ロードバランサー
⑥Aurora MySQL

依存関係はVPCやサブネットが必ず上位に来るために、仮想ネットワークが1番目に作成が必要。セキュリティーグループは各サーバーやロードバランサー、Auroraの作成に関係してくるので、2番目に構成が必要。また踏み台サーバーやwebサーバーをssh認証させることから、キーペアは事前に用意しておく必要があります。

キーペアもcloudformationで作成ができるかもしれませんが、一度しかダウンロードできない制約があることから、事前に作るのがいいのではないかと考えております。

意識したこと

セキュリティホールとならないように、セキュリティグループはそれぞれで必要な場所で必要な通信のみ抑えてのアクセス制御をかけています。

ssh(22)
http, https(80, 443)
mysql(3306)

初歩的な話

自分はインフラエンジニアではないので、初歩的な話になるかもしれませんが、publicサブネットとprivateサブネットは以下のような違いがあるようです。

・パブリックサブネット・・・サブネットには、インターネットゲートウェイへの直接ルートがある。
・プライベートサブネット・サブネットには、インターネットゲートウェイへの直接ルートがなく、パブリックサブネットへの通信として NAT デバイスが必要。

その観点を元にルートテーブルを見ると、どちらがpublicサブネットなのか、privateサブネットなのかわかるようです。

上記はルートテーブルになりますが、インターネットゲートウェイがついているので、publicサブネット。

上記はNatがついており、かつインターネットゲートウェイがないので、privateサブネット。

まだ作成途中ですが、焦らずコツコツ頑張っていきたいと思います。

Discussion