If you are familiar with machine virtualization think of these as templates. An image is used as the base of a container.
So, when a container is 'run' it is essentially a differencing file system that is linked to an image file system. This allows something to happen within the container and for that to be written back to disk in a unique place.
This is really no different than the concept to using a single virtual disk and creating multiple virtual machines from it using differencing disks. The differencing disk contains the unique character of each machine. In this case the container contains any uniqueness.
Let me give a bit of background here. If you were not aware, I am employed as a software tester. I also do some development. But, I like to keep my workstations clean. And containers give me that in a tidy way.
Lately, I am working with a NodeJS application. And I don't want to have to install Node and all of its dependencies on my workstation. This is how I see many developers get themselves into the classic 'works on my machine' trap.
At some point in time they installed some strange DLL or package ( or security settings or anything ) and then later took that as a dependency and never realized it. Then they distribute the package, I put it on a different system, and wham, no workie.
So I am actually going to do a few tricks that containers easily enable. And I will also use a real example that I am working with and you could as well.
Enough of that. Lets take a moment to look at the syntax of the container run command
( the entire run reference is here: http://docs.docker.com/reference/run/ )
I am going to begin with the Node image that I pulled down. This image is based on Ubuntu and already has NodeJS and the NPM package manager installed. This saves me a bit of time with installing Node, its dependent libraries
sudo docker run -i -t --name meshblu node:latest /bin/bash
Lets break this apart:
- sudo - this is Ubuntu and Docker runs as root (or local system) so in order to interact with it, you must elevate yourself. Windows admins; think RunAs.
- docker - call the docker service then pass it a command
- run - self explanatory, but I want to run a container
- -i - interactive. This will put the container console into my current console.
- -t - virtual tty. This gives you a tty console session for STDIN. Important if you want to interact with the container in a console way.
- --name - this will be the name of the container, and simply helps you to keep them straight. Without it a random (and silly) name is given. And you will have to keep them straight. The key here is that this is just a quick way to locate the container ID, which is the really important thing.
- node:latest - this is the name of the image I pulled / want to use. It will check if you have this local, if not it will look to the configured hub and try to find it and pull it.
- /bin/bash - this is the command plus any arguments to run. Everything after the image name will be executed within the container. So you can have any command plus parameters at the end. /bin/bash is simply a bash shell - pretty much were you are at any Linux console.
Notice that your prompt changed. Because now your command window is connected to the container process and you are essentially "within" the container. For me this is: root@06b874873e86:/#
I am in the container as root, and the container ID just happens to be '06b874873e86'.
If you type 'exit' the container stops running and you drop back to your command prompt.
If you type 'ctrl+p' then 'ctrl+q' you drop back to your command prompt, but the container stays running.
To see any running containers type (at the Docker host): sudo docker ps
To see all containers (running and stopped / paused): sudo docker ps -a
If you want back into a running container use: sudo docker attach 06b87
(notice that I did not type the entire container id, just enough to uniquely identify it. A nifty usability feature)
Lastly, to start a container that has been stopped: sudo docker start -i 06b87
(the -i connects you to it interactively)