Docker Releases Plugin for Simplified Deployments into AWS
1–10 of 116 posts
Re: Docker Releases Plugin for Simplified Deployments into AWS
#2This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services.
It’s the most direct route vs formalizing a standard but, uglh.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#3This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services. It’s the most direct route vs formalizing a standard but, uglh.
Its not a mystery AWS profit from docker as is call ECS, they even had ecs cli that felt like a poor version of docker's tool. So upstream support in AWS was actually an good move.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#4This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services. It’s the most direct route vs formalizing a standard but, uglh.
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.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#5This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services. It’s the most direct route vs formalizing a standard but, uglh.
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 configure an AWS load balancer, not just "a load balancer".
Terraform does NOTHING to help you move between cloud platforms aside from providing a language that will work across providers. You still need to understand how everything ties together and is configured in each platform, now you just can use the examples in the documentation or the newest features.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#6I have the feeling that docker compose only supports a small subset of ECS. ECS has stuff like Load Balancers, schedulers and a parameter store in very specific ways. I don't think you'd want to use docker compose for that on AWS.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#7I 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 => CloudFront + WAFv2 => ALB => TargetGroup => Fargate w/ security groups, subnets underpinning it all.
I can't recommend looking at this seriously as something to run in production. CloudFormation/Terraform is still the best place to sink your time.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#8This is far from the first time, but I have a weird dirty feeling when i see infrastructure management tools directly reference specific service provider IaaS/PaaS services. It’s the most direct route vs formalizing a standard but, uglh.
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.
In my opinion, being cloud-agnostic is today’s being database-agnostic.
In more than two decades of professional software development, I have only once encountered a situation where an existing application was migrated to a different RDBMS instead of just being rewritten. Using an ORM framework for the sake of database independence seems hardly justified in that case.
I suppose that things will turn out much the same with cloud agnosticism.
Similar to the RDBMS case, being agnostic of the underlying technology prevents you from using that technology’s more interesting features, to the extent that you’re treating a database as a dumb data store or cloud hosting as a mere space for hosting your files.
Re: Docker Releases Plugin for Simplified Deployments into AWS
#9I 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 settled on) for Fargate is?
Re: Docker Releases Plugin for Simplified Deployments into AWS
#10I guess Docker gave up on Swarm?