この記事は リンクバルアドベントカレンダー2023 の17日目の記事です。
2日連続AWS Copilotの記事です！
昨日
はじめに
AWS Copilotは、複数AWSアカウントにenvをかんたんに作ることができます。
必要なIAMもよしなに設定してくれます。
が、複数アカウント運用だと以下のデメリットがあります。
- 本番リソースとそれ以外のリソースでもろもろの権限を分けられない
- 厳密にはほぼすべてのリソースに付くtagの
copilot-environmentで設定できますが、私はアカウントごと分けたかったです- pipeline系のリソースには付きません、、、
- 厳密にはほぼすべてのリソースに付くtagの
- 一つのAWSアカウントに作られるリソースとenvのAWSアカウントに個別に作られるリソースがあってややこしい
AWS Copilotの思想にはきっと逆らうのでしょうが、これらのデメリットを解決する方法を紹介します。
結論
envを作成したいAWSアカウントの認証情報で copilot app init する。
AWS Copilotは、app initをしたAWSアカウントにApplicationが作成されます。
たとえ他のAWSアカウントで作成したアプリケーションと同じ名前でも、アカウントが異なれば完全に別アプリケーションとなります。
これは当たり前で、そうでなければS3バケットのように世界で一つのApplication名にしないといけませんからね。
具体的なコマンド
前提
-
~/.aws/configに[profile A]と[profile B]があり、それぞれは異なるAWSアカウントとする - Aは本番環境、Bはstg環境用とする
# 実際の作業は、 alias copsand='AWS_PROFILE=sandbox copilot' で copsand を使った
# Aでapplication作成
$ AWS_PROFILE=A
$ copilot app init app_name
# Aでenv作成
$ copilot env --profile A init -a app_name -n prod
# profileやVPCなど適切なものを選択
# 必要に応じてmanifestファイル編集
$ copilot env deploy -n prod
# Aでsvc作成
$ copilot svc init -n frontend
# 必要に応じてmanifestファイル編集
$ copilot svc deploy -n frontend -e prod
# Aでpipeline作成
$ copilot pipeline init -n aaa -p Workloads -u aaaaa
# 必要に応じてmanifestファイル編集
$ copilot pipeline deploy -b aaa --yes
##########
# Bでapplication作成
$ AWS_PROFILE=B
$ copilot app init app_name
# Bでenv作成
$ copilot env --profile B init -a app_name -n stg
# profileやVPCなど適切なものを選択
# 必要に応じてmanifestファイル編集
$ copilot env deploy -n stg
# Bでsvc作成
$ copilot svc init -n frontend
# 必要に応じてmanifestファイル編集
$ copilot svc deploy -n frontend -e prod
# Bでpipeline作成
$ copilot pipeline init -n bbb -p Workloads -u bbbbb
$ copilot pipeline deploy -b bbb --yes
なお、aliasを作成することをおすすめします。
構築段階だとcopilotコマンドの実行回数は多く、毎回 AWS_PROFILE などを指定するのは面倒ですし、指定漏れが起きるためです。
私は以下のようなaliasを設定しています。
alias cop='copilot'
alias copprod='AWS_PROFILE=A copilot'
alias copstg='AWS_PROFILE=B copilot'
注意点
一つのアカウントにだけあればよいリソースもできてしまいます。
それは人によりますが、ECRは一つだけにしたい、という方はいる気がします。
参考
公式ドキュメントの以下の2つは必ず読みましょう。
どのリソースがアカウント共通かenvのアカウントごとにできるかは、以下のスライドがひじょうにわかりやすいです！
おわりに
おわり