this post was submitted on 21 Oct 2024
28 points (100.0% liked)

Selfhosted

39856 readers
450 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

So Tailscale has this whole series about hosting services on one's Tailnet using Docker. Their approach is to run Tailscale in Docker and have the services' containers share its namespace by setting network_mode: service:<tailscale_service_name>.

I am trying to understand why this is better than just binding the service's port to the Tailscale IP of the host device, given that option is not even mentioned in any of their blog posts.

The only advantage I can think of is that you get to have different Tailscale rules/configurations for different services. In my case, this is not an advantage because I will run Tailscale on the host anyway and I won't have different configurations for each service.

Can anyone help me understand?

https://tailscale.com/kb/1282/docker

you are viewing a single comment's thread
view the rest of the comments
[–] farcaller@fstab.sh 5 points 1 week ago

If tailscale inside a container allows you to talk to it via “direct” connection and not a derp proxy, then it will offer you better service isolation (can set the tailscale ACLs for this specific service) without sacrificing performance.

Tailscale pushes for it because it just ties you in more. It allows to to utilize the ACLs better, to see your thing in their service mesh, and every service will count against the free node limit.

In practice, I often do both. E.g. I’ll have my http ingress exposed to tailscale and route a bunch of different services through it at a single tailscale node, where the access control is done by services individually. But I’ll also run a pod-to-pod tailscale between two k8s clusters because tailscale ACL is just convenient.