Looks like MongoDB is the problem here.
I Want to Run Stateful Containers, Too
71–80 of 102 posts
Re: I Want to Run Stateful Containers, Too
#72MongoDB is the hub of this problem.
Re: I Want to Run Stateful Containers, Too
#73[deleted]
Re: I Want to Run Stateful Containers, Too
#74Right now VM's are the better choice for Statefull use cases like running a a conventional databases that expects a real filesystem. In a few years I think container and container schedulers will get good at doing persistent volumes.
In the meantime I think a less known but great solution for reliabily creating VM' is OpenSoure BOSH http://bosh.io/ is an excellent tool that will allow you to deploy VM's on most major IaaS including AWS, Azure, OpenStack, vSphere and others.
BOSH is a hard to learn and it has a different philosophy than typical configuration management tools such as chef/puppet/ansible ... etc but it is totally worth it once you have it you have an amazing power tool at your disposal.
There are a lot of bosh releases for popular tools on github.com for example here is one for mongoDB https://github.com/Altoros/mongo-bosh
Re: I Want to Run Stateful Containers, Too
#75At the end of the day you want to be robust to failures right? Be able to quickly restore from a database in a hardware failure?
If so, why not just boot that way every time? It'll keep your backup system well exercised and it means fewer code paths since you don't have a separate hot boot.
Re: I Want to Run Stateful Containers, Too
#76The 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 individual where time and complexity are highly-valued commodities?
The least-complex setup will be preferred, as the hundreds of 1-man side-projects will not be able to maintain their 43 container-clusters using x-software on top of y-software that is managed by z-software.
=====
A good answer here will probably help hundreds of individuals here avoid the situation of "I should probably containerize my app because everyone else does it" scenarios.
Re: I Want to Run Stateful Containers, Too
#77Earlier 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…
Can anyone explain why Docker image handling is so terrible? For one, building an image creates lots of unnecessary overlays (resulting in the absurd need for "garbage collection"), rather than just compacting everything into one file? But also the whole registry thing. Why can't I just point Docker at an S3 bucket? Sure, you can run a private registry, but that involves (last I checked) running a daemon, Redis, and…
1. The idea behind the overlays is to "cache" and reuse as much as you can between images. If you have a long list of packages you install before you copy your app source to the container, you don't have to install the packages again and again every time you do a change to the source and rebuild.
2. You can point Docker to a file - use 'docker save' and 'docker load'.
Re: I Want to Run Stateful Containers, Too
#78What 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…
The point is better hardware utilization. Part of the "isolation" that containers provide is resource allocation. You assign limits to the CPU cycles, RAM, disk IO, network IO etc that each container can use.
Without any kind of virtualization, i.e. processes in an OS running on bare metal, processes can starve each other of resources - hog the CPU, fill up the disk etc. Virtual machines like kvm and Xen limit the resource usage of guest operating systems, but that comes with a lot of overhead. Each VM has to run its own kernel and a bunch of user-space programs in addition to the the service you're trying to provide. The disk images have to include a full operating system as well - config files, libraries, executables and so on.
With containers you get the best of both worlds: the resource limits of virtual machines with the low overhead of processes sharing an OS. That means you can run multiple services per machine without them interfering with one another, and you can pack more of them onto each machine than if you were using virtual machines.
So if you're Google (which did the initial kernel work to support containers in Linux) you can get a lot more computation out of your 100K-server data centre if you package all your software as containers and write sophisticated software to distribute them to server and shuffle them around as load fluctuates and batch jobs get run.
For those of us that don't run our own data centres the benefit is much less clear. Running containers on top of virtual machines seems like a pretty terrible idea. With all that overhead, performance suffers and you end up running more containers to compensate, which just makes everything more complicated and more expensive.
I think the current container craze boils down to two things: first, no matter what ugly, undocumented, unspecified process you use to build a container image, once you have the image you can deploy it in a repeatable, consistent way. That's a big improvement over Chef/Puppet right there. Second, fashion. Doing ops the Google way is cool, and it'll make my resume look good even if I'm not currently in a position to reap the benefits that Google does. Being a Puppet expert is so passé.
Re: I Want to Run Stateful Containers, Too
#79What 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…
Disclaimer: I work at Google on Kubernetes
The number one feature we see people get out of containers (as we did at Google) is flexibility. Bin packing and (some) isolation is important and valuable, but the vast majority is just being able to throw 25k containers at a system (Borg for internal work, now Kubernetes externally) and just say "Go run this somewhere." The system figures it out for you - and you never have to deal with server config. Then if you need to move to a new data center - presto, happens in seconds.
Re: I Want to Run Stateful Containers, Too
#80What 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…
The point is better hardware utilization. Part of the "isolation" that containers provide is resource allocation. You assign limits to the CPU cycles, RAM, disk IO, network IO etc that each container can use. Without any kind of virtualization, i.e. processes in an OS running on bare metal, processes can starve each other of resources - hog the CPU, fill up the disk etc. Virtual machines like kvm and Xen limit the re…
Disclaimer: I work at Google on Kubernetes
Portability, as you mentioned, is huge - but beyond that there is also binpacking benefits. You can basically cut your serving costs by 50% or more by using lots of single process containers instead of poorly utilized VMs.