Moving gitea to debian host

This commit is contained in:
juvdiaz 2026-06-26 22:16:10 -06:00
parent 39d500866c
commit 2f290b8ce2
4 changed files with 36 additions and 37 deletions

View File

@ -142,8 +142,8 @@ cd ~/my-homelab-configs
./lab.sh up
```
The script first deploys external Gitea to the Raspberry Pi with Docker Compose
under `/data/homelab-gitea`, backed by the Raspberry Pi SSD, so Git stays
The script first deploys external Gitea to the Debian host with Docker Compose
under `/data/homelab-gitea`, backed by the HP laptop NVMe, so Git stays
outside the Kubernetes rebuild blast radius. It then detects the
Pimox host at `192.168.100.80` in auto mode. When SSH, `qm`, and `vmbr0` are
available, it applies `bootstrap/provisioning`, creates or reuses the Debian 13
@ -197,8 +197,8 @@ translation endpoints such as `save_idea.php`, `visitor_ideas.php`,
`translate.php`, and `save_lang.php`.
Set `LAB_GITEA_DEPLOY=false` to skip the external Gitea deployment step when the
Raspberry Pi service is already managed manually. The default Gitea target is
`jv@192.168.100.89`, install directory `/data/homelab-gitea`, HTTP port `3000`,
service is already managed manually. The default Gitea target is
`jv@192.168.100.73`, install directory `/data/homelab-gitea`, HTTP port `3000`,
and SSH port `32222`.
## Validation
@ -215,7 +215,7 @@ kubectl -n website-production get pods -o wide
kubectl -n demos-static get pods -o wide
kubectl -n heimdall get pods -o wide
ssh jv@192.168.100.89 'cd /data/homelab-gitea && sudo docker compose ps'
ssh jv@192.168.100.73 'cd /data/homelab-gitea && sudo docker compose ps'
docker info --format '{{.DockerRootDir}}'
df -h / /data /data/openebs/local /data/docker
@ -250,13 +250,12 @@ Run a full cluster rebuild from the Debian server with:
./lab.sh rebuild-cluster
```
That path preserves external Raspberry Pi Gitea, rebuilds the Pimox template
That path preserves external Gitea, rebuilds the Pimox template
with 2 cores and 4 GiB memory, replaces two Pimox worker VMs with 2 cores and
4 GiB memory, and joins those workers to the Kubernetes cluster. CPU affinity is
disabled by default because the Bullseye-pinned Pimox `qm` does not support it.
The Raspberry Pi is still included as a Kubernetes worker by default; `nuke`
does not clean it unless you explicitly add it to `WORKER_SSH_TARGETS`, so the
external Gitea Docker service survives cluster rebuilds.
does not clean it unless you explicitly add it to `WORKER_SSH_TARGETS`.
To exclude the Raspberry Pi from the Kubernetes cluster, set
`LAB_INCLUDE_RASPBERRY_WORKER=false`. To manage workers manually instead, add
@ -539,14 +538,14 @@ Buildx state, and image caches from filling `/`.
## Gitea
Gitea is external bootstrap infrastructure. It runs on the Raspberry Pi as an
Gitea is external bootstrap infrastructure. It runs on the Debian host as an
always-on Docker Compose service from `infra/gitea/docker-compose.yml`, not as a
Kubernetes workload. This keeps Git available when the Kubernetes cluster is
destroyed and rebuilt.
The default data path is `/data/homelab-gitea/data` on the Raspberry Pi SSD.
The Raspberry Pi Docker root is also expected to live on the SSD-backed `/data`
mount rather than the SD card.
The default data path is `/data/homelab-gitea/data` on the HP laptop NVMe. The
Docker root is also expected to live on the `/data` storage path rather than the
root filesystem.
Public source browsing stays available through
`https://lab2025.duckdns.org/git/`. Registration is disabled and anonymous users
@ -578,16 +577,16 @@ Deploy or refresh the external Gitea container from the Debian host with:
## Gitea Backups
`./lab.sh up` installs a Debian-host systemd timer named
`homelab-gitea-backup.timer`. The timer runs daily, SSHes to the Raspberry Pi,
executes `gitea dump` inside the Gitea Docker container, copies the dump back to
Debian, and stores it under `/home/jv/backups/gitea`. The default retention is
30 days.
`homelab-gitea-backup.timer`. The timer runs daily, SSHes to the configured
Gitea host, executes `gitea dump` inside the Gitea Docker container, copies the
dump back to Debian, and stores it under `/home/jv/backups/gitea`. The default
retention is 30 days.
The same install step also creates `homelab-gitea-restore-drill.timer`. The
monthly drill is non-destructive: it verifies the latest backup ZIP, extracts it
to a temporary directory, records a report under
`/home/jv/backups/gitea-restore-drills`, and removes the temporary extract. It
does not write into the live Raspberry Pi Gitea data directory.
does not write into the live Gitea data directory.
Run a manual backup from the Debian server with:
@ -617,7 +616,7 @@ This repo includes a Gitea Actions workflow at
`.gitea/workflows/homelab-main.yml`. It runs only on pushes to `main` and targets
a repository-scoped Debian host runner with the label `homelab-debian`.
The workflow only blocks automatic deploy for Raspberry Pi Gitea service
The workflow only blocks automatic deploy for external Gitea service
changes: files under `infra/gitea/`, or edits inside the `deploy_gitea`,
`install_gitea_backup_timer`, `backup_gitea`, or `drill_gitea_restore`
functions in `lab.sh`. Other changes use `HOMELAB_ACTION_COMMAND=auto` by
@ -631,7 +630,7 @@ on the runner to force one path.
`./lab.sh bootstrap-gitea-repo` also registers the Debian host SSH public key
with the Gitea repository and switches the Debian working copy's `gitea` remote
to `ssh://git@192.168.100.89:32222/jv/my-homelab-configs.git`. The default key
to `ssh://git@192.168.100.73:32222/jv/my-homelab-configs.git`. The default key
is `/home/jv/.ssh/id_ed25519.pub`; set `LAB_GITEA_REPO_SSH_KEY_PATH` to use a
different Debian-host key, or `LAB_GITEA_REPO_SSH_BOOTSTRAP=false` to leave SSH
access unchanged. The Actions deploy job uses the checked-out Actions workspace
@ -684,8 +683,8 @@ links, iptables rules, and local OpenTofu state. It does not delete retained dat
under `/data/openebs/local`.
For multi-node labs, set `WORKER_SSH_TARGETS` to a space-separated list of SSH
targets. It defaults to an empty string so the Raspberry Pi Gitea host is not
cleaned unless you explicitly include it.
targets. It defaults to an empty string so worker nodes are not cleaned unless
you explicitly include them.
## Website App

View File

@ -72,7 +72,7 @@ variable "gitea_backend_port" {
variable "gitea_backend_host" {
type = string
default = "192.168.100.89"
default = "192.168.100.73"
}
variable "haproxy_stats_user" {

View File

@ -2,14 +2,14 @@
Gitea is bootstrap infrastructure, not a Kubernetes workload.
`lab.sh deploy-gitea` copies `docker-compose.yml` to the Raspberry Pi and runs
`lab.sh deploy-gitea` copies `docker-compose.yml` to the Debian host and runs
Gitea as an always-on Docker Compose service. The current default stores data on
the Raspberry Pi SSD under `/data/homelab-gitea/data`; the Pi Docker root is
also expected to live on the SSD-backed `/data` mount.
the HP laptop NVMe under `/data/homelab-gitea/data`; Docker root is also
expected to live on the `/data` storage path.
Defaults:
- host: `192.168.100.89`
- host: `192.168.100.73`
- user: `jv`
- install dir: `/data/homelab-gitea`
- HTTP port: `3000`
@ -25,10 +25,10 @@ adds the Debian host deploy key when needed, and points the Debian checkout's
`gitea` remote at:
```text
ssh://git@192.168.100.89:32222/jv/my-homelab-configs.git
ssh://git@192.168.100.73:32222/jv/my-homelab-configs.git
```
Argo CD does not read from the Raspberry Pi Gitea SSH port. It reads from the
Argo CD does not read from the Gitea SSH port. It reads from the
Debian bare GitOps mirror through `gitops_repo_url`, normally:
```text
@ -40,6 +40,6 @@ The platform bootstrap registers that repo secret and updates
refresh the Debian host key in that ConfigMap and restart `argocd-repo-server`.
Backups are installed on the Debian host by `lab.sh deploy-gitea` and
`lab.sh backup-gitea`. The timer runs `gitea dump` inside the Raspberry Pi
container, copies the archive to Debian, and stores it under
`lab.sh backup-gitea`. The timer runs `gitea dump` inside the Gitea container,
copies the archive to Debian, and stores it under
`/home/jv/backups/gitea`.

14
lab.sh
View File

@ -2046,8 +2046,8 @@ wait_for_deployment_ready() {
deploy_gitea() {
local mode="${LAB_GITEA_DEPLOY:-true}"
local gitea_host="${LAB_GITEA_HOST:-${LAB_RASPBERRY_HOST:-192.168.100.89}}"
local gitea_user="${LAB_GITEA_USER:-${LAB_RASPBERRY_USER:-jv}}"
local gitea_host="${LAB_GITEA_HOST:-192.168.100.73}"
local gitea_user="${LAB_GITEA_USER:-jv}"
local gitea_key="${LAB_GITEA_SSH_KEY_PATH:-${LAB_RASPBERRY_SSH_KEY_PATH:-/home/jv/.ssh/id_ed25519}}"
local install_dir="${LAB_GITEA_INSTALL_DIR:-/data/homelab-gitea}"
local image="${LAB_GITEA_IMAGE:-gitea/gitea:1.21.7}"
@ -2398,8 +2398,8 @@ ensure_gitea_repo_ssh_access() {
bootstrap_gitea_repo() {
local mode="${LAB_GITEA_REPO_BOOTSTRAP:-true}"
local gitea_host="${LAB_GITEA_HOST:-${LAB_RASPBERRY_HOST:-192.168.100.89}}"
local gitea_user="${LAB_GITEA_USER:-${LAB_RASPBERRY_USER:-jv}}"
local gitea_host="${LAB_GITEA_HOST:-192.168.100.73}"
local gitea_user="${LAB_GITEA_USER:-jv}"
local gitea_key="${LAB_GITEA_SSH_KEY_PATH:-${LAB_RASPBERRY_SSH_KEY_PATH:-/home/jv/.ssh/id_ed25519}}"
local container_name="${LAB_GITEA_CONTAINER_NAME:-homelab-gitea}"
local http_port="${LAB_GITEA_HTTP_PORT:-3000}"
@ -2599,8 +2599,8 @@ ASKPASS_EOT
}
install_gitea_backup_timer() {
local gitea_host="${LAB_GITEA_HOST:-${LAB_RASPBERRY_HOST:-192.168.100.89}}"
local gitea_user="${LAB_GITEA_USER:-${LAB_RASPBERRY_USER:-jv}}"
local gitea_host="${LAB_GITEA_HOST:-192.168.100.73}"
local gitea_user="${LAB_GITEA_USER:-jv}"
local gitea_key="${LAB_GITEA_SSH_KEY_PATH:-${LAB_RASPBERRY_SSH_KEY_PATH:-/home/jv/.ssh/id_ed25519}}"
local gitea_container="${LAB_GITEA_CONTAINER_NAME:-homelab-gitea}"
local backup_dir="${LAB_GITEA_BACKUP_DIR:-/home/jv/backups/gitea}"
@ -3165,7 +3165,7 @@ rebuild_cluster() {
export LAB_PIMOX_WORKER_REPLACE_EXISTING="${LAB_PIMOX_WORKER_REPLACE_EXISTING:-true}"
export TF_VAR_force_worker_rejoin="${TF_VAR_force_worker_rejoin:-true}"
echo "Rebuilding the Kubernetes cluster without touching external Raspberry Pi Gitea..."
echo "Rebuilding the Kubernetes cluster without touching external Gitea..."
nuke
run_pimox_pipeline