s3-deployment: blue/green

[eladb]

See #936 for context. There may be use cases where users would want to deploy each update to a new subfolder in the destination bucket to support "blue/green" deployments (old users can still access the old contents and new users are directed to the new content).

This can be achieved by allocating a unique ID during deployment and returning it as resource attribute so it can be used downstream (e.g. by CloudFront).

[eladb]

Still releavnt

[gavindoughtie-aon]

was about to implement this myself, so yes. Please do it for me.

[eladb]

We can combine something like S3File combined with toJsonString with this to allow web apps to find AWS resources defined in the same CDK apps and referenced through attributes.

[ericzbeard]

This feature will help with the difficulties around configuring a single page web app. If your stack has resources like an API Gateway or Cognito User Pools, you have to use a custom resource to create a config file with environment-specific variables that is copied into the site bucket after deployment. This can lead to downtime since there is a small window between the deployment of the static resources and the addition of configuration file. Doing a blue green deployment would solve this part of the problem.

[sholtomaud]

Any update?

[shivatalwar]

Is there an ETA on this, if this is in progress or not?

[eladb]

We don't have a concrete plan for this at this point, but your comments and +1s can help us prioritize.

[sholtomaud]

Thanks for the response @eladb - it could work like the Lambda b/g deployment (which requires a description for blue/green)

[misterjoshua]

FYI, I'm doing this kind of blue/green with s3-deployment right now, but I generate the key prefix in my construct and provide it to both the BucketDeployment and the resource responsible for routing HTTP requests. Here's an example using HttpApi:

// Produce the key prefix
const destinationKeyPrefix = new Date().toISOString();

// Instruct BucketDeployment to upload into the key prefix
const deployment = new s3_deployment.BucketDeployment(this, 'BucketDeployment', {
  destinationBucket: bucket,
  destinationKeyPrefix: destinationKeyPrefix,
  sources: [s3_deployment.Source.asset(__dirname)],
});

// Create a route to the new destination key prefix
const httpRoute = new apigw2.HttpRoute(this, 'ApiRoute', {
  httpApi,
  routeKey: apigw2.HttpRouteKey.with('/{proxy+}'),
  integration: new apigv2_int.HttpProxyIntegration({
    url: `${bucket.bucketWebsiteUrl}/${destinationKeyPrefix}/{proxy}`,
  }),
});

// But, change the route only after the bucket deployment is finished.
httpRoute.node.addDependency(deployment);

I use a scheduled lambda to clean out the old files.

YMMV with this example because API GatewayV2's L2 constructs are experimental, but the L1 constructs are also available.

[DharmSonariya]

+1

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[JamesRamm]

Can anyone give any info on how this might be achieved currently?
I am looking at this but run against the following stumbling blocks:

• We are considering using lambda@edge to route users to one of two buckets (blue and green), but have seen comments (specifically here) advising against this. If not a lambda function what would be the way to implement this?

• The logistics of a CI/CD pipeline (we are using Gitlab) to facilitate zero-downtime switching between the buckets. My main idea is to update an environment variable of the lambd@edge function in a pipeline job in order to switch the default routing from bucket A to B, however how to actually achieve this in the context of CDK is confusing me. In my understanding, issuing cdk deploy will deploy the whole stack, resulting in downtime, What we want to be able to do is:

  1. Update bucket 'B' with the new contents in a CI job. (Bucket 'A' is the 'live' bucket at this point)
  2. Manual testing
  3. In a second CI job, automatically update the lambda@edge so bucket 'B' is now the live bucket. (There shouldn't be any manual updates of the lambda code at this point - it should be automatically handled by the CI job and/or CDK)

Is this possible with CDK?

[misterjoshua]

Can anyone give any info on how this might be achieved currently?
I am looking at this but run against the following stumbling blocks:

• We are considering using lambda@edge to route users to one of two buckets (blue and green), but have seen comments (specifically here) advising against this. If not a lambda function what would be the way to implement this?

• The logistics of a CI/CD pipeline (we are using Gitlab) to facilitate zero-downtime switching between the buckets. My main idea is to update an environment variable of the lambd@edge function in a pipeline job in order to switch the default routing from bucket A to B, however how to actually achieve this in the context of CDK is confusing me. In my understanding, issuing cdk deploy will deploy the whole stack, resulting in downtime, What we want to be able to do is:

  1. Update bucket 'B' with the new contents in a CI job. (Bucket 'A' is the 'live' bucket at this point)
  2. Manual testing
  3. In a second CI job, automatically update the lambda@edge so bucket 'B' is now the live bucket. (There shouldn't be any manual updates of the lambda code at this point - it should be automatically handled by the CI job and/or CDK)

Is this possible with CDK?

We're using the key prefix approach I mentioned above and a cloudfront function (not Lambda at edge) to rewrite the request uri to the new key prefix.

We've been using this approach for quite some time now. The only major issue we've had was with CloudFront timing out when updating the function, so we replace the function instead of updating it whenever we deploy a change.

To handle your manual testing part, perhaps you could use a staging cloudfront distribution to send your test traffic to the new bucket location. For us, we usually have an entirely different environment for manual testing. The only place we're using the staging distribution approach is in a canary situation while doing a "test in prod" experiment.

[andreialecu]

I believe this could be relevant. CloudFront got blue/green support directly a while ago, which I haven't seen mentioned here:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/continuous-deployment.html

[sholtomaud]

did aws provide any cdk code? seems pretty dead here