The short introduction on that tutorial is much better than that actual docker site and 10-15 min interactive tutorial on what docker actually is and what it can be used for. A note to other developers, it's a good idea to not use some language without first defining the word... Especially if it's an overloaded term.
Agreed, it's a nice intro. I still think the hardest part is understanding how docker fits into the bigger picture. I think I've more or less figured it out on my own, but I struggled with e.g. do I want my source built in the image or mounted as a volume?
If you're loading the source from outside, aren't you losing the advantages of immutability of the Docker container? Suddenly the same image may have different behaviours depending on the state of the code outside.
But if the source is mutable data, what isn't? Everything eventually mutates - dependencies have updates, configurations change, etc. Isn't the point of images that you "freeze" a static release that can be deployed everywhere?
It seems that by that point you've lost the advantage of using images; if parts of the system must be loaded outside of the container, it seems you might as well simply use a configuration manager to install the stuff and then run LXC/LXD containers instead of using images at all.
I know, I'm a little late to this party, but just in case anyone is still around... :)
For me, mounting my local app files as a volume is useful during development since it keeps the workflow fast. I don't have to rebuild the image every time I want to try the app out, I get to use the new code without delay.
If I were deploying as a container, I presume my build process would check the app out of git and build the image based on that fresh checkout. I'm just using Docker as a convenient way of simulating my production environment (dev'ing on Ubuntu 15.04, but deploying to Debian 7), and still be able to iterate rapidly.
When I want to understand in a few lines some business or software, I normaly avoid their web site because it's usually just riddled with buz words and a sales funnel to force you to register or get some trial without even understanding what it is or how it costs.
For a good 2-3 sentences description I go on Wikipedia when available.
For some reason I found docker very unintuitive, even writing a simple build script was confusing. I agree, this book would have done a much better job of introduction than the docker site.
It was mostly how we wanted to use it at my company. It didn't seem clear whether docker should just set up the system (apt-get, pip install) or also checkout the code. To add to the complexity, we have a puppet script we run on the machine to install dependencies. I had no idea how Docker who supposed to fit into this pipeline. So basically, I didn't know what docker was supposed to be good at, i.e. do better than other tools.
I never really got to play extensively with Docker mainly because I have found the setup of OS X not quite friendly. While I understand the value of Docker, basically booting up a VMware/VirtualBox image was faster for my own use.
I'll have to give boot2docker a try to see if it is changing things. Having a good guide will definitely help.
Machine makes it really easy to create Docker hosts on your
computer, on cloud providers and inside your own data center.
It creates servers, installs Docker on them, then configures
the Docker client to talk to them.
For some reason, when using docker machine on a mac, the VM always fails to start and freezes at the "VM starting" phase. For this reason, I've had to switch back to boot2docker.
Super sorry to hear - we've had some issues with VirtualBox around networking and some setups we didn't anticipate -- Would be really appreciative if you'd give the latest 0.3.0 release candidate a whirl and see if it fixes the issue for you: https://github.com/docker/machine/releases.
When you start playing around with docker and come to the area where you start to see that many things that should be very easy start to be really complicated, then you should take a look at lxc and the upcoming lxd and compare.
Is docker ready for production? Is someone using it on real production environments? Most recipes at Docker Registy are a mess, and with plenty of bugs
Yes, but it's not like they don't warn people. From the Docker docs:
"This backend is pretty fast, however btrfs is still maturing and is not considered production ready for heavy write loads. Mounting /var/lib/docker on a different filesystem than the rest of your system is recommended in order to limit the impact of filesystem corruption. You would also want to mount the volume directory /var/lib/docker/vfs/ on a standard XFS or EXT4 filesystem to ensure container data is protected."
I haven't done any systematic comparison to tell which one's cheaper. AWS allows 1 year of free tier service, so I'm using that. What I like about Beanstalk is that it's extremely easy to deploy updates. Just commit the changes and execute eb deploy. Setting up a new environment via. CLI is also a breeze.
There is some outdated information on this site for boot2docker on Mac OS X.
1. You need to set more than just tcp://ip:2376. You need to run
$ eval $(boot2docker shellinit)
to also set vars for DOCKER_CERT_PATH
2. In order to get proper forwarding from your host Mac OS X to your boot2docker-vm, you use -P as a command line option for any containers you 'run'.
Bonus docker gotcha:
docker containers can't make fsync() calls on shared folders between your Mac and the boot2docker-vm. This means a lot of database software can't use a shared folder to store a database.
