Feedback on Repo #140
Description
Feedback from TinfoilComputer on Reddit thread.
Great question! And thank you for the great repo!
I think that would be helpful. With no Docker Compose knowledge, or not having watched certain YouTube videos, or even with some Docker experience but not enough understanding of the networking wizardry going on here, it could be difficult for some folks. But obviously you don't want to duplicate Tailscale and Docker documentation. And for stuff like GPU pass through, the service docs are going to be the best ones usually.
You'll have multiple types of users:
1. those who already have the service running and discovered TailScale and need to convert their setup without breaking it
2. those who have maybe already set up a TailScale service and want to add a new thing they've never used before
3. People from 2 who don't see their favorite targeted service in the repo yet.
I'd focus on these things:
- link to some of the better recent videos that might help people
- explaining how the sidecar TS container handles the networking
- maybe giving steps to a setup, such as what to check before you enable Magic DNS (this could be a general guide, not per service, though for certain services you may need specifics). I remember in many of the Tailscale videos Alex would finally load the magic url and have to say "this may take a moment, but look here in the logs, it's getting a certificate"
- mention in each service's README any gotchas, like needing to first set up a user and giving it Docker group access, needing to pass the video / render groups, links to the service's docs, needing to rename one of the config directories to say ts-config (or simply do that in the compose file) so it won't conflict, pre-creating the empty volume directories
- explain the 0.0.0.0 optional port exposure and when it might be needed and why it's commented out, and explain why you will usually need to remove the exposed port configs.
- a little bit about networking and how the compose services can talk to each other but can't be accessed (messy topic btw)
- explain the serve.json a bit (especially since it doesn't take advantage of the .env SERVICEPORT.)
I am going to bet the folks in group 1 have the most issues, they want to change their compose file as minimally as possible, yet they see all these ${VARS} etc, so they may skip important stuff, or accidentally set a local directory to a docker directory, even if they came here after watching a few videos. Or ask AI to rewrite the compose file for them (we know that works sometimes...)
For user group 3, the template could maybe use an extra CONTRIBUTING.md file for contributors (in the main repo) that explains why they should follow the template pattern (e.g. the dot env file, health checks, etc) and how to best modify their existing compose file to set stuff up. While the number of folks needing this may be fairly small, it could save time in code reviews. And then again, you may find a few service maintainers having a much easier time adding their services to your repo themselves (and then hopefully keeping their contributions up to date) with such a guide.
Also, I'd suggest using compose.yaml if you can.
[EDIT to avoid silly auto-link of file name, sigh, markdown edit FTW]