9 ms·

Docker 1.6: Engine and Orchestration Updates, Registry 2.0, and Windows Client

258 points by bfirsh 12y ago

tracker1 12y ago
Yay for a windows docker client... though, I'm already just SSHing to a server with docker on it. My workflow is pretty much a samba share to my account directory in an ubuntu server, and a couple SSH shells on said server... easy enough to edit/run that way. (though my VM image started crashing, I'm now just remoting to an actual hardware server).
omni 12y ago
So excited for Registry 2.0, the slowness of the current registry is a real pain point. Anyone who writes an article benchmarking the two against each other will receive my upvote.
- Sirupsen 12y ago
  We put our registries behind a caching Nginx, also has the nice side-effect of HA if you push to all of them.
  - deleted 12y ago
    [deleted]
  - toomuchtodo 12y ago
    Behind ELBs with S3 as the backend store is where its at :)
    - omni 12y ago
      That is actually how I'm deployed right now. Still pretty slow, and S3 has its own downsides (mostly you can get false 404s after you've pushed an image but before it's fully propagated).
      - toomuchtodo 12y ago
        > and S3 has its own downsides (mostly you can get false 404s after you've pushed an image but before it's fully propagated). Only happens in us-east-1 due to it having eventual consistency (whereas all other S3 regions have read-after-write consistency). Use another region and the false 404s will go away. http://shlomoswidler.com/2009/12/read-after-write-consistency-in-amazon.html http://shlomoswidler.com/2009/12/read-after-write-consistenc...
chatmasta 12y ago
Any possibility of a boot2docker equivalent for windows, i.e. run docker in minimal linux VM? Seems like this would open new possibility for distributing client side apps via docker containers. Cross platform apps with http frontend would be viable with easy tooling around VM and docker.
- WestCoastJustin 12y ago
  Looks like boot2docker does have a windows installer @ https://github.com/boot2docker/windows-installer/releases https://github.com/boot2docker/windows-installer/releases
- SideburnsOfDoom 12y ago
  You won't run windows docker images on a linux host. That's not how docker works. If you're looking for a minimal windows host for VMs and containers, that's "nanoserver" in the works: http://www.techradar.com/news/software/operating-systems/microsoft-s-stripped-down-nano-server-is-on-the-way-1290666 http://www.techradar.com/news/software/operating-systems/mic... http://www.infoworld.com/article/2909650/devops/microsoft-nano-server-and-the-future-of-devops.html http://www.infoworld.com/article/2909650/devops/microsoft-na...
  - chatmasta 12y ago
    Doesn't boot2docker run images on a linux host? It boots a minimal Ubuntu VM in virtualbox. How would that be different on windows?
    - ahmetmsft 12y ago
      Boot2Docker also comes with a docker client for Windows. In that case you don't have to run or install VirtualBox at all. You can just point it to your existing Docker host.
- lloeki 12y ago
  Using docker-machine as a superset of boot2docker is my favorite on OS X instead of the "plain old" boot2docker command (due to simple local machine management and VMware Fusion support), doesn't it run on Windows since it also has an Hyper-V driver? [0]: https://github.com/docker/machine/tree/master/drivers https://github.com/docker/machine/tree/master/drivers
mpdehaan2 12y ago
I'm finding that the distinction between Swarm, Compose, and Machine is not immediately obvious. Docker would probably benefit to "you should use this when", kind of logic, between the two. Clearly, Swarm is the lightweight "cloud" thing (yay!), but if I'm deploying to Swarm, do I use Machine or Compose? Etc. Possibly too many nouns would be made simpler by a single command line tool with subcommands, that were less skeomorphic, and instead were named after what they did. Just my two cents, but the documentation needs to explain a bit more of the basics at a high level before going into the weeds, IMHO. The other gotcha page is "if I'm on Amazon", when would I want to use swarm, if at all, when I had ECS, and how much remains relevant? I'm guessing not so much still applies, but perhaps I'm wrong. Another good article would be what parts of these new tools remain relevant if I'm using, say, CoreOS (fleet), Kubernetes, or Mesos, or OpenStack with Docker. I'm not saying the others are better, it's just difficult to visualize how they interplay.
- numo16 12y ago
  > if I'm deploying to Swarm, do I use Machine or Compose? All three actually seem to work quite nicely together[0] [0]: https://blog.docker.com/2015/02/orchestrating-docker-with-machine-swarm-and-compose/ https://blog.docker.com/2015/02/orchestrating-docker-with-ma...
  - mpdehaan2 12y ago
    Yeah, I read that back in the day, and I'm still finding it hard to follow. I'm trying to pass on some marketing advice here mostly. Leaving it to the reader to try to assemble a video down into their brains, because they have problems with the text wall (particularly visual learners) is probably not a good thing. I work best off examples and pictures. I'd benefit hugely by having a list of the CLI commands, without the text filler, showing a few use cases end to end. I have a hard time keeping all the video in my brain all at once. Just seeing the bash history alone, with some light text commentary, would work for me better than the video -- by a lot. I know different people learn differently. Show all three tools delivering a "pet store" type stack maybe. Tell me when do I want compose and when can I skip it, as quickly as possible. I know these are things you can figure out in several hours/days by trying them all, but for those of us that don't have time, it needs to be presented at a higher level showing how they connect, rather than the marketing speak "it works great together" and then pages that contradict that by saying the integration is minimal. The current result is everyone's Docker topology is VERY different. I know it's not proscriptive, but it's a bit of a mess. I've encountered a lot of people doing lightweight cloud with Docker (basically no-cloud) with Ansible and manual instance management, for instance, and there SHOULD be better options - but I think people go that route because they are confused about the complexity of options they have. Back down to technical bits, I see the line "we're working with AWS to make Swarm usable on ECS", etc, as confusing and a bit marketey (as to the reason for the integration). Why do I need Swarm on ECS? Make the case, etc, these already appear to be container orchestrators. What does Swarm add on top of these other systems? Is Compose trying to be vApp or not? (vApp itself not widely deployed). So a matrix of what ECS can do versus Swarm, etc, would also help. Ultimately, from an outside perspective, it looks like other parties are doing more Docker management a lot better than Docker, and these are moves to catch up, but it's unclear where they fit, and whether they are needed in those contexts. Note: I wrote Ansible, if it's not clear to me, it's a problem -- and this is a common perception around a lot of folks I talk to :) Consider presenting things for different learning styles if you can, especially as the technology doesn't really fit into traditional management patterns - I'm genuinely interested, and probably not the only one having this problem. Again, genuinely interested in wanting to keep up.
XorNot 12y ago
So I'm not sure I like Docker so much anymore. In most ways the systemd-nspawn system seems a lot easier to use practically and to move into normal host deployment. The docker model shines when it comes to image setup, but the runtime and management aspects leave a lot to be desired.
- eropple 12y ago
  So I work in this space and, I'll be honest: I'd never seen systemd-nspawn before. I'm interested. Thanks for the heads up.
beagile 12y ago
Everybody who is interested in test-driving Docker 1.6 in a really easy and fast way and has a Raspberry Pi lying around should have a look at our prepared Docker SD card image. Get it here: http://blog.hypriot.com/post/docker-1-6-is-finally-released-into-the-wild http://blog.hypriot.com/post/docker-1-6-is-finally-released-...
- jimmcslim 12y ago
  Not sure if images on the registry also support the new labels functionality, but that might be a way to avoid to obvious image architecture (x86 vs ARM) issues.
bsrx 12y ago
The logging drivers reduce a major production pain point - standardized centralized logging that doesn't require modifying the underlying image. Docker has a bad security reputation; this is one more step in the right direction.
- ploxiln 12y ago
  It's crazy that (until now) docker always logged stdout/stderr to a file, and never rolled it. Without a separately configured logrotate (in copy-truncate mode), these log files will grow without bound, until the container is removed (usually replaced).
  - bsrx 12y ago
    It may be critically important, but they can't do everything at once. They're moving incredibly fast as it is. Other people were attempting to solve this problem too - https://registry.hub.docker.com/u/kiyoto/docker-fluentd/ https://registry.hub.docker.com/u/kiyoto/docker-fluentd/
  - amouat 12y ago
    Reminds me of the day I foolishly did "docker run -d debian yes" so I could play with some of the inspection commands. I forgot about it and an hour later it had eaten nearly all of my hard disk space...
- gyre007 12y ago
  "Docker has a bad security reputation" Ecept for ulimit, there is literally NO security improvement in this release. Logging merely gives you a visibility - right, you get hacked but at least it's not painful to look for information, but I would really rather prefer not to get hacked due to the existing insecurities...
  - bsrx 12y ago
    SecOps mission is: prevent, detect, respond. Yes, outright prevention is important. Yet proper centralized log collection and intelligence helps with all three missions, including prevention. Proper logging allows you to identify known-good behavior patterns and outlying anomalies. With profiles in place, one can automate blocking of reconnaissance and probes, not just blocking known vulnerabilities.
ftcHn 12y ago
Does anyone know if/when AWS will support docker on Windows?
- flurdy 12y ago
  I am sure there may be one but I don't quite see any reason for running Docker inside a Windows VM in AWS? Run Docker with ECS or with Machine with EC2, or any native linux VMs. Adding another abstraction layer seems pointless. Unless it is for Azure.
languagehacker 12y ago
I've got a bone to pick with the new Docker Compose. Take a look at this issue: https://github.com/docker/compose/issues/495 https://github.com/docker/compose/issues/495 Back in January I went through the effort of outlining a solution that was approved by the maintainers before implementing it. After I provided a PR, I responded to revision requests by the maintainers, and still haven't seen this change go into the project. It's a simple change. If this feature isn't the architectural direction Docker wants, they need to close the issue and reject the pull request, instead of changing the project over and over again so that I have to maintain a PR that's over three months old. Very uncool.
- msane 12y ago
  The fact that it's still open probably means it is under some level of serious consideration. It was opened before they released Machine (and Swarm?) so maybe they just didn't know how/when it should fit in until the dust settles. Agree that they could have said something to this effect though.
languagehacker 12y ago
Oh cool, another change to fig/docker-compose that doesn't include the most requested feature: https://github.com/docker/compose/issues/495 https://github.com/docker/compose/issues/495 As the person who wrote the PR for its solution and have been waiting for it to get merged for months, this is super, super frustrating. If you guys don't want to put the logic in, reject the PR and close the issue as won't fix. Quit stringing the community along.
- omni 12y ago
  Did you really need to grind your axe in two separate comments on the same story? The first was sufficient.
  - languagehacker 12y ago
    Whoops, sent it when HN went down and didn't think it had posted.
ekidd 12y ago
I've been several docker components heavily, on a real system. This was the state of play just prior to the Docker 1.6 announcement: - Docker registry, the old pre-2.0 version: I hate it. It's incredibly slow, and it raises lots of errors. - Docker 1.5: Mostly stable and usable if you're on the right kernel, occasionally does something weird. - docker-machine (from git): Very nice for provisioning basic docker hosts locally or on AWS. Nice feature: it's capable of automatically regenerating TLS certificates when Elastic IP addresses get remapped. - docker-compose 1.1.0: Kind of a toy, but a fun toy, and it generally did what it advertised. - docker swarm: With docker-compose 1.1.0 and docker 1.5, it was pretty much unusable. Simply running "docker-compose up -d" twice in a row was enough to make it fail with random errors. I'm going to re-evaluate swarm with docker 1.6 and the new docker-compose.
jfoutz 12y ago
I still don't understand multiple host networking. I'm not sure if i'm missing something super obvious, or if it's just complicated. I like the openvswitch approach, but it's a pretty traditional approach, and won't really work on aws/gce. Weave seems super neat, but i still want the option to run on aws/gce, and weave (afaict) precludes that. Ambassador containers i guess? I dunno. There's just no easy answer.
- bboreham 12y ago
  Weave Network works great on AWS, GCE, Azure, your laptop, ... Pretty much anywhere you can run a (privileged) container, you can run Weave. Here's some use-cases for each (and in one case both!): http://weaveblog.com/tag/gce/ http://weaveblog.com/tag/gce/ http://weaveblog.com/tag/aws/ http://weaveblog.com/tag/aws/ Did you mean to write something else? I would love to know where you got that idea. Note: I work for Weaveworks. > Weave seems super neat Thanks!
  - jfoutz 12y ago
    Wow. that looks really great. I'll check it out this weekend. > Thanks! no, thank you!
- pas 12y ago
  SocketPlane ? https://github.com/socketplane/socketplane/blob/master/demo/multicloud/README.md https://github.com/socketplane/socketplane/blob/master/demo/...
mjhea0 12y ago
See Docker 1.6, Compose 1.2, and Machine 0.2 in action at https://realpython.com/blog/python/dockerizing-flask-with-compose-and-machine-from-localhost-to-the-cloud/ https://realpython.com/blog/python/dockerizing-flask-with-co... Cheers!

258 points by bfirsh 12y ago

Yay for a windows docker client... though, I'm already just SSHing to a server with docker on it. My workflow is pretty much a samba share to my account directory in an ubuntu server, and a couple SSH shells on said server... easy enough to edit/run that way. (though my VM image started crashing, I'm now just remoting to an actual hardware server).

omni 12y ago

So excited for Registry 2.0, the slowness of the current registry is a real pain point. Anyone who writes an article benchmarking the two against each other will receive my upvote.

Sirupsen 12y ago
We put our registries behind a caching Nginx, also has the nice side-effect of HA if you push to all of them.
- deleted 12y ago
  [deleted]
- toomuchtodo 12y ago
  Behind ELBs with S3 as the backend store is where its at :)
  - omni 12y ago
    That is actually how I'm deployed right now. Still pretty slow, and S3 has its own downsides (mostly you can get false 404s after you've pushed an image but before it's fully propagated).
    - toomuchtodo 12y ago
      > and S3 has its own downsides (mostly you can get false 404s after you've pushed an image but before it's fully propagated). Only happens in us-east-1 due to it having eventual consistency (whereas all other S3 regions have read-after-write consistency). Use another region and the false 404s will go away. http://shlomoswidler.com/2009/12/read-after-write-consistency-in-amazon.html http://shlomoswidler.com/2009/12/read-after-write-consistenc...

chatmasta 12y ago

Any possibility of a boot2docker equivalent for windows, i.e. run docker in minimal linux VM? Seems like this would open new possibility for distributing client side apps via docker containers. Cross platform apps with http frontend would be viable with easy tooling around VM and docker.

WestCoastJustin 12y ago
Looks like boot2docker does have a windows installer @ https://github.com/boot2docker/windows-installer/releases https://github.com/boot2docker/windows-installer/releases
SideburnsOfDoom 12y ago
You won't run windows docker images on a linux host. That's not how docker works. If you're looking for a minimal windows host for VMs and containers, that's "nanoserver" in the works: http://www.techradar.com/news/software/operating-systems/microsoft-s-stripped-down-nano-server-is-on-the-way-1290666 http://www.techradar.com/news/software/operating-systems/mic... http://www.infoworld.com/article/2909650/devops/microsoft-nano-server-and-the-future-of-devops.html http://www.infoworld.com/article/2909650/devops/microsoft-na...
- chatmasta 12y ago
  Doesn't boot2docker run images on a linux host? It boots a minimal Ubuntu VM in virtualbox. How would that be different on windows?
  - ahmetmsft 12y ago
    Boot2Docker also comes with a docker client for Windows. In that case you don't have to run or install VirtualBox at all. You can just point it to your existing Docker host.
lloeki 12y ago
Using docker-machine as a superset of boot2docker is my favorite on OS X instead of the "plain old" boot2docker command (due to simple local machine management and VMware Fusion support), doesn't it run on Windows since it also has an Hyper-V driver? [0]: https://github.com/docker/machine/tree/master/drivers https://github.com/docker/machine/tree/master/drivers

mpdehaan2 12y ago

I'm finding that the distinction between Swarm, Compose, and Machine is not immediately obvious. Docker would probably benefit to "you should use this when", kind of logic, between the two. Clearly, Swarm is the lightweight "cloud" thing (yay!), but if I'm deploying to Swarm, do I use Machine or Compose? Etc. Possibly too many nouns would be made simpler by a single command line tool with subcommands, that were less skeomorphic, and instead were named after what they did. Just my two cents, but the documentation needs to explain a bit more of the basics at a high level before going into the weeds, IMHO. The other gotcha page is "if I'm on Amazon", when would I want to use swarm, if at all, when I had ECS, and how much remains relevant? I'm guessing not so much still applies, but perhaps I'm wrong. Another good article would be what parts of these new tools remain relevant if I'm using, say, CoreOS (fleet), Kubernetes, or Mesos, or OpenStack with Docker. I'm not saying the others are better, it's just difficult to visualize how they interplay.

numo16 12y ago
> if I'm deploying to Swarm, do I use Machine or Compose? All three actually seem to work quite nicely together[0] [0]: https://blog.docker.com/2015/02/orchestrating-docker-with-machine-swarm-and-compose/ https://blog.docker.com/2015/02/orchestrating-docker-with-ma...
- mpdehaan2 12y ago
  Yeah, I read that back in the day, and I'm still finding it hard to follow. I'm trying to pass on some marketing advice here mostly. Leaving it to the reader to try to assemble a video down into their brains, because they have problems with the text wall (particularly visual learners) is probably not a good thing. I work best off examples and pictures. I'd benefit hugely by having a list of the CLI commands, without the text filler, showing a few use cases end to end. I have a hard time keeping all the video in my brain all at once. Just seeing the bash history alone, with some light text commentary, would work for me better than the video -- by a lot. I know different people learn differently. Show all three tools delivering a "pet store" type stack maybe. Tell me when do I want compose and when can I skip it, as quickly as possible. I know these are things you can figure out in several hours/days by trying them all, but for those of us that don't have time, it needs to be presented at a higher level showing how they connect, rather than the marketing speak "it works great together" and then pages that contradict that by saying the integration is minimal. The current result is everyone's Docker topology is VERY different. I know it's not proscriptive, but it's a bit of a mess. I've encountered a lot of people doing lightweight cloud with Docker (basically no-cloud) with Ansible and manual instance management, for instance, and there SHOULD be better options - but I think people go that route because they are confused about the complexity of options they have. Back down to technical bits, I see the line "we're working with AWS to make Swarm usable on ECS", etc, as confusing and a bit marketey (as to the reason for the integration). Why do I need Swarm on ECS? Make the case, etc, these already appear to be container orchestrators. What does Swarm add on top of these other systems? Is Compose trying to be vApp or not? (vApp itself not widely deployed). So a matrix of what ECS can do versus Swarm, etc, would also help. Ultimately, from an outside perspective, it looks like other parties are doing more Docker management a lot better than Docker, and these are moves to catch up, but it's unclear where they fit, and whether they are needed in those contexts. Note: I wrote Ansible, if it's not clear to me, it's a problem -- and this is a common perception around a lot of folks I talk to :) Consider presenting things for different learning styles if you can, especially as the technology doesn't really fit into traditional management patterns - I'm genuinely interested, and probably not the only one having this problem. Again, genuinely interested in wanting to keep up.

XorNot 12y ago

So I'm not sure I like Docker so much anymore. In most ways the systemd-nspawn system seems a lot easier to use practically and to move into normal host deployment. The docker model shines when it comes to image setup, but the runtime and management aspects leave a lot to be desired.

eropple 12y ago
So I work in this space and, I'll be honest: I'd never seen systemd-nspawn before. I'm interested. Thanks for the heads up.

beagile 12y ago

Everybody who is interested in test-driving Docker 1.6 in a really easy and fast way and has a Raspberry Pi lying around should have a look at our prepared Docker SD card image. Get it here: http://blog.hypriot.com/post/docker-1-6-is-finally-released-into-the-wild http://blog.hypriot.com/post/docker-1-6-is-finally-released-...

jimmcslim 12y ago
Not sure if images on the registry also support the new labels functionality, but that might be a way to avoid to obvious image architecture (x86 vs ARM) issues.

bsrx 12y ago

The logging drivers reduce a major production pain point - standardized centralized logging that doesn't require modifying the underlying image. Docker has a bad security reputation; this is one more step in the right direction.

ploxiln 12y ago
It's crazy that (until now) docker always logged stdout/stderr to a file, and never rolled it. Without a separately configured logrotate (in copy-truncate mode), these log files will grow without bound, until the container is removed (usually replaced).
- bsrx 12y ago
  It may be critically important, but they can't do everything at once. They're moving incredibly fast as it is. Other people were attempting to solve this problem too - https://registry.hub.docker.com/u/kiyoto/docker-fluentd/ https://registry.hub.docker.com/u/kiyoto/docker-fluentd/
- amouat 12y ago
  Reminds me of the day I foolishly did "docker run -d debian yes" so I could play with some of the inspection commands. I forgot about it and an hour later it had eaten nearly all of my hard disk space...
gyre007 12y ago
"Docker has a bad security reputation" Ecept for ulimit, there is literally NO security improvement in this release. Logging merely gives you a visibility - right, you get hacked but at least it's not painful to look for information, but I would really rather prefer not to get hacked due to the existing insecurities...
- bsrx 12y ago
  SecOps mission is: prevent, detect, respond. Yes, outright prevention is important. Yet proper centralized log collection and intelligence helps with all three missions, including prevention. Proper logging allows you to identify known-good behavior patterns and outlying anomalies. With profiles in place, one can automate blocking of reconnaissance and probes, not just blocking known vulnerabilities.

ftcHn 12y ago

Does anyone know if/when AWS will support docker on Windows?

flurdy 12y ago
I am sure there may be one but I don't quite see any reason for running Docker inside a Windows VM in AWS? Run Docker with ECS or with Machine with EC2, or any native linux VMs. Adding another abstraction layer seems pointless. Unless it is for Azure.

languagehacker 12y ago

I've got a bone to pick with the new Docker Compose. Take a look at this issue: https://github.com/docker/compose/issues/495 https://github.com/docker/compose/issues/495 Back in January I went through the effort of outlining a solution that was approved by the maintainers before implementing it. After I provided a PR, I responded to revision requests by the maintainers, and still haven't seen this change go into the project. It's a simple change. If this feature isn't the architectural direction Docker wants, they need to close the issue and reject the pull request, instead of changing the project over and over again so that I have to maintain a PR that's over three months old. Very uncool.

msane 12y ago
The fact that it's still open probably means it is under some level of serious consideration. It was opened before they released Machine (and Swarm?) so maybe they just didn't know how/when it should fit in until the dust settles. Agree that they could have said something to this effect though.

languagehacker 12y ago

Oh cool, another change to fig/docker-compose that doesn't include the most requested feature: https://github.com/docker/compose/issues/495 https://github.com/docker/compose/issues/495 As the person who wrote the PR for its solution and have been waiting for it to get merged for months, this is super, super frustrating. If you guys don't want to put the logic in, reject the PR and close the issue as won't fix. Quit stringing the community along.

omni 12y ago
Did you really need to grind your axe in two separate comments on the same story? The first was sufficient.
- languagehacker 12y ago
  Whoops, sent it when HN went down and didn't think it had posted.

ekidd 12y ago

I've been several docker components heavily, on a real system. This was the state of play just prior to the Docker 1.6 announcement: - Docker registry, the old pre-2.0 version: I hate it. It's incredibly slow, and it raises lots of errors. - Docker 1.5: Mostly stable and usable if you're on the right kernel, occasionally does something weird. - docker-machine (from git): Very nice for provisioning basic docker hosts locally or on AWS. Nice feature: it's capable of automatically regenerating TLS certificates when Elastic IP addresses get remapped. - docker-compose 1.1.0: Kind of a toy, but a fun toy, and it generally did what it advertised. - docker swarm: With docker-compose 1.1.0 and docker 1.5, it was pretty much unusable. Simply running "docker-compose up -d" twice in a row was enough to make it fail with random errors. I'm going to re-evaluate swarm with docker 1.6 and the new docker-compose.

jfoutz 12y ago

I still don't understand multiple host networking. I'm not sure if i'm missing something super obvious, or if it's just complicated. I like the openvswitch approach, but it's a pretty traditional approach, and won't really work on aws/gce. Weave seems super neat, but i still want the option to run on aws/gce, and weave (afaict) precludes that. Ambassador containers i guess? I dunno. There's just no easy answer.

bboreham 12y ago
Weave Network works great on AWS, GCE, Azure, your laptop, ... Pretty much anywhere you can run a (privileged) container, you can run Weave. Here's some use-cases for each (and in one case both!): http://weaveblog.com/tag/gce/ http://weaveblog.com/tag/gce/ http://weaveblog.com/tag/aws/ http://weaveblog.com/tag/aws/ Did you mean to write something else? I would love to know where you got that idea. Note: I work for Weaveworks. > Weave seems super neat Thanks!
- jfoutz 12y ago
  Wow. that looks really great. I'll check it out this weekend. > Thanks! no, thank you!
pas 12y ago
SocketPlane ? https://github.com/socketplane/socketplane/blob/master/demo/multicloud/README.md https://github.com/socketplane/socketplane/blob/master/demo/...

mjhea0 12y ago

See Docker 1.6, Compose 1.2, and Machine 0.2 in action at https://realpython.com/blog/python/dockerizing-flask-with-compose-and-machine-from-localhost-to-the-cloud/ https://realpython.com/blog/python/dockerizing-flask-with-co... Cheers!