omv6:docker_in_omv

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
omv6:docker_in_omv [2023/10/15 12:08] – [4. Create the user "appuser"] chenteomv6:docker_in_omv [2024/04/27 17:17] (current) chente
Line 1: Line 1:
-<html><center><span style="color:#000066;font-size:300%;">Docker in OMV</span></center></html>+{{indexmenu_n>8}} 
 +<html><center><span style="color:#000066;font-size:300%;">Docker in OMV 6</span></center></html>
 \\ \\
- +<html><center><span style="font-size:150%;"> 
-[[omv6:docker_in_omv|{{ :omv6:dockeromv10.jpg?direct&400 |Docker in OMV}}]]+<b>Link to</b> → <a href="https://wiki.omv-extras.org/doku.php?id=omv7:docker_in_omv">Docker in OMV 7</a><br> 
 +<br/></span></center></html> 
 +[[omv6:docker_in_omv|{{ :omv6:dockeromv10.jpg?direct&400 |Docker in OMV 6}}]]
  
 ---- ----
 \\ \\
 \\ \\
-====== Docker in OMV ======+====== Docker in OMV ======
 \\ \\
 \\ \\
Line 49: Line 52:
 Docker is a system that allows you to run an application using the main resources of the system but in such a way that it does not have the capacity to modify (damage) the existing system. The operation is similar to a virtual machine but lighter. Docker is a system that allows you to run an application using the main resources of the system but in such a way that it does not have the capacity to modify (damage) the existing system. The operation is similar to a virtual machine but lighter.
  
-It is based on packages (**images**) that are usually created by a third party and downloaded from a remote repository. Using docker-compose we create a **compose file** that allows us to configure various parameters to define and create a **container** from that image. For example, the access ports to the application or the system folders that will be accessible to that container. If we run that compose file it will download the image and create the container following the instructions we have given it.+Docker can be run from the command line directly. A single command with the right parameters will do all the work. Docker-compose was developed to make it easy to create that command and those parameters using easy-to-read configuration files. The openmediavault-compose plugin uses docker-compose for container management. 
 + 
 +Docker is based on packages (**images**) that are usually created by a third party and downloaded from a remote repository. Using docker-compose we create a **compose file** that allows us to configure various parameters to define and create a **container** from that image. For example, the access ports to the application or the system folders that will be accessible to that container. If we run that compose file it will download the image and create the container following the instructions we have given it.
  
 The author of the image we have downloaded will usually do maintenance and at some point create another updated image, at which point we need to update our container. The way to update a container is to delete it and recreate it again by downloading a new updated image. To recreate it simply run the compose file again after removing the container. The author of the image we have downloaded will usually do maintenance and at some point create another updated image, at which point we need to update our container. The way to update a container is to delete it and recreate it again by downloading a new updated image. To recreate it simply run the compose file again after removing the container.
Line 87: Line 92:
 **data folder (or whatever you want to call it)** **data folder (or whatever you want to call it)**
  
 +  * There is no space in the plugin settings to define this or these folders. The GUI establishes a field where you define a folder to store the persistent data, the appdata folder defined in the previous section. If you use relative paths for this data, nothing else will be necessary. Then you can use this for another purpose, defining a path to the data folder that will make it easier for us to compose later. You can use this field as you see fit, this guide proposes using relative paths for persistent data and using this field to define the data folder.
   * In the plugin GUI this folder corresponds to the Shared folder field in the Data section in **Services** > **Compose** > **Settings**.   * In the plugin GUI this folder corresponds to the Shared folder field in the Data section in **Services** > **Compose** > **Settings**.
   * In many containers you will have the need to "tell" the container where the files it needs for its operation are, for example in Jellyfin we refer to movies, photos, etc. The plugin allows you to set a shared folder so that in the compose file we can refer to it using the ''CHANGE_TO_COMPOSE_DATA_PATH'' expression. This will allow easily reusable paths to be set in compose files.   * In many containers you will have the need to "tell" the container where the files it needs for its operation are, for example in Jellyfin we refer to movies, photos, etc. The plugin allows you to set a shared folder so that in the compose file we can refer to it using the ''CHANGE_TO_COMPOSE_DATA_PATH'' expression. This will allow easily reusable paths to be set in compose files.
Line 105: Line 111:
     * If the drive is fast, like an **SSD or nmve**, applications will run faster.     * If the drive is fast, like an **SSD or nmve**, applications will run faster.
     * Make sure you have **enough space**, the docker folder can take up a lot of space. 60GB may be an acceptable minimum depending on what you are going to install.     * Make sure you have **enough space**, the docker folder can take up a lot of space. 60GB may be an acceptable minimum depending on what you are going to install.
-    * **mergerfs** is not suitable for hosting the docker folder spanned across multiple disks. If you don't have alternatives you can use one of the disks in the pool instead of the pool to host the folder. If you want to do it this way create a folder in the mount path of one of the disks instead of using the pool path. This way the mergerfs logic will disappear from the docker procedures.+    * **mergerfs** is not suitable for hosting the docker folder spanned across multiple disks. If you don't have alternatives you can use one of the disks in the pool instead of the pool to host the folder. If you want to do it this way create a folder in the mount path of one of the disks instead of using the pool path. This way the mergerfs logic will disappear from the docker procedures. If you do this never use the mergerfs leveling tool, doing so will break docker.
     * **BTRFS and ZFS** have incompatibilities with docker. They can be used to host the docker folder but doing so requires additional actions. You can consult the docker documentation if you want to use these file systems, in both cases it can be solved by creating block devices.     * **BTRFS and ZFS** have incompatibilities with docker. They can be used to host the docker folder but doing so requires additional actions. You can consult the docker documentation if you want to use these file systems, in both cases it can be solved by creating block devices.
     * **NTFS** is prohibited. Docker won't work. Do not use NTFS to host docker folders or you will have permissions issues. Always use native Linux file systems.     * **NTFS** is prohibited. Docker won't work. Do not use NTFS to host docker folders or you will have permissions issues. Always use native Linux file systems.
Line 126: Line 132:
 ---- ----
  
-=== USER FOR DOCKER. appuser. ===+=== USER FOR DOCKER. appuser.  (or whatever you want to call it) ===
 {{ :omv6:dockeromv12.jpg?direct&300|hacker}} {{ :omv6:dockeromv12.jpg?direct&300|hacker}}
   * A user that will be in charge of executing the container, which we will call **//appuser//**.   * A user that will be in charge of executing the container, which we will call **//appuser//**.
Line 228: Line 234:
 === Why use global environment variables === === Why use global environment variables ===
  
 +  * If you change a path or any other variable that affects multiple containers, it is enough to vary this value in the global environment variables file. The value will change automatically in all containers. Useful if you change a data drive, or if you reinstall OMV and change routes, for example.
   * It is integrated into the plugin, it is enough to press a button to access the file to directly introduce the variables without doing anything else.   * It is integrated into the plugin, it is enough to press a button to access the file to directly introduce the variables without doing anything else.
   * They allow us to define a value once and all the containers that we create will use this value automatically.   * They allow us to define a value once and all the containers that we create will use this value automatically.
Line 346: Line 353:
 === 4. Create the user "appuser" === === 4. Create the user "appuser" ===
 \\ \\
 +{{ :omv6:dockeromv16.jpg?direct&400|UID-GID}}
   * In the OMV GUI go to **Users** > **Users** click on the **+Create** button   * In the OMV GUI go to **Users** > **Users** click on the **+Create** button
-    * Define **//appuser//** name+    * Define **//appuser//** name (or whatever you want to call it).
     * Assign password.     * Assign password.
-    * In the groups field we add it to the //users// group.+    * In the groups field we add it to the //users// group (He is probably already in that group, at the time of writing the OMV GUI does this by default).
     * Membership in that group should ensure that **//appuser//** has write permissions to the **//appdata//** and **//data//** folders. Check it. If not, make sure the folder permissions are 775, the owner is //root//, and the owner group is //users//. See [[misc_docs:nas_permissions|NAS Permissions In OMV]]     * Membership in that group should ensure that **//appuser//** has write permissions to the **//appdata//** and **//data//** folders. Check it. If not, make sure the folder permissions are 775, the owner is //root//, and the owner group is //users//. See [[misc_docs:nas_permissions|NAS Permissions In OMV]]
       * If you need to reset some permissions on your NAS you can use [[omv6:omv6_plugins:resetperms|Reset Permissions Plugin For OMV6]]. Do not modify the permissions of the **//docker//** folder.       * If you need to reset some permissions on your NAS you can use [[omv6:omv6_plugins:resetperms|Reset Permissions Plugin For OMV6]]. Do not modify the permissions of the **//docker//** folder.
Line 373: Line 380:
   * Replace the values ​​with the appropriate ones in your case.   * Replace the values ​​with the appropriate ones in your case.
     * You can see your local configuration in **System** > **Date & Time** in **//Time zone//** field.     * You can see your local configuration in **System** > **Date & Time** in **//Time zone//** field.
-    * You can see the values ​​of user appdata in **Users** > **Users** in the UID and GID columns.+    * You can see the values ​​of user //appuser// in **Users** > **Users** in the UID and GID columns.
   * In this case we don't need it since we have defined the DATA folder in the plugin GUI at **Services**>**Compose**>**Settings**. But if you need to define other different routes you can also do it here in the same way as the rest of the variables.   * In this case we don't need it since we have defined the DATA folder in the plugin GUI at **Services**>**Compose**>**Settings**. But if you need to define other different routes you can also do it here in the same way as the rest of the variables.
  
  • omv6/docker_in_omv.1697371680.txt.gz
  • Last modified: 2023/10/15 12:08
  • by chente