Docker Containers are just that – self contained instances of an application and they allow us to not only exploit controlled, wafer thin virtual environments but also let us apply a modular approach to updating our applications by swapping out elements of it rather than having to update the entire thing. So if you’re application requires say, a LAMP set-up you have everything you have your application as well as everything it needs one neat container.
Really there’s just three concepts to get used to here:
What makes containers different to just a single virtual machine is that the elements that are required to run the application are available as layers that can be swapped in and out rather than having to provide another entire image of application.
When we first create a container we can pull an image from the registry to form the basis of it.
$sudo docker run ubuntu:14.04 /bin/echo ‘Hello World’
This simple command runs a container using Ubuntu 14.04 as the base image and tells it to run the echo command to output:
Once this command is run the container stops.
$ sudo docker run -t -i ubuntu:14.04 /bin/bash
There are two flags here -t – which lets use that container’s terminal prompt and -i which lets us use container interactively. This all means that we can run commands from within the container using the bash shell.e.g.:
The same ‘Hello World’ command as above with a -d flag will run the command but return a long string of numbers and letters:
This runs the command in ‘daemon’ mode which runs in the background. The long string is the container ID.
The docker ps command gives us a list with information on all the containers currently running:
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES b1dbeaf4d4ad 856138e90429 "/usr/bin/supervisor 2 weeks ago Exited (0) 19 seconds ago insane_babbage
The Container ID uses the first few characters of the long string we saw earlier when we used the
We can also see the image used to create the container, any commands running on it as well as the name automatically assigned to it so we don’t have to remember that long string or the shorter Container ID.
If we want to see the name of the last docker started we just add the flag
-l and to see all containers (stopped and started) just add the flag
So essentially what we have here is a self-contained, sufficient instance of our application deployed on a very light weight version of Linux but say we’re running Windows or OS X – we’re going to need a VM to run the Docker containers and that’s were Vagrant comes in.
Vagrant lets us provision a VM and create a working environment for us to run the VM so we can have control over every aspect of the VM including port forwarding or what’s running it (including Docker and any containers).
Following installing Vagrant and VirtualBox (though there’s also support for VMWare) we can then create and run a Vagrantfile which is basically a manifest describing what VM we want to run and any configurations we want to make to it. Once the Vagrantfile is in place (usually at the root of the User Directory) we use
This pulls the VM from the location we’ve set in the Vagrantfile and configures it. If the VM is already on the host machine it just starts it up. If you want to access, say Docker, (if it’s been installed on the VM) just use the
vagrant ssh command.
The beauty of both Vagrant and Docker is that whether you’re a developer or a designer you can ensure that you have full control over the environment your application runs in so when it comes to deploying it in different environments (live or just testing) you can be confident that everything is going to run.