23 comments

[ 3.2 ms ] story [ 58.7 ms ] thread
Does this tie in with the cloud.docker.com (formerly tutum)? Will this be a separate offering? Very cool nonetheless
In the basic mode, this Docker for AWS enables installing some Docker engines integrated into a Swarm with integration into AWS.

It also provides an option for an alternate full stack which solves a similar problem to Docker Cloud called the Docker Datacentre.

Docker Cloud is a public platform for managing containers.

Docker Datacentre is the behind the firewall version, but here they are standing it up in AWS.

I would expect them to converge over time.

AWS already has two other ways of hosting Docker containers: EC2 Container Service [1] and Elastic Beanstalk [2].

Container service apparently "provides more fine-grained control and access to a wider set of use cases" compared to Beanstalk.

What's the difference of this third option? If you are new to AWS and/or Docker, how do you know which to choose?

[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/... [2] https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/creat...

I don't have that much experience with ECS, but it's a lot different than just having a remote docker host or docker swarm. You can't use docker-compose to just automagically spin up a project. I think they have their own yaml format that's similar to docker-compose V1 files, but it's cumbersome to not know what is and isn't supported and what amazon specific features you need to use, etc.

If you're new to AWS but know Docker (like me) then Docker for AWS seems like a winner.

> If you're new to AWS but know Docker (like me) then Docker for AWS seems like a winner.

I'd disagree. It seems you still need to know AWS well enough to setup the various prerequisites. If you're new to AWS but know Docker, you're far better off with something like Convox (which does support docker-compose files)

I meant that only as a comparison between ECS and Docker for AWS.
This is lower level - installing engines and clustering them using Docker Swarm.

ECS provides a GUI and uses its own orchestration layer rather than Docker Swarm.

EC2 is not a Docker solution. EC2 Task&Service definitions are not Docker Task&Service definitions. So this basically ties to with the AWS platform. You can not move your Docker infra between AWS and Azure. Docker for AWS is the way to go, but I believe it could be enhanced greatly. I also think that AWS does not seem to support Docker Swarm very eagerly, because I think AWS still did not figure out to charge Containers, they are still charging Nodes.
Skytap also has a good (fast and quick) solution, with all the docker bells and whistles.
Docker should not do such things, they should stick to their core things and not try to create 10000 things. I know they need to make money, but that is actually the wrong way.
Or at least get the core things rock solid. The impression I'm nearly always left with is that Docker's business decisions are very focused on the 80% functionality and they don't want to be bothered with the diminishing returns that are so critical to get right before you try to run down another rabbit trail.

Deep roots are critical for growing wide branches if you don't want to get blown over in a light breeze.

This is about Docker distributing their software onto a new platform rather than attempting anything radically new.

They have distribution deals with Microsoft, HP, Canonical (announced Today), AWS & Azure.

> I know they need to make money, but that is actually the wrong way.

This will not go well. They're already past $100M in investment and they don't even have a business model.

What about docker for Azure ? I also thought there were too much issues with Swarm to be used in production.
Currently, Azure better supports Docker & Swarm.
Safety Tip: Use the ECS optimized AMI by Amazon if you want to run docker on AWS.

It's based on Ubuntu + an Amazon in house docker edition with custom patches.

It seems that Amazon, Google and RedHat are all desperately trying to get a stable system out of docker. Better rely on them that figure this out on your own.

Insider Info: https://news.ycombinator.com/item?id=12364522

I'm pretty sure that AMI is based on CentOS not Ubuntu.
> ... and can provision Docker in a few clicks

One cool thing about docker is I can write a build file for generating reproducible-ish builds that I can run or rebuild anywhere. My Dockerfile can be version-controlled, copied, edited as code, etc.

But now to run it the official docker way in aws I have to click around a gui? That means no version-controlling my configuration, copying the same configuration to a new staging environment, it's harder to test a config change in staging and then be sure I roll out the exact same change to production, etc.

It seems like more and more of these infrastructure SAAS products are focusing on this kind of pointy clicky experience, and I don't understand why. Sure, a gui is potentially easier for deploying a quick sample app to try it out. But how is the "hello world" market lucrative enough that all these companies seem to focus on it to the exclusion of the "professional developer wanting to use modern best practices" market?

EDIT: and this obviously isn't exclusive to this product. AWS itself does the exact same thing. You have to go out of your way to find something like Terraform that lets you treat your infrastructure as code, and nowhere that I've seen does AWS itself encourage any kind of reproducibility of infrastructure or other kinds of workflow best practices.

They will eventually. Keep in mind, AWS itself was launched about a decade ago and they've been filling out the offering ever since. If or when the growth from new product lines slows, they will focus on the user experience, at which point they will pick off the most symbiotic third party product and replace it with their own version.
AWS pushes Cloudformation.

You won't find it in a getting started guide, because it's simpler not to.

Also, there are caveats like "make sure it doesn't shut down your database"

The point and click is fully optional. Docker for AWS uses all the native AWS primitives, so you can script the install with any AWS client.
Docker Swarm is a great idea. But I think that with Swarm, I don't have to deal(and see) with nodes (server instances). I would be able to just run and scale services(containers). Scaling with nodes should be supported and done with AWS and Azure behind the scenes.