holm/zerotier-docker
1
1
Fork 0
forked from extern/zerotier-docker
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Lukas Prettenthaler 2020-12-01 09:10:36 +01:00 committed by GitHub
parent 398a312876
commit 029c147c3e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -4,11 +4,11 @@
#### Description
This is a container with a lightweight Alpine Linux image and a copy of ZeroTier One built for that image. It's designed to allow you to run ZeroTier One as a service on container-oriented distributions like CoreOS, though it should work on any Linux system with Docker.
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 CoreOS):
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 \
@ -17,7 +17,7 @@ To run this container in the correct way requires some special options to give i
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 CoreOS has no package management this is the preferred way of distributing software for it.
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.