add self-hosted Docker zrok-instance

[qrkourier]

🚧 work in progress

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
zrok	⬜️ Ignored (Inspect)	Visit Preview		Apr 26, 2024 8:57pm

[deanpcmad]

Very interested in this

[qrkourier]

Thanks for saying so, @deanpcmad! Will you share how you plan to run the OpenZiti instance that your zrok will use, e.g., k8s, expressInstall() compose, all-in-one compose, directly on Linux, etc?

zrok needs a ziti management API address and credential so it can bootstrap its own overlay, so there's no requirement that ziti is running in the same compose project, but it might be convenient if it is.

[deanpcmad]

If it can all go in the same docker compose file, that's fine by me! That's always the issue with these kinda things, when you need multiple services to run, but if it's all in the same file it makes things much easier

[qrkourier]

@deanpcmad That's what I was thinking. Compose has this neat merge feature that happens when you have two compose files with the magic names compose.yml and compose.override.yml. They automatically become one compose project when you run the up command. I'm thinking put the ziti stuff in one and zrok stuff in the other so they can live in their respective Git repos and all that's necessary is a file rename to make them part of the same compose project.

[compgeniuses]

looking forward to a ping of this once released

[Kavan72]

looking forward to a ping of this once released

+1

[qrkourier]

I gave this some thought today. I can see two alternatives: a more robust, complete solution and one that's quicker to ship.

The quick solution would be a sample compose project directory you can download from GitHub. It requires the user to know how to configure zrok. This requires the user to employ Docker Compose and run everything in one project because we must build the container images just-in-time with the modified configs and we must make certain assumptions in the configs for the sake of simplicity.

The more production-ready and complete solution introduces Linux packages and container images for the zrok controller and zrok frontend to the zrok release job. Both would use a new feature in zrok CLI to generate a valid configuration for the deployment (compose file or systemd env file) from a minimal set of input values, or you can bring your own config. This gives greater flexibility for different types of zrok deployments by separating the controller and frontend as discrete deployments (link to discussion issue about this idea).

[qrkourier]

For this branch, I'll focus on the quick, minimal solution, but please continue to add ideas and feedback here about running your own zrok in Docker.

[qrkourier]

Merging phase 1 of 3:

1. current: clunky install but it works
2. next: all you need is the compose.yml (refinement of the current project, est. 4 hours work)
3. final: bundle everything in zrok CLI so all you need is the binary

[metya]

Hooray!

Where I can subscribe to the next phase, where all the things are in one docker-compose.yml? Is there an issue about it?

[qrkourier]

Hooray!

Where I can subscribe to the next phase, where all the things are in one docker-compose.yml? Is there an issue about it?

Good idea. Here's an issue for the next phase: #613

Will you test drive this phase when it's released? I've got one PR pending review, then I'll ask for a release stamp to build everything out. The instructions in the doc site won't work until then.

[metya]

Cool! Thank you for the issue :)

I definitely will test the version with one compose file, yes.
I've subscribed to the PR.
But I use another reverse proxy service in docker that called nginx-proxy.
When I figure out how to bypass the caddy and use nginx-proxy instead I will test it!

[qrkourier]

Yep! You can delete the caddy service container and replace it with your preferred TLS load balancer. Ensure NGINX is configured to terminate TLS with your cert and has upstreams for the controller (zrok.$ZROK_DNS_ZONE), OAuth (if wanted, oauth.${ZROK_DNS_ZONE}, and a wildcard/catchall for your zrok frontend to handle public shares *.${ZROK_DNS_ZONE}.

I asked ChatGPT to translate the new zrok-instance for Docker's Caddyfile for NGINX. This looks believably close, but I haven't tested it. There's an NGINX guide in our self-hosting docs, though not tailored for Docker, that you might find helpful too.

server {
    listen 80;
    server_name _;
    return 301 https://$host$request_uri;
}

upstream zrok_frontend {
    server zrok-frontend:FRONTEND; # Replace FRONTEND with the actual port number
}

upstream zrok_controller {
    server zrok-controller:CTRL_PORT; # Replace CTRL_PORT with the actual port number
}

upstream zrok_oauth {
    server zrok-frontend:OAUTH; # Replace OAUTH with the actual port number
}

map $host $upstream {
    default zrok_frontend;
    ~^oauth\. example.com zrok_oauth;
    ~^zrok\. example.com zrok_controller;
}

server {
    listen 443 ssl;
    server_name *.example.com; # Replace example.com with your {$ZROK_DNS_ZONE}

    ssl_certificate /path/to/ssl/cert.pem; # Set the path to your SSL certificate
    ssl_certificate_key /path/to/ssl/key.pem; # Set the path to your SSL key

    # SSL Configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Logging
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log debug;

    location / {
        proxy_pass http://$upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Please ensure you send the original host header when forwarding requests to the frontend container because it needs that info to route the request to the zrok share backend.