Getting Docker to run on Linode(nick.stinemat.es)
nick.stinemat.es
Getting Docker to run on Linode
http://nick.stinemat.es/
38 comments
Ken Cochrane also compiled a huge list of docker-related resources here: https://github.com/dotcloud/docker/issues/614
Thanks, Ken!
Thanks, Ken!
I have one for getting it on Chunkhost.
http://sbaronda.com/2013/05/05/getting-docker-on-chunkhost/
http://sbaronda.com/2013/05/05/getting-docker-on-chunkhost/
Thank you, I have added it to https://github.com/dotcloud/docker/issues/614 Would you be interested in submitting a pull request to add it to the official docs?
I could probably do that. Do you just want an acknowledgement that Docker works with Chunkhost or something more detailed?
something like this.
http://docs.docker.io/en/latest/installation/rackspace/ http://docs.docker.io/en/latest/installation/amazon/
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.
The docs are located here: https://github.com/dotcloud/docker/tree/master/docs/sources/... if you have any questions, feel free to submit the PR with your questions, or jump on the IRC channel #docker on freenode.
http://docs.docker.io/en/latest/installation/rackspace/ http://docs.docker.io/en/latest/installation/amazon/
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.
The docs are located here: https://github.com/dotcloud/docker/tree/master/docs/sources/... if you have any questions, feel free to submit the PR with your questions, or jump on the IRC channel #docker on freenode.
Thanks a bunch for posting this, shykes. :)
I want to add that, my site is so far a bit pre-mature for all of this traffic. I added some more content but linked to the article in the top post.
I'll be implementing a more "real" blog shortly, but that's part of the development process of this blog.
Feedback is much appreciated. And feel free to come say hi in #docker on freenode.
I'll be implementing a more "real" blog shortly, but that's part of the development process of this blog.
Feedback is much appreciated. And feel free to come say hi in #docker on freenode.
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.
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.
I would argue it is closer to the Unix way :)
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.
I would argue it is closer to the Unix way :)
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.
Failure detection is your friend.
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.
Failure detection is your friend.
Yeah, I guess that makes sense. Thanks for the response!
Andrew - check out the latest article to see how I get nginx (a webserver like Apache) to run the site you're viewing. Just re-click the link.
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 ?
Use the ADD command.
ADD <folder/on/host> </mount/point/on/image>
ADD <folder/on/host> </mount/point/on/image>
More specifically it's:
ADD <folder/on/sourcedir> </mount/point/on/image>
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!
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!
What do you mean by support using a proxy server? Can you put a link to the Docker ticket, and I'll take a look.
Sure thing: https://github.com/dotcloud/docker/issues/813
What I mean is, that in order to pull from the repository (eg, docker pull base) I need to connect using a proxy server.
What I mean is, that in order to pull from the repository (eg, docker pull base) I need to connect using a proxy server.
I see, thanks. I'll see if I can get someone to look at it.
I am new to this.
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 ?
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.
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.
Interesting. Does this also mean you can run your container on both 64 and 32 bit platforms?
Yes, although only x86_64 is officially supported at the moment, that should change very soon.
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.
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.
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.
That's a great way to describe it. It's a "lightweight" VM that is created per process.
[deleted]
"curl http://get.docker.io | sh" - what reason would there be to not use SSL here?
https is not available for the site. The script doesn't seem particularly sensitive, is it?
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.
[1] https://github.com/dotcloud/docker/pull/648
[1] https://github.com/dotcloud/docker/pull/648
* 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.