
Announcing Docker Machine Beta - pyprism
https://blog.docker.com/2015/02/announcing-docker-machine-beta/
======
bfirsh
In you're interested, we also announced beta versions of Swarm and Compose
today:

[http://blog.docker.com/2015/02/scaling-docker-with-
swarm/](http://blog.docker.com/2015/02/scaling-docker-with-swarm/)

[http://blog.docker.com/2015/02/announcing-docker-
compose/](http://blog.docker.com/2015/02/announcing-docker-compose/)

And a sneak preview of how these tools can work together:

[http://blog.docker.com/2015/02/orchestrating-docker-with-
mac...](http://blog.docker.com/2015/02/orchestrating-docker-with-machine-
swarm-and-compose/)

~~~
jingletells
Might as well ask here. What does "beta" mean?

I haven't noticed too many crazy changes with these tools so I'm wondering
what this label means to you.

~~~
shykes
Basically it means 1) it's stable enough to be useful, 2) but not stable
enough that we feel comfortable telling you to rely on it in production, and
3) the UI and integration into the rest of the Docker platform are susceptible
to change.

------
rubiquity
It looks interesting but seems like a very Docker-centric Packer[0] in that it
has code to create ready to go with Docker images on various cloud providers
and virtual machines.

The real hurdle and problems you'll be solving with Docker are when you have
containers on separate hosts. Will Machine handle configuring firewalls, SSL,
SSH keys and all that jazz across hosts so containers can reach each other?
I've automated a lot of this myself but would love something that does it for
you (other than the existing discovery service tools that often introduce
problems of their own). From the post it seems like Machine will also handle
this but I wonder how and how well.

[0] - [https://packer.io/](https://packer.io/)

~~~
nchammas
> It looks interesting but seems like a very Docker-centric Packer

I think you mean a Docker-centric Vagrant, no? Packer is for building images,
Vagrant is for launching environments.

You can use Packer to build Docker images akin to `docker build`, except
Packer will let you use a variety of provisioners to build your Docker image
like Chef, Ansible, or just simple Bash scripts. It's `docker build` without
the Dockerfiles. [1]

Docker Machine seems geared towards launching a resource that is ready to run
Docker, whether it be a VM running locally or a remote instance in some cloud.
It's a single-purpose Vagrant, to really stretch the analogy. :)

Once you have a resource that runs Docker, I _think_ that's where Docker
Compose [2] steps in. Docker Compose is more like the full Vagrant in that it
spins up a full, functioning environment with running services and whatnot.

[1]
[https://www.packer.io/docs/builders/docker.html](https://www.packer.io/docs/builders/docker.html)
(See the last section, titled "Dockerfiles".)

[2] [http://docs.docker.com/compose/](http://docs.docker.com/compose/)

------
cmpb
This looks pretty interesting. Could someone give me a good use-case for this?
I suppose spinning up dev environment on a host other than localhost could be
useful? I could also see this being useful as an interface for multiple
docker-installed production environments.

Perhaps someone could give me a "for instance."

~~~
jingletells
Deploying across multiple clouds. This abstracts away virtually all of the
details.

All you have to worry about is that your containers run on Docker, and as long
as your provider is supported by Machine, nothing else matters, and your code
isn't polluted by anything provider-specific.

~~~
dkarapetyan
In theory. I still have to see a cross-cloud solution that just works.

~~~
contingencies
To expand on this comment, common issues may include...

(1) Availability (Something fails eventually), both in terms of monitoring
(Find out) and failover (How to resolve when this happens?)

(2) Security (Who had access to which key when? Are they still at the company?
Where's the audit trail? Third-party managed security credentials ... can you
say side-channel?)

(3) Legal jurisdiction (Are we allowed to put _x_ in _y_ location? Do we want
government _x_ using law _y_ to potentially perform action _z_?)

(4) Latency (Site _x_ on provider _y_ is experiencing a DDoS)

(5) Heterogeneous management (What happens if something auto-managed gets
manually-managed for awhile? Do things break?)

(6) Resource lead time and failure impact (What happens when the hardware you
just wanted to spin up from the endless cloud supply isn't available?)

(7) Actual performance characteristics (Usually every provider offers only a
specific selection of environments and offers weak to no SLAs/guarantees on
real world performance.)

... and so on. A lot of these are sort of cloud restatements of the RFC1925[1]
fundamental truths of networking. Also, this is all docker-specific, so it
hinges on people wanting to build their infrastructure on a self-described
insecure and immature platform and tie their whole management paradigm to it.

FWIW, I am still working on an OS and virtualization platform agnostic
alternative devops process management tool[2] and am trying to get my company
to agree to open source it. It can easily wrap docker, having far broader
scope, and was designed to be future-proofed... it is thus potentially useful
for embedded dev, the BSDs, real hardware, clusters, etc. It takes a very
different paradigm to docker, abstracting cloud providers, services and
platforms separately, and allowing the former to figure out how to connect and
manage the other two internally... with standardized interfaces for major
operations and notifications.

[1]
[http://tools.ietf.org/rfc/rfc1925.txt](http://tools.ietf.org/rfc/rfc1925.txt)

[2] _cims_ ... read on from
[http://stani.sh/walter/pfcts/](http://stani.sh/walter/pfcts/) via 'original
post'

~~~
peterwwillis
> I am still working on an OS and virtualization platform agnostic alternative
> devops process management tool

Me too! I call it "shell scripts". Been in production use since ~1970. Seems
to handle most of my needs. I just wish it was written in JavaScript.

~~~
dkarapetyan
Shell scripts are pretty nice and it's unfortunate that the new crop of
configuration management tools puts them on the sidelines instead of treating
them as first class citizens in the configuration pipeline.

Now the much harder problem of orchestration is still an unsolved problem and
I think that is what the author was referring to.

~~~
peterwwillis
IMHO you can't make an orchestration product that a devops person will like.
The only people i've met who appreciate pre-built, non-customized
orchestration tools are people who can't program.

For the devops crowd, I think fail-closed or fail-safe shell scripts work
really well for orchestration. Too many times i've seen a really complex chain
of operations make it much harder to debug and fix a problem because the tool
was trying to be smarter than it needed to be, or ignored failures. You get
faster development time, simplicity, portability, extensibility,
interoperability, etc for free. And really i'm sick of re-writing the same
tool only to later fix it with a shell script because tackling the tool would
be too complex or time-consuming.

~~~
contingencies
_fail-closed or fail-safe shell scripts_

I nearly choked. Perhaps in the 1980s when you could hire people with shell
minutiae memorized, this was a good strategy. These days, I would be wrapping
the executable for the job (purposefully in an unspecified language to
facilitate broader use and survivability of the design) in a layer that makes
its environment temporary and OS-level sandboxed (to stave off security
challenges), and completely explicit (to nip the clasically vast number of
undocumented dependencies in the bud). Ideally, versioning of such
environments and their builds would be supported. That's exactly _cims_.

------
ambrop7
Thank you but I like NixOS & nixops too much.

~~~
nextos
I do too. What do you think about Guix?

~~~
ambrop7
Huh, I've never bothered. NixOS & Nix do what I need, and are much more
developed.

------
mrinterweb
This looks like an interesting project. I'd have to spend some time with it to
determine if it would suit my deployment needs. I wrote a tool to help with
docker deployment
[https://github.com/mrinterweb/freighter](https://github.com/mrinterweb/freighter).

------
rasur
Am I missing something here? No KVM as a provider (or on the forthcoming
list).

~~~
ehazlett
There has been a request
([https://github.com/docker/machine/issues/504](https://github.com/docker/machine/issues/504))
but no PR yet.

~~~
rasur
Thanks, I had indeed missed that. Glad to hear it's not completely forgotten.

------
vegancap
I just started learning Docker the other day and was curious as to how I could
use it to deploy to Digital Ocean, then I saw this! Great timing :)

~~~
jaideepsingh
This helped me get started a little while ago
[http://chrisbarra.me/posts/docker-
orchestration.html](http://chrisbarra.me/posts/docker-orchestration.html)

------
mrkrwtsn
Does anyone know if this could this replace boot2docker on the Mac? I just
tried it and it seems to have similar functionality.

~~~
zenlikethat
Eventually docker-machine will deprecate boot2docker-cli (the piece which you
use to actually manage the VM). However, boot2docker-cli is (mostly) pretty
stable and a lot of people use it (including me), so we don't want to toss it
out overnight or without a good migration path for b2d users.

------
gtaylor
I didn't see a clear "Read the Documentation here" link on the article. That's
a bit disappointing.

Here's what I found with a quick search on Google:
[https://docs.docker.com/machine/](https://docs.docker.com/machine/)

------
wildpeaks
That sounds like a Docker-only competitor to Vagrant: it would be interesting
to have a direct features comparaison because Vagrant is already pretty handy,
even with Docker boxes.

