Earlier quoted context omitted.
This starts to sound more and more like how they manufacture plumbuses
I always wondered how plumbuses got made.
Me too! Now I know: https://www.youtube.com/watch?v=eMJk4y9NGvE
AWS Copilot
91–97 of 97 posts
Re: AWS Copilot
#92Earlier quoted context omitted.
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 St…
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.
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 -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.
Re: AWS Copilot
#93Note also that the Docker integration into Fargate was released at the same time, see https://aws.amazon.com/blogs/containers/aws-docker-collabora... and https://www.docker.com/blog/from-docker-straight-to-aws/ - this provides a simpler way of using Fargate, especially if you are already using Docker Compose. You can output cloudformation from this as well, but you don't have to understand the internals of ECS to use…
My goodness, Docker Compose file to production stack?! My dreams have come true.
The arguments for k8s I have is that the local and production setups are identical.
It's a PITA to run k8s locally, but the alternative is that you use Docker Compose local, and then deploy to k8s, which means two sets of configs. And that's terrible.
Or, you use Docker Compose locally, and fragment all of the containers into individual ECS/Fargate services which you write the deploy pipeline for individually.
These were your best options, for one glaring reason: You can't use a docker-compose.yaml in production. (I know, I know, Kompose, but it doesn't always work quite right and you now have a k8s cluster).
Really excited to try this out, thanks for the work on it!
Re: AWS Copilot
#94Not directly related to copilot but in context of ever increasing yml/json configurations for cloud apps, am I the only one who feels overwhelmed with the configuration options? I see tons of articles with just drop this json here and that yml there and run this cli command - where is the reference for these json/ymls? Does everyone fully know/understands the structure/options? How do people keep track of the changes…
The new J2EE.
Re: AWS Copilot
#95I probably missed it in the blogpost and github readme, but is there a good way to "export" this into a CloudFormation/Terraform template? After all, this seems to spawn a few things (networking, mostly), so I want to make sure I can automate any further deployments. Thanks!
Yea! You can run copilot svc package which spits out the CloudFormation for the service.
Re: AWS Copilot
#96Not directly related to copilot but in context of ever increasing yml/json configurations for cloud apps, am I the only one who feels overwhelmed with the configuration options? I see tons of articles with just drop this json here and that yml there and run this cli command - where is the reference for these json/ymls? Does everyone fully know/understands the structure/options? How do people keep track of the changes…
I feel like trying to use a "dumb" declarative config language for everything is part of the problem. The domain is not simple enough for that, so you end up with all kinds of weird scripts around it all, or other templating/codegen solutions, plus all kinds of ad-hoc conventions that are extremely easy to break and very annoying to navigate. Having a full blown statically typed language like TypeScript - where thing…
This also sounds like the Nix language (https://nixos.org/).
Re: AWS Copilot
#97Earlier quoted context omitted.
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 St…
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.
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.