Yeah, what Solomon said. For the moment, Dokku is focusing on the same sort of stateless apps Heroku supports and considers running databases a separate concern. For now you can run your databases, etc on the same host, in Docker containers, somewhere else, just out of band from Dokku.
But I'd love to hear your thoughts on how Dokku could better support datastores.
No. In terms of io and other kinds of overhead, you are always better off running your database on a container rather than a VM. The majority of public cloud database services are either running inside containers, or in the process of migrating to containers.
An additional advantage of containers is that you can start running them on top of a VM, and then migrate to bare metal later, as your infrastructure requirements evolve.
I think in my head I had container ON A VM. Which just inherits the problem of running it on a VM. Is there a good linux tool for limiting the IO of a process or user?
That's my favorite aspect of the Dokku/Docker combo: your paas doesn't need to be in a walled garden, isolated from the rest of your stack. You can mix containers deployed by Dokku with other containers deployed directly on Docker - in the end they're all docker containers, so you can manage them with the same tools.
This is a great project. I am currently trying to help progrium to fix a bug that is keeping the Python buildpack to work. So if you want to help, here's the GH issue:
Awesome! I've wanted something like this for a while. About 2 weeks ago, I tried running this and it took upwards of half an hour to get running on my VPS with DigitalOcean.
Today however it took 30 seconds so I'm not sure whether it has been updated but a great improvement :-) The only thing I can't wrap my head around in the README is the 'deploy an app' section.
It says to cd into node-js-sample. Where does that folder come from? I created a bare repo called 'node-js-sample' in /home/git and I tried pushing to that but I get this error:
/usr/local/bin/gitreceive: line 54: /home/git/node-js-test/hooks/pre-receive: Permission denied
I looked and that hook doesn't exist (that'd be why! Haha) What's the proper way of creating an app ready to be deployed on the server?
Saw this a while back. It looks like a fun little project for Docker. What I'd be more interested in is seeing a more robust version of something like this (and the author mentions it on his Github). Things like scaling ability and similar would be cool. It certainly would move it from the realm of 'smallest PaaS', but for my uses at least it's not very useful without being able to do any sort of multi-tenancy/multi-host type stuff.
If anyone is aware of a Docker project being worked on like that. I'd be very interested in seeing it as well.
There are several ongoing projects to orchestrate deployment to a cluster of multiple docker hosts. Docker is designed to be easily dropped into a distributed system, which helps.
For example, there is an Openstack integration [1], Hipache and Nginx integration for load balancing [2] [3], and I know several people are exploring integration with Apache Mesos and Zookeeper. There's also a Velociraptor/Docker integration [4].
Lastly, I've seen a lot of ops teams plug docker into their own deployment tools, but those are generally not open-source.
Feel free to drop by the IRC channel (#docker@freenode) to chat some more!
Velociraptor does use LXC containers though, and provide the same kind of buildpack support as Dokku, plus a nice dashboard with streaming updates on your processes and some help for managing all the config for your instances (if 2 apps use the same database, you only have to record its URL in one place).
We're running dozens of apps and hundreds of instances on Velociraptor at YouGov, but it still has plenty of rough edges.
I did see the openstack Docker integration and it seems like a very interesting prospect. Hopefully something that will be integrated into the core Openstack project (although perhaps it might be better to integrate LXC into Openstack and then feed Docker through that).
The one thing I haven't seen any real solution for is the scaling/autoscaling portion of the equation. I think if that can be solved for, the rest would just be window-dressing on top of the Docker core.
First, OpenStack is a poor abstraction for what most people want. I don't even think it's worth bothering with if you can help it. Docker is what people should (and will) be building tools around instead of OpenStack. Docker integration in OpenStack is neat and even fun, but to me a distraction.
Autoscaling is interesting because it's only one part of a more complex problem of distributed orchestration. There might not be a good general purpose solution to this for a while. Every organization has different policies and requirements for scheduling resources. Docker was designed to be driven by any sort of automation at that level, but specifically avoids solving that problem.
But there's plenty out there to help you put together this solution for yourself. I'm curious what exactly you're waiting for in a solution.
Many people want to run a certain piece of software in its own machine and docker allows that. Some people thing OpenStack is the right choice for that. OpenStack is great if you are running your servers through AWS, but you want to transition to a self hosted system then you would use OpenStack. In other words its great for building a IaaS but not a PaaS
Most people don't realize it but they just want to run a process. That's where the computation is defined that you care about. And in many cases, you want to run a long running daemon process. So why are we futzing around with hosts and virtual machines? If all you want is to run managed processes in a cloud (which is what you should want), then OpenStack is unnecessary. You could just write automation around Docker, regardless of whether you're using EC2 or physical servers.
Only through libvirt, which by design only exposes the lowest common denominator among all supported backends. Docker needs its own native backend for the same reason Xen has its own: so it can do more cool stuff.
See [1] and [2] for more details. It looks like the blueprint just got approved, too!
I was talking to somebody in the Docker IRC channel that was using some of the same Dokku components to build a more distributed version of Dokku. Not sure if it's released yet.
Part of the goal of Dokku is to define some components that would work just as well in a distributed fashion if the components were distributed. By deferring that complexity, I can focus on making something simple and modular that should be easier to do as a distributed system later.
My involvement in Docker in the early stages was with this same thought in mind. Docker was designed to be a component to build things like a PaaS, as well as many other things. Much like the other components of Dokku. The end result is a loosely defined "toolkit" that you can build your own variation of a PaaS with whatever requirements you might have.
OpDemand is working on exactly what you're describing. Heroku-style private PaaS with emphasis on control over instances, routing layer, hosting providers, etc. Current version has full scaling support (instances, processes & nginx proxies). It's based on Docker, Heroku buildpacks all glued together via Chef server. It'll be released under Apache license. More to come...
Openshift per the #openshift channel only currently supports scaling of HTTP resources (I'm a bit surprised about that).
I currently use Cloudify, but have had some... issues and they use a Java agent which is pretty memory heavy, so I'm working on alternatives. Cloud Foundry is about the only other viable option I've found so far.
Same here. Most seem to expect you to do the Heroku route and just run your database off of another cloud service... well, what if I DON'T want to do that? The answer seems to be oh well for many projects. Frustrating for sure.
I had this argument last night. Ultimately I probably won't care if people say it wrong relative to author intention. Some people will know, others won't. I just want to at least document the intended pronunciation, which is the way the actual word is said in Japanese. Which, btw, means "dock" ... the closest I could get to Docker and just happens to sound like Heroku.
Do I just set that stuff up like normal on my box or should I be integrating that with Docker?
Very cool project, would love to get this working and used for internal projects.