jf/taskmanager
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

docs: explain Cloudflare registry upload limit and direct TLS prerequisite
All checks were successful
check / verify (push) Successful in 3m0s
Details
check / publish (push) Has been skipped
Details

Browse Source
This commit is contained in:
Weapie 2026-10-08 11:33:20 +02:00
parent 6fd5e21008
commit 90c85083bc
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
REGISTRY.md
View File

@ -59,6 +59,20 @@ curl -sS -D - -o /dev/null https://git.jfritzsche.de/v2/
Ohne Anmeldung ist HTTP 401 normal. Der `WWW-Authenticate`-Header muss als Bearer-Realm **`https://git.jfritzsche.de/v2/token`** nennen. Ein HTTP-Realm kann den Upload mit `authorization server did not include a token in the response` scheitern lassen, obwohl `docker login` erfolgreich erschien. Keine HTTP-/TLS-Ausnahmen als Ersatz einrichten. Nach Korrektur den fehlgeschlagenen `publish`-Job erneut starten; dafür weder einen Release-Tag verschieben noch die Anwendung neu versionieren.
### Upload scheitert mit HTTP 413 von Cloudflare
Enthält die Fehlerantwort beim Push einer Image-Schicht `413 Payload Too Large` und den HTML-Absender `cloudflare`, blockiert Cloudflare den Upload. Eine funktionierende Registry-Anmeldung und ein korrekter HTTPS-Realm schließen diesen Fehler nicht aus. Cloudflare begrenzt einzelne Upload-Anfragen je Tarif, bei Free/Pro auf 100 MB; kleinere konfigurierte Grenzwerte sind ebenfalls möglich. Siehe [Cloudflare: Error 413](https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-413/).
Für große Registry-Uploads kann `git.jfritzsche.de` als **DNS only** (graue Wolke) betrieben werden. **Vor der Umstellung** muss Dokploy/Traefik die Domain selbst auf Port 443 mit einem öffentlich vertrauenswürdigen Zertifikat, etwa von Let's Encrypt, bedienen. Ein reiner HTTP-Router auf `web` reicht nicht. Ein nur von Cloudflare vertrautes Origin-CA-Zertifikat reicht für direkte Docker-Clients ebenfalls nicht. Die direkte Erreichbarkeit des Origins muss zur Firewall-Konfiguration passen. Die Umstellung betrifft auch die Gitea-Weboberfläche auf derselben Domain.
Vorher von außerhalb des Servers mit dessen tatsächlicher öffentlicher IP prüfen:
```bash
curl --resolve git.jfritzsche.de:443:SERVER_IP -sS -D - -o /dev/null https://git.jfritzsche.de/v2/
```
Erwartet: erfolgreiche TLS-Prüfung ohne `-k`, HTTP 401 und HTTPS-Bearer-Realm. Erst danach den DNS-Proxy abschalten, die DNS-Auflösung abwarten und den fehlgeschlagenen Publish-Job erneut starten. Keine Änderung von ROOT_URL, Tokens oder Release-Tags erforderlich. Falls der Cloudflare-Schutz für die Domain erhalten bleiben soll, benötigt der Publisher stattdessen einen gezielt eingerichteten direkten HTTPS-Zugang zum Origin; auch der BuildKit-Container muss diesen verwenden. Ein erneuter Lauf über dieselbe begrenzte Verbindung behebt HTTP 413 nicht.
### Neues Release erstellen
```bash