For quite a long time, I was running on TrueNas Scale 22.02.0.1. However, I noticed in the release notes of the next version (22.02.1), that the docker-compose binary would get disabled. Specifically, the changes in NAS-115010. However, my entire Docker 🐳 setup is based on it. Like Ixian already said on the TrueNas form (🔗 link), I don’t really want to learn about Kubernetes and Ingress. In particular, because I am pretty happy with my Traefik-managed “ingress” variant.

So I will ride the train 🚝 (TrueNas Scale that is) as long as possible (because they consider dropping docker altogether 😱). Back to the problem at hand: the host docker-compose binary is destined to be inaccessible or removed during the update I planned. Josh suggested in the TrueNas forum to use the TrueCharts provided Docker compose app to boot-strap a docker-compose based setup (🔗 link). I tried that, without success though. Sadly, Apps have very poor logging and debuggabilty in general.

I then thought 🤔💭: maybe there is a Docker 🐳 container through which I can launch docker-compose. After all, Portainer is able to run docker-compose and launch it into the connected docker socket. I found that Docker themselves even provide such a container: docker/compose. However, there were two things I didn’t like:

1. The entrypoint script was confusing (weird conditions) and not documented
2. If I mount a docker-compose.yml file and deploy the stack, the stack name will be of the parent folder and all host-related paths (.env files or volume mounts) wouldn’t be found. The stack name could easily be overwritten with the -p option. However, the relative / absolute path problem remained.

Eventually, I decided to build my own compose image and publish it on patzm/compose 🎉 🤗. I employ a trick (obviously propose by someone on the web 🌐) to mirror the host environment. This trick is, for instance, also used in my Portainer stack: instead of simply mounting it to /data. I need to tell Portainer then where to store (and find) stack information though with the --data argument: This approach has two benefits:

1. The docker-compose.yml’s parent folder is exactly the same as it is outside of the container and thus the stack name won’t be changed.
2. All environment files (e.g. .env) and volume mounts of the host file system work ✅.

One can then very easily launch a stack:

cd to/my/stack-folder
docker run -it --rm \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v $(pwd):$(pwd) \
    patzm/compose \
    $(pwd) up -d

The -e flags can be used to pass additional environment variables.

I then performed the upgrade, boot-strapped 🥾 my essential stacks again (Traefik, Portainer, and authentication), and then used the Portainer service to deploy the rest directly from GitHub. Sadly, I could not get rid of overwriting the default TrueNas Scale /etc/docker/daemon.json file with the following:

{
    "data-root": "/mnt/ssd-1tb/docker-standalone",
    "exec-opts": ["native.cgroupdriver=cgroupfs"],
    "iptables": true,
    "bridge": "",
    "dns": ["192.168.178.1"]
}

In particular, iptables still needs to be enabled.

The source of the compose bootstrap image can be found 👉 here 👈.