1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

Leaner Technologies Inc.

黒曜
(@kokuyouwind)

$ whoami

黒曜 / @kokuyouwind
名古屋在住
Leaner Technologies Inc. 所属
Railsエンジニア
Next.js とか AWS 周りも触ってる

https://leaner.jp/

We're Hiring!!!

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

Copilot？

そっちじゃないです

AWS Copilot CLI

AWS上でコンテナアプリを構築するツール

https://aws.github.io/copilot-cli/ja/

https://zenn.dev/leaner_tech/articles/20210607-migrate-rails-copilot

Leaner では昨年5月に EC2 -> ECS 移行で採用

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

🤔

「Nつ」とは…？

タイトル決めるときに考えてなかった

少し癖や制約のあるツールなので、

フェーズやサービス特性によって

合うかどうか異なる(Nが変わる)

AWS Copilot CLIの向き・不向き

新規でのWebアプリ構築に最も向いている
- ベストプラクティスに沿った構成が一気通貫で作れる
既存環境の移行にも使えるが、やや旨みが減る
- DNS・VPC周りは既存のものを使い回すほうが楽
用途や現状構成によってはCopilotが適さない可能性
- 厳密なBlue/Greenデプロイはできない
- マルチAWSアカウントの構成によっては使いづらい

AWS Copilot CLI で何ができるか、
どういう点が便利なのか、
どんな癖があるのかを紹介します

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

具体的なNの値は
最後のスライドで！

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

AWS Copilot CLI(再掲)

AWS上でコンテナアプリを構築するツール

https://aws.github.io/copilot-cli/ja/

こういう構成が簡単に作れる

一番簡単な使い方

$ copilot init

https://aws.github.io/copilot-cli/ja/docs/getting-started/first-app-tutorial/

📢 お知らせ
チュートリアル目的以外では
copilot init はオススメしません

copilot init の功罪

copilot init では複数のCopilotリソースがまとめて作られる
- Copilotの特徴的な概念が隠蔽されてしまい理解しづらい
細かいオプションが制御できない
- ドメイン名の紐付け
- 環境を構築するAWSアカウントの指定
Copilotリソースごとの init サブコマンドを使うとよい
- copilot app init, copilot svc init など

Copilot のリソース構成

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

Copilotリソース: Application

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

1つのWebアプリケーションを表現

https://aws.github.io/copilot-cli/ja/docs/concepts/applications/

Copilotリソース: Environment

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

1つのWebアプリケーションを表現

サービスの
動作環境を表現

https://aws.github.io/copilot-cli/ja/docs/concepts/environments/

Copilotリソース: Service

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

サービスの
動作環境を表現

1つのWebアプリケーションを表現

コンテナで動く
サービスを表現

https://aws.github.io/copilot-cli/ja/docs/concepts/services/

Env, Service と実際のコンテナの関係

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

Env × Service ごとにコンテナが作られる
(これはCopilot管理リソースではない)

🤔

コンテナのデプロイは…？

$ copilot deploy --env test

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

この2箇所が
デプロイ対象になる

😣

手作業でデプロイしたくない！

Copilotリソース: Pipeline

Application: MyApp

Test

Prod

Stage

WebAPI

Worker

(Environment)

(Service)

Container

DevPipeline

(Pipeline)

ProdPipeline

developブランチ

mainブランチ

Test Envにデプロイ

Stage Envにデプロイ

E2Eテストが通ったら
Productionにデプロイ

AWS Copilot CLIの概要: まとめ

Copilotでは独自の単位でリソースを管理する
- Application: Webアプリケーション全体を表現
- Environment: テスト・本番などの環境を表現
- Service: APIサーバ・Workerなどのサービスを表現
- Pipeline: デプロイパイプラインを表現
Environment × Service ごとにコンテナなどが作られる
- Environment単位でデプロイされる
- Pipelineからは複数のEnvironmentを順に更新できる

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

各Copilotリソースの init コマンドの使い方と、

具体的に何のAWSリソースが作られるかを
紹介していきます

Copilotリソース: Application

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

https://aws.github.io/copilot-cli/ja/docs/concepts/applications/

Applicationの詳細

copilot app init で Application を作成できる
- Parameter Store上にメタデータが格納される
- ローカルに copilot/.workspace が作られる
このコマンド実行時のAWS Profileが
Copilot CLI利用時の中央アカウントを規定する
- 以降のコマンド実行時は同じProfile指定が必要
- ECRやCodePipelineなど、環境横断のAWSリソースは
  このAWSアカウントに作成される

Application の生成

❯ copilot app init

Use existing application: No
Application name: copilot-test

✔ Created the infrastructure to manage services and jobs under 
application copilot-test.

✔ The directory copilot will hold service manifests for application
copilot-test.


❯ copilot app ls
copilot-test

Parameter Store

copilot/.workspace

❯ cat copilot/.workspace
application: copilot-test
path: ""

ドメインの紐付け

copilot app init --domain 'leaner.jp'
- api.test.copilot-test.leaner.jp のように、
  [svcName].[envName].[appName].[domain] を紐付ける
Route 53 に上記ドメインのホストゾーンが必要
- leaner.jp のホストゾーンに copilot-test.leaner.jp に向ける
  NSレコードが追加される
- copilot-test.leaner.jp のホストゾーンが作成される

ここまでの構成

Application

中央アカウント

Metadata

リポジトリ内
ファイル

.workspace

Route 53

HostZone

Copilotリソース: Environment

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Service)

Container

https://aws.github.io/copilot-cli/ja/docs/concepts/environments/

Environmentの詳細

copilot env init で Environment を作成できる
- 環境を作るAWSアカウントを指定できる
- VPCとSubnetが作成される
  (既存のリソースを使うこともできる)
- [envName].[appName].[domain] の
  Route 53 ホストゾーンが作られる
- Environmentのメタ情報が中央アカウントの
  Parameter Storeに格納される

Environment の生成 (1)

❯ copilot env init
Environment name: test

  Which credentials would you like to use to create test?
  [Use arrows to move, type to filter, ? for more help]
  
  > Enter temporary credentials
    [profile default]
    [profile env-test]

Environment の生成 (2)

❯ copilot env init
Environment name: test
Credential source: [profile env-test]

  Would you like to use the default configuration for 
  a new environment?
    - A new VPC with 2 AZs, 2 public subnets and 2 private subnets
    - A new ECS Cluster
    - New IAM Roles to manage services and jobs in your environment
  [Use arrows to move, type to filter]
  > Yes, use default.
    Yes, but I'd like configure the default resources
      (CIDR ranges, AZs).
    No, I'd like to import existing resources (VPC, subnets).

Environment の生成 (3)

❯ copilot env init
Environment name: test
Credential source: [profile env-test]
Default environment configuration? Yes, use default.
✔ Linked account xxxxxxxxx and region ap-northeast-1 to application copilot-test.

✔ Proposing infrastructure changes for the copilot-test-test environment.
- Creating the infrastructure for the copilot-test-test environment.          [create complete]  [105.3s]
  - An IAM Role for AWS CloudFormation to manage resources                    [create complete]  [36.1s]
  - An ECS cluster to group your services                                     [create complete]  [8.7s]
  - An IAM Role to describe resources in your environment                     [create complete]  [37.7s]
  - A security group to allow your containers to talk to each other           [create complete]  [6.0s]
  - An Internet Gateway to connect to the public internet                     [create complete]  [18.0s]
  - Private subnet 1 for resources with no internet access                    [create complete]  [6.0s]
  - Private subnet 2 for resources with no internet access                    [create complete]  [6.0s]
  - A custom route table that directs network traffic for the public subnets  [create complete]  [15.1s]
  - Public subnet 1 for resources that can access the internet                [create complete]  [6.0s]
  - Public subnet 2 for resources that can access the internet                [create complete]  [6.0s]
  - A private DNS namespace for discovering services within the environment   [create complete]  [49.2s]
  - A Virtual Private Cloud to control networking of your AWS resources       [create complete]  [12.6s]
✔ Created environment test in region ap-northeast-1 under application copilot-test.

CloudFormation Stack (VPC)

Parameter Store

ここまでの構成

Application

Environment

中央アカウント

Test環境用
アカウント

Metadata

リポジトリ内
ファイル

Metadata

.workspace

Route 53

HostZone

Route 53

HostZone

VPC

Copilotリソース: Service

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Container

https://aws.github.io/copilot-cli/ja/docs/concepts/services/

Serviceの詳細

copilot svc init で Service を作成できる
- Service のタイプなどを対話的に入力する
  (今回はLoad Balanced Web Serviceを選択)
- copilot/[svcName]/manifest.yml ファイルが作られる
- Service用のECR RepoとメタデータParameter Storeが
  中央アカウントに作られる
- ALBがEnvironmentに紐付いて作られる
別途デプロイしない限りコンテナは起動しない

Service の生成(1)

❯ copilot svc init
Note: It's best to run this command in the root of your workspace.

  Which service type best represents your service's architecture?
  [Use arrows to move, type to filter, ? for more help]
  
    Request-Driven Web Service  (App Runner)
  > Load Balanced Web Service   (Internet to ECS on Fargate)
    Backend Service             (ECS on Fargate)
    Worker Service              (Events to SQS to ECS on Fargate)

Service の生成(2)

❯ copilot svc init
Note: It's best to run this command in the root of your workspace.
Service type: Load Balanced Web Service
Service name: api

  Which Dockerfile would you like to use for api? 
  [Use arrows to move, type to filter, ? for more help]
  
  > docker/Dockerfile
    Enter custom path for your Dockerfile
    Use an existing image instead

Service の生成(3)

❯ copilot svc init
Note: It's best to run this command in the root of your workspace.
Service type: Load Balanced Web Service
Service name: api
Dockerfile: docker/Dockerfile
parse EXPOSE: no EXPOSE statements in Dockerfile docker/Dockerfile
Port: 80
✔ Wrote the manifest for service api at copilot/api/manifest.yml
Your manifest contains configurations like your container size and port (:80).

✔ Created ECR repositories for service api.

copilot/api/manifest.yml

name: api
type: Load Balanced Web Service

http:
  path: '/'

image:
  build: docker/Dockerfile
  port: 80

cpu: 256
memory: 512
platform: linux/x86_64
count: 1
exec: true

CloudFormation Stack (ECR)

Parameter Store

ここまでの構成

Application

Environment

Service

中央アカウント

Test環境用
アカウント

Metadata

リポジトリ内
ファイル

Metadata

manifest.yml

.workspace

ECR Repo

Route 53

HostZone

Route 53

HostZone

ALB

VPC

Copilotリソース: Pipeline

Application: MyApp

Test

Prod

Stage

WebAPI

Worker

(Environment)

(Service)

Container

DevPipeline

(Pipeline)

ProdPipeline

developブランチ

mainブランチ

Test Envにデプロイ

Stage Envにデプロイ

E2Eテストが通ったら
Productionにデプロイ

Pipelineの詳細

copilot pipeline init で設定ファイルを作成
- copilot/pipelines/[pipelineName] 以下に
  manifest.yml と buildspec.yml が作られる
- この時点ではAWSリソースは作られない
copilot pipeline deploy で AWS リソースを作成
- manifest.yml を元に CodePipeline と関連リソースが
  中央アカウントに作られる

Pipeline の初期化 (1)

❯ copilot pipeline init
Only one git remote detected.
Your pipeline will follow 'git@github.com:leaner-co-jp/copilot-test'.

Your pipeline will follow branch 'develop'.
Pipeline name: copilot-test-pipeline

  Which environment would you like to add to your pipeline?
  [Use arrows to move, type to filter, ? for more help]

> test
  [No additional environments]

Pipeline の初期化 (2)

❯ copilot pipeline init
Only one git remote detected.
Your pipeline will follow 'git@github.com:leaner-co-jp/copilot-test'.

Your pipeline will follow branch 'develop'.
Pipeline name: copilot-test-pipeline
1st stage: test

✔ Wrote the pipeline manifest for copilot-test at
'copilot/pipelines/copilot-test-pipeline/manifest.yml'
The manifest contains configurations for your pipeline.
Update the file to add stages, change the tracked branch,
add test commands or manual approval actions.

✔ Wrote the buildspec for the pipeline's build stage at 
'copilot/pipelines/copilot-test-pipeline/buildspec.yml'
The buildspec contains the commands to push your container images, 
and generate CloudFormation templates.
Update the "build" phase to unit test your services before pushing the images.

copilot/pipelines/.../manifest.yml

name: copilot-test-pipeline
version: 1

source:
  provider: GitHub
  properties:
    branch: develop
    repository: https://github.com/leaner-co-jp/copilot-test

stages:
      name: test
      # Optional: flag for manual approval action before deployment.
      # requires_approval: true
      # Optional: use test commands to validate this stage of your build.
      # test_commands: [echo 'running tests', make test]

copilot/pipelines/.../buildspec.yml

長いので割愛

自動生成ファイルなので、
基本的には手を加えない

Pipeline の作成 (1)

❯ copilot pipeline deploy
Only found one pipeline; defaulting to: copilot-test-pipeline
✔ Successfully added pipeline resources to your application: copilot-test

⠋ Creating a new pipeline: copilot-test-pipelineACTION REQUIRED!
Go to https://console.aws.amazon.com/codesuite/settings/connections to 
update the status of connection copilot-leane-leaner-purchasing- from PENDING to
AVAILABLE.
⠸ Creating a new pipeline: copilot-test-pipeline

Pipeline の作成 (2)

Pipeline の作成 (3)

❯ copilot pipeline deploy
Only found one pipeline; defaulting to: copilot-test-pipeline
✔ Successfully added pipeline resources to your application: copilot-test

⠋ Creating a new pipeline: copilot-test-pipelineACTION REQUIRED!
Go to https://console.aws.amazon.com/codesuite/settings/connections to 
update the status of connection copilot-leane-leaner-purchasing- from PENDING to
AVAILABLE.
✔ Successfully created a new pipeline: copilot-test-pipeline

CloudFormation Stack (Pipeline)

ここまでの構成

Application

Environment

Service

Pipeline

中央アカウント

Test環境用
アカウント

Metadata

リポジトリ内
ファイル

Metadata

manifest.yml

buildspec.yml

.workspace

CodePipeline

ECR Repo

Route 53

HostZone

Route 53

HostZone

ALB

VPC

CodeBuild

CodePipelineからのデプロイ

CodeBuildで docker build を行い、ECR Repoにpushする
- 複数環境にデプロイする場合でもDockerイメージは
  サービスごとに共通
各ServiceのCloudFormation StackをCreateOrUpdate する
- ECS Serviceや関連リソースの他、
  ALB Listener Rule や Target Group なども作られる
- 更新はローリングアップデートで行われる

CodePipeline からのデプロイ

CloudFormation Stack(ECS Service)

ここまでの構成

Application

Environment

Service

Pipeline

中央アカウント

Test環境用
アカウント

Metadata

リポジトリ内
ファイル

Metadata

manifest.yml

buildspec.yml

.workspace

CodePipeline

ECR Repo

Route 53

HostZone

Route 53

HostZone

ECS Service

ALB

VPC

CodeBuild

最終的な構成

Application

Environment

Service

Pipeline

中央アカウント

Test環境用
アカウント

Metadata

リポジトリ内
ファイル

Metadata

manifest.yml

buildspec.yml

.workspace

CodePipeline

ECR Repo

Route 53

HostZone

Route 53

HostZone

ECS Service

ALB

VPC

CodeBuild

各Copilotリソースの詳細: まとめ (1)

application init 時のAWS Profile指定が重要
- メタデータのParameterStoreやCodePipeline,
  ECRなどがこのアカウントに作られる
- 以降のcopilotコマンド実行時もこのProfileを指定する
environment init 時にAWSアカウントを指定することで
環境ごとのAWSアカウント分割が簡単に行える
service init 時には copilot/[serviceName]/manifest.ymlに
サービスマニフェストが生成される
- 環境ごとのデプロイは別途行う必要がある

各Copilotリソースの詳細: まとめ (2)

pipeline init 時にはファイルだけ作成され、
AWSリソースは作られない
- pipeline deploy で CodePipeline などが実際に作成される
initコマンド実行結果がParameter Store, CloudFormation,
ローカルファイルの最大3箇所に反映される
- copilot コマンドを経由せずに削除すると
  不整合になる可能性があるため注意

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

😆 Copilot CLI の便利な点

ベストプラクティスに沿った構成を簡単に作れる
直感的な単位でリソースを管理できる
デフォルトでセキュリティ設定が担保される
Manifestファイルで簡易的なIaCが行える
定期実行ジョブもServiceとして一元管理できる
copilot svc exec で簡単にコンテナ内作業が行える
Addonで追加のAWSリソースを管理できる

AWSサービスを組み合わせた標準Webアプリ構成
- Route 53での環境ごとのDNSホストゾーン分割
- ALBでのHTTPリクエスト受付・ECSへのルーティング
- ECS Fargateでのサービス起動・ローリングアップデート
- CodePipelineでのソース変更検知と自動デプロイ
環境ごとのAWSアカウント分割
Multi-AZ構成

ベストプラクティスに沿った構成を簡単に作れる

直感的な単位でリソースを管理できる

Application: MyApp

Test

Prod

Stage

WebAPI

Worker

(Environment)

(Service)

Container

DevPipeline

(Pipeline)

ProdPipeline

developブランチ

mainブランチ

Test Envにデプロイ

Stage Envにデプロイ

E2Eテストが通ったら
Productionにデプロイ

デフォルトでセキュリティ設定が担保される

ECSコンテナはALBと他のサービスコンテナからのみ
接続が通るセキュリティグループが設定されるなど、
デフォルトで十分なセキュリティ設定が担保される

Manifestファイルで簡易的なIaCが行える

http:
  path: '/'
  healthcheck:
    path: '/health'
    healthy_threshold: 3
    unhealthy_threshold: 2
    interval: 10s
    timeout: 5s
    grace_period: 300s
  deregistration_delay: 10s

network:
  vpc:
    placement: 'private'

Service ManifestでALBのHealth Check設定や
ネットワーク配置設定(private化)などが指定できる

定期実行ジョブもServiceとして一元管理できる

name: daily-batch
type: Scheduled Job

on:
  # JST 9:00 -> UTC 0:00
  schedule: "0 0 * * *"
retries: 0
timeout: 1h

image:
  build:
    context: .
    dockerfile: ./docker/Dockerfile
command: "bundle exec rake app:daily_batch"

Service Type: Scheduled Job でスケジュール実行できる
(AWS上では Step Function + ECS OneShot Task で実行される)

copilot svc exec で簡単にコンテナ内作業が行える

❯ copilot svc exec

  Into which service would you like to execute? 
  [Use arrows to move, type to filter, ? for more help]
    api (staging)
    api (production)
  > api (develop)
  
  Service: api
Execute `/bin/sh` in container api in task 
  03020538d7b1482790d362faa1979d9a.

Starting session with SessionId: 
  ecs-execute-command-00e6b3ab703b08eb1
#

サービスと環境を選んで、そのコンテナ内でコマンド実行できる

(内部的にはSessonManagerで接続する)

Addonで追加のAWSリソースを管理できる

Resources:
  FireLensPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action:
              - logs:CreateLogStream
              - logs:CreateLogGroup
              - logs:DescribeLogStreams
              - logs:PutLogEvents
            Resource:
              - "arn:aws:logs:*:*:log-group:/ecs/logs/copilot-test"
              - "arn:aws:logs:*:*:log-group:/ecs/logs/copilot-test:log-stream:*"

copilot/[svcName]/addons/[addonName].yml に
CloudFormation YAMLで任意のAWSリソースを追加できる

https://aws.github.io/copilot-cli/ja/docs/developing/addons/modeling/

🤔 Copilot CLI の癖のある点

Copilotリソースの単位で何が作られるかを知らないと、
トラブルシューティングが非常に難しい
ドメイン紐付けが Application init 時にしかできない
意識しないとデフォルトAWSアカウントに色々作られてしまう
ルートドメインのホストゾーンとApplication用のホストゾーンを
別のAWSアカウントに分けることができない
サービスごとにDocker BuildやECR Repo Pushが行われるため
同じビルド設定で複数サービス・ジョブが必要だと非効率
デプロイがCloudFormation更新で行われるため、
ローリングアップデート固定でBlue-Green Deployできない

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

移行事例

https://zenn.dev/leaner_tech/articles/20210607-migrate-rails-copilot

尺足りなさそうなのでブログ読んで！

Copilot CLI Tips (1)

既存環境移行時はドメイン紐付けを動作環境用と割り切って、
全く別のドメインを紐付けて置くと動作確認が楽
- 問題なければALB Listener Ruleに既存ドメイン設定入れた上で
  hosts弄って既存ドメインでの挙動を改めて確認する
- それも良ければ既存DNSレコード弄ってCopilot ALBに向ける
healthcheck周りの設定を入れるとデプロイが速くなる
- healthy_threshold, interval, deregistration_delay あたり
platformをlinux/arm64にする場合はCodeBuild環境もarmに変更する
- ここを直さないとビルドに失敗するか、
  イメージ形式が合わずECS Taskの起動に失敗する

Copilot CLI Tips (2)

サービス初回デプロイでデプロイ失敗した場合は、
ECS Service含むCloudFormation Stackの削除が必要
- イメージとECS Taskでplatform不一致のときなどに発生
- CREATE_FAILED になるので以降のCreateOrUpdateが必ず失敗
- 一度作成に成功していれば、以降はRollbackになるので大丈夫
vpc.placementをprivateにするとセキュリティ的には安心だが、
NAT Gatewayが作られるのでコストは高くなる
- コストを抑えたいなら本番環境のみ設定を入れるのがおすすめ
DockerfileのFROMイメージはECR Public Repositoryにするとよい
- DockerHubだと上限引っかかることがよくある

アジェンダ

AWS Copilot CLIの概要と特徴
各Copilotリソースの作り方と詳細
Copilot CLIの便利な点・癖のある点
Leanerでの事例紹介とTips
まとめ

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

😆 Copilot CLI の便利な点(再掲)

ベストプラクティスに沿った構成を簡単に作れる
直感的な単位でリソースを管理できる
copilot svc exec で簡単にコンテナ内作業が行える
Manifestファイルで簡易的なIaCが行える
定期実行ジョブもServiceとして一元管理できる
デフォルトでセキュリティ設定が担保される
Addonで追加のAWSリソースを管理できる

まとめ

少なくとも 7 個のおすすめポイントがある(多分もっとある)
- 癖はあるが、リソース管理単位が直感的で扱いやすい
- スタートアップ規模なら制限要件も特に気にならないはず
AWSマルチアカウント構成は最初に考えておくとよい
- ルートホストゾーンを含むCopilot用の中央アカウントと、
  App × Envごとのアカウントを作るのがおすすめ
- ルートホストゾーンのあるアカウントの共有が厳しい場合は、
  Copilot割当を冗長なドメインにしてしまうのも手
  ( api.develop.myapp.copilot-myapp.leaner.jp など)

質疑応答や
移行事例・Tipsなどを聞きたい方は
oVice会場かMeetyでお話しましょう！

https://meety.net/matches/pABFTFpaORla

1年間本番運用してわかった、スタートアップこそAWS Copilot CLIを使うべきNつの理由

By 黒曜

1年間本番運用してわかった、スタートアップこそAWS Copilot CLIを使うべきNつの理由

AWS Startup Communityの「スタートアップ事例祭り〜監視・モニタリング・セキュリティ編〜」で発表した資料です。 https://aws-startup-community.connpass.com/event/241721/

1年間本番運用してわかった、 スタートアップこそAWS Copilot CLIを使うべきNつの理由

Leaner Technologies Inc.

黒曜 (@kokuyouwind)

$ whoami

We're Hiring!!!

1年間本番運用してわかった、 スタートアップこそAWS Copilot CLIを使うべきNつの理由

Copilot？

AWS Copilot CLI

Leaner では昨年5月に EC2 -> ECS 移行で採用

1年間本番運用してわかった、 スタートアップこそAWS Copilot CLIを使うべきNつの理由

🤔

タイトル決めるときに考えてなかった

少し癖や制約のあるツールなので、

フェーズやサービス特性によって

合うかどうか異なる(Nが変わる)

AWS Copilot CLIの向き・不向き

AWS Copilot CLI で何ができるか、 どういう点が便利なのか、 どんな癖があるのかを紹介します

1年間本番運用してわかった、 スタートアップこそAWS Copilot CLIを使うべきNつの理由

具体的なNの値は最後のスライドで！

アジェンダ

アジェンダ

AWS Copilot CLI(再掲)

一番簡単な使い方

📢 お知らせ チュートリアル目的以外では copilot init はオススメしません

copilot init の功罪

Copilot のリソース構成

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Copilotリソース: Application

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Copilotリソース: Environment

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Copilotリソース: Service

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

Env, Service と実際のコンテナの関係

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

🤔

$ copilot deploy --env test

Application: MyApp

Test

Production

Stage

WebAPI

Worker

(Environment)

(Service)

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

黒曜
(@kokuyouwind)

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

AWS Copilot CLI で何ができるか、
どういう点が便利なのか、
どんな癖があるのかを紹介します

1年間本番運用してわかった、
スタートアップこそAWS Copilot CLIを使うべきNつの理由

具体的なNの値は
最後のスライドで！

📢 お知らせ
チュートリアル目的以外では
copilot init はオススメしません