4 ms·
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 lev
by dpeterson 11y ago
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 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-new-quick-start-reference-deployment/ 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/mongodb https://github.com/ansible/ansible-examples/tree/master/mong...
- smt88 11y agoI 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.
- petard 11y agoFrom 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.
- toomuchtodo 11y agoAgreed! (We're running a few hundred virtual machines; stateless in docker containers, stateful bare on the VM).
- dpeterson 11y agoSo 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.
- cpuguy83 11y agoIndeed. 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`
- dpeterson 11y agoGreat, 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.
- muraiki 11y agoI'm not trying to be pedantic, but the phrase is "passes muster." https://en.wiktionary.org/wiki/pass_muster https://en.wiktionary.org/wiki/pass_muster But "passes mustard" did give me a pretty funny visual image. :)
- dpeterson 11y agoHa, well that was stupid of me :)
- deleted 11y ago[deleted]
- hangonhn 11y agoVMware can do the same.