Live data from Hacker News

DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

techcrunch.com

31–40 of 63 posts

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#31
post #13
post #12

Earlier quoted context omitted.

Just curious - what do you see as its shortcomings?

its not about its shortcomings, its a database. your saying it replaces chef and opsworks. you're missing a few pieces to make that picture. ie. how do i update the load balancer as i add capacity to my web app, how do i setup a new db instance and open up the firewall rules to an app on a different host. etc. docker, and etcd are both nice pieces, but they don't make a complete picture. nor does fleet imo.

etcd is better compared to zookeeper (SOA orchestration, service discovery, etc) and etcd (after researching for the last two weeks for a production environment) is nowhere near as stable (ie non-beta/alpha) as zookeeper or Netflix's Eureka.

Configuration management (puppet, chef, salt, ansible) is a completely different beats than service discovery, health management, etc.

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#32

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

This was useful, as I couldn't figure out how to add the cloud-config files I use for my Vagrant-base CoreOS cluster. 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 dire…

CoreOS is not a drop-in replacement for Ubuntu; migrating to it requires re-deploying your services inside Docker containers. I would think you might want to run your service implementations in parallel and then cut over later.

Can you not move IP's between Digitalocean droplets?

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#33
post #4
post #2

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.

I still am very impressed with CoreOS but I find sad that they were forced to move away from their initially touted "only systemd+etcd". (No blame on them, that was expected as the Docker ecosystem is still young and very fast-moving; plenty of interleaved problems must be solved elegantly.) When you say that Docker+etcd is saner that other solutions, I wonder for how long this will remain the case as the field matur…

Would you be willing to share more about what's in CoreOS that you feel like shouldn't be?

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#34

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…

For those experimenting, you can also switch to the release channel[1] (or beta, if you prefer). CoreOS will not downgrade so you will be on the alpha version until this version is promoted to the channel you subscribe to. This way, when the changes do get promoted, you will be tracking the release channel without any additional changes.

[1]: https://coreos.com/docs/cluster-management/setup/switching-c...

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#36
post #13

Earlier quoted context omitted.

its not about its shortcomings, its a database. your saying it replaces chef and opsworks. you're missing a few pieces to make that picture. ie. how do i update the load balancer as i add capacity to my web app, how do i setup a new db instance and open up the firewall rules to an app on a different host. etc. docker, and etcd are both nice pieces, but they don't make a complete picture. nor does fleet imo.

+1 If you want to do orchestration of both the infra and the app, you need things like opsworks.

No, you don't. Kapilvt and you aren't up on the latest and greatest out there right now. Etcd solves many of the problems he mentions.

Why the hell would you update the load balancer, when the load balancer is already subscribed to the etcd node correspodning to the web front end units.

Hm.

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#37

Earlier quoted context omitted.

This was useful, as I couldn't figure out how to add the cloud-config files I use for my Vagrant-base CoreOS cluster. 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 dire…

Similarly, I created a new coreos droplet just to play around, neglected to add the cloud_config yaml configuration. I couldn't find a setting to add it to the droplet afterwards.

Semantically, cloud-config is really not something you can add after. cloud-config comes from Ubuntu, but the semantics are a virtual clone of the ones of AWS's cfn-init; the point of both is to inject your config during initial instance bring-up, when system config files are first being generated by the instance provisioner. You can't really run them again once you've already brought up the instance, since they'd just messily trample over their previously spewed configs without removing the previous ones first.

With cloud-config, you're basically expected to be using ephemeral (or nearly-so) instances, particularly within the context of an autoscaling group or equivalent. The lifecycle is supposed to go "[scale up], provision, configure, start services; [crash or scale down], terminate, repeat." CoreOS adds to this soft reboots for upgrades, but definitely still assumes cattle, not snowflake, instances.

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#38
post #13
post #12

Earlier quoted context omitted.

Just curious - what do you see as its shortcomings?

its not about its shortcomings, its a database. your saying it replaces chef and opsworks. you're missing a few pieces to make that picture. ie. how do i update the load balancer as i add capacity to my web app, how do i setup a new db instance and open up the firewall rules to an app on a different host. etc. docker, and etcd are both nice pieces, but they don't make a complete picture. nor does fleet imo.

One simple solution would be to add etcd configuration items as a CloudFormation/Heat custom resource type.

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#39
post #24

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…

Vultr have supported CoreOS for a while (and FreeBSD!) https://coreos.com/docs/running-coreos/cloud-providers/vultr...

And any other x86 OS that supports VirtIO :)

Re: DigitalOcean Partners with CoreOS for Large-Scale Cluster Deployments

#40
post #32

Earlier quoted context omitted.

This was useful, as I couldn't figure out how to add the cloud-config files I use for my Vagrant-base CoreOS cluster. 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 dire…

CoreOS is not a drop-in replacement for Ubuntu; migrating to it requires re-deploying your services inside Docker containers. I would think you might want to run your service implementations in parallel and then cut over later. Can you not move IP's between Digitalocean droplets?

It's impossible to move IP's between DO droplet, it's a big drawback I think. It prevent a lot of people to use DO over AWS EC2.
Post reply on HN