Live data from Hacker News

I Want to Run Stateful Containers, Too

techcrunch.com

81–90 of 102 posts

Re: I Want to Run Stateful Containers, Too

#81

What exactly does containerizing everything give you anyways? I really don't get it. Before - use chef/puppet to manage dependencies, distribute config files. run processes. maybe use something like upstart to restart on failure. After - use Dockerfiles to manage dependencies (same thing, bunch of install commands). now you have a container for the web app, one for another service, etc. so everything is isolated.. gr…

I see an instance as sort of a compiled binary of your app and the environment it runs in. You can install your app, all its dependencies, get all the config files correct, run tests on the created instance, and then you have a Docker instance and can start up any number of them in production. If any of those steps fails in the middle of some script, you haven't put any server in some half way there state. If a rollb…

Disclaimer: I work at Google on Kubernetes

I'd love to hear more - anything in particular that doesn't feel like a fit?

Re: I Want to Run Stateful Containers, Too

#82

The author is correct. We should be running stateful containers, but until the the software is ready the default advice quite rightly should be not to unless you understand the implications. For example we run ceph and use it in kubernetes. We obviously only run replica sets (the kubernetes feature, for those uninitiated) of 1 for these services. There's also some rough edges with locking for dead nodes, but it's def…

Disclaimer: I work at Google on Kubernetes

Yep - and the ability to run just one per node is coming "soon" (ideally by next milestone). It's something we wanted to get in, but just didn't have the time by 1.1.

My #1 recommendation is to do whatever you do today. If you mount an NFS mount into your VM to store your MySQL data, that's what you should do again. The speed at restarting a pod is very low - but you do need to do the (small) hack today if you want to be absolutely sure you don't have multiple pods with on the same node.

To be clear, the ugly-ness is one line in your config file:

nodePort: 1024 &

Re: I Want to Run Stateful Containers, Too

#83
post #39

I believe part of what the author is looking for is currently being pushed by the Deis guys with Helm[1]. Think of it as a package manager for creating Kubernetes configurations. I think we'll see some stable and reusable templates for both stateful and stateless services there. [1] https://helm.sh/

Disclaimer: I work at Google on Kubernetes

We _LOVE_ what Helm is doing, and are actively helping. Please dive in! :)

Re: I Want to Run Stateful Containers, Too

#84

The complexity of this setup screams 1 major thing to me: security issues Seeing as we are on this topic, I would like to pose 1 simple and theoretical question for all those who only need 1 decently-sized 4GB server to get their small projects running: ===== What type of setup can be used to get a simple Rails/Sinatra/Flask/Django webapp + Postgres-DB on a single 4GB server that has to be maintained by a single indi…

Disclaimer: I work at Google on Kubernetes.

I put that disclaimer at the top of all my posts, but this one truly is HIGHLY biased.

The absolute easiest way to do what you describe is to use GKE (Google's hosted Kubernetes). For $0.15/hr, we'll manage everything for you, and you can build out teeny tiny clusters that do everything you need. It's even free for clusters https://github.com/kubernetes/kubernetes/tree/master/example...) and you're done.

Re: I Want to Run Stateful Containers, Too

#85

Earlier quoted context omitted.

I'm curious Would you be ok with being locked in with X provider's storage specific solution? (say a ECS only way of doing things) Is the headache in the setup, config, or risk of being at the helm of orchestrating your own data?

My experience is that you are going to be "locked in" in some way no matter what. Current infrastructure systems are a mess of vendor specific solutions and configurations. Migrating from one open source system to another is going to be just as hard as migrating from a proprietary thing like vanilla ECS to say kubernetes on bare metal. There are other concerns like vendor pricing and stuff, but I have not had bad luc…

Disclaimer: I work at Google on Kubernetes.

I should mention Kubernetes is 100% open source, runs on AWS, Google Cloud, Azure, Digital Ocean, Vagrant, bare metal, VMWare, Rackspace and lots more I'm probably forgetting. Then you can pick the cloud you like, and lock-in be gone.

Re: I Want to Run Stateful Containers, Too

#86
post #48

The author seems to be mixing some valid observations regarding the difficulty of stateful containers with some paranoia about the growth of cloud deployments and ownership of data. Or maybe it's not paranoia. I don't know. But it's different. First off, containers don't absolutely have to be stateless. The first and foremost benefit of containers is dependency isolation and configuration management. Once you use the…

Disclaimer: I work at Google on Kubernetes.

This is a really good point - I've said it before and I'll say it again - containers neither add to (nor subtract) from whatever you're doing today. If you have a single VM and no shared storage, you're exactly as vulnerable as if you were doing things in a container. And, in the majority of cases, the exact same techniques you'd use in a VM work in a container or Kubernetes too.

Re: I Want to Run Stateful Containers, Too

#87
post #60

Earlier quoted context omitted.

* Kubernetes is not written in Java * There is no one size fit all, just like never ending Ruby vs JavaScript VS Java. * Kubernetes just hit v1.0 not long ago. * Seem like you already wrote the functionality you want, now what is the problem?

* Alright, sorry Kubernetes is in Go I must've gotten it confused with some other project. * Well, alright, but they market it as a general purpose project. I'm just saying that to us it's strange that none of these frameworks out there deal with persistent storage, as the author of the article also observed. * Ok. * Well the problem is that it'd be much nicer if we could just use Kubernetes. Obviously having a homeg…

Disclaimer: I work at Google on Kubernetes.

We do care enormously about stateful solutions; I'll say what I've said elsewhere - how do you handle stateful services in your VMs?

Re: I Want to Run Stateful Containers, Too

#88

The complexity of this setup screams 1 major thing to me: security issues Seeing as we are on this topic, I would like to pose 1 simple and theoretical question for all those who only need 1 decently-sized 4GB server to get their small projects running: ===== What type of setup can be used to get a simple Rails/Sinatra/Flask/Django webapp + Postgres-DB on a single 4GB server that has to be maintained by a single indi…

Disclaimer: I work at Google on Kubernetes. I put that disclaimer at the top of all my posts, but this one truly is HIGHLY biased. The absolute easiest way to do what you describe is to use GKE (Google's hosted Kubernetes). For $0.15/hr, we'll manage everything for you, and you can build out teeny tiny clusters that do everything you need. It's even free for clusters https://github.com/kubernetes/kubernetes/tree/mast…

Is that really the easiest? I couldn't see a sample app there that matched the description.

One other issue is that's also over 100 dollars per month. I can rent 32GB SSD backed xeon E3 servers for half that. Or a stack of 10 4G VPS.

Re: I Want to Run Stateful Containers, Too

#89
post #15

Earlier quoted context omitted.

There are still a whole lots of pieces of the puzzle missing. I think it's all about creating ready to use containers which are running on different hosts which can replicate their data between themselves and handle failovers (they need to connect to etcd or zookeeper or consul for that). For PostgreSQL it seem to have already solved (?) 2 times by different people: https://github.com/zalando/patroni https://flynn.io…

Flynn co-founder here. We plan to expand to support many more popular open source databases next year (and expose a framework for others to do the same). The goal is that a supported database should "just work" on the platform and be sanely configured out of the box with high availability, automatic failover/recovery, encrypted streaming backups, app credential provisioning, etc. Our Postgres appliance is unique in t…

I think your ideas are sound, but last time I tried the manual install I couldn't get it running. So that was disappointing. That was many months ago, a lot might be changed now. I'll need to find time to have an other look.

Anyway keep up the good work.

Re: I Want to Run Stateful Containers, Too

#90
post #60

Earlier quoted context omitted.

* Alright, sorry Kubernetes is in Go I must've gotten it confused with some other project. * Well, alright, but they market it as a general purpose project. I'm just saying that to us it's strange that none of these frameworks out there deal with persistent storage, as the author of the article also observed. * Ok. * Well the problem is that it'd be much nicer if we could just use Kubernetes. Obviously having a homeg…

Disclaimer: I work at Google on Kubernetes. We do care enormously about stateful solutions; I'll say what I've said elsewhere - how do you handle stateful services in your VMs?

We don't run anything in VMs at the moment. I guess if we would we'd do it like we're doing with the containers, mount the drives into them. Do you guys run the search engine in VMs?
Post reply on HN