4 ms·

I'm actually in the middle of moving some apps to ECS/Fargate. Here are a few of our requirements, it'd be great if you could share if copilot meets or does not

I'm actually in the middle of moving some apps to ECS/Fargate. Here are a few of our requirements, it'd be great if you could share if copilot meets or does not meet them. 1. Production and Staging in separate accounts 2. A new environment provisioned per github PR with setup/teardown - ideally within the same VPC/Subnet ranges, so they can utilise shared databases 3. Secrets stored in Secrets Manager or Parameter Store 4. Blue/Green deploys for production with a manual cutover step (manual step optional) 5. Deployment of 2 services (app, background tasks) from the same dockerfile/commit

kohidavez 6y ago
Awesome - first best of luck on your transition! 1 Yeap! We can do that. 2 hmmm we don’t support this out of the box - but I’d love to know what you expect out of this. All your services spun up and infra? 3. Check! 4. No blue green deployments yet :( 5. Yea! We support this via a pipeline.
- palmdeezy 6y ago
  Number 2 would attract an enormous amount of developers. Can you consider doing an example of such a workflow with copilot and pipelines, including provisioning a LB and/or tweaking an existing one to get per-branch subdomains with https?
- dclausen 6y ago
  As far as expectations for 2 above, in my experience, teams really love having a completely separate environment per PR. Gitlab has done this on top of Kubernetes using a dynamic domain such as <truncated-branch-name>-review-app.domain.com. This gives QA and stakeholders the ability to easily review/signoff on changes prior to going live and not getting bottlenecked by a small number of QA/UAT environments. This becomes particularly helpful as the engineering team scales up.
- jsmeaton 6y ago
  For 2 - we would already have the time infra spun up via something like terraform. So we’d need to “adopt” the VPC/subnets from copilot. The actual connection details would be stored as env vars, but would need a “on create” hook to create the database for the environment.

kohidavez 6y ago

Awesome - first best of luck on your transition! 1 Yeap! We can do that. 2 hmmm we don’t support this out of the box - but I’d love to know what you expect out of this. All your services spun up and infra? 3. Check! 4. No blue green deployments yet :( 5. Yea! We support this via a pipeline.

palmdeezy 6y ago
Number 2 would attract an enormous amount of developers. Can you consider doing an example of such a workflow with copilot and pipelines, including provisioning a LB and/or tweaking an existing one to get per-branch subdomains with https?
dclausen 6y ago
As far as expectations for 2 above, in my experience, teams really love having a completely separate environment per PR. Gitlab has done this on top of Kubernetes using a dynamic domain such as <truncated-branch-name>-review-app.domain.com. This gives QA and stakeholders the ability to easily review/signoff on changes prior to going live and not getting bottlenecked by a small number of QA/UAT environments. This becomes particularly helpful as the engineering team scales up.
jsmeaton 6y ago
For 2 - we would already have the time infra spun up via something like terraform. So we’d need to “adopt” the VPC/subnets from copilot. The actual connection details would be stored as env vars, but would need a “on create” hook to create the database for the environment.