Hello. Relatively new here, to both tailscale and docker. Bear with…
My run command for my tailscale container contains the TS_AUTHKEY= flag, with a key generated from the tailscale web console. All good.
However I noticed that a host reboot left the container restarting with an auth error. I guess the key was a one time thing…
I set another key this time and set it to reusable. That has resulted in tailscale almost seeing a new machine joining the network each time my container host is rebooted - I get hostname1 after first reboot, hostname2 after the second reboot.
Can someone advise on the best-practice running tailscale in a container that is able to survive a host reboot nicely? Also curious on how to deal with the 180-day key expiry…
You didn’t say what container you are running, so we can only guess what it does with the value of the TS_AUTHKEY environment variable, but a reasonable assumption is that something looks there to find a Tailscale pre-authentication key.
There’s no need to guess–you generated the key, and the second paragraph of Tailscale’s “auth key” documentation states that keys can be either of the following:
One-off, for one-time use. They can be used to connect a device or server, only once. This is meant for situations where you can’t authenticate on the device yourself, so using a key is more practical. For example, a cloud server might use a one-off key to connect.
Reusable, for multiple uses. They can be used to connect multiple nodes. For example, multiple instances of on-prem database might use a reusable key to connect.
This is likely the expected behavior, though, again, you didn’t say anything about the container you are using, so we can only guess. Unless tailscaled in the container has access to persistent storage and is directed to save its state there, from Tailscale’s perspective, it is a new machine (i.e., a new Tailscale node).
Are you using an ephemeral auth key, as the Tailscale docs indicate that you should?
Depending on what devices you’re authenticating, consider using an auth key that is:
Ephemeral, for authenticating ephemeral nodes as part of short-lived workloads. Since node keys are not persisted when a workload restarts, these will reconnect as a different node. Nodes which are no longer active will be automatically removed. For example, containers or Lambda functions should use an ephemeral key to connect.
Please be more specific. For example, what did you mean by “a container that is able to survive a host reboot”?
If you asked a specific question, someone might be able and willing to answer. It’s not at all clear from what you wrote what you meant by “deal with the 180-day key expiry.”
Regardless, you can likely find your answer and save others some time by reading Tailscale’s “Key expiry” documentation.
Please note that Tailscale maintain a managed Docker image, which they publish on Docker Hub and Github Images. The docs for that image indicate how to point tailscaled at persistent storage where it should store its state:
TS_STATE_DIR: This directory needs to persist across container restarts, and will be used to store tailscaled state. It will be passed to tailscaled --statedir=
I’m learning, my questions aren’t going to be great. I did say that.
I’m using the tailscale/tailscale image on docker. I am following their published guidance, including volumes for persistent storage.
My goal is to set up a tailscale machine as an always-on server, advertising routes and acting as an exit node. Possibly the temporary nature of containers means they aren’t the right solution and I should configure on the host…