Basically the steps required by someone in order to get it up and running on Chunkhost. Best to start from beginning (creating a new server) and go from there.
My one primary issue right now with Docker is that it's a little difficult to get something like Apache going, since it's a service. Docker obviously detects the command I pass in as finished, and then stops the container.
Here it's solved by turning the nginx daemon off and running the command directly, but is there a better way to run something like Apache (which runs as a service) to host PHP applications, without resorting to sending long running commands like "while true; sleep 1; done"?
I guess this kind of defeats the purpose of Docker, in a sense, since the project's more about isolating applications (which generally run as a long running process, a la Node.js). But, PHP is still a popular platform for development and I'd love to be able to try out Docker for some of my own PHP stuff versus spinning up entire VMs with Vagrant.
I recently tried out the instructions at http://robknight.org.uk/blog/2013/05/drupal-on-docker/ (70% intro to Docker, 30% PHP+Apache), and I think it put me on the right track. I still have a long ways to go (like getting PHP-FPM working in this environment) but Rome wasn't built in a day...
Hey Andrew, you can definitely run Apache+php as a docker container. Apache can run in the foreground with "httpd -D FOREGROUND", so that docker can monitor it. Then add a few layers to your Dockerfile with php, mod_php, 3d party php packes and your own code - you should be ready to go.
Having docker monitor a foreground process has many advantages over the traditional "init script + self-daemonize" approach. Mostly it avoids reinventing the wheel. For example each process doesn't have to worry about logging, service registration/discovery, etc.
It also has the added advantage of stopping (and presumably automatically restarting, or at least triggering an alarm) a container when the service dies, something a daemonized version with a "while true; sleep" one would not.
This is something baked into the design of djb's daemontools (as well as later efforts in that realm like launchd and upstart), something the traditional shell-script startup stuff always got wrong.
How do you get the repo's files into the Dockerfile build context ? Do you have to install git and then `git clone` or are these available at a specific path inside the container ?
I really want start getting my hands dirty with Docker and give it a good evaluation. However, until they can support using a proxy server, it's dead-on-arrival for me.
I filed a bug report and even been on to the IRC channel to chat to the devs, but no-one seems interested.
Developers of the world: a large number of people will experiment with your products at work and a large number of work places use proxies. Don't forget about us when you invent a shiny new toy!
So that someone between you and http://get.docker.io doesn't decide to replace the script with their own special version that runs as root on your box.
Sorry, I realize that. I mean, you're asking people to literally pipe data into their shell from a website and you're not using HTTPS. That seems lax to me.
There's an ongoing issue for this [1]. The script is currently hosted on an S3 bucket which doesn't support SSL access via the CNAME. We're migrating it to a separate server.
Docker lets us use same set of configs so that we have uniform server setup everywhere right ? How is this different from Vagrant ? Or did I miss something ?
They are complementary. Vagrant is a tool for configuring VMs for development.
Docker is a tool for packaging your code and all its dependencies into a portable lightweight container. You can deploy docker containers across VMs and physical machines, regardless of how they are configured. Some of your machines may be configured with Vagrant, some of them with Puppet, Chef, Salt or any number of home-made tools. But all of them can run your docker container exactly as you built it, byte for byte.
Looks like it's built around KVM (Kernel Virtualization Modules), i.e. "containers", rather than full-blown virtual machine emulation like Xen or VirtualBox/Vagrant.
It appears to be a configuration management / deployment tool for KVM containers. New to me too, gonna dive in and check it out.
KVM is full machine emulation (i.e. hardware is emulated, and you can run different kernels inside the guests than you do on the host).
Docker uses LXC which is like BSD Jails, most of the advantages of VMs but you don't have to emulate a whole system, there's only one kernel atop which multiple containers/jails can run different software and have thorough isolation. Very fast and light-weight, but you can't run different OS kernels.
nitpicking: KVM stands for "Kernel Virtual Machine". It's an implementation of virtual machines, just like VirtualBox or VMWare. Containers are completely separate from KVM.
* Docker on Rackspace: http://blog.docker.io/2013/05/running-docker-on-rackspace/
* Docker on Digital Ocean: http://blog.docker.io/2013/06/running-docker-on-digital-ocea...
If you have installed docker on another hosting provider and want to share your notes, let me know.