Hacker News Reader

Comment by waffle_ss | Hacker News Reader

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/

View on HN

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

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

> 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.

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.

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...

Etcd isn't consisdered production grade?

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).

You could already do these things outside of dockerland via the host-integration stuff (ie, systemd to handle restarts/monitoring).

1.0 was/is about API stability, engine stability, full ecosystem with Docker Hub, and enterprise support.

Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.

FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc.

So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.

> it will get the same IP as well.

Not for me. Just tested it.

How did you test it?

Reply on news.ycombinator.com