概要
この記事では、
・本番環境
・ステージング環境
・開発環境
の3つの環境を使うプロジェクトを、AWSに構築する際の設計を紹介します。
詳しくは、下記書籍に記述されています。
アカウントは環境ごとに分ける
AWSのアカウントは、環境ごとに分けます。
| 本番環境用AWSアカウント |
| ステージング環境用AWSアカウント |
| 開発環境用AWSアカウント |
| 共有リソース用AWSアカウント |
この4つのアカウントを用意します。
特に本番環境は別アカウントにするのが安全です。
1つのアカウントでVPCを分ければいいのでは？という案もありますが、
完全にアカウントを分けておくのが安全とのことです。
また、Gitリポジトリなどの共有リソース用のアカウントも作成します。
Gitリポジトリは1つ、環境ごとにブランチを作成する
CodeCommitやGithubのGitリポジトリは1つにします。
環境ごとにブランチを作成します。
| 本番環境用ブランチ | production |
| ステージング環境用ブランチ | staging |
| 開発環境用ブランチ | develop |
このようなブランチのリポジトリを共有リソース用のアカウントのCodeCommmit(or Github)に作成します。
Gitリポジトリを環境ごとに分けてしまうと、
マージ作業が大変になってしまいます。
CodePipeline-CodeDeployは？
それぞれの環境で、
CodePipline(CodeBuild->CodeDeploy->ECS)を用意します。
開発環境のPipelineは開発用に自由に使えるものです。
開発ブランチにPushされると、CodeBuildが起動し、テスト・ビルドを実行します。
ビルドはリソース共有用アカウントに用意した開発環境用ECRにPushされ、Code DeployがECSにデプロイします。
ステージング環境のPipelineも基本的には同様です。
ステージングブランチにPushされると、CodeBuildが起動し、テスト・ビルドを実行します。
ビルドはリソース共有用アカウントに用意したステージング・本番環境用ECRにPushされ、Code DeployがECSにデプロイします。
本番環境もPipelineを構築します。
ですが、本番環境ではCodeBuildではテスト・ビルドをするのではなくて、
ステージング環境で作成されたテスト済みイメージをステージング・本番環境用ECRからPullするだけとします。
ECRにおけるイメージのメンテナンス
ECRはS3上に構築されるため、イレブンナインの耐久性がある。
ただし、S3よりも料金が高いため、過去バージョンについては、
ライフサイクルポリシーを用いて料金を低減させること。
Bastion設計
各AWSアカウント上に構築されたコンテナやRDSには、踏み台ホスト（Bastion）からアクセスするのが一般的です。
踏み台ホストは、privateサブネットに配置します。
また、pemファイルを用いたSSH接続させるのではなく、
セッションマネージャーを用いて接続させます。
IAMに対してセッションマネージャー接続を許可することで、
セキュリティマネージメントをIAMに寄せることができるからです。