3 ms·

Great, but what are the benefits of running Docker in AWS? You are still running VMs and you are being charged for running them. With Docker you are simply putt

by takeda 11y ago

Great, but what are the benefits of running Docker in AWS? You are still running VMs and you are being charged for running them. With Docker you are simply putting yet another layer of complexity, because now you have to run more beefier VMs, you now have problem with network communication between containers running on different hosts. So you will most likely need to use overlay network. You also decrease resiliency, because now when AWS terminated a single VM, all apps running on that node suddenly disappear. I also don't get the argument about running the same container in dev/test/prod. For example my company is working on going Docker and one of the problem with these environments is that app running there has different configuration. So the idea to solve it is to create three different versions of the same container. Genius! But now are you really running the same thing in dev/test/prod? How is it different to what we did in the past? Especially that before Docker through our continuous delivery we actually were using exact same artifact on machines set up with chef that were configured the same way as in prod, while with Docker now we plan to use three different containers.

osipov 11y ago
>what are the benefits of running Docker in AWS? I don't see benefits to running Docker in AWS. In my opinion, AWS implemented its Docker-based Container Service very poorly. I advise my customers against using AWS when want to use Docker. There are many bare metal as a service providers out in the marketplace. >the argument about running the same container in dev/test/prod Is this issue really caused by Docker because you said that you had consistent environments when built by chef?
- notwedtm 11y ago
  Can you name a few bare metal as a service providers?
  - nickstinemates 11y ago
    Rackspace, SoftLayer/Bluemix
- pavel_lishin 11y ago
  > In my opinion, AWS implemented its Docker-based Container Service very poorly. We looked into using it earlier this year. The web UI was flat-out busted in several ways - they only listed the first 100 security groups, and we have a magnitude more than that. The command line interface was poorly documented, and was missing some of the functionality. It was a total waste of a week; I wonder if they've fixed any of that.
- vosper 11y ago
  Would you mind elaborating on some of the issues you see with Elastic Container Service? I'd hoped it would be something like an AWS-specific Mesos, but I haven't looked into it closely.
- nnain 11y ago
  I installed the Amazon Linux Installation Image (AMI) with docker and Python 3.4 for a recent project. I know ElasticBeanstalk fairly well, but configuring this was a big headache. WASTED LOT OF TIME. Instead of making life easy, it just added unnecessary burden of learning Docker for the future project members. Documentation is poor, had to hunt for hours for solutions to simple queries. On AWS, I would suggest you stick with the basic Linux flavour that you know. Use their Docker build only IF you know docker very well.
bri3d 11y ago
Robust composition. Instead of needing a separate database, message queue, app server VM, you can run all 3 containers together on one omnibus machine, or separated as scalability needs demand. Yes, you can achieve something similar using multiple layers in OpsWorks or different deployment schemes with normal Chef, but IMO containers make provisioning and deploying combinations of components easier than most other provisioning and deployment solutions. There's less opportunity for unexpected version collisions and because the network infrastructure is virtual, you can move containers between underlying VMs, allowing capacity planning without substantial reconfiguration.
spdustin 11y ago
Your environment-specific config shouldn't be in the container, but described in the environment itself, whether through ENV vars exposed to the container, or a mounted volume of config files. This is a solved problem, in my (admittedly limited, compared to some other commenters) experience.
nogox 11y ago
Check out https://medium.com/@hyperhq/docker-hyper-and-the-end-of-guest-os-79548fc4099f https://medium.com/@hyperhq/docker-hyper-and-the-end-of-gues... I think this is the way Container-as-a-Service to go, instead of the current form of AWS ECS.
stevelandiss 11y ago
@takeda, how do you create 3 different containers in Docker for dev/test/prod? What parameters are you changing in the three stages?

by takeda 11y ago

osipov 11y ago

>what are the benefits of running Docker in AWS? I don't see benefits to running Docker in AWS. In my opinion, AWS implemented its Docker-based Container Service very poorly. I advise my customers against using AWS when want to use Docker. There are many bare metal as a service providers out in the marketplace. >the argument about running the same container in dev/test/prod Is this issue really caused by Docker because you said that you had consistent environments when built by chef?

notwedtm 11y ago
Can you name a few bare metal as a service providers?
- nickstinemates 11y ago
  Rackspace, SoftLayer/Bluemix
pavel_lishin 11y ago
> In my opinion, AWS implemented its Docker-based Container Service very poorly. We looked into using it earlier this year. The web UI was flat-out busted in several ways - they only listed the first 100 security groups, and we have a magnitude more than that. The command line interface was poorly documented, and was missing some of the functionality. It was a total waste of a week; I wonder if they've fixed any of that.
vosper 11y ago
Would you mind elaborating on some of the issues you see with Elastic Container Service? I'd hoped it would be something like an AWS-specific Mesos, but I haven't looked into it closely.
nnain 11y ago
I installed the Amazon Linux Installation Image (AMI) with docker and Python 3.4 for a recent project. I know ElasticBeanstalk fairly well, but configuring this was a big headache. WASTED LOT OF TIME. Instead of making life easy, it just added unnecessary burden of learning Docker for the future project members. Documentation is poor, had to hunt for hours for solutions to simple queries. On AWS, I would suggest you stick with the basic Linux flavour that you know. Use their Docker build only IF you know docker very well.

bri3d 11y ago

Robust composition. Instead of needing a separate database, message queue, app server VM, you can run all 3 containers together on one omnibus machine, or separated as scalability needs demand. Yes, you can achieve something similar using multiple layers in OpsWorks or different deployment schemes with normal Chef, but IMO containers make provisioning and deploying combinations of components easier than most other provisioning and deployment solutions. There's less opportunity for unexpected version collisions and because the network infrastructure is virtual, you can move containers between underlying VMs, allowing capacity planning without substantial reconfiguration.

spdustin 11y ago

Your environment-specific config shouldn't be in the container, but described in the environment itself, whether through ENV vars exposed to the container, or a mounted volume of config files. This is a solved problem, in my (admittedly limited, compared to some other commenters) experience.

nogox 11y ago

Check out https://medium.com/@hyperhq/docker-hyper-and-the-end-of-guest-os-79548fc4099f https://medium.com/@hyperhq/docker-hyper-and-the-end-of-gues... I think this is the way Container-as-a-Service to go, instead of the current form of AWS ECS.

stevelandiss 11y ago

@takeda, how do you create 3 different containers in Docker for dev/test/prod? What parameters are you changing in the three stages?