Articles tagged "gitea"

Docker-Gitea-Postgres Part 4: Gitea startet nicht

Teil 4 einer Reihe über Gitea & Postgres im Docker-Container: Gitea startet nicht

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Docker und Debugging - zwei Welten treffen aufeinander

Vorlauf

Bis zu diesem Schritt lief soweit alles problemlos ab:

  • Backup von Gitea - und auch dessen Restore auf einer anderen Maschine!
  • Backup der alten Postgres-9-Instanz
  • Testweiser Restore des Postgres-Backups auf einem Postgres-9 und Postgres-14

Gitea startet nicht mehr - oder doch?

Ein Versuch auf das Web-Frontend zuzugreifen, brachte verschiedene Fehler des Reverse-Proxys zu Tage. Ein Zugriff auf Gitea war aber nicht möglich.

Erst nach einiger Zeit und einigen docker ps -a fiel mir auf, dass der Gitea-Container sich offensichtlich immer wieder beendete - aber eben nicht sofort, sondern nach ca. einer Minuten. Er wurde dann wieder neu gestartet und nach einer weiteren Minute begann das Spiel von vorne. Von einem Blick in die Logs erhofft man sich ja Aufschluss, was da gerade vor sich geht:

root@docker:~ # docker logs gitea
Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 15
cmd/web.go:150:runWeb() [I] Global init
routers/init.go:107:GlobalInitInstalled() [I] Git Version: 2.30.3, Wire Protocol Version 2 Enabled
routers/init.go:110:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
routers/init.go:111:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
routers/init.go:112:GlobalInitInstalled() [I] Custom path: /data/gitea
routers/init.go:113:GlobalInitInstalled() [I] Log path: /data/gitea/log
routers/init.go:114:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
routers/init.go:115:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

Und das wiederholte sich immer und immer wieder. Die ersten beiden Zeilen kommen BTW vom OpenSSH-Server, welcher auch im Gitea-Container läuft.

Nach einiger Zeit (und Frust) bin ich dann wieder mal in den Container gegangen und hab dort nach weiteren Informationen gesucht. Und siehe da, im Gitea-Log-File stehen Informationen, die es - warum ich immer - nicht ins docker logs geschafft haben:

root@bash-5.1# cat /data/gitea/logs/gitea.log
[...]
routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #8/10...
cmd/web.go:153:runWeb() [I] PING DATABASE postgres
routers/common/db.go:33:InitDBEngine() [E] ORM engine initialization attempt #8/10 failed. Error: pq: password authentication failed for user "gitea"
routers/common/db.go:34:InitDBEngine() [I] Backing off for 3 seconds
[...]

Warum zum Geier schafft es eine solch essentielle Fehlermeldung nicht in die docker logs?! Warum auch immer ich die Idee hat, mir im Container die Logs anzusehen - ohne diese Zeilen hätte ich vermutlich bald aufgegeben und wäre wieder auf die alte Postgres-Version zurückgegangen.

Was sagt denn die Datenbank dazu?

Mit diesem Hinweis schaute ich dann natürlich auch noch in die docker logs der Datenbank. Und siehe da:

root@bash-5.1# docker logs gitea_db
[...]
FATAL:  password authentication failed for user "gitea"
DETAIL:  User "gitea" does not have a valid SCRAM secret.
    Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"
[...]

Der Fehler ist also weniger bei Gitea- als in der Postgres-Datenbank zu suchen - wobei "Fehler" hier natürlich auch nicht korrekt ist. Der alte, aus dem Backup stammende, gitea-Benutzer der Postgres-Datenbank hat einfach kein passend verschlüsseltes Passwort!

Das Setzen eines neue Passworts wird im Teil 5: Postgres MD5- und SCRAM-Passwörter beschrieben.

Fazit

Solche Dinge begegnen mir im Docker-Umfeld immer und immer wieder. Gar keine Logs, Logs nicht an der vermuteten/offiziellen Stelle, zu schnell rotiert Logs - Gründe dafür gibt's viele. Aber genau das sorgt dafür, dass man ohne tiefes Wissen gar keine Chance mehr hat, selbständig aus dieser Situation wieder herauszukommen. Docker wurde eingeführt, damit sich Admins mit gewissen Themen nicht mehr beschäftigen müss(t)en - aber dann eben einfach an einer Wand zerschellen, weil sie keine Ahnung (in diesem Fall rund um die Logs) haben...

Docker-Gitea-Postgres Part 1: Gitea Backup

Teil 1 einer Reihe über Gitea & Postgres im Docker-Container: Gitea Backup

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Gitea

Backup allgemein

Gitea hat eine integrierte Backup-Funktion, welche man sehr einfach über die Command-Line aufrufen kann. Ergebnis ist dann eine ZIP-Datei, welche später oder wo anders wieder eingespielt werden kann:

gitea@gitea:~ # gitea dump -c .../app.ini --file /tmp/gitea-dump.zip

Backup im Docker

Wenn Gitea im Docker läuft, muss man natürlich auf die laufende Gitea-Instanz im Container zugreifen und anschließend die Sicherung aus dem Container holen. Dies kann mit dem folgenden Script passieren, welches der Sicherung am Schluss auch noch einen Zeitstempel verpasst:

#!/bin/ash

CONT_NAME=gitea
CONT_ID=$(docker ps -qf "name=^${CONT_NAME}$")
docker exec -u git -it -w /tmp ${CONT_ID} bash -c '/app/gitea/gitea dump -c /data/gitea/conf/app.ini --file /tmp/gitea-dump.zip'
docker cp ${CONT_ID}:/tmp/gitea-dump.zip .
docker exec -u git -it -w /tmp ${CONT_ID} bash -c 'rm /tmp/gitea-dump.zip'
BACKUPFILE=gitea-dump-$(date +"%Y%m%d%H%M").zip
mv ./gitea-dump.zip $BACKUPFILE

Da ich aktuell nur eine Gitea-Instanz am Laufen habe, ist der Container-Name im Script in Zeile 3 fest auf gitea gesetzt - natürlich kann man das Script an dieser Stelle erweitern und z.B. den Container-Namen an der Command-Line übergeben. Oder über ein Konstrukt eine Schleife bauen, welche gleich alle Gitea-Instanzen sichert.

Apropos Anpassungen: Meine Docker-Hosts nutzen AlpineLinux, daher ruft das Script in Zeile 1 eine ash auf - dies muss ggf. noch auf sh oder bash korrigiert werden.

Restore

Leider gibt es aktuell kein Restore-Command für Gitea. Die notwendigen Schritte sind jedoch IMHO ausreichend in der - nicht immer sehr ausführlichen - Dokumentation von Gitea unter Usage: Backup and Restore beschrieben. Bei mir haben die Schritte funktioniert - sowohl beim Restore als auch beim Umzug auf einen anderen Rechner/Host. Falls der Link nicht mehr gehen sollte, hier die Schritte:

# open bash session in container
root@docker:~ # docker exec --user git -it 2a83b293548e bash
# unzip your backup file within the container
root@bash-5.1# unzip gitea-dump-1610949662.zip
root@bash-5.1# cd gitea-dump-1610949662
# restore the gitea data
root@bash-5.1# mv data/* /data/gitea
# restore the repositories itself
root@bash-5.1# mv repos/* /data/git/repositories/
# adjust file permissions
root@bash-5.1# chown -R git:git /data
# Regenerate Git Hooks
root@bash-5.1# /usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks