Differences

This shows you the differences between two versions of the page.

--- docs_in_draft:docker_compose [2025/12/07 07:51] – [Docker in OMV 8] chente
+++ docs_in_draft:docker_compose [2025/12/07 12:56] (current) – removed chente
@@ Line 1: / Line 1: @@
-<html><center><span style="color:#b7620b;font-size:300%;">Incomplete Document</span></center></html>
-<html><center><span style="color:#b7620b;font-size:300%;">Not for public use</span></center></html>
-{{ :underconstruction.jpg?400 |}}
-\\
-----
-<html><center><span style="color:#000066;font-size:300%;">Docker in OMV 8</span></center></html>
-\\
-[[omv7:docker_in_omv|{{ :omv7:dockeromv7-1.png?direct&600 |Docker in OMV 8}}]]
-----
-\\
-\\
-====== Docker in OMV 8 ======
-\\
-\\
-===== Summary =====
-\\
-\\
-[[https://forum.openmediavault.org/|{{ :omv7:dockeromv7-2.jpg?direct&200|Go to -> OMV forum}}]]
-**This document establishes a method to successfully install any application on OMV using Docker.**
-The [[https://forum.openmediavault.org/|OMV forum]] is a bi-directional tool. Provides users with solutions to their problems. It provides developers with information about user problems and allows them to implement appropriate solutions in software and methods.
-In the case of Docker, the forum has received numerous queries about very diverse problems. Based on that forum experience, this document offers a simple method for configuring Docker that fixes the vast majority of these problems before they arise.
-\\
-\\
-**Index:**
-  * [[omv7:docker_in_omv#what_is_docker|What is Docker.]]
-  * [[omv7:docker_in_omv#user_and_permission_management_in_docker_and_omv_more_security|User and permission management in docker and OMV. More security.]]
-  * [[omv7:docker_in_omv#install_and_configure_docker|Install and configure Docker.]]
-  * [[omv7:docker_in_omv#configuring_a_container_step_by_step_jellyfin|Configuring a container step by step (Jellyfin).]]
-  * [[omv7:docker_in_omv#examples_of_configuration_of_some_containers|Examples of configuration of some containers.]]
-  * [[omv7:docker_in_omv#some_basic_procedures_for_container_management|Some basic procedures for container management.]]
-  * [[omv7:docker_in_omv#the_whys|The whys.]]
-\\
-----
-\\
-===== What is Docker =====
-\\
-\\
-[[https://www.docker.com/resources/what-container/|{{ :omv7:dockeromv7-3.png?direct&200|Go to -> www.docker.com}}]]
-//" A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.//
-//Container images become containers at runtime and in the case of Docker containers – images become containers when they run on Docker Engine. Available for both Linux and Windows-based applications, containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging. "//
-\\
-\\
-** That's all very well, but... :-) What the hell is docker? :-) **
-\\
-\\
-\\
-[[omv7:docker_in_omv#what_is_docker|{{:omv7:dockeromv7-4.png?direct&300 |What?}}]]
-That definition is very good and very professional, but it is of little use to people on the street, so we will try to explain in an easier way what docker is and how it works. **If you are an experienced docker user you will probably want to skip this part**. If this is your first time using docker, keep reading.
-Docker is a system that allows you to run an application within your server as if it were an independent and isolated system. It has its own processes, its own file system, and its own networking, all independent of the main (host) server. The container cannot access the host's file systems or network, and vice versa. This is why we say that it is isolated, and way it cannot damage your system. It is safe.
-Docker is quite similar to a virtual machine, but with one key difference: a virtual machine includes a complete operating system, with its own kernel, drivers, and services. Docker, on the other hand, does **not** run a complete operating system. Instead, it uses the host's kernel and only isolates the container's processes, network, and file system.
-Because of this, containers consume far fewer resources and start up in a matter of seconds, although their isolation is not as deep as that of a traditional virtual machine.
-**This makes containers designed for different architectures**. A container designed for Raspberry PI (ARM architecture) will not work on an Intel/AMD system (amd64 architecture) and vice versa. You should keep this in mind when choosing a container to install on your system.
-Many modern containers include multiple architectures, and Docker will automatically select the correct one. However, not all images support this, so it is important to verify that the image is compatible with your architecture.
-At this point it is good to remember that the **32-bit architecture is obsolete**, little by little 32-bit containers are disappearing. OMV 8 no longer works on 32-bit systems, so **if you were able to install OMV 8, your system is 64-bit**. This simplifies things considerably: when installing a container, always make sure to choose the 64-bit version, which is the one that corresponds to your system. In most cases, Docker automatically selects the correct image version, but not always. If an image offers several variants, choose the one labeled amd64 or x86_64, which are the common names for 64-bit systems.
-[[omv7:docker_in_omv#what_is_docker|{{ :omv7:dockeromv7-17.jpg?direct&200|32-bits}}]]
-The operation of docker is very simple. Someone on the Internet packages a system into a file we call an **image**. This image contains the necessary packages for the application we want to use to work. Docker downloads that image, installs it on our server and runs it. We already have a **container** working.
-Now the creator of that image does the corresponding maintenance and publishes a new updated image. Docker is responsible for downloading it automatically and replacing the one we had with the new one. Docker runs it and we have our container updated and working.
-So far so good. But now we want to configure certain information in our application, for example a password to access that application. We could "enter" the container and make that configuration by writing to the ''/folderpass/password'' file inside the container. That would work, but on the next image update that ''/folderpass/password'' file will be overwritten and the settings will be lost. To solve this Docker allows **folder mapping**.
-Mapping a folder means that Docker will make a configuration such that when the container writes to the ''/folderpass/password'' file it will actually be writing to an external folder, a folder located on our server file system. This way, when we update the container image, all its files will be overwritten except ''/folder/password'', since this folder is not in the container but in the file system of the host server, and when the container is running it will be able to continue reading the password that we have stored in our server file system. As an added bonus, mapping a folder makes it easier to manipulate the files in that folder from the server without needing to enter the container.
-In the same way that Docker maps folders it can also **map network ports**, we can map port 3800 that the container uses internally to any port on our server, for example 4100, the container will send data packets to port 3800 internally but Docker will that these packets be sent through port 4100 of our server.
-[[omv7:docker_in_omv#what_is_docker|{{:omv7:dockeromv7-18.jpg?direct&300 |PUID Explained}}]]
-**We can also map users**. And this is important to understand. The container will work internally as //root//, but we can make that user be another user on the server, for example the user //superman//. From that moment on, everything the container does to the mapped files or ports will not be done by //root//, it will be done by //superman//. That allows us to restrict the permissions of that container, we only have to restrict the permissions of the //superman// user of our system. We will give the user //superman// write permissions to the ''/folderpass/password'' file on our system so that he can write or modify that file but we will not give him permissions to write to any other folders. In this way we ensure that the container remains isolated.
-To define all these container configurations the **openmediavault-compose plugin uses docker-compose** for its simplicity. Using a configuration file of a few lines we define the mappings and other configurations of a container and then we execute it.
-To map a user we define the PUID value, the user's identifier, and to map the group it will be the PGID value, the group's identifier. In the OMV GUI we can see the PUID value for each user in the USERS > USERS tab by opening the UID and GID columns using the icon at the top right. So if the user //superman// has the values 1004 and 100, in the compose file we would do something like this:
-''- PUID=1004''
-''- PGID=100''
-The way to map a folder (**volume**) in docker-compose is something like this:
-''- /srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/folderpass:/folderpass''
-That could be one of the lines in the compose file that defines a container. This line is divided into two parts. To the left of the '':'' we have ''/srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/folderpass'' which is the path of a real folder on our server, in our file system. On the right of the '':'' we have ''/folderpass'' which is the path of a folder within the container, in its own file system.
-<html><body><table width="100%" border="0"><tr><td colspan="2" style="background-color:#69A5FF;height:30px;"><strong><span style="color:#FFFFFF;font-size:110%;">&#160;
- Beginners Info
-</span></strong></td></tr><tr><td style="background-color:#E6FEFF;height:25px;width:380px;">
-All that long string of numbers is the path of one of our disks on the server and inside that disk we have an appdata folder and inside we create the folderpass folder<br>
-Filesystem mount paths are usually in the /srv folder and the following folder contains a uuid to uniquely identify that drive. That folder is the mount folder for that hard drive. You should never modify the permissions of that folder or use it to create a shared folder. Create a folder inside to use as a shared folder.
-</tr></table></body></html>
-From now on, every time the //root// user of the container writes to its ''/folderpass'' folder, what will really be happening is that the //superman// user will be writing to our ''/srv/dev-disk-by-uuid-9d43cda9-20e5-474f-b38b-6b2b6c03211a/appdata/folderpass'' folder from our server. The content of that folder is what we call **persistent data**. Naturally we must give permission to the //superman// user on our server to write to that folder or the container will throw an error.
-The advantage of all this is that the container is limited to writing to that folder. We could be unlucky enough to download an image that has harmful code inside. Or if that container was exposed to the internet and had a security hole, perhaps it could be hacked. In this case the hacker could take control of the //root// user of the container. The advantage is that that //root// user on our system is actually the //superman// user, and in this case, no matter how superman he is, he can only write to the ''/folderpass'' folder, so he cannot access our server in any way. The user //superman// does not have permissions to write or read any other files on our server. Contained threat.
-Conclusion. **Never map the container user to the //root// user of the server**, unless it is absolutely necessary and the container developer is fully trusted. If there were a security hole in that container, your server would be at the mercy of the hacker, since they would have permissions for everything. Related to this, **never include the user running a container in the //docker// group**, this is another story but any user in the docker group can gain //root// access to the system by escalating permissions.
-If you're reading this, it's probably your first time using Docker. Docker may seem complicated at first glance, but once you get over the initial learning curve, setting up and installing a container literally takes less than 30 seconds. Keep going.
-----