[MrPowerGamerBR]

For those who want to run Tailscale on their Docker containers, but don't want to switch to images based off linuxserver.io, you can still run Tailscale as a sidecar container, and use "network_mode: service:tailscale"

I do that for my containers and it is incredibly useful for cross containers communication, especially for containers that are hosted in different dedicated servers.

https://mrpowergamerbr.com/us/blog/2023-03-20-untangling-you...

[whs]

I run my game servers using `network_mode: service:tailscale` and every time the game server needs to restart (or crash) Tailscale will permanently lose connectivity and needs to be recreated (restart doesn't work).

To solve this problem I add another container which should never need to be restarted, and both the game and Tailscale use the networking of that container. This is also the exact use case of Kubernetes' pause containers, so I just use the EKS pause image from ECR public gallery.

Another tip I'd recommend is to run the Tailscale container with `TS_USERSPACE: 'false'` `TS_DEBUG_FIREWALL_MODE: nftables` (since autodetection fails on my machine) and give it `CAP_NET_ADMIN`. This allow Tailscale to use tun device instead of emulation, and it supposed to be more performant. But the clear benefit is that the game server will see everyone's Tailnet IP instead of 127.0.0.1.

In Thai: https://blog.whs.in.th/node/3676

[MrPowerGamerBR]

I may be wrong about the "TS_USERSPACE" environment variable, but I think that you don't need to disable it.

If you were using userspace networking, you wouldn't be able to connect to other services in your tailnet without setting up a HTTP/SOCKS5 proxy https://tailscale.com/kb/1112/userspace-networking/

[whs]

It'll work but my Minecraft server sees everyone as 127.0.0.1. After disabling TS_USERSPACE I see each person's Tailnet IP. Tailscale doesn't provide this information anywhere (since their node name is private), so once I have their IP address I can also use `tailscale ping` to ping the IP and see whether the connection is going through relay or direct, which is helpful when debugging their latency.

My users report better latency, but I doubt it.

[rcarmo]

This seems a lot cleaner than injecting new binaries into existing images or depending on linuxserver.io images.

[tylergetsay]

The "benefit" of one tailscale daemon per container is https/external access/etc can be handled automatically

[iansinnott]

Does linuxserver.io have a bad reputation? or is it just that it's yet another dependency in the stack?

Asking because I've been happy with their containers so far

[xena]

Many useful images are based on linuxserver.io containers, but most docker images are not based on linuxserver.io.

[wccrawford]

I use quite a few linuxserver.io containers on my home stack on my Synology NAS, and they've been awesome. When I see that they're from there, I know they'll be reliable and the setup process is going to be straightforward and similar to other containers I've already used.

Ironically, the 1 container I really wanted to use this Tailscale mod for was not from linuxserver.

[zzyzxd]

I find it's a bit annoying that almost all their images assume root access by default. Their init script does a bunch of things as root and only switch to a non-root user at the very last step before starting the main process if some magic environment variable is discovered. If your infra does not allow root users in containers you can't use their images.

It's also too much magic for my liking. Some software distributed as a single executable binary gets packaged in some over complicated base image on top of another base image, when I can technically just copy the binary into a scratch and call it a day. I understand the benefits when they have to manage tons of images at scale, but my life has been much easier with images packaged by myself or the upstream projects.