I’m not sure how common this technique is. I described the why I use unix sockets with my docker apps in my last post Why I build my Custom Images.
Let’s talk about the how
I’ll start with an easy example. Let’s find an image that exposed a port. I’ll go with Glances.
Modifying the Configs
To expose your app over a socket instead you will need to use a reverse proxy inside
the container. Which means you will have 2 running processes, the proxy and in our
case the glances app. I use s6-overlay
but you can use quite literally
whatever you’re comfortable with. But this is what the Dockerfile would look like.
You could use something lighter than Caddy but we’re not concerned with that here.
To actually run the services together we will follow the s6-overlay way of creating
etc/services.d/{service_name}/run
files for Caddy and Glances and then
copying them to the container. (see Dockerfile above)
{glances_path_on_my_host_machine}etc/services.d/caddy/run
{glances_path}/etc/services.d/glances/run
Here’s what my Caddyfile will look like {glances_path}/Caddyfile
61208
is what Glances runs at. Now in my docker compose I would do
something like:
Glances will run over a UDS stored in
{glances_path}/sockets/glances.sock
and our container doesn’t expose any
ports!
Now, the last thing we gotta do is to make sure my Tailnet can still access glances. So in my Caddyfile, I’ll make the following changes.
Note
Caddy’s syntax for UDS is
unix//
+<path to .sock>