f28b665afd
1. Support `ZEROTIER_ONE_USE_IPTABLES_NFT` environment variable. If omitted or has any value other than `true`, `iptables` is used (maintains backwards compatibility). If `true`, substitutes `iptables-nft`. This definitely seems to be necessary on Raspberry Pi running Bullseye. 2. Support `ZEROTIER_ONE_LOCAL_PHYS` environment variable. Defaults to `eth0` if omitted (maintains backwards compatibility). Allows for overriding to `wlan0` (eg Raspberry Pi Zero 2W), or both `eth0 wlan0` to support multiple subnets or failover modes, or similar situations (eg extra network interface cards). 3. Support `ZEROTIER_ONE_NETWORK_ID` as an alternative to the `join` command. Means container will always fail safe if its persistent storage is erased - will look like a new identity but can be authorised and will then be reachable for additional configuration. 4. Support `PUID` + `PGID` environment variables. Default to 999 and 994, respectively, mimicking what happens on a "native" install of ZeroTier-One (on a Raspberry Pi). 5. Perform unconditional reset of ownership (PUID:PGID) throughout persistent store on each launch. This avoids many permission problems that can sometimes occur in docker environments. 6. Add launch message with date. Assists in assessing recency of "sendto: Network unreachable" messages that can occur after a reboot where the container resumes before networking is available. Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> |
||
|---|---|---|
| .github/workflows | ||
| k8s | ||
| patches | ||
| scripts | ||
| docker-compose.yml | ||
| Dockerfile | ||
| Dockerfile.router | ||
| LICENSE | ||
| README.md | ||
zerotier-docker
Description
This is a container based on a lightweight Alpine Linux image and a copy of ZeroTier One. It's designed to allow you to run ZeroTier One as a service on container-oriented distributions like Fedora CoreOS, though it should work on any Linux system with Docker or Podman.
Run
To run this container in the correct way requires some special options to give it special permissions and allow it to persist its files. Here's an example (tested on Fedora CoreOS):
docker run --name zerotier-one --device=/dev/net/tun --net=host \
--cap-add=NET_ADMIN --cap-add=SYS_ADMIN \
-v /var/lib/zerotier-one:/var/lib/zerotier-one zyclonite/zerotier
This runs zyclonite/zerotier in a container with special network admin permissions and with access to the host's network stack (no network isolation) and /dev/net/tun to create tun/tap devices. This will allow it to create zt# interfaces on the host the way a copy of ZeroTier One running on the host would normally be able to.
In other words that basically does the same thing that running zerotier-one directly on the host would do, except it runs in a container. Since Fedora CoreOS has no package management this is the preferred way of distributing software for it.
It also mounts /var/lib/zerotier-one to /var/lib/zerotier-one inside the container, allowing your service container to persist its state across restarts of the container itself. If you don't do this it'll generate a new identity every time. You can put the actual data somewhere other than /var/lib/zerotier-one if you want.
To join a zerotier network you can use
docker exec zerotier-one zerotier-cli join 8056c2e21c000001
or create an empty file with the network as name
/var/lib/zerotier-one/networks.d/8056c2e21c000001.conf
Router mode
It is the implementation of the local network router paper
docker run --name zerotier-one --device=/dev/net/tun \
--cap-add=NET_ADMIN --cap-add=NET_RAW --cap-add=SYS_ADMIN \
-v /var/lib/zerotier-one:/var/lib/zerotier-one zyclonite/zerotier:router
That will start the zero-one, establish connection and build the NAT+router once the zt interface is up.