Random Research: Using docker to keep your server clean when testing

Docker is amazing. Containers make setting up a media server almost like building with LEGOs. You just pull down the image you want (likely from the great linuxserver.io), make sure you wire up the ports and volumes appropriately, and Bob's your uncle.

Sometimes what you want to do isn't packaged up in a nice Docker container for you. Docker is still helpful in these situations.

I don't know about you, but when I'm experimenting with something, I am always weary about installing stuff because I don't want a bunch of trash hanging around on my server when I'm done. There's always chroot'ing or lxc, but I've found that generating a customized docker image and spinning up a new container when you need it is easy and makes cleanup a cinch.

Build the image

Assuming you have docker installed, create a new directory and call it something like base or test. Inside, create a file called Dockerfile.

Here is what I have in my Dockerfile:

FROM ubuntu:16.04
RUN apt-get update && apt-get install -y net-tools nano sudo

RUN useradd -ms /bin/bash trent
RUN echo trent:password | chpasswd
RUN sudo adduser trent sudo

USER trent
WORKDIR /home/trent

Going through it:

  • FROM ubuntu:16.04 - This tells docker to use the official ubuntu image as it's base. Specifically version 16.04.
  • RUN apt-get update && apt-get install -y net-tools nano sudo - Since containers are designed to be small and lightweight, the ubuntu image is pretty much bare. You can always 'apt-get install' what you need from within the container, but there are some tools I need pretty much every time so I build them into the image. I'll probably need to keep adding to this list, but these three get me started.
  • useradd, chpasswd, sudo adduser, etc - By default, you get dropped in as root. When I'm experimenting, I want it more like a standard environment where you operate as a user and need to sudo for root access. The top line creates a new user: trent. The next line sets this user's password to password. The third line adds trent to the sudoers list so he can run sudo to get root access.
  • USER trent, WORKDIR /home/trent - These two lines just make it so the container starts as the new user and in his home directory.

With the Dockerfile set up, we just need to build it and tag it with an easy to remember name:

docker build -t test .

Running the container

When I'm ready to putz around with something, I can now spin up one of these containers on demand and experiment within it. Here's how I start one:

docker run -it --rm test bash

The -it flag tells docker that we want to use an interactive terminal. The --rm flag tells docker to remove the container when we are finished with it. If this is a longer term experiment and don't want it to delete immediately, remove that --rm and maybe add "--name=something" for easier identification.

Finally, if you are doing something more advanced that requires more low-level access to the hardware, add the -privileged flag. I've had to do this when playing with FUSE mounts.