Comment by dpeterson | Hacker News Reader

Comment by dpeterson | Hacker News Reader

Parent Full thread

I did a quick smoke test to see if Tutum passes muster. My smoke test for this kind of tool is if they have a solution for deploying mongodb as a production level service with sharding or at the very least replica sets. Like so many other “let’s do the easy part and stop there” companies, they have a template for starting a single development mongodb node that would be easy enough to do myself. I want a tool that has a repository of templates for making formations of very hard things easy. Openshift is at least working on it: https://github.com/openshift/mongodb Their replica set version is not able to persist data permanently until Kubernetes figures out how to attach separate persistent volumes to pods in the same service. Unfortunately, Amazon is again the only game in town that does exactly what I want: https://aws.amazon.com/blogs/aws/mongodb-on-the-aws-cloud-ne....

If I want to run locally, I have to ditch Docker entirely and just use Ansible: https://github.com/ansible/ansible-examples/tree/master/mong...

I'm not trying to be pedantic, but the phrase is "passes muster." https://en.wiktionary.org/wiki/pass_muster

But "passes mustard" did give me a pretty funny visual image. :)

Ha, well that was stupid of me :)

From my experience running stateful applications should be avoided with the current state of things. We've deployed ElasticSearch, Kafka etc container-less but use containers for all of our stateless services.

So many people say that but if you can't scale anything stateful what is the point of all of this. Often it is the database that needs to scale the most since business applications spend a lot of time there and much less time actually performing cpu intense calculations. I do work for a very large organization that can afford mongodb as a service but for startups without large sums of money, 1400 dollars per month for amazon to run mongodb or 1000 a month for mongolabs to do it seems high. Plus, I want to colocate my data with my apps to limit latency. It just seems like "running stateful services in containers is a bad idea" is parroted over and over because its such a hard problem few people seem capable of solving. Instead they spin up 1000 stateless containers that print hello world and become impressed with themselves.

Indeed. This is why we've developed the plugin ecosystem, and a proper volumes API in docker.

With plugins your volume can either live locally or on some other storage management system, like ceph, gluster, s3, etc. These are all working solutions today. `docker run -v importatndata:/var/lib/mydata --volume-driver ceph` Run that on two hosts and you get the same data.

In 1.9 there is the volume API that allows you to wire this up prior to docker run `docker volume create --driver ceph --o foo=bar --name importantdata`, then `docker run -v importantdata:/var/lib/mydata`

Great, now have someone at Docker package that up in a Docker-Compose, Docker Swarm, Docker Machine template that starts up a Mongodb Replica set and I am happy as a clam.

Agreed! (We're running a few hundred virtual machines; stateless in docker containers, stateful bare on the VM).

I wonder if your Mongo-based test is really the best test. I've never used it, but Mongo has a poor reputation for... actually everything, including sharding/replication.

VMware can do the same.

Reply on news.ycombinator.com