Files
trade-doc/gitea-k3s-rv32i.md
2026-01-06 12:33:47 +01:00

151 lines
3.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Gitea na k3s (Traefik + cert-manager + Lets Encrypt) dla `rv32i.pl`
Ten dokument instaluje Gitea w k3s:
- Ingress: Traefik
- TLS: cert-manager + Lets Encrypt (`ClusterIssuer` = `letsencrypt-prod`)
- Host: `rv32i.pl`
- Secret TLS: `rv32i-pl-tls`
## Ważne (hasła/sekrety)
Nie wstawiam i nie zalecam trzymania haseł w plikach w repo (`doc/`), bo to zwykle kończy się wyciekiem (git history, backupy, screeny).
Zamiast tego:
- trzymamy hasła w **Kubernetes Secret** (w klastrze),
- a w dokumentacji zostawiamy **placeholderey** i komendy, które proszą o hasło interaktywnie.
Jeśli mimo wszystko chcesz „na sztywno” wpisać hasła do pliku, podaj je jawnie w wiadomości — ale to jest zła praktyka.
## 0) Wymagania
1) `cert-manager` działa, a `ClusterIssuer` jest gotowy:
```bash
sudo k3s kubectl get clusterissuer letsencrypt-prod
```
2) DNS wskazuje na VPS:
```bash
dig +short rv32i.pl A
```
Oczekiwane: `77.90.8.171`
3) Porty 80/443 są otwarte z internetu (firewall/ACL u providera).
## 1) Instalacja Helm (jeśli nie masz)
```bash
helm version || true
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | sudo bash
helm version
```
## 2) Namespace
```bash
sudo k3s kubectl create namespace gitea
```
## 3) Secret z kontem admina (bez wpisywania hasła do historii)
Ten krok tworzy w klastrze sekret `gitea-admin` z loginem/hasłem/email admina.
```bash
read -rp "Gitea admin username: " GITEA_ADMIN_USER
read -rsp "Gitea admin password: " GITEA_ADMIN_PASS; echo
read -rp "Gitea admin email: " GITEA_ADMIN_EMAIL
sudo k3s kubectl -n gitea create secret generic gitea-admin \
--from-literal=username="$GITEA_ADMIN_USER" \
--from-literal=password="$GITEA_ADMIN_PASS" \
--from-literal=email="$GITEA_ADMIN_EMAIL"
```
## 4) Helm values (Ingress + TLS + Postgres w klastrze)
Utwórz plik `gitea-values.yaml` na VPS (nie musi być w repo):
```bash
cat <<'YAML' > gitea-values.yaml
ingress:
enabled: true
className: traefik
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
hosts:
- host: rv32i.pl
paths:
- path: /
pathType: Prefix
tls:
- secretName: rv32i-pl-tls
hosts:
- rv32i.pl
gitea:
admin:
existingSecret: gitea-admin
config:
server:
DOMAIN: rv32i.pl
ROOT_URL: https://rv32i.pl/
PROTOCOL: http
persistence:
enabled: true
storageClass: local-path
size: 10Gi
postgresql:
enabled: true
primary:
persistence:
enabled: true
storageClass: local-path
size: 10Gi
YAML
```
## 5) Instalacja Gitea
```bash
helm repo add gitea-charts https://dl.gitea.com/charts/
helm repo update
helm upgrade --install gitea gitea-charts/gitea \
-n gitea \
-f gitea-values.yaml
```
## 6) Sprawdzenie
```bash
sudo k3s kubectl -n gitea get pods -o wide
sudo k3s kubectl -n gitea get ingress -o wide
sudo k3s kubectl -n gitea get certificate -o wide
sudo k3s kubectl -n gitea get order,challenge
```
Wejdź na:
- `https://rv32i.pl`
Jeśli `Certificate` nie robi się `Ready=True`, to najczęściej:
- port 80 nie dochodzi z internetu (Lets Encrypt HTTP-01),
- Ingress nie ma `className: traefik`,
- DNS nie wskazuje na VPS.
## 7) (Opcjonalnie) dostęp do haseł po czasie
Jeśli chcesz podejrzeć login/email z sekretu (hasło też da się odczytać, ale rób to ostrożnie):
```bash
sudo k3s kubectl -n gitea get secret gitea-admin -o jsonpath='{.data.username}' | base64 -d; echo
sudo k3s kubectl -n gitea get secret gitea-admin -o jsonpath='{.data.email}' | base64 -d; echo
```
## 8) Uwaga o Git przez SSH
Na VPS port 22 zajmuje systemowy OpenSSH. Na start korzystaj z klonowania przez HTTPS.
Jeśli chcesz klonować przez SSH z Gitei:
- najprościej wystawić Gitea SSH na innym porcie (np. 2222) i zrobić NodePort/LoadBalancer,
- albo zmapować port przez Traefik TCP (wymaga dodatkowej konfiguracji).