Rather than attaching app containers to the tailscale container's network, attach the tailscale container to the app container network.
Originally, a tailscale container would be created, and app containers would set their network mode to share the tailscale container's network space. This caused an issue where, if there was more than one container requesting the same port, the newer container(s) would fail because the port is already taken.
One option could have been to expect the app container to have a dynamic port, whether it sets that port itself or requests tailscale to set the port for the app. But that gets to be too non-deterministic, and sets a higher expectation for an app to be written to comply with this tailscale plugin.
Alternatively, I learned that the tailscale/docker integration will work by swapping which container connects to which network. In this case, which is what is implemented in this PR, the app container starts, and then the tailscale container starts and sets its network mode to share the app container's network. This allows for there to be multiple app containers using the same port assignments, because they're each running in their own network space. This is a more determinstic, and normal, mode to run in.
The tailscale container operates the same way that it used to without issue with one exception. In the old way, the tailscale container sets its hostname with the --hostname flag to docker run.... The --hostname flag is not accepted by docker when paired with this new network mode for a container. However, we can set the --hostname flag on the app container, and tailscale will set the machine's name on the tailnet to the value set there, which is what we want. Multiple containers can apparently have the same hostname, so scaling is not a concern with this.
One thing of note is that tailscale:up will add the docker-option to set the hostname on the app container, which means if the app had already been deployed prior to running tailscale:up, then the hostname will be the container ID by default. The containers must be re.......started?deployed? in order to take on the new hostname.
need to make sure that we track which apps requested tailscale. Currently, the post-deploy trigger takes effect on every deploy, regardless of whether or not tailscale is desired
Rather than attaching app containers to the tailscale container's network, attach the tailscale container to the app container network.
Originally, a tailscale container would be created, and app containers would set their network mode to share the tailscale container's network space. This caused an issue where, if there was more than one container requesting the same port, the newer container(s) would fail because the port is already taken.
One option could have been to expect the app container to have a dynamic port, whether it sets that port itself or requests tailscale to set the port for the app. But that gets to be too non-deterministic, and sets a higher expectation for an app to be written to comply with this tailscale plugin.
Alternatively, I learned that the tailscale/docker integration will work by swapping which container connects to which network. In this case, which is what is implemented in this PR, the app container starts, and then the tailscale container starts and sets its network mode to share the app container's network. This allows for there to be multiple app containers using the same port assignments, because they're each running in their own network space. This is a more determinstic, and normal, mode to run in.
The tailscale container operates the same way that it used to without issue with one exception. In the old way, the tailscale container sets its hostname with the
--hostname
flag todocker run...
. The--hostname
flag is not accepted by docker when paired with this new network mode for a container. However, we can set the--hostname
flag on the app container, and tailscale will set the machine's name on the tailnet to the value set there, which is what we want. Multiple containers can apparently have the same hostname, so scaling is not a concern with this.One thing of note is that
tailscale:up
will add thedocker-option
to set the hostname on the app container, which means if the app had already been deployed prior to runningtailscale:up
, then the hostname will be the container ID by default. The containers must be re.......started?deployed? in order to take on the new hostname.