Docker is a technology that allow users to provide each application with it’s own isolated operating Linux environment, isolating compatibility or coexistence conflicts with other applications. If you want more information on docker and its underlying technology than is provided in this guide then you should visit the docker web site.
Using Docker Unraid can run any Linux application regardless of the distribution format as long as it is available as a Docker container. That means whether an app was written for Ubuntu, CentOS, Arch, Red Hat, or any other variant, Unraid can run it. This is accomplished through the use of Docker Containers, which allows each application to be provided with it’s own isolated operating environment in which it cannot create software compatibility or coexistence conflicts with other applications. This also means that the application is isolated from the hosting Unraid system so that it is not affected by new releases of Unraid, and conversely it will not install software components into Unraid that might lead to system instability
- A system up and running with unRAID 6 and are connected via a web browser to the UnraidD webGui
- A share created called “appdata” that will be used to store application metadata.
NOTE: Applications are made available and supported by both the Docker and unRAID user communities respectively.
Adding Applications as Containers
By default, you will have access to any and all applications that Lime Technology publishes to its public Docker repository. To add them to your system, perform the following steps:
- Click Add Container on the Docker tab in the webGui.
- Click the Template drop down and select an application.
- Read the description and instructions for using this application.
- Click Create to begin downloading the application to your system as a Docker container.
To gain access to a wider set of applications, see this post in the Lime Technology forums for information on installing the Community Applications plugin. This plugin will allow you to add more applications to your system through an app store interface.
NOTE: The applications available on this store come in multiple forms (containers and plugins) and are not directly supported by Lime Technology. Support for community maintained Docker containers can be found in the Docker Containers subforum.
If the Bridge type is selected, the application’s network access will be restricted to only communicating on the ports specified in the port mappings section. If the Host type is selected, the application will be given access to communicate using any port on the host that isn't already mapped to another in-use application/service. Generally speaking, it is recommended to leave this setting to its default value as specified per application template.
Applications can be given read and write access to files on the host by mapping a directory path from the container to a directory path on the host.
When looking at the volume mappings section
- The Container volume represents the path from the container that will be mapped.
- The Host path represents the path the Container volume will map to on your Unraid system.
- The Access Mode specifier what the container can do with the files/folders to which it has been given access. It is good practice to give the most restrictive access that is consistent with the container being able to run successfully.
Clicking on the Edit button brings up a dialog allowing you to alter a volume mapping. Clicking inside the resulting fields provides a “picker” that will let you navigate to where the mapping should point.
For applications that are installed via Community Applications (i.e. the Apps tab) then you are typically provided with many of the settings for a particular container pre-set to sensible values. You should review these as being what you actually want on your system. Additional mappings can be manually created by clicking the Add another Path, Port, Variable, Label or Device option.
Note that this means that the path to any particular file/folder can be different when viewed from insides the container to that when viewed from the host level.
All applications should require at least one volume mapping to store application metadata (e.g., media libraries, application settings, user profile data, etc.). The expectation is that all dynamic data will be configured to exist outside the container (although docker does no make this mandatory) so that the docker image file ends up only containing all the binaries associated with the docker container and none of the variable data.
Most applications will need you to specify additional mappings in order for the application to interact with other data on the system (e.g., with Plex Media Server, you should specify an additional mapping to give it access to your media files). It is important that when naming Container volumes that you specify a path that won’t conflict with already existing folders present in the container. If unfamiliar with Linux, using a prefix such as “unraid_” for the volume name is a safe bet (e.g., “/unraid_media” is a valid Container volume name).
Special points to note when setting up volume mappings are:
- Path names are case significant both at the host level and the container level.
- Container paths should start with a / character. If this is omitted the path is a realise path so it will not be clear where inside the container the path can be found.
- If you are setting up a mapping that will use an Unassigned Device at the host level then it is important that you set the Access Mode to use on if the Slave access modes. If you do not do this then dynamic paths nay not be seen until the docker sub-system is restarted.
Host paths mentioned in a container's volume mappings are created when the container starts if they do not already exist. If you find that you get unexpected folders appearing at the Unraid level then this can be a good indication that you have got a container mapping wrong and so the folder gets recreated every time the container is run.
When the network type is set to Bridge, you will be given the option of customizing what ports the container will use. While applications may be configured to talk to a specific port by default, we can remap those to different ports on our host with Docker. This means that while three different apps may all want to use port 8000, we can map each app to a unique port on the host (e.g., 8000, 8001, and 8002). When the network type is set to Host, the container will be allowed to use any available port on your system. Additional port mappings can be created, similar to Volumes, although this is not typically necessary when working with templates as port mappings should already be specified.
IMPORTANT NOTE: If adjusting port mappings, do not modify the settings for the Container port as only the Host port can be adjusted.
Container Creation Process
With your volume and port mappings configured, you are now ready to create your first Docker container. Click the Create button and the download process will begin. A few things worth noting while the image is downloading:
- After clicking Create, do not close your browser window or attempt to navigate to other tabs using the browser until the download is complete.
- Initial downloads per template repository may take longer than subsequent downloads per repository.
- When the download process completes, you can click the Done button to return to the Docker page and continue adding applications.
Controlling container startups
The default behaviour when stating up the Docker sub-system is to simply attempt to start all the Docker containers that are listed on the Docker tab to be auto-started as fast as possible in the order they are listed.
There are times when the order in which containers are started and their timing with relation to other containers becomes important.
Example cases that spring to mind are:
- Starting a container running a database before any application that attempts to use it is started.
- Starting a container that runs a specialist network link (e.g. a VPN) before any other container attempts to use it.
You can alter the container start-up behaviour from the default in the following ways:
- Changing the order:
- The simplest capability is to simply change the order in which the docker containers are listed on the Docker tab. If you use a mouse to click-and-hold on the container name then you will find that you can use drag-and-drop to move the container to another position in the list.
- Adding wait times:
- If simply changing the startup order is not sufficient because some containers take a while to finish their startup process then you can also add delays into the start-up sequence. You can do this by the following steps.
- Switch to Advanced View using the toggle at the top right.
- A wait field will appear in the AutoStart column. It will initially be set to 0 indicating no delay before starting the next container.
- Enter a value into the wait field indicating the delay (in seconds) to be used before attempting to start the next container in the list. That gives this container time to finish its startup process. Yoou may have to do some trial-and-error to determine what are appropriate values for this wait time.
Using these mechanisms should allow you to control the container startup process to achieve the results that you want.
Controlling Your Application
Once the download is complete, the application is started automatically. To interact with your application, we begin by clicking on the icon visible on the Docker page of the unRAID web interface. Doing so will make a context menu appear with multiple options:
- Most apps added through Docker will have a web interface that you can access to configure and use them, but not all.
- Clicking this option will launch a new browser tab/window directly to the applications web interface.
- For apps that do NOT have a web interface, read the description when adding the container for instructions on how to make use of the app once it’s running.
- This option only appears after clicking Check for Updates (if available).
- This will toggle the active state of the container.
- If you are having difficulties with your application, useful information may be present the application’s log.
- Logs for applications are stored separately from unRAID’s system log itself.
- Container settings such as port and volume mappings can be changed by clicking this option.
- Once changes are applied, the container will start automatically, even if it is stopped initially.
- Enable/Disable autostart
- Toggling this will change the default behavior of the application when the Docker service is started.
- Allows you to remove either the entire application, or just the container.
- Removing a container without it’s “image” will make adding the application again later a much faster process (as it will not need to be redownloaded).
Accessing a Volume Mapping Inside a Container
One of the first things you will do after your application is running will be to configure it. Configuration typically will involve specifying storage locations from within the applications web interface. When doing so, remember to look for the volume mappings you defined when adding your container. For example, if I needed to specify a folder path in the BT Sync app that would point to my Media share, I would specify the path of “/unraid_media” in the applications interface, as depicted below.
Other Tips and Tricks
Using Docker containers to run applications on unRAID is incredibly easy and very powerful. Here are some additional tips to improve your experience:
- Using a cache device or pool for storing your Docker virtual disk image and application data can improve performance.
- Run multiple instances of the same app at the same time, which is useful for testing out alternate versions before upgrading.
- Click the Advanced View toggle on the top right when viewing the Docker page or adding applications to see additional configuration options.
- Learn more about Docker containers from our helpful user community.