dave/site
1
0
Fork 0
mirror of https://github.com/davegallant/davegallant.github.io.git synced 2025-08-05 08:13:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update gitea blog post to use Tailscale Serve and Funnel

Browse Source
This commit is contained in:
Dave Gallant
2024-02-10 10:20:25 -05:00
parent 379e9ce5ff
commit eb1136bf90
1 changed files with 35 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
content/blog/setting-up-gitea-actions-with-tailscale/index.md
View File

@@ -29,17 +29,18 @@ Actions (gitea's implementation) has me excited because it makes spinning up a n
## Integration with Tailscale ## Integration with Tailscale
So how does Tailscale help here? Well, more recently I've been exposing my self-hosted services through a combination of traefik and the tailscale (through the tailscale-traefik proxy integration described [here](https://traefik.io/blog/exploring-the-tailscale-traefik-proxy-integration/)). This allows for a nice looking dns name (i.e. gitea.my-tailnet-name.ts.net) and automatic tls certificate management. I can also share this tailscale node securely with other tailscale users without configuring any firewall rules on my router. > **2024-02-10**: I had originally written this post to include [Tailscale-Traefik Proxy Integration](https://traefik.io/blog/exploring-the-tailscale-traefik-proxy-integration/), but have since removed it in favour of Tailscale Serve after learning from this [example](https://github.com/tailscale-dev/docker-guide-code-examples). This simplifies the setup and reduces the number of moving parts.
So how does Tailscale help here? Well, more recently I've been exposing my self-hosted services using Tailscale [Serve](https://tailscale.com/kb/1312/serve). This allows for a nice looking dns name (i.e. gitea.my-tailnet-name.ts.net), automatic tls certificate management, and optionally allowing the address to be publically accessible (by using [Funnel](https://tailscale.com/kb/1223/funnel)).
## Deploying Gitea, Traefik, and Tailscale ## Deploying Gitea, Traefik, and Tailscale
In my case, the following is already set up: In my case, the following is already set up:
- [docker-compose is installed](https://docs.docker.com/compose/install/linux/) - [docker-compose is installed](https://docs.docker.com/compose/install/linux/)
- [tailscale is installed on the gitea host](https://tailscale.com/kb/1017/install/)
- [tailscale magic dns is enabled](https://tailscale.com/kb/1081/magicdns/) - [tailscale magic dns is enabled](https://tailscale.com/kb/1081/magicdns/)
My preferred approach to deploying code in a homelab environment is with docker compose. I have deployed this in a [proxmox lxc container](https://pve.proxmox.com/wiki/Linux_Container) based on debian with a hostname `gitea`. This could be deployed in any environment and with any hostname (as long you updated the tailscale machine name to your preferred subdomain for magic dns). My preferred approach to deploying code in a homelab environment is with docker compose. I have deployed this in a LXC on Proxmox. You could run this on a virtual machine or a physical host as well.
The `docker-compose.yaml` file looks like: The `docker-compose.yaml` file looks like:
@@ -49,6 +50,7 @@ services:
gitea: gitea:
image: gitea/gitea:1.21.1 image: gitea/gitea:1.21.1
container_name: gitea container_name: gitea
network_mode: service:ts-gitea
environment: environment:
- USER_UID=1000 - USER_UID=1000
- USER_GID=1000 - USER_GID=1000
@@ -62,60 +64,44 @@ services:
- ./data:/data - ./data:/data
- /etc/timezone:/etc/timezone:ro - /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro - /etc/localtime:/etc/localtime:ro
traefik: ts-gitea:
image: traefik:v3.0.0-beta4 image: tailscale/tailscale:v1.58
container_name: traefik container_name: ts-gitea
security_opt: hostname: gitea
- no-new-privileges:true environment:
restart: unless-stopped - TS_AUTHKEY=<FILL THIS IN>
ports: - TS_SERVE_CONFIG=/config/gitea.json
- 80:80 - TS_STATE_DIR=/var/lib/tailscale
- 443:443
volumes: volumes:
- ./traefik/data/traefik.yaml:/traefik.yaml:ro - ${PWD}/state:/var/lib/tailscale
- ./traefik/data/dynamic.yaml:/dynamic.yaml:ro - ${PWD}/config:/config
- /var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock - /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: unless-stopped
``` ```
`traefik/data/traefik.yaml`: Note that you must specify a `TS_AUTHKEY` in the `ts-gitea` service. You can generate an auth key [here](https://login.tailscale.com/admin/settings/keys).
`config/gitea.json`:
```yaml ```yaml
entryPoints: {
https: "TCP": { "443": { "HTTPS": true } },
address: ":443" "Web":
providers: {
file: "${TS_CERT_DOMAIN}:443":
filename: dynamic.yaml { "Handlers": { "/": { "Proxy": "http://127.0.0.1:3000" } } },
certificatesResolvers: },
myresolver: "AllowFunnel": { "${TS_CERT_DOMAIN}:443": false },
tailscale: {} }
log:
level: INFO
``` ```
and finally `traefik/data/dynamic/dynamic.yaml`:
```yaml
http:
routers:
gitea:
rule: Host(`gitea.my-tailnet-name.ts.net`)
entrypoints:
- "https"
service: gitea
tls:
certResolver: myresolver
services:
gitea:
loadBalancer:
servers:
- url: "http://gitea:3000"
```
Something to consider is whether or not you want to use ssh with git. One method to get this to work with containers is to use [ssh container passthrough](https://docs.gitea.com/installation/install-with-docker#ssh-container-passthrough). I decided to keep it simple and not use ssh, since communicating over https is perfectly fine for my use case.
After adding the above configuration, running `docker compose up -d` should be enough to get an instance up and running. It will be accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within the tailnet. After adding the above configuration, running `docker compose up -d` should be enough to get an instance up and running. It will be accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within the tailnet.
Something to consider is whether or not you want to use ssh with git. One method to get this to work with containers is to use [ssh container passthrough](https://docs.gitea.com/installation/install-with-docker#ssh-container-passthrough). I decided to keep it simple and not use ssh, since communicating over https is perfectly fine for my use case.
## Theming ## Theming
I discovered some themes for gitea [here](https://git.sainnhe.dev/sainnhe/gitea-themes) and decided to try out gruvbox. I discovered some themes for gitea [here](https://git.sainnhe.dev/sainnhe/gitea-themes) and decided to try out gruvbox.
@@ -131,7 +117,7 @@ After restarting the gitea instance, the default theme was applied.
## Connecting runners ## Connecting runners
I installed the runner by [following the docs](https://docs.gitea.com/usage/actions/quickstart#set-up-runner). I opted for installing it on a separate host (another lxc container) as recommended in the docs. I used the systemd unit file to ensure that the runner comes back online after system reboots. I installed tailscale on this gitea runner as well, so that it can have the same "networking privileges" as the main instance. I installed the runner by [following the docs](https://docs.gitea.com/usage/actions/quickstart#set-up-runner). I opted for installing it on a separate host as recommended in the docs. I used the systemd unit file to ensure that the runner comes back online after system reboots. I installed tailscale on the gitea runner as well, so that it can be part of the same tailnet as the main instance.
After registering this runner and starting the daemon, the runner appeared in `/admin/actions/runners`. I added two other runners to help with parallelization. After registering this runner and starting the daemon, the runner appeared in `/admin/actions/runners`. I added two other runners to help with parallelization.