How to use delegated data set for docker volume?

[Adel-Magebinary]

Hi guys,

Just wandering, is it possible to use a delegated dataset with a Docker volume? It will help us a lot when deploying services like Minio or other web applications, so we don't need to pull the code / other media assets all the time.

Can delegated dataset support be fully implemented in Triton-docker via docker volume create -d triton -o delegate_dataset=true as per RFD 0044? Is there documentation or an environment flag required to enable it if already implemented?

Thanks,
Adel.

[danmcd]

A delegated dataset creates a child dataset of a zone that is in control of the zone.

If you're sharing across multiple zones on the same CN, you could use lofs, but that's not triton-managed today. Your stated use case of not needing to pull code/media-assets/etc. upon zone creation suggests you might want that. Of course, if your docker volumes span multiple CNs, each CN might need a copy of the assets, etc. Unless of course you're comfortable lofs-mounting an NFS mount that originates in the global zone.

[Adel-Magebinary]

Hello @danmcd, thanks for replying to me so quickly. Here is our use case on the same CN.

Our goal is to persist data storage inside the compute node (CN) across container upgrades, restarts, or removals without wasting switch bandwidth or dealing with NFS volume performance.

1. Create the Volume (once)

This step provisions the ZFS dataset under its own UUID and makes it reusable:

triton-docker volume create \
  --driver=triton_delegate_dataset \
  --name=minio-data-client-a

• This volume now exists independently.

• Triton allocates a separate dataset under something like:

  /zones/<volume-uuid>/delegates/minio-data-client-a
  

• It is not tied to any one container and is not destroyed when containers are removed.

---

2. Run or Re-run Docker Containers

Attach the independent volume to a docker container, even new ones (Docker API will locate the volume location first to determine the CN.):

triton-docker run -d \
  --name minio-client-a \
  -e MINIO_ACCESS_KEY=minio \
  -e MINIO_SECRET_KEY=minio123 \
  --mount source=minio-data-client-a,target=/data \
  minio/minio:**RELEASE.2024-04-26T00-00-00Z** server /data

3. Upgrade Containers Safely

Just remove and recreate containers without touching the volume:

triton-docker rm -f minio-client-a

triton-docker run -d \
  --name minio-client-a \
  -e MINIO_ACCESS_KEY=minio \
  -e MINIO_SECRET_KEY=minio123 \
  --mount source=minio-data-client-a,target=/data \
  minio/minio:**RELEASE.2025-05-05T00-00-00Z** server /data

✅ This preserves /data content across upgrades without the switch / nic bandwidth and still performs native zfs IO performance on the same compute node. (imagine the /data is 10TB...)

Note that triton may need to locate the container CN by querying the delegated volume location first to ensure the container lands on the same CN as the volume.

---

[Adel-Magebinary]

If Triton can support the above use case, it will be a life-changing feature for us 👍