Hello Dinko, I tried the new image with a read-only root filesystem:
docker run --rm --read-only --name hatest -d haproxytech/haproxy:debian-s6-3.5-dev7 And the error was: [ALERT] (117) : Binding [/etc/haproxy/haproxy.cfg:10] for frontend GLOBAL: protocol unix_stream: error when trying to unlink previous UNIX socket (Read-only file system) [/var/run/haproxy-runtime-api.sock]. 2026/09/25 13:36:41 error initializing dataplane internal storage: missing directory, unable to create: mkdir /usr/local/var/lib/dataplaneapi/storage: read-only file system The services did not start. Should these directories be exported as tmpfs on read-only filesystems? There is another related issue: 01-dataplaneapi attempts to replace the default admin password using sed -i. With --read-only, that write cannot succeed, but the script explicitly exits with 0. So unless I am missing something, after making the runtime directories writable, Data Plane API could end up starting with the shipped admin password unchanged. Illustration: docker run --rm --tmpfs /var/run --read-only --name hatest -d haproxytech/haproxy:debian-s6-3.5-dev7 docker exec -it hatest grep password: /usr/local/etc/haproxy/dataplaneapi.yml password: admin Adding "set -eu" to that script should at least prevent deploying something with password set to "admin". Perhaps read-only operation should either be supported explicitly, with the required writable paths documented, or fail clearly when the configuration cannot be updated. Side note: I suggest increasing the password size to 24 characters. 8 characters from 66 characters alphabet is pretty weak by today's standard ;) I normally use the images from docker.io/haproxy rather than the haproxytech images, so perhaps this limitation was already present before the gopherd migration. I could not find anything about read-only filesystems in the README. Best, /Nicolas On 25 Sep, Dinko Korunic wrote: > Hi everyone, > > I wanted to announce that we're migrating from s6-overlay to gopherd (project > home: https://github.com/haproxytech/gopherd, docs w/ examples: https:// > github.com/haproxytech/gopherd/tree/dev/documentation) in HAProxy CE Docker > images. > > All three image flavours — Ubuntu (https://github.com/haproxytech/ > haproxy-docker-ubuntu), Debian (https://github.com/haproxytech/ > haproxy-docker-debian), and Alpine (https://github.com/haproxytech/ > haproxy-docker-alpine) — are currently being converted and rebuilt, while > keeping all Docker tags and their existing format. > > s6-overlay has been a persistent source of friction with Docker and especially > Kubernetes compatibility, so we've written our own zero-dependency init. It's > purpose-built for containers, flexible enough to enable/disable services based > on environment variables, handles proper signal forwarding and rewriting, and > includes several other features we found missing in other minimal-init > implementations. > > We know many users have standardized on s6-overlay, so our images also ship > shims (s6-svc and s6-svstat) that translate their parameters into gopherd > calls > — easing migration and minimizing breakage in derived images. > > > > Kind regards, > D. > > -- > Dinko Korunic ** Standard disclaimer applies ** > Sent from OSF1 osf1v4b V4.0 564 alpha > -- ~Nico
