As of Deis 0.8.0 it only runs on CoreOS, and I believe most other DIY PaaS systems are moving the same way.
IMO Docker + etcd is a far more sane configuration than endless Ruby Chef scripts, or worse, Amazon OpsWorks.
For what use case? Doesn't using Docker for everything take you into 'golden master image' dead-ends, as outlined by the Opscode guys in comments to a Docker blog post last year [1].
What Lamont and Joshua had to say in that thread resonated, but I haven't really looked into DevOps approaches with Docker.
I'm also not sure what you mean by 'endless Ruby Chef scripts'?
[1] http://blog.relateiq.com/why-docker-why-not-chef/#comment-43...
So yes, powering 20 thin clients running different apps from a single server is a perfect use case.
Deis is the best thing I've seen come out of Docker's DevOps gold rush.
On the subject of DigitalOcean images, there was a severe Docker bug[3] the last month or so that made Linux kernel 3.15 unusable. Linode let me easily select a 3.14 kernel to use for my host OS to get around the bug, but DigitalOcean doesn't have that level of granularity. So DigitalOcean either needs to provide more fine-tuned configuration of images or provide a CoreOS Stable image before I would think of using it for production Docker containers.
Finally, CoreOS is still an enormous pain[4] to install on Linode, so I hope this gives Linode a strong nudge to make it easier to install there.
[1]: https://coreos.com/releases/
[2]: https://coreos.com/docs/running-coreos/platforms/vagrant/
[1]: https://coreos.com/docs/cluster-management/setup/switching-c...
https://coreos.com/docs/running-coreos/cloud-providers/vultr...
Since droplets with private networking enabled are on the same private network as other customers' droplets, then if "$private_ipv4" is specified for "addr" and "peer-addr" in cloud-config, isn't it critical that etcd be secured with TLS and client cert authentication?
See: CoreOS – Etcd: Reading and Writing over HTTPS[2]
I realize that delving into that aspect of coreos/etcd configuration is beyond the scope of an introductory "how to" article, but I believe that some strong mention should be given to this concern.
I made a comment[3] to this effect on DigitalOcean's website.
[1] https://www.digitalocean.com/community/tutorials/how-to-set-...
[2] https://coreos.com/docs/distributed-configuration/etcd-secur...
[3] https://www.digitalocean.com/community/tutorials/how-to-set-...
However, what is the standard approach for securing Docker container to container communication across hosts. For example from an app server to a DB server.
Is IPSec setup within CoreOS network layer, or is the security provided by Docker? If so, what are the options?
It should be possible via cloud-config to change the runtime config of the docker service[1], in which case one could set "--icc=false"[2] to enforce stricter rules about inter-container communication on a particular docker host (e.g. a coreos droplet).
[1] https://coreos.com/docs/launching-containers/building/custom...
[2] https://docs.docker.com/articles/networking/#between-contain...
EDIT:
Okay, I see you were asking about regulating network comm between containers on separate docker hosts, i.e. coreos instances.
That's a good question! I still don't think CoreOS addresses that concern in any special way at the level of iptables and routing (but I could be wrong). What it does give you is the ability to control service affinity with respect to your fleet "units". That way, you can be certain that docker containers which need to be "linked" in order to communicate properly (e.g. you have set "--icc=false") will run on the same host.
Here's another question: If I have a droplet up and running already, anyone know how I might change it from Ubuntu to the new CoreOS image? I'd rather change it than create a new one to maintain the same public IP, or else I have to have my DNS records updated, which takes time, and is outside my direct control.
Can you not move IP's between Digitalocean droplets?
In short, CoreOS maintains two OS partitions, A and B. When an update is available, it is automatically downloaded to the B partition, and upon reboot the B partition becomes active, effectively rotating the partitions.
Digital Ocean is doing lots of advertising but their servers are not holding the traffic.
I had my website hosted with them and I was literally unable to connect on it via SSH due to the low quality of their link.
I was disappointed with DreamHost, moved to Digital Ocean, now I am testing Linode.
Also whilst you are testing Linode have a look into their behaviour the last few times they were hacked. They deliberately withheld information from their customers. Pretty despicable company if you ask me.
After we've had a chance to work through some of the bugs that customers will uncover that we've missed in our testing we'll move forward to updating the rest of our images for this new metadata service and launching it publicly for production consumption for all customers.
Thanks
This is exciting to me from a technological standpoint.
1. One of first large public projects written in Go (after docker) 2. One of the first large public projects using Raft. (consensus algorithm aimed to replace Paxos)
I am really looking forward to seeing how this project turns out. Personally, I wouldn't move any of my projects onto CoreOs for at least a few years.
Other than that, I always question how they plan to make money. Consulting model?
