AWS Copilot v1.18: 証明書のインポート、Pipeline でのデプロイの順序付け、他

The AWS Copilot コアチームは、Copilot v1.18 リリースを発表します。このリリースに貢献した @corey-cole に感謝を申し上げます。私たちのパブリックなコミュニティチャットは常に成長しており、オンラインでは約 280 人、GitHub では 2.2k のスターを獲得しています。AWS Copilot へご支援、ご支持いただいている皆様お一人お一人に感謝をいたします。

Copilot v1.18 では、いくつかの新機能提供と改善が行われました:

証明書のインポート: copilot env init --import-cert-arns を実行すると、検証済みの ACM 証明書を Environment のロードバランサーリスナーにインポートできるようになりました。詳細はこちらをご覧ください。
Pipeline での順序付け: 継続的デリバリーの Pipeline において、Service や Job がデプロイされる順番を制御できるようになりました。詳細はこちらをご覧ください。
Pipeline の追加改善: デプロイ順序の他に、Pipeline にデプロイする Service や Job を制限したり、Pipeline にカスタム CloudFormation スタックをデプロイすることができるようになりました。詳細はこちらをご覧ください。
再デプロイの迅速化を実現する "recreate" 戦略: "recreate" デプロイ戦略を指定することで、ECS が新しいタスクを開始する前に Service 内の古いタスクを停止するようになりました。詳細はこちらをご覧ください。
Load Balanced Web Service、Worker Service、Backend Service のトレース: ECS タスクから AWS X-Ray にトレースを収集して出力するため、Manifest に observability.tracing の設定を導入し、AWS Distro for OpenTelemetry Collector のサイドカーコンテナを追加しています。詳細はこちらをご覧ください。

AWS Copilot とは?

投稿日: 2022 年 5 月 9 日

AWS Copilot CLI は AWS 上でプロダクションレディなコンテナ化されたアプリケーションのビルド、リリース、そして運用のためのツールです。開発のスタートからステージング環境へのプッシュ、本番環境へのリリースまで、Copilot はアプリケーション開発ライフサイクル全体の管理を容易にします。 Copilot の基礎となるのは、 AWS CloudFormation です。CloudFormation により、インフラストラクチャを 1 回の操作でコードとしてプロビジョニングできます。 Copilot は、さまざまなタイプのマイクロサービスの作成と運用の為に、事前定義された CloudFormation テンプレートと、ユーザーフレンドリーなワークフローを提供します。デプロイメントスクリプトを記述する代わりに、アプリケーションの開発に集中できます。

より詳細な AWS Copilot の紹介については、Overview を確認してください。

証明書のインポート

Contributed by Penghao He

Route 53 以外で管理しているドメインがある場合、またはアプリケーションにドメインを関連付けずに HTTPS を有効にしたい場合、新設の --import-cert-arns フラグを使用して、Environment 作成時に検証済みの証明書をインポートすることができるようになりました。

$ copilot env init --import-cert-arns arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 --import-cert-arns arn:aws:acm:us-east-1:123456789012:certificate/87654321-4321-4321-4321-210987654321

例えば、ある証明書のドメインが example.com で、サブジェクトの別名（Subject Alternative Names/SAN）が *.example.com であったとします。

???+ "Sample certificate" の例

{
  "Certificate": {
    "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012",
    "DomainName": "example.com",
    "SubjectAlternativeNames": [
      "*.example.com"
    ],
    "DomainValidationOptions": [
      {
        "DomainName": "example.com",
        "ValidationDomain": "example.com",
        "ValidationStatus": "SUCCESS",
        "ResourceRecord": {
          "Name": "_45c8aa9ac85568e905a6c3852e62ebc6.example.com.",
          "Type": "CNAME",
          "Value": "_f8be688050b7d23184863690b3d4baa8.xrchbtpdjs.acm-validations.aws."
        },
        "ValidationMethod": "DNS"
      }
    ],
    ...
}

次に、Load Balanced Web Service の Manifestで、インポートされた証明書のいずれに対しても有効なエイリアスを指定する必要があります。

name: frontend
type: Load Balanced Web Service
http:
  path: 'frontend'
  alias: v1.example.com

Attention

Service Manifest に http.alias を指定することは、インポートされた証明書を持つ Environment に Service をデプロイするために必要です。デプロイ後、Environment に作成された Application Load Balancer (ALB) の DNS を、エイリアスドメインがホストされている場所に A レコードとして追加してください。例えば、エイリアスドメインが Route 53 でホストされている場合、

???+ "Sample Route 53 A Record" の例

{
  "Name": "v1.example.com.",
  "Type": "A",
  "AliasTarget": {
    "HostedZoneId": "Z1H1FL3HABSF5",
    "DNSName": "demo-publi-1d328e3bqag4r-1914228528.us-west-2.elb.amazonaws.com.",
    "EvaluateTargetHealth": true
  }
}

これで、あなたの Service は独自の証明書を使用して HTTPS が有効になり、https://v1.example.com からアクセスできるようになりました!

Pipeline におけるデプロイの順序を制御する

Contributed by Efe Karakus

Copilot は、git リポジトリにマイクロサービスを自動的にリリースする継続的デリバリーパイプラインを作成するための copilot pipeline コマンドを提供します。

v1.18 以前は、git リポジトリで定義されたすべての Service や Job は、ステージごとに並行してデプロイされました。例えば、3 つのマイクロサービス (frontend、orders、warehouse）を持つ monorepo があったとします。これらはすべて、test と prod Environment に同時にデプロイされました。

Pipeline

Rendered pipeline

Pipeline Manifest

name: release
source:
  provider: GitHub
  properties:
    branch: main
    repository: https://github.com/user/repo
stages:
- name: test
- name: prod
  requires_approval: true

Repository Layout

copilot
├── frontend
│   └── manifest.yml
├── orders
│   └── manifest.yml
└── warehouse
    └── manifest.yml

v1.18 からは、新しい deployments フィールドで Pipeline 内のデプロイの順番を制御できるようになりました。

stages:
  - name: test
    deployments:
      orders:
      warehouse:
      frontend:
        depends_on: [orders, warehouse]
  - name: prod
    require_approval: true
    deployments:
      orders:
      warehouse:
      frontend:
        depends_on: [orders, warehouse]

上記の Manifest では、orders と warehouse のService を frontend よりも先にデプロイすることを宣言しています。これは、下流の Service が受け入れる準備が整う前にクライアントが新しい API リクエストを送信できないようにするためです。Copilot はスタックをどの順番でデプロイすべきかを判断し、その結果、CodePipeline は次のようになります。 Rendered ordered pipeline

Pipeline の追加改善

その他にも、新しい deployments フィールドに付随するいくつかの機能強化があります。 1. monorepos で、Pipeline にデプロイする Service や Job を設定することができるようになりました。例えば、Pipeline で orders のマイクロサービスだけをデプロイするように制限することができます。

deployments:
  orders:

2. Pipeline が Copilot で生成されないスタンドアロンの CloudFormation テンプレートをデプロイできるようになりました。例えば、以下のような構造のリポジトリがあった場合、

copilot
 ├── api
 │   └── manifest.yml
 └── templates
     ├── cognito.params.json
     └── cognito.yml

その際、 deployments の新しい stack_name、template_path、template_config フィールドを活用して、Pipeline で cognito cloudformation スタックのデプロイを指定することができます。

deployments:
  cognito:
    stack_name: myapp-test-cognito
    template_path: infrastructure/cognito.yml
    template_config: infrastructure/cognito.params.json
  api:

最後のステップは、copilot/templates の下にあるファイルを infrastructure/ にコピーするために cp -r copilot/templates infrastructure/ で、template_path と template_config フィールドが既存のファイルを指すように、copilot が生成する buildspec を変更することです。

再デプロイを加速させる "recreate" 戦略

Contributed by Parag Bhingre

Alert

"recreate" によって Service が停止する可能性があるため、本番 Service での使用はお勧めしません。

v1.18 より前のバージョンでは、Copilot ECS ベースのサービス（Load Balanced Web Service、Backend Service、Worker Service）の再デプロイでは常に新しいタスクをスピンアップし、それらが安定するのを待って古いタスクを停止していました。開発段階にある ECS ベースのサービスの高速な再デプロイをサポートするために、ユーザーは Service Manifest でデプロイ戦略として "recreate" を指定することができます。

deployment:
  rolling: recreate

Copilot は、新しいタスクを起動する前に古いタスクを停止するように、minimumHealthyPercent と maximumPercent をそれぞれ 0 と 100 に設定します（デフォルトは 100 と 200 です）。

Load Balanced Web Service、Worker Service、Backend Service のトレース

Contributed by Danny Randall

v1.17で、Copilot は Request-Driven Web Service から AWS X-Ray にトレースを送信するサポートを開始しました。 Service Manifest で observability を設定することで、Load Balanced Web Service、Worker Service、Backend Service から X-Ray に簡単にトレースをエクスポートできるようになりました。

observability:
  tracing: awsxray

これらの Service タイプでは、Copilot は AWS Distro for OpenTelemetry Collector サイドカーコンテナをデプロイして、Service からトレースを収集し、X-Ray にエクスポートします。トレースを送信するために Service をインストルメント化 (訳注: 計装、アプリケーションに計測のためのコードを追加すること) をした後、Application のデバッグとパフォーマンスの監視するために、Service を通してエンドツーエンドでリクエストの実行状況を確認できます。

X-Ray Service Map Example

可観測性 (Observability) をご一読いただき、トレースについての知識を深めて、早速始めてみましょう！

次は？

以下のリンクより、新しい Copilot CLI バージョンをダウンロードし、GitHub やコミュニティチャットにフィードバックを残してください。

最新 CLI バージョンのダウンロード
スタートガイドを試す
GitHub でリリースノートの全文を読む

今回のリリースの翻訳はソリューションアーキテクトの杉本が担当しました。