Straightforward Docker for DevOps

Warning - this post is assuming that you have basic-tutorial-level knowledge of Docker, if you don't, please spend 10 min. there. I swear, it only takes that long.

Technology has been evolving faster than the usual in the last years. If your infrastructure keeps you busy enough that it's not an optimal usage of time to read multiple endless articles, see different one hour talks about new technologies, this is my short summary about what is relevant to help you use the advantages of Docker, without the hassle of having to learn the new-suggested-solution-of-the-universe way to operate described in the documentation.

The main advantage of docker is to do pretty much the same as a virtual machine, but not having as much overhead. Think of it as the good and old BSD Jail. It is also much faster to start a Docker container than to start a virtual machine. It  tries to isolate one process per container, that will be for example your web application deployed in an Apache.

One scenario we can easily imagine where one wants to test puppet modules inside vagrant boxes inside of Jenkins. By the time that I tried that, the vagrant plugin was badly broken, so I thought of having a closer look in Docker, as there was also a Docker plugin.

Some useful concepts/general tips :

• You will find a raw image of the distro you like, and will have to build your env a bit on top of that. It's ok, do that, docker commit and you will have what you need ready to use.
• I found mainly 2 ways to use it
• Interactive session, if you use VMs for validation/testing you're at home
• Run a container to execute "a job" and exit, get the exit code and do something with it.
• For example, "cpan install My::Perl::Module" and make sure all goes fine (0)
• There is a third usage that I will let aside - run a service such as a webserver inside the container, leave it running for long, for other purposes.
• All changes need to be commited, otherwise they get lost. This is good and bad.
• Get used to divide the bigger task in chunks, so you commit small chunks and can revert if needed
• Basically aim to have a checkpoint RIGHT BEFORE running your test.

I think that this list is good enough, so let's proceed to the last part where I actually show how to do the VM-like interactive session and then use what you will do in the test workflow, non-interactively.

Although a lot of people say that it's a sin to run docker as root, I think it's ok to do so, depending on the context. In a test/dev environment surely, so you will miss your dear sudo, sorry :

~# docker run -t -i samircury/centospuppet /bin/bash
Attention on the -t -i flags.

This will give you a terminal on your docker container, go there, do many customizations such as "yum install gcc expat-devel", configure CPAN, everything. Make sure that everything will go fine until you are able to run your test. To start getting concrete, what I want to do is that "cpan HTCondor::Queue::Parser" installs fine.

What I like to do on this part, is go to the very end, installing dependencies, see that the module installs properly, then exit, not commit any changes. By then I will know all depencies as I wrote them down somewhere.

Next step will be to get a bash again, install only what I need for the test, exit, run :


~# docker ps -l  # will list your
~# docker commit a3e333a99b231f56 samircury/centospuppet


Ok, now we're all set for the test. Let's drop the -t -i flags, run it non-interactively and see the magic happening :



[root@darkstar ~]# docker run samircury/centospuppet /usr/bin/cpan HTCondor::Queue::Parser

--suppressed-extremely-long-cpan-output--
Installing /usr/local/share/perl5/HTCondor/Queue/Parser.pm
Installing /usr/local/share/man/man3/HTCondor::Queue::Parser.3pm
Appending installation info to /usr/lib64/perl5/perllocal.pod
SAMIRCURY/HTCondor-Queue-Parser-0.04.tar.gz
/usr/bin/make install -- OK

Warning (usually harmless): 'YAML' not installed, will not store
persistent state
[root@darkstar ~]# echo $?
0

Now an interesting observation, you saw that $? was 0 -- everything was fine, but if I use the standard CentOS image :

[root@darkstar ~]# docker run centos /usr/bin/cpan HTCondor::Queue::Parser
2014/08/10 00:02:31 exec: "/usr/bin/cpan": stat /usr/bin/cpan: no such
file or directory
[root@darkstar ~]# echo $?
1


I won't pollute here with all the evidence, but I did extensive testing and I found very nice that the exit code of your non-interactive command is propagated to the exit code of the "docker" command itself. In other words, in Jenkins I wouldn't even need a Docker plugin, if I used this exit code instead.

I hope this helps people to get to the point where they can use Docker for something useful faster.