Docker 1.2.0, with restart policies

https://blog.docker.com/2014/08/announcing-docker-1-2-0/

by julien421 • 12 years ago

187 72 12 years ago

blog.docker.com

waffle_ss3• 12 years ago

This is excellent news. The lack of a container restart policy was the main reason why I was spending a bunch of time learning CoreOS and fleet.

Trying to get CoreOS installed on VPS providers is a huge pain[0], and fleet and etcd are technically not labelled as production-ready (only CoreOS used as a base OS is)[1], so I'm really glad I can go back to vanilla Docker.

[0] http://serverfault.com/a/620513/85897

[1] https://coreos.com/blog/stable-release/

Alupis6• 12 years ago

I was wasting a bunch of time learning CoreOS

I'm pretty sure CoreOS and Docker are different solutions to different problems. So... one is not really inter-changeable with another, and thus you were not "wasting" your time.

So, perhaps you didn't understand the problem you were trying to solve? Docker is about application environment isolation/portability (not! virtualization! -- there is no security provided here), where CoreOS is about scaling and HA.

waffle_ss3• 12 years ago

You're right, "wasting" was really harsh - edited. I do think it's a valuable skill to have and I didn't waste my time, I just spent it.

However, right now I don't have a Mesos-type of cluster with a bunch of horizontally scalable services that would truly benefit from CoreOS, Consul, etc. I've got three basic services that are going to be pinned to specific boxes. I don't need an elastic scaling solution right now - I just need container restarting, and I'll handle provisioning and upgrades myself with Ansible. Basically I don't have cattle right now, I have kittens.

I had been looking for a way to manage my containers with the usual supervisors - supervisord, systemd, etc., but didn't see any resources on anyone else doing it. After I started adding systemd on the host to manage container restarts, and a playbook for managing Docker daemon upgrades, I started to feel like I was re-inventing CoreOS, so I gravitated towards it. CoreOS also has other benefits like being a minimal Docker host and providing the distributed configuration with etcd so it seemed like a good idea.

But to fit within that paradigm I had to start re-wiring my images to be horizontally scalable. Then I ran into the problem of how hard it was to just get CoreOS installed on Linode, and got frustrated.

I didn't mean to knock CoreOS or anything, I'm just saying this solved a use case problem I've been having. I'm sure if I spent more time with CoreOS I would have gotten everything working correctly, but at this point I'm just trying to run my multi-host Docker application in a stable way without doing the whole horizontally scalable cluster thing.

nl2• 12 years ago

there is no security provided here

Actually there is plenty of security[1]. It may not be "as secure" as a traditional virtualization platform, but that doesn't mean Docker/containers don't have plenty of capabilities (ha!) to offer in terms of security.

You need to understand what they offer, but the old "Docker isn't secure" thing is not more truthful than "Docker is a security solution". Security is a continuum, and Docker has some very interesting security uses.

I've already linked to [1], but I'd encourage all to read it.

[1] http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applica...

toomuchtodo• 12 years ago

Etcd isn't consisdered production grade?

omglol2• 12 years ago

Well, Docker just slapped a "1.0" sticker on and called itself "production ready" when it clearly wasn't (features like in this 1.2 release are kind of mandatory for any serious deployments).

lsllc• 12 years ago

Try Vultr, they support CoreOS (and FreeBSD!).

https://coreos.com/docs/running-coreos/cloud-providers/vultr...

shykes7• 12 years ago

Hi all, no World-changing features in this one, but we believe that over time, relentless incremental improvements can make a huge difference.

This week we are freezing all feature merges and focusing on refactoring, code cleanup and generally repaying as much technical debt as possible.

We are also considering a gradual slowdown of the release cadence (we currently cut a release every month), to give more time for QA. Even though we work hard to keep master releasable at all times and run every merge through the full test suite, in practice there can never be enough real-world testing before a release. An 8-week cycle (which is roughly what Linux does) would allow us to freeze the release 1-2 weeks in advance and do more aggressive QA.

nathankleyn• 12 years ago

You guys are doing a fantastic job, anything that can give you a bit more of a breather between releases and increase quality is something I'm certain the community will embrace.

omglol2• 12 years ago

This seems to be the real 1.0 release...

prudhvis• 12 years ago

Are you kidding?. Ability to modify /etc/hosts and specifying exact Capabilities is awesome. Thanks for the great work. I for one waited very long for this :)

simonebrunozzi• 12 years ago

Hi Solomon! I agree with prudhvis here - I think this is quite a nice add!

Keep up the good work!

darklajid• 12 years ago

Now that needs to be possible in docker build:

https://github.com/docker/docker/issues/1916

That said, yes this release looks interesting!

zaphar• 12 years ago

I literally needed writable /etc/resolv.conf just this morning. You couldn't have timed the release any better.

tlrobinson• 12 years ago

ravenkat: in case you see this, it looks like you've been hellbanned. Since your question was a reasonable one, I'll copy it here:

"Currently if we restart docker daemon, all the running containers also restart. Are there any plans to keep the running containers running even if we upgrade our docker daemon?"

shykes7• 12 years ago

Definitely a reasonable question.

The answer is yes, there are plans to do exactly that :)

hipsters_unite2• 12 years ago

I've spent literally the last week working out restart strategies for our critical containers, so it's fair to say this has something pretty world-changing as I might be able to ship next week now. Seriously, I was writing bash wrappers to listen for exit codes and all sorts to make my own pseudo exit hooks on the host, so this is just awesome.

Thanks guys!

jijojv• 12 years ago

Writable `/etc/hosts`, `/etc/resolv.conf` is huge - no more local dns hacks.

shykes7• 12 years ago

Yeah that one was super-high on the request list, there were 3 competing patches before we finally got it right.

knite3• 12 years ago

Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host?

Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.

charford• 12 years ago

Any update on when the OS X version will be available? I'm only seeing version 1.1.2 here:

https://github.com/boot2docker/osx-installer/releases

tachion• 12 years ago

And anything related to FreeBSD Jail support? :)

Alupis6• 12 years ago

Docker != Jails

(not in any way, shape, nor form). Please stop trying to make Docker into everything it's not.

justizin2• 12 years ago

Use the Vagrant env, boot2docker is a mess IMO.

namin• 12 years ago

I liked the Vagrant env but I don't see it mentioned as an option here: https://docs.docker.com/installation/#installation

Are there any up-to-date installation instructions for the Vagrant env?

knite3• 12 years ago

Why is boot2docker a mess? I find it unusable due to lack of file sharing from the host through to a container. Are there any other showstoppers?

shykes7• 12 years ago

The boot2docker devs are running their build right now. The QA for that part is harder to automate (mac, windows, virtualbox etc). I think starting with the next release we'll need to pull in b2d builds as a gateway to the main release process to avoid this problem.

troym2• 12 years ago

Maybe a bit off-topic.

I haven't found a satisfactory solution to having communicating containers across multiple hosts. There seems to be quite a few solutions in the making (libswarm, geard, etc). How are other people solving this (in production, beyond two or three hosts)?

Alupis6• 12 years ago

CoreOS seems to do what you are asking.

cpuguy8311• 12 years ago

https://github.com/cpuguy83/docker-grand-ambassador https://github.com/progrium/ambassadord

troym2• 12 years ago

Interesting, thanks! FWIW, ambassadord has consul integration and that's something I've wanted.

ivix• 12 years ago

I simply expose ports (or do --net=host) and communicate between hosts in the normal fashion. Unless you don't trust your host I don't see the problem with that.

frik• 12 years ago

How to deal with persistent storage (e.g. databases) in Docker 1.2?

is this info up-to-date? http://stackoverflow.com/questions/18496940/how-to-deal-with...

cpuguy8311• 12 years ago

Yes, no changes here.

alexandre_m• 12 years ago

Check Flocker https://github.com/ClusterHQ/flocker

hipsters_unite2• 12 years ago

Mountable volumes and data containers works for us in staging atm, you can easily spin up single task dockers to pull that out, tar it up and send to S3 as a backup regime as well.

antocv• 12 years ago

Oh this is juuuust great. /sarcasm.

So now docker is taking on the work of what systemd and other daemon-managers are supposed to solve? Looking forward to docker run --restart on-failure ubuntu /bin/bash exit -1

When you include a --restart "feature" you know for sure you have don goofed.

But anyway, the rest of the stuff looks like pure candy. Great job!

knickle• 12 years ago

1) Then don't use it in your scripts.

2) Restart policies are exposed in the API, so daemon managers can leverage this feature to hook in their own restart policies in a consistent, supported way.

sciurus• 12 years ago

There's definitely feature overlap, and there are still problems running docker via systemd as show by the existence of workarounds like https://github.com/ibuildthecloud/systemd-docker

abraham_s• 12 years ago

Any idea when AWS Elastic BeanStalk will start supporting this version?

IanCal2• 12 years ago

I'm not sure about how I feel about this (edit - restart policies). It's cool, but seems to ignore what the OTP part of erlang development learned. They've already gone to "X number of restarts = failure" but with no time involved. There's also no hierarchy, which is where you really start to get the benefits.

While great, I worry that this is a part-solution that will delay the implementation of a proper one.

michaelneale3• 12 years ago

You can happily use containers supervised by systemd in a hierarchy like any other process if you like.

cpuguy8311• 12 years ago

1) We do degrade restarts over time. 2) There is hierarchy (so it will start linked containers).

IanCal2• 12 years ago

Perhaps I'm being a bit harsh.

1) We do degrade restarts over time.

Is this adjustable? X restarts in Y seconds? I feel this is something that could be quite application specific.

2) There is hierarchy (so it will start linked containers).

So if A has a link to B, will A be restarted if B is restarted?

I'd be aiming to build hierarchies with restart strategies like these:

http://www.erlang.org/doc/design_principles/sup_princ.html

LunaSea• 12 years ago

Is it possible yet to build and "RUN" multiple sublayers inside the same Dockerfile ?

Docker 1.2.0, with restart policies

Related Stories