Tuesday, February 3, 2015

Installing SABnzbd in Docker on OMV, Part 2

Continued from Part 1.

I'm going to assume you've read (or skimmed) through part 1 of this guide, and you have a Dockerfile prepared.  In order to build an image off this Dockerfile, run the following command;
sudo docker build -t sabnzbd

This will build a new image, using your Dockerfile, and the image will be called "sabnzbd".  If this is the first image you've built, the process may take a little while.  At the start of the Dockerfile, we specified that our image will be built based on debian:wheezy.  So the docker daemon will need to download a copy of wheezy to serve as the starting point.  Don't worry, this is not a full-blown copy of Debian, just a minimalist image to serve as a starting point.

If you build more images, using the same debian:wheezy image, you won't need to download this image again.  The Docker daemon is smart enough to use the existing image.

Once the image has been built, you can check to see it by running;
sudo docker images
This will give you a list of the images currently on your system.  At the very least, you should see a listing for debian and a listing for your newly created sabnzbd image.

Now that your image has been created, let's fire it up with the following command (this assumes you used the default options from the build in the previous article);
sudo docker run -v /etc/downloaders/sabnzbd:/etc/downloaders/sabnzbd -v /export/Downloads:/export/Downloads -v /etc/localtime:/etc/localtime:ro -p 8080:8080 --name=sabnzbd -d --restart=always sabnzbd
Yep, it's a pretty long command.  Let's examine the components of the command.

sudo docker run
This is pretty straightforward -- we're instructing the docker daemon to run a new container.
-v /etc/downloaders/sabnzbd:/etc/downloaders/sabnzbd
The -v parameter is used for allocating volumes.  During the build, we specified a volume for config files.  During execution, we map the path /etc/downloaders/sabnzbd on the host system (ie, on the left hand side of the colon), to /etc/downloaders/sabnzbd in the container (ie, on the right hand side of the colon).  With this mapping, anything stored inside the container in this directory path will ALSO be available on the host.  And these files will continue to reside on the host, even if the container is stopped or destroyed.

The -v parameter can be called multiple times from the command prompt.  We call it once to map the config directory, and then a second time to map where we store our downloads (ie, /export/Downloads).  I've also chosen to map the file /etc/localtime on the host to /etc/localtime in the container.  This helps to keep the clock on the host synchronised with the clock inside the container.  The container doesn't need to change localtime, so it's mapped using the option ro which basically means it is mapped as "read only".
-p 8080:8080
The -p option maps ports on the host system, with ports on the container.  When we built our sabnzbd image, we configured it to listen to the port 8080 (which is the default port that sabnzbd listens on).  However, traffic on the 8080 port won't reach the container, unless it is directed there by the Docker daemon.  This option basic tells the Docker daemon to listen on port 8080, and then redirect it to port 8080 inside the container (where sabnzbd is listening).  The ports don't necessarily have to match... Docker could listen on port 8000, and redirect to 8080.  But for the sake of simplicity, we'll leave them matching.
--name=sabnzbd
This option basically names out new container "sabnzbd".  If we don't specify a name, the Docker daemon randomly assigns one.
-d
This instructs the Docker daemon to run our new container in the background.
--restart=always
The --restart option if and when to restart the container in the event that it shuts down.  By specifying "always", the Docker daemon will start our container on reboot, or if the container crashes for whatever reason.  However, if you deliberately stop the container, it will stay stopped.  Keep in mind, that the application running inside the container might stop (or crash), but the container itself will continue to run.  Docker will only restart if the container itself crashes.  This is something you need to be mindful of -- if you shutdown sabnzbd from the GUI, the application won't automatically restart.  You'll need to go into the running container and restart the application, OR, you need to stop the container and restart it... at which point, our Start script will run.

After running the sabnzbd container, we should be able to check and see it running by using the following command;
sudo docker ps
This gives you a list of all containers running, and a little bit of information about them.  Hopefully, if you've followed the commands from Part 1 and 2 of this guide, sabnzbd should be running.  You can now point your browser to your server, and it should be waiting for you.



No comments:

Post a Comment