10 ms·

Docker Betas for AWS, Azure, Mac, and Windows

314 points by petemill 10y ago

andor436 10y ago
As usual with AWS (or anything I guess) there's more than one way to accomplish a particular goal. How much of Amazon's Elastic Container Service is replicated by Docker for AWS? I'm currently using ECS + Docker but this looks potentially simpler.
- petemill 10y ago
  Seems like there's not much in the way, at the moment, about attaching EBS volumes, or using your own custom AMI. For example, I want to mount an NFS share on the host to connect some container data volumes to directories inside. I've asked about this on the new forum https://forums.docker.com/c/docker-for-aws https://forums.docker.com/c/docker-for-aws
  - tracker1 10y ago
    What if your app was designed to work against AWS's data offerings, from RDS, S3, etc? Unless you're self-hosting your DB, concerns about persistence are less of an issue. Also worth considering if you are self-hosting is the replication/redundancy in the platform, you should be able to preserve-restart instances. Me, I'd rather use what's available than self-host more often than not, but depends on the use-case.
    - petemill 10y ago
      Not sure I get what you're saying. NFS is not self-hosting. In fact, AWS has an NFS service called EFS (in preview).
      - tracker1 10y ago
        I meant writing your apps specifically against data services, not the filesystem directly.
- KenCochrane 10y ago
  Hello, I'm a developer on this project. Our goal for this project was to keep it as simple as possible. We tried to only use standard AWS features (CloudFormation, EC2, Autoscaling groups, VPC, ELB, etc) and we are using Docker 1.12 out of the box, with no changes. All of the scheduling is handled in the docker engine itself, so we didn't need to add anything outside of that. This version is pretty much an MVP, and we hope that the beta testers will help us test it out, and guide the future direction of the project.
jowiar 10y ago
Long-term, where does using something like this make sense vs. Mesos?
- zjaffee 10y ago
  I don't think it does make a difference, these are all just resource/cluster managers. Swarm and Kubernetes are more focused on containers, where Mesos is more robusta and can support running many other things on top of it.
- theptip 10y ago
  Mesos is proven at massive scale (Apple use it for Siri, Twitter use it for their data warehouse). You can run a cluster of 10k nodes if you want. I believe they have run simulations at higher scale than that. Docker Swarm is not yet proven at such scale. They have run perf tests at 1k nodes, which is high enough for most use cases, but not for truly warehouse-scale computing. 1k nodes is also where Kubernetes tops out at (though expect that to be higher in Kubernetes 1.3, which should be released in the coming weeks). On the other hand, if you're trying to run Docker container workloads, it's going to be easier in a Docker-first cluster orchestrator like Docker Swarm or Kubernetes; Mesos has Docker support but it's not as tightly integrated, and doesn't implement the full Docker management API.
tbrock 10y ago
The more I use Docker the more I realize that GCE is going to smoke AWS and Azure in the future with regards to deploying a containerized infrastructure. This is mostly because turn-key kubernetes on GCE is light years ahead of what ECS provides. It almost makes amazon's offering seem like a joke. This might level the playing field a bit by having Docker itself provide the infrastructure management software instead of it being tied to a particular service.
- AlexCoventry 10y ago
  A better comparison is probably Amazon's Elastic Beanstalk / Docker integration. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create...
  - tbrock 10y ago
    No, elastic beanstalk is terrible.
    - MBCook 10y ago
      Works great for us so far. Care to elaborate?
      - yoanisgil 10y ago
        I've been using Elastic Beanstalk for some time now and while I find it quite useful for people who just want to get Docker to production without investing to much time into Orchestration, it looks to me like there is a bit of price to pay for that 'simplicity': - Elastic Beanstalk does not provide a native Docker experience. You're forced to use AWS own way of defining services and dependencies (Dockerrurn.aws.json, which comes in two versions). This means you cannot longer use docker-compose, and not all of the options from `docker run` are available (logging driver, privileged containers, though I think the ability to run privileged containers was recently added). - From my personal experience deployment times can be unacceptable long ranging from 5 - 20 mins. They get longer as you add more instances to the environment or if the instances are not powerful enough. I think Elastic Beanstalk makes a good choice for starters or for not so mission-critical applications. As a result of the points explained above I'm now looking into more Docker-centric solutions such Rancher/Kubernete or Docker's UCP.
parent5446 10y ago
What happened to the good ol' Unix philosophy? The docker command used to be about containers, not service and network scaling in the cloud.
- clvx 10y ago
  It doesn't apply to startup/companies.
- Artemis2 10y ago
  rkt does this: https://coreos.com/blog/rocket https://coreos.com/blog/rocket
- geofft 10y ago
  You can either have a bunch of different tools that do their own little thing and do them well and need a bunch of perl scripts and sysadmins on call to actually do anything useful, or you can have one large tool that does one meaningful thing and, by virtue of being one tool, does it well. The UNIX philosophy is fine, it's just slowly escaping from the people who misunderstood it. (Oddly enough UNIX kernels have always been fine, partly because of the bikeshed principle, and partly because experimentally, doing a bunch of tiny things well doesn't actually get you a working OS.)
  - parent5446 10y ago
    That I can agree with, but I still feel like there is a reasonable line to be drawn between application containerization and coordination and load-balancing of networked services.
    - IanCal 10y ago
      Does it automatically do all of that? The launching/coordination/etc seem to be more the job of machine, compose and swarm (?). edit - Ah, I think I've just seen the other docker announcement this might be about.
- shykes 10y ago
zymhan 10y ago
Am I the only one getting SSL errors trying to connect to their blog?
- KenCochrane 10y ago
  It happened to me for a brief second, and it is fixed now, are you still seeing an issue?
julienchastang 10y ago
Slightly off topic. What are people doing about user data persistence on the cloud/Docker? Specifically, we are porting a desktop application to the cloud via application streaming technology with Docker, but we would like the user’s data and preferences to not go "poof" when the cloud instance disappears. Ideally, we would like some automagic way to attach, say, the user's dropbox account or the equivalent to the cloud instance. Is anyone working on that problem?
- pat2man 10y ago
  Kubernetes has persistent volumes: http://kubernetes.io/docs/user-guide/persistent-volumes/ http://kubernetes.io/docs/user-guide/persistent-volumes/ You can use something like Glusterfs and distribute your files or it can hook in to your clod provider and create persistent storage automatically on something like EBS.
  - ShakataGaNai 10y ago
    When I tried it way back when, he trouble I had with Gluster is that it didn't readily handle nodes randomly leaving and new ones joining. It was more hardware-centric in that if a node left, you were expected to bring that specific node back online. Is that still the case?
- dominotw 10y ago
  NFS volumes. There are many storage solutions out there for containers.
  - e12e 10y ago
    I think this is where the idea of co-locating compute and storage really shines (eg: Joyent/Manta, scaleableinformatics.com) - moving all state to nfs sounds like a great way to widen the performance gap between RAM and permanent storage... Not to mention that if you really want to spread your data and your application, you would require nfs over vpn (unless encrypted nfsv4 actually works now?).
dang 10y ago
We merged the threads on these announcements. The Mac beta is at https://www.docker.com/products/docker#/mac https://www.docker.com/products/docker#/mac and the Windows one at https://www.docker.com/products/docker#/windows https://www.docker.com/products/docker#/windows.
pgz 10y ago
I don't understand why Docker for Mac is a GUI application. I'd rather get the same features from the CLI.
- KenCochrane 10y ago
  You can still use the CLI, there is nothing stopping you.
  - pgz 10y ago
    So I assume the new native hypervisor is available from cli as well? Then that's excellent!
    - ryanschneider 10y ago
      Yea, the GUI is just there to manage updates and to let you know it's up and running, you use the actual docker CLI commands for everything just like on Linux. The hypervisor is completely abstracted away. For example, here's the output of me running `docker info`: Kernel Version: 4.4.13-moby Operating System: Alpine Linux v3.4 OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 1.954 GiB
    - KenCochrane 10y ago
      Yup, try it out, and let us know if you have any issues, or ideas on how to make it better.
      - DanielDent 10y ago
        Can it fall back to Virtualbox/vmware/parallels/etc if Hypervisor.framework isn't available? Hypervisor.framework doesn't run on somewhat dated x86 machines.
        moondev 10y ago
        Not that i'm aware of, but using the hypervisor is pretty much the entire point. If you need to use vbox etc then just use docker-machine
tacos 10y ago
They never emailed me from the last "private beta" before announcing this. And now deploying this on AWS or Azure requires me to sign up for yet another "we'll get back to you..." private beta. Love the tech, hate all this marketing runaround. EDIT to add: either your beta is ready or it ain't. I understand a gentle initial seed to verify it's not an utter catastrophe but no need to play nanny with my bits across 20+ beta releases. I'm a grown up. Make a disclaimer and let me assess the risk. Your corporate logo looks like a 1970s Carvel ice cream cake--I know what I'm getting myself into.
- KenCochrane 10y ago
  Check your spam folder, some of the email from the last private beta went in people's spam folder, so they never saw them. Either way it doesn't matter anymore since Docker for Mac and Windows is now public to use without the need of a code.
  - tacos 10y ago
    I'm not sure there's much overlap is between people who can get Docker Machine limping on VirtualBox with storage and networking flowing properly on Windows 10 fast ring and those who don't know how to check their spam folders, but I appreciate the tip. No messages (and I applied via two accounts for two different platforms). No message telling me "go get the bits!" today. And nothing in spam folders. But yet another blog post asking me to sign up for yet another private beta... ugh. EDIT to add: As polite feedback--two separate requests, two separate Docker accounts, one Gmail and one corporate email address, and I did not receive any invite during the private beta nor notification today when it went public.
    - KenCochrane 10y ago
      You would be surprised how many people didn't see it in their spam folder. Hence the reason why I mentioned it. :) Not sure what you mean about no message telling me to go get the bits today. There was no email saying that docker for mac/windows was made public, it was announced during the keynote at DockerCon (this morning), and a blog post went out. Before we made it public, everyone who had signed up for the beta had an invite sent to them, and there was no one left in the queue.
Sanddancer 10y ago
They need to put a note on their page that docker for windows is not compatible with docker for windows containers. I've been playing around with docker for windows containers for a few days, then saw this and thought, "cool, an update." I installed, and discovered that while the client is compatible between the two, the daemons they run cannot see the containers created in the other daemon. MS and Docker need to sort this stuff out, because right now, windows containers are nicer for the few images that have been released, but docker for windows allows for the full docker ecosystem.
- justincormack 10y ago
  We will sort this out soon, sorry.
spilk 10y ago
Not a fan of the new Windows version as it requires you to enable Hyper-V, which stops any other virtualization (Virtualbox, VMware, etc.) from functioning. The only workaround I've found is rebooting to enable/disable it on demand.
- syaz1 10y ago
  What are you talking about? I had to enable Hyper-V to get Virtualbox or any other VM solution working. But yes you're right that you can't use them at the same time. The new native docker doesn't use third-party VM (boot2docker) and interfaces with the host hypervisor directly. So I had to stop all running virtualbox VMs to get docker to start.
GordonS 10y ago
And the Windows version is still Windows 10 only :/ Many large organisations are going to be tied to Windows 7 for a good while yet...
- pjmlp 10y ago
  Because it makes use of Windows containers introduced in Windows 10, instead of bring GNU/Linux with Virtual Box along. Same thing on Mac OS X, they have migrated to the hypervisor API.
FloNeu 10y ago
Now even docker wants me to upgrade to windows 10 ^^ Keep up the great work!
mwambua 10y ago
IBM's Bluemix has supported Docker Containers for a while now, but hasn't gotten much limelight... probably as a result of the size of their community and Bluemix's sketchy [but improving] stability. Does anyone have any experience using their container service? And would this be a big improvement?
- patwolf 10y ago
  I've been using the container service for a few months. I have encountered a case where my running containers completely disappeared and was told by support that this was because of a "migration". They claimed to have notified me beforehand on several occasions, but I have no evidence of this. Hopefully this was a one time occurrence and will lead to greater stability. One other general problem I've had is the time it takes to launch a container. I would expect containers to be an improvement over VMs in terms of how quickly you can launch, but that doesn't seem to be my experience so far. I would wait a while longer before I would consider their container services for production workloads.

314 points by petemill 10y ago

As usual with AWS (or anything I guess) there's more than one way to accomplish a particular goal. How much of Amazon's Elastic Container Service is replicated by Docker for AWS? I'm currently using ECS + Docker but this looks potentially simpler.

petemill 10y ago
Seems like there's not much in the way, at the moment, about attaching EBS volumes, or using your own custom AMI. For example, I want to mount an NFS share on the host to connect some container data volumes to directories inside. I've asked about this on the new forum https://forums.docker.com/c/docker-for-aws https://forums.docker.com/c/docker-for-aws
- tracker1 10y ago
  What if your app was designed to work against AWS's data offerings, from RDS, S3, etc? Unless you're self-hosting your DB, concerns about persistence are less of an issue. Also worth considering if you are self-hosting is the replication/redundancy in the platform, you should be able to preserve-restart instances. Me, I'd rather use what's available than self-host more often than not, but depends on the use-case.
  - petemill 10y ago
    Not sure I get what you're saying. NFS is not self-hosting. In fact, AWS has an NFS service called EFS (in preview).
    - tracker1 10y ago
      I meant writing your apps specifically against data services, not the filesystem directly.
KenCochrane 10y ago
Hello, I'm a developer on this project. Our goal for this project was to keep it as simple as possible. We tried to only use standard AWS features (CloudFormation, EC2, Autoscaling groups, VPC, ELB, etc) and we are using Docker 1.12 out of the box, with no changes. All of the scheduling is handled in the docker engine itself, so we didn't need to add anything outside of that. This version is pretty much an MVP, and we hope that the beta testers will help us test it out, and guide the future direction of the project.

jowiar 10y ago

Long-term, where does using something like this make sense vs. Mesos?

zjaffee 10y ago
I don't think it does make a difference, these are all just resource/cluster managers. Swarm and Kubernetes are more focused on containers, where Mesos is more robusta and can support running many other things on top of it.
theptip 10y ago
Mesos is proven at massive scale (Apple use it for Siri, Twitter use it for their data warehouse). You can run a cluster of 10k nodes if you want. I believe they have run simulations at higher scale than that. Docker Swarm is not yet proven at such scale. They have run perf tests at 1k nodes, which is high enough for most use cases, but not for truly warehouse-scale computing. 1k nodes is also where Kubernetes tops out at (though expect that to be higher in Kubernetes 1.3, which should be released in the coming weeks). On the other hand, if you're trying to run Docker container workloads, it's going to be easier in a Docker-first cluster orchestrator like Docker Swarm or Kubernetes; Mesos has Docker support but it's not as tightly integrated, and doesn't implement the full Docker management API.

tbrock 10y ago

The more I use Docker the more I realize that GCE is going to smoke AWS and Azure in the future with regards to deploying a containerized infrastructure. This is mostly because turn-key kubernetes on GCE is light years ahead of what ECS provides. It almost makes amazon's offering seem like a joke. This might level the playing field a bit by having Docker itself provide the infrastructure management software instead of it being tied to a particular service.

AlexCoventry 10y ago
A better comparison is probably Amazon's Elastic Beanstalk / Docker integration. http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create...
- tbrock 10y ago
  No, elastic beanstalk is terrible.
  - MBCook 10y ago
    Works great for us so far. Care to elaborate?
    - yoanisgil 10y ago
      I've been using Elastic Beanstalk for some time now and while I find it quite useful for people who just want to get Docker to production without investing to much time into Orchestration, it looks to me like there is a bit of price to pay for that 'simplicity': - Elastic Beanstalk does not provide a native Docker experience. You're forced to use AWS own way of defining services and dependencies (Dockerrurn.aws.json, which comes in two versions). This means you cannot longer use docker-compose, and not all of the options from `docker run` are available (logging driver, privileged containers, though I think the ability to run privileged containers was recently added). - From my personal experience deployment times can be unacceptable long ranging from 5 - 20 mins. They get longer as you add more instances to the environment or if the instances are not powerful enough. I think Elastic Beanstalk makes a good choice for starters or for not so mission-critical applications. As a result of the points explained above I'm now looking into more Docker-centric solutions such Rancher/Kubernete or Docker's UCP.

parent5446 10y ago

What happened to the good ol' Unix philosophy? The docker command used to be about containers, not service and network scaling in the cloud.

clvx 10y ago
It doesn't apply to startup/companies.
Artemis2 10y ago
rkt does this: https://coreos.com/blog/rocket https://coreos.com/blog/rocket
geofft 10y ago
You can either have a bunch of different tools that do their own little thing and do them well and need a bunch of perl scripts and sysadmins on call to actually do anything useful, or you can have one large tool that does one meaningful thing and, by virtue of being one tool, does it well. The UNIX philosophy is fine, it's just slowly escaping from the people who misunderstood it. (Oddly enough UNIX kernels have always been fine, partly because of the bikeshed principle, and partly because experimentally, doing a bunch of tiny things well doesn't actually get you a working OS.)
- parent5446 10y ago
  That I can agree with, but I still feel like there is a reasonable line to be drawn between application containerization and coordination and load-balancing of networked services.
  - IanCal 10y ago
    Does it automatically do all of that? The launching/coordination/etc seem to be more the job of machine, compose and swarm (?). edit - Ah, I think I've just seen the other docker announcement this might be about.
shykes 10y ago

zymhan 10y ago

Am I the only one getting SSL errors trying to connect to their blog?

KenCochrane 10y ago
It happened to me for a brief second, and it is fixed now, are you still seeing an issue?

julienchastang 10y ago

Slightly off topic. What are people doing about user data persistence on the cloud/Docker? Specifically, we are porting a desktop application to the cloud via application streaming technology with Docker, but we would like the user’s data and preferences to not go "poof" when the cloud instance disappears. Ideally, we would like some automagic way to attach, say, the user's dropbox account or the equivalent to the cloud instance. Is anyone working on that problem?

pat2man 10y ago
Kubernetes has persistent volumes: http://kubernetes.io/docs/user-guide/persistent-volumes/ http://kubernetes.io/docs/user-guide/persistent-volumes/ You can use something like Glusterfs and distribute your files or it can hook in to your clod provider and create persistent storage automatically on something like EBS.
- ShakataGaNai 10y ago
  When I tried it way back when, he trouble I had with Gluster is that it didn't readily handle nodes randomly leaving and new ones joining. It was more hardware-centric in that if a node left, you were expected to bring that specific node back online. Is that still the case?
dominotw 10y ago
NFS volumes. There are many storage solutions out there for containers.
- e12e 10y ago
  I think this is where the idea of co-locating compute and storage really shines (eg: Joyent/Manta, scaleableinformatics.com) - moving all state to nfs sounds like a great way to widen the performance gap between RAM and permanent storage... Not to mention that if you really want to spread your data and your application, you would require nfs over vpn (unless encrypted nfsv4 actually works now?).

dang 10y ago

We merged the threads on these announcements. The Mac beta is at https://www.docker.com/products/docker#/mac https://www.docker.com/products/docker#/mac and the Windows one at https://www.docker.com/products/docker#/windows https://www.docker.com/products/docker#/windows.

pgz 10y ago

I don't understand why Docker for Mac is a GUI application. I'd rather get the same features from the CLI.

KenCochrane 10y ago
You can still use the CLI, there is nothing stopping you.
- pgz 10y ago
  So I assume the new native hypervisor is available from cli as well? Then that's excellent!
  - ryanschneider 10y ago
    Yea, the GUI is just there to manage updates and to let you know it's up and running, you use the actual docker CLI commands for everything just like on Linux. The hypervisor is completely abstracted away. For example, here's the output of me running `docker info`: Kernel Version: 4.4.13-moby Operating System: Alpine Linux v3.4 OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 1.954 GiB
  - KenCochrane 10y ago
    Yup, try it out, and let us know if you have any issues, or ideas on how to make it better.
    - DanielDent 10y ago
      Can it fall back to Virtualbox/vmware/parallels/etc if Hypervisor.framework isn't available? Hypervisor.framework doesn't run on somewhat dated x86 machines.
      - moondev 10y ago
        Not that i'm aware of, but using the hypervisor is pretty much the entire point. If you need to use vbox etc then just use docker-machine

tacos 10y ago

They never emailed me from the last "private beta" before announcing this. And now deploying this on AWS or Azure requires me to sign up for yet another "we'll get back to you..." private beta. Love the tech, hate all this marketing runaround. EDIT to add: either your beta is ready or it ain't. I understand a gentle initial seed to verify it's not an utter catastrophe but no need to play nanny with my bits across 20+ beta releases. I'm a grown up. Make a disclaimer and let me assess the risk. Your corporate logo looks like a 1970s Carvel ice cream cake--I know what I'm getting myself into.

KenCochrane 10y ago
Check your spam folder, some of the email from the last private beta went in people's spam folder, so they never saw them. Either way it doesn't matter anymore since Docker for Mac and Windows is now public to use without the need of a code.
- tacos 10y ago
  I'm not sure there's much overlap is between people who can get Docker Machine limping on VirtualBox with storage and networking flowing properly on Windows 10 fast ring and those who don't know how to check their spam folders, but I appreciate the tip. No messages (and I applied via two accounts for two different platforms). No message telling me "go get the bits!" today. And nothing in spam folders. But yet another blog post asking me to sign up for yet another private beta... ugh. EDIT to add: As polite feedback--two separate requests, two separate Docker accounts, one Gmail and one corporate email address, and I did not receive any invite during the private beta nor notification today when it went public.
  - KenCochrane 10y ago
    You would be surprised how many people didn't see it in their spam folder. Hence the reason why I mentioned it. :) Not sure what you mean about no message telling me to go get the bits today. There was no email saying that docker for mac/windows was made public, it was announced during the keynote at DockerCon (this morning), and a blog post went out. Before we made it public, everyone who had signed up for the beta had an invite sent to them, and there was no one left in the queue.

Sanddancer 10y ago

They need to put a note on their page that docker for windows is not compatible with docker for windows containers. I've been playing around with docker for windows containers for a few days, then saw this and thought, "cool, an update." I installed, and discovered that while the client is compatible between the two, the daemons they run cannot see the containers created in the other daemon. MS and Docker need to sort this stuff out, because right now, windows containers are nicer for the few images that have been released, but docker for windows allows for the full docker ecosystem.

justincormack 10y ago
We will sort this out soon, sorry.

spilk 10y ago

Not a fan of the new Windows version as it requires you to enable Hyper-V, which stops any other virtualization (Virtualbox, VMware, etc.) from functioning. The only workaround I've found is rebooting to enable/disable it on demand.

syaz1 10y ago
What are you talking about? I had to enable Hyper-V to get Virtualbox or any other VM solution working. But yes you're right that you can't use them at the same time. The new native docker doesn't use third-party VM (boot2docker) and interfaces with the host hypervisor directly. So I had to stop all running virtualbox VMs to get docker to start.

GordonS 10y ago

And the Windows version is still Windows 10 only :/ Many large organisations are going to be tied to Windows 7 for a good while yet...

pjmlp 10y ago
Because it makes use of Windows containers introduced in Windows 10, instead of bring GNU/Linux with Virtual Box along. Same thing on Mac OS X, they have migrated to the hypervisor API.

FloNeu 10y ago

Now even docker wants me to upgrade to windows 10 ^^ Keep up the great work!

mwambua 10y ago

IBM's Bluemix has supported Docker Containers for a while now, but hasn't gotten much limelight... probably as a result of the size of their community and Bluemix's sketchy [but improving] stability. Does anyone have any experience using their container service? And would this be a big improvement?

patwolf 10y ago
I've been using the container service for a few months. I have encountered a case where my running containers completely disappeared and was told by support that this was because of a "migration". They claimed to have notified me beforehand on several occasions, but I have no evidence of this. Hopefully this was a one time occurrence and will lead to greater stability. One other general problem I've had is the time it takes to launch a container. I would expect containers to be an improvement over VMs in terms of how quickly you can launch, but that doesn't seem to be my experience so far. I would wait a while longer before I would consider their container services for production workloads.