AWS CDK 以及如何在不卡住的情况下更新 ECS答案

【问题标题】：AWS CDK and how to update ECS without getting stuckAWS CDK 以及如何在不卡住的情况下更新 ECS
【发布时间】：2020-08-16 12:40:19
【问题描述】：

我有一个简单的 CDK 堆栈来通过 ApplicationLoadBalancedEc2Servic 部署 docker 容器。部署效果很好。但是当我升级时，例如通过将 docker 容器设置为 hasura/graphql-engine:v1.3.1-beta.1，更新需要永远，最后的输出类似于：

12:23:01 | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack
| HasuraStack
12:23:32 | UPDATE_IN_PROGRESS   | AWS::ECS::Service
| Hasura/Service/Service

我认为这与将 desiredCapacity 和 minCapacity 设置为 1 有关。只要我转到 AWS 控制台并将它们手动设置为 0，更新就会起作用。我尝试了 minCapacity/maxCapacity/desiredCapacity 的不同配置，但没有成功。

最好的结果是运行 2 个实例，一个缓慢耗尽的旧实例和一个将所有新流量重定向到的新实例。有什么简单的方法可以实现类似的东西并获得更新吗？短暂的停机时间也是可以接受的。

代码如下：

const cluster = new Cluster(this, 'Cluster', {
  vpc: props.vpc,
});

cluster.addCapacity('ASGroupCapacity', {
  instanceType: new InstanceType(props.instanceType || 't3.micro'),
});

this.service = new ApplicationLoadBalancedEc2Service(this, 'Hasura', {
  publicLoadBalancer: true,
  cluster,
  // assignPublicIp: props.hasuraServiceProps?.assignPublicIp || true,
  domainName: `${props.subDomain}.${props.zone.zoneName}`,
  domainZone: props.zone,
  protocol: ApplicationProtocol.HTTPS,
  memoryReservationMiB: 512,
  desiredCount: 1,
  taskImageOptions: {
    image: ContainerImage.fromRegistry('hasura/graphql-engine:v1.3.0'),
    containerPort: 8080,
    environment: {
      HASURA_GRAPHQL_DATABASE_URL: props.connectionString,
      HASURA_GRAPHQL_ENABLE_TELEMETRY: 'true',
      HASURA_GRAPHQL_ENABLE_CONSOLE: 'true',
      HASURA_GRAPHQL_JWT_SECRET: `{"type": "HS256", "key": "${this.jwtSecret.secretValue.toString()}"}`,
    },
    secrets: {
      HASURA_GRAPHQL_ADMIN_SECRET: Secret.fromSecretsManager(this.secret),
    },
  },
});

【问题讨论】：

标签： node.js amazon-web-services aws-cdk

【解决方案1】：

分享一下，我也遇到过类似情况。

对于集群容量，我设置了以下内容：

    cluster.addCapacity("my-scaling-group", {
      instanceType: ec2.InstanceType.of(
        ec2.InstanceClass.T3A,
        ec2.InstanceSize.SMALL
      ),
      minCapacity: 1,
      maxCapacity: 3
    });

我发现最重要的一点是注销延迟，默认为 5 分钟（=300 秒）。

service.targetGroup.setAttribute("deregistration_delay.timeout_seconds", "30")

整个重新部署大约需要 10 分钟

【讨论】：