Tim's Blog

Information, Technology, Security, and other stuff.

Migrating to Docker in the Homelab

Published 2015-09-15

So far I've watched the emergence of the container trend from the sidelines. I run a couple of Linux servers at home, but so far have stuck to installing my applications the old fashioned way. I had a brief play with Docker but didn't get beyond running a shell inside a container.

This all changed though with the purchase of my latest piece of kit from eBay, an old enterprise desktop:


I love these machines as they cost next to nothing, don't consume too much power or make too much noise (as long as they're not too old), and can be easily replaced if failing. And I don't need to get a rack to mount it in.

Now I had planned this box to run Confluence (to maybe replace my DokuWiki server), my VPN and my Mail archive server. I've got far too many machines now running in my homelab, and I'm concerned about the heat and power draw for the upcoming summer months. Here's pretty much all the machines currently in my environment:

Network Diagram

So I installed Pritunl, Confluence and iRedMail on the new box. All seemed to install fine, but I couldn't get to the Admin portal of iRedMail for some reason. I'd just get a "502 Bad Gateway" from nginx.

I spun up a test VM and performed the same installation, and still no admin page. It turns out uwsgi was clashing with something on the machine (this machine being a Server with a GUI installation of CentOS, which I don't normally do but I wanted a backup desktop as well).

Trying some basic things suggested here didn't solve the problem, so I decided to fix my dependency problem by trying to install it as a container with Docker. Although it's kind of overkill to fix this problem, and I confess I really have next to no idea what uwsgi is, I figure this is a good reason to tackle containers.

I did have a crack at making my own images, but in the end it was so nice to just use others that are already out there. Except for iRedMail. It seems there aren't any maintained iRedMail containers out there, so I figured I'd try an alternative and found Poste, a more lightweight mail server solution to iRedMail running almost the same underlying components. It seems to work OK so I'll see how it goes for now.

Anyway, here's what I did on my new CentOS 7 box:

## Elevate
sudo su

## Disable root login
sed -i 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
sed -i 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
systemctl reload sshd.service
## Update the Server
yum update -y
## Switch SELinux to Permissive for now
sed -i 's/enforcing/permissive/g' /etc/selinux/config

## Reboot to apply the SELinux change

## Elevate
sudo su
## Install the Prerequisites
yum install epel-release -y && yum install wget yum-cron -y

## Turn on Auto Updates
sed -i 's/apply_updates = no/apply_updates = yes/g' /etc/yum/yum-cron.conf

## Add the Docker Repository
cat >/etc/yum.repos.d/docker.repo <<-EOF
name=Docker Repository

## Install Docker
yum update -y && yum install docker-engine -y

## Enable and Start the Service
systemctl start docker.service
systemctl enable docker.service

## Disable postfix, otherwise the Poste instance can't start from a port 25 clash
systemctl stop postfix.service
systemctl disable postfix.service

## Install Confluence Container
docker run -d -p 8090:8090/tcp cptactionhank/atlassian-confluence:latest

## Install Pritunl Container
docker run -d --privileged -p 1194:1194/udp -p 1194:1194/tcp -p 9700:9700/tcp johnae/pritunl:latest

## Install Poste Container
docker run -d -p 25:25 -p 80:80 -p 443:443 -p 110:110 -p 143:143 -p 465:465 -p 587:587 -p 993:993 -p 995:995 -v /opt/vmail:/data -t analogic/poste.io:latest

I'm still learning how to use Docker, but for now this works. I'm excited at the thought of being able to just move my containers around between hosts, as I'm running a lot of low-power machines. Confluence, being a Java application, is quite heavy on the resource usage so I may need to try it on a few hosts before I get it running in a satisfactory state.

My main concern is the lack of visibility of what is happening when these machines build. For all I know they could be enforcing the use of an unsavoury repository for the data to come down from (and turning off signature checking), or installing something extra that I don't want. Or even just deploying a less-than-ideal configuration for long term use (like using a test database like H2).

For a production server, I'd recommend either poring over the build process of these containers or building your own to get the assurance that they haven't been tampered with.