from Hacker News

DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

by dedene on 9/5/14, 11:38 AM with 58 comments

  • by waffle_ss on 9/5/14, 2:26 PM

    This image uses the CoreOS Alpha channel, which is not supposed to be used for production[1]. It "closely tracks current development work and is released frequently" so I would be using it with the knowledge that things might break. In other words, CoreOS on DigitalOcean should only be used for trying out CoreOS and not for running production apps (for now). But if I were going to do that, there is already a Vagrant setup[2] that is super easy to use. Hopefully DigitalOcean will provide a CoreOS Stable image soon.

    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/

    [3]: https://github.com/docker/docker/issues/6345

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

  • by michaelsbradley on 9/5/14, 6:03 PM

    The article How To Set Up a CoreOS Cluster on DigitalOcean[1] (written by a DigitalOcean employee) fails to mention what seems to me to be a serious security-related concern.

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

  • by beigeotter on 9/5/14, 12:38 PM

    You can find the DigitalOcean tutorials on using CoreOS here: https://www.digitalocean.com/community/tutorial_series/getti...

  • by STRML on 9/5/14, 12:21 PM

    This is actually really big news for anyone running or interested in running a Docker-based PaaS system such as Deis or Flynn. DigitalOcean's cheap instances are a great match for Docker containers.

    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.

  • by jmbro on 9/6/14, 6:50 AM

    Digital Ocean doesn't load the kernel from the current system image, but instead uses a prestored external kernel associated with the image. This means that upgrade to the kernel from within the droplet (e.g. distribution security updates) are ignored (See http://digitalocean.uservoice.com/forums/136585-digital-ocea...). There is a workaround using kexec (see https://www.alextomkins.com/2013/11/digitalocean-debian-kern...). Does any body know if a similar approach would work for CoreOS ,given their whole image update process, or whether the DigitalOcean/CoreOS team have already taken care of this some other way?

  • by rb2e on 9/5/14, 12:37 PM

    The post on DO's blog maybe be more informative: https://www.digitalocean.com/company/blog/coreos-now-availab...

  • by kapilvt on 9/5/14, 2:13 PM

    one nice unrelated thing that didn't make any of the blog posts, digital ocean now supports userdata when launching instances via console or the api! but it looks like they still need to update their other os images to install cloudinit.

  • by jimmyfalcon on 9/5/14, 9:30 PM

    I remember attending a talk given by the CEO a few months ago. The strong point of CoreOS is for hosting application servers because it is does auto restart / updates rather than hosting can-not-go-down systems such as Databases.

    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?

  • by polvi on 9/5/14, 12:32 PM

  • by cdnsteve on 9/5/14, 2:10 PM

    So this means DigitalOcean, when running CoreOS via Docker for your deployment, means you no longer need to worry about OS level updates? Is this now handled by DigitalOcean?

  • by ebarock on 9/5/14, 8:49 PM

    Marketing, marketing and marketing...

    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.

  • by avinassh on 9/5/14, 4:23 PM

  • by fishnchips on 9/5/14, 12:33 PM

    Hurray! I've been really waiting for that for the last few months. I remember there being a huge thread about it in the DO community.

  • by notastartup on 9/5/14, 9:32 PM

    What benefits do you get with CoreOS support? I don't understand from just reading the article maybe a real world example makes more sense.