Single application
Bridge and DHCP or a fixed CIDR address are chosen. The LXC has an address of its own and the summary shows the complete URLs of the services.
What lives in the rootfs, what survives its replacement, how data is shared between containers and how each container gets its address.
Persistence is decided before the LXC exists
The template supplies the paths the application needs. Each one is placed on a container disk or on a host directory, and more paths can be added before the summary.
/config, /data, libraries, downloads and every volume the application declares are listed.
Each path is placed on a disk of the container or on an existing host directory.
A container disk is created on a Proxmox VE storage with the size given. The default installation asks once for the storage of the container and its data when the node has more than one; the advanced installation asks the storage of each path right before its size and proposes the one of the rootfs. It appears as vm-VMID-disk-N and is attached as mpN.
A host directory is given by its path. A directory that does not exist is created, owned by the user the container maps.
More pairs of host path or volume and container path can be added before installing.
The complete mapping is shown before the CT is created and is stored in its instance contract.
| Property | Container disk | Host directory |
|---|---|---|
| In the configuration | mpN: STORAGE:vm-VMID-disk-N,mp=/config,backup=1,size=16G | mpN: /mnt/oci-shared/media,mp=/data/media |
| Container backup (vzdump) | Included, with backup=1 | Not included |
| Size | Fixed; grown with a resize of the mount point | The free space of the host filesystem or dataset |
| Other containers | Mounted only by its own container | The same directory can be mounted in several containers |
| Snapshots and restore | Managed by Proxmox VE together with the CT | Managed on the host storage |
| Removing the application | Deleted with the container | Kept, with its content |
| Moving the CT to another node | Moves with the CT | The same path has to exist on the other node |
The rootfs is reserved for the binaries and the content of the image. An update or a recreation replaces it without touching either kind of mount point.
A host directory is mounted with everything the host has mounted inside it. A directory such as /mnt/pve shows its network shares, disks and datasets in the container, and what the host mounts or unmounts there later appears or disappears without restarting the container. A directory added as read-only is read-only together with what is mounted inside it when the container starts. A filesystem the host mounts afterwards arrives with the permissions the host mounts it with, and becomes read-only as well when the container is restarted.
rootfs: local-lvm:vm-151-disk-0,size=8G # Container disk, part of the CT backup mp0: local-lvm:vm-151-disk-1,mp=/config,backup=1,size=16G # Host directory, outside the CT backup mp1: /mnt/oci-shared/media,mp=/data/media
An update or a recreation replaces only the rootfs: mp0 keeps users, libraries and settings, and mp1 keeps showing the same media. Restoring the CT backup brings back /config; the media directory is restored, if needed, from the backup of the host storage.
The application sees the path the image publishes; only where it is stored changes.
The Rclone application of the catalog offers, besides its installation, Enable a mount on an existing Rclone OCI container. It mounts a remote already created and authorised in the Rclone web UI and publishes it on the host, where other containers can use it as a host directory.
The VMID of the Rclone container, the exact name of the remote and, optionally, a path inside it.
The name of the mount and the VFS cache mode: off, minimal, writes or full (default).
A common root, /mnt/oci-shared by default, holds a read/write view in /mnt/oci-shared/remotes/NAME and a read-only view in /mnt/oci-shared/remotes-ro/NAME.
After a confirmation, the CT is stopped, its start command and a Proxmox VE hookscript are set, and it is started again. The operation waits until both views are mounted on the host.
If the mount does not come up
A single application needs an address. A multi-container application also needs a stable network between its members.
Bridge and DHCP or a fixed CIDR address are chosen. The LXC has an address of its own and the summary shows the complete URLs of the services.
A free subnet is found, a persistent private bridge is created and each member (application, database, cache) gets a fixed address on it.
Dependencies talk over the private network and have no address on the LAN.
The stack contract stores bridge, subnet, addresses and the relations between services. Updating the application reuses the same topology for every member. ProxMenux Monitor opens the main container at its LAN address, not at its address on the private network.
| Element | In the CT vzdump | Where it is kept |
|---|---|---|
| OCI rootfs | Yes | The CT backup; it can also be rebuilt from the image and the contract |
Container disk with backup=1 | Yes | The CT backup |
| Host directory | No | The backup of the host storage |
| Instance contract | Yes, the copy carried inside the CT | /.proxmenux/oci-record.json inside the CT; additional host and cluster copies are kept separately |
| Multi-container application | Each member in its own backup | The backups of every member, plus the stack contract and its bridge on the host |