I never understood why people use Docker. QEMU exists
Docker Releases Plugin for Simplified Deployments into AWS
11–20 of 116 posts
Re: Docker Releases Plugin for Simplified Deployments into AWS
#12I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
We’re thinking about doing a similar migration. One of my concerns is that the current Beanstalk infra isn’t described in code, and when I’ve experimented a little with Beanstalk in CloudFormation it’s been horrible to write - for something a lot simpler. I obviously want us to move to using CloudFormation or something like it if we migrate, how good or bad would you say using it (or Terraform if that’s what you sett…
Have you considered experimenting with AWS CDK? The code looked far more elegant than cloudformation
Re: Docker Releases Plugin for Simplified Deployments into AWS
#13I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
Could you comment on why you are moving away from elastic beanstalk? We manage a fairly simple EB deployment but it seems perfect for our infra needs, and I'm not able to imagine why we might need to scale out of it - if any other services are required, I'm tempted to only launch multiple EB deployments instead of going the kubernetes/fargate route.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#14I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
We’re thinking about doing a similar migration. One of my concerns is that the current Beanstalk infra isn’t described in code, and when I’ve experimented a little with Beanstalk in CloudFormation it’s been horrible to write - for something a lot simpler. I obviously want us to move to using CloudFormation or something like it if we migrate, how good or bad would you say using it (or Terraform if that’s what you sett…
If you're looking for confidence in infrastructure changes then I 100% recommend fighting through the 'horrible to write' CloudFormation/Terraform.
CloudF is infra as yaml and Terra is as code. CloudF also has the CDK which can use TypeScript and be infra as code that 'transpiles' down to yaml.
All options feel terrible. It's like learning a whole new programming language that takes 10 minutes to see if your code runs or which part got stuck.
But once you've got your stack working, changes are a breeze and can be done with way way more confidence. Spinning up clone environments is barely any work.
Is it terrible? Absolutely. Is it worth it? Again - absolutely.
If I had to do it again, I would pick the CDK (more powerful), but the fight would've taken longer.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#15I never understood why people use Docker. QEMU exists
Docker is about the tooling, not the namespaces.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#16I never understood why people use Docker. QEMU exists
Apples and oranges. Containers aren’t VMs.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#17Earlier quoted context omitted.
How do you have a “standard” without each provider having to wait on a committee anytime they want any improvements? Even the almighty Terraform which for some reason people still think makes it easy not to experience “cloud lock-in” has cloud specific provisioners.
I was so disappointed when I learned that I'd been duped in regards to Terraforms abilities. My colleagues had explained that Terraform would allow us to avoid being locked in to own cloud provider, because it's "cloud agnostic" so we could easily move to between Azure, GCP and AWS. Imagine my disappointment when I learned that no actually, Terraform will need to know which type of EC2 instance you want, you need to…
Either your colleagues were very misinformed, or this was a slight misunderstanding on your part: Terraform IS cloud agnostic, but not in the way you understood.
Instead, it allows you to use the same tool and management model for resources on any of the 3 big cloud providers, about a 100 assorted SaaS providers, and most importantly, wire them together (e.g. create a Mailgun configuration, and set up its verification DNS records on AWS), all in code, and in the same workflow.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#18I guess Docker gave up on Swarm?
Curious to know why you think so? ECS is a managed service. If Swarm was a managed service on AWS, I'd agree with you here but that's not the case.
Swarm is still brilliant for running multi-node deployments.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#19I am in the process of migrating my stack from Elastic Beanstalk multi-container to Fargate so this looked like an interesting thing I could 'pick up'. This does potentially unify the container definitions between compose and ContainerDefinitions in the task definitions, but for my self, that's not a super helpful tool. Much of the complexity of running Fargate is outside of Fargate, wiring everything up so Route 53…
Could you comment on why you are moving away from elastic beanstalk? We manage a fairly simple EB deployment but it seems perfect for our infra needs, and I'm not able to imagine why we might need to scale out of it - if any other services are required, I'm tempted to only launch multiple EB deployments instead of going the kubernetes/fargate route.
Largely I don't think it's worth moving off EB except in specific scenarios.
I'm a Rails monolith and DB migrations are not well suited in ElasticBeanstalk when running docker containers. There's no way to run a single container that 'completes' and then returns whether it was successful or not.
Currently I have a separate environment that holds a single EC2 (lots of idle time) to run migrations. It fires and the deployment process moves on. I have to hope the migration finishes before the next set of containers gets rotated out, 2-3 minutes.
That's not a good policy to run a prod env by so I'm switching to Fargate where I can run a One Off task and poll for the result.
Other benefits include not paying for that dedicated EC2 idle time. Not worrying about EC2 management. Direct access to parameter store and secrets (EB can't do secrets from Dockerrun.aws.json yet =(
Drawbacks - I lose 'Rolling Update/Deployments based on Health' and HealthD. Another big one, I lose access to the container unless you run sshd itself (don't do it).
I am running both environments side by side to evaluate but realistically the migration requirement is going to push me to a full Fargate.
I could only run the migration step in Fargate while the rest in EB - best of both worlds? But somehow that feels dirty... we'll see what I end up doing.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#20Earlier quoted context omitted.
We’re thinking about doing a similar migration. One of my concerns is that the current Beanstalk infra isn’t described in code, and when I’ve experimented a little with Beanstalk in CloudFormation it’s been horrible to write - for something a lot simpler. I obviously want us to move to using CloudFormation or something like it if we migrate, how good or bad would you say using it (or Terraform if that’s what you sett…
If you're looking for confidence in infrastructure changes then I 100% recommend fighting through the 'horrible to write' CloudFormation/Terraform. CloudF is infra as yaml and Terra is as code. CloudF also has the CDK which can use TypeScript and be infra as code that 'transpiles' down to yaml. All options feel terrible. It's like learning a whole new programming language that takes 10 minutes to see if your code run…
Yep I definitely agree with the importance, it’s probably the most impactful technical debt we have. Clone environments is a big driving force for it too.
I guess what I was hoping is that Beanstalk wasn’t designed with infra as code in mind, but things like Fargate were, and somehow it had become less horrible. Maybe that’s just never going to happen though and it’s the nature of the problem.
Appreciate the pointer toward CDK too, I have used it a tiny bit and it definitely seemed worth exploring further.