# Applications Management ## Release Creation Process To create a Release in Edgehog: 1. Navigate to the **Applications** section in the Edgehog web interface 2. Open the app for which you want to create a release 3. Click on **Create Release** action button 4. Fill in the release form: - **Version**: Enter a unique version number that follows the [Semantic Versioning](https://semver.org) spec - **Supported System Models**: Choose system model(s) which the release should support. If left blank, the release supports all devices 5. Add container(s) by clicking **Add Container** button (see [Container creation](applications_management.html#container-creation) for more details) 6. Click **Create** to create the release  ## Reuse Release Configuration Edgehog also let's you reuse existing containers and their configurations from the same or some other application. To reuse a Release: 1. Click on **Reuse Release** button in the Create Release page 2. Choose application and release from which you want to copy containers and their configurations 3. Click **Confirm** to import release configuration  ## Container Creation By clicking the **Add Container** button on the **Create Release** page, a form for specifying container configuration is displayed. The form is organized into logical sections: - **Image Configuration** - **Network Configuration** - **Storage Configuration** - **Resource Limits** - **Security & Capabilities** - **Runtime & Environment** - **Device Mappings** Below is an overview of each section. #### **Image Configuration**  Specify the image that will be used to run the container. - **Image Reference** – represents the name of the image to pull. It follows the pattern: ``` [registry-host[:port]/][image-repo/]image-name[:(tag|digest)] ``` For more details, refer to [Images](containers_core_concepts.html#images) - **Image Credentials** – Select credentials if the image is stored in a private registry. For more details, refer to [Image Credentials](containers_core_concepts.html#image-credentials) #### **Network Configuration**  Define how the container connects to networks. - **Hostname**: refers to the name a container (or host) uses to identify itself on the network and in its own environment. If you don’t set anything, a container’s hostname defaults to its container ID. - **Network Mode**: controls how a container is connected to networks and what network namespace it uses. When network_mode is set, networks: is not allowed . - **Networks**: Attach the container to one or more previously created networks. For more detailed information on creating and managing networks, refer to the [Network Management](./network_management.md) page. - **Extra Hosts**: Adds entries to the container’s /etc/hosts file so name resolution for those hostnames bypasses DNS and uses the IPs you specify. Format is `HOSTNAME:IP`. Special value host-gateway resolves to the host’s internal IP. - **Port Bindings**: Port bindings control how ports inside a container are made accessible on the host and beyond. By default, a container’s ports are not accessible from the host; they’re only reachable from the host itself and containers on the same bridge network. To make a port reachable from outside the host (or from other networks), you must publish it. #### **Storage Configuration**  Configure volumes and bind mounts. - **Bind Mounts**: Map host directories into the container. Lets both host and container see and modify the same files. - **Volumes**: Docker-managed storage that persists data independently of the container lifecycle. For more detailed information on creating and managing volumes, refer to the [Volumes management](./volume_management.md) page. - **Volume Driver**: Driver that container uses to mount volumes - **Storage Options**: allows for specifying storage driver options when creating a container. The specific options available depend on the storage driver being used. - **Tmpfs Mounts**: an in‑memory filesystem: data is stored in the host’s RAM (and possibly swap), not on disk, and disappears when the container stops. - **Read-only Mode**: makes the container’s root FS read-only; the container can only write to: - tmpfs mounts - volumes / bind mounts you explicitly attach #### **Resource Limits**  Set performance and usage restrictions for the container. - **Memory**: Defines the maximum amount of **RAM (in bytes)** available to processes in the container. The minimum allowed value is **6 000 000 bytes** (≈6 MiB). - **Memory Reservation**: A _soft_ memory limit, also specified in **bytes**. It serves as a hint to Docker and the kernel about how much memory the container should typically use. - It must always be **less than the hard Memory limit**. - The container can still use memory up to the hard limit. - When the host is under memory pressure, Docker attempts to reclaim memory so that the container stays near or below the reservation value. - **Memory Swap**: Defines the total amount of **RAM + swap**, in **bytes**. This value only has effect if **Memory** is also set. **Rules:** - If **Memory Swap** is **set to a positive integer**: - **Memory** must also be set. - **Memory** = maximum RAM (bytes). - **Memory Swap** = total (RAM + swap), in bytes. **Example:** ``` Memory = 314572800 bytes (≈300 MiB) Memory Swap = 1073741824 bytes (≈1 GiB) ``` → Total allowed = 1 073 741 824 bytes → Swap size = 1 073 741 824 − 314 572 800 → ≈ 758 MiB of swap. - If **Memory Swap = 0** → Ignored; treated as **unset**. - If **Memory Swap = Memory** and Memory > 0 → Container has **no swap access** (RAM only). - If **Memory** is set and **Memory Swap is unset** → Total allowed memory = **Memory × 2**, half RAM, half swap. **Example:** ``` Memory = 314572800 bytes ``` → Total = 629 145 600 bytes → 314 572 800 RAM + 314 572 800 swap. - If **Memory Swap = -1** → **Unlimited swap**, up to the host’s available swap space. * **Memory Swappiness**: controls how aggressively the kernel swaps out anonymous memory pages used by a container. It’s a percentage between 0 and 100. - `0` – turn **off** anonymous page swapping for the container. - `100` – allow **all** anonymous pages to be swappable (most aggressive swapping). - If not set – the container **inherits** the host’s swappiness value. * **CPU Period**: sets the **CFS (Completely Fair Scheduler) period** for a container: the length of each CPU scheduling window, in microseconds. It’s used together with `CPU Quota` to control how much CPU time a container can use in each period. - Default: `CPU Period = 100_000` (100 ms). - `CPU Quota` is the number of microseconds of CPU time allowed per period. - Effective CPU share = `CPU Quota / CPU Period`. * **CPU Quota**: sets a **hard upper limit on CPU time** a container can use per CFS period (used with `CPU Period`). * **CPU Real-Time Period**: configures the **real‑time scheduler period** for a container, in microseconds. It works together with `CPU Real-Time Runtime` and requires special kernel/daemon setup. - It sets the **length of the real‑time scheduling period** for a container. - `--cpu-rt-runtime` then specifies how many microseconds within that period the container may run at real‑time priority. - Both values **cannot exceed** the limits configured on the daemon/parent cgroup, and require the host kernel to support real‑time scheduling with `CONFIG_RT_GROUP_SCHED`. #### Requirements To use `--cpu-rt-period`/`--cpu-rt-runtime`: 1. Kernel must have `CONFIG_RT_GROUP_SCHED` enabled. 2. Docker daemon must be started with real‑time runtime configured, e.g.: ```bash dockerd --cpu-rt-runtime=950000 ``` * **CPU Real-Time Runtime**: See explanation for `CPU Real-Time Period` #### **Security & Capabilities**  Control container privileges and security-related settings. - **Privileged Mode** – gives a container almost the same power as the host, bypassing most isolation. Use it only when absolutely necessary. Makes these changes for the container: - Enables **all Linux kernel capabilities** (no capability dropping). - Disables the **default seccomp** profile. - Disables the **default AppArmor** profile. - Disables the **SELinux process label**. - Grants access to **all host devices**. - Makes `/sys` **read‑write**. - Makes **cgroups mounts read‑write**. In other words, the container can then do almost everything the host can do. Recommended practice: Avoid --privileged for normal workloads. Prefer adding only the specific capabilities you need with `Cap Add`. - **Cap Add**: add specific Linux kernel capabilities to a container, instead of giving it full privileges with `Privileged`. For list of available capabilities refer to the [Docker Documentation](https://docs.docker.com/engine/containers/run/#runtime-privilege-and-linux-capabilities) - **Cap Drop**: Remove default capabilities. #### **Runtime & Environment**  Set runtime behavior and environment variables. - **Restart Policy** – Define what happens if the container exits. Supported policies: - `No` (default)\ Don’t automatically restart the container. - `On Failure`\ Restart only if container exits with a non‑zero status. - `Always`\ Always restart if the container stops.\ If manually stopped, it’s restarted only when the Docker daemon restarts or you manually start it again. - `Unless Stopped`\ Like `always`, except if the container is stopped (manually or otherwise), it isn’t restarted after a Docker daemon restart. - **Environment Variables** – JSON array of environment variables in `"key": "value"` format #### **Device Mappings**  Expose specific host devices to the container. - **Device Mappings** – Map host devices into the container (e.g., `/dev/ttyUSB0`). Useful for hardware-dependent workloads. > **Note:** On the right side of every field there is  icon. Hovering over it displays a short tooltip explaining the purpose of that field.