Intially I had setup a high availability cluster for my gitea instance,
basically as an experiment. Though this experiement was doomed by my
effort to keep the required infrastructure small when ever possible. In
the end I struggled with constant downtimes due to memory limitations
and other sideeffects.
On the other hand I do _not_ need a highly available DB for my very
personal git-server. In the worst case I can still deconnect the whole
thing from the internet, restart it and investigate issues without
pressure.
Note though that even this little shift needed some preparation:
1. Forward the DB-port to the local machine
`kubectl port-forward -n gitea service/gitea-postgresql-ha-pgpool 5432:5432`
2. Create valid backup of the DB
`pg_dump --dbname=gitea --file=/app/Gitea-$(date +%Y_%m_%d_%H_%M_%S)-dump.sql -F c --host=localhost --port=5432`
3. Apply the new setup
`ansible-playbook site.yml --tags=gitea`
4. Forward the DB-port to the local machine of the new DB
`kubectl port-forward -n gitea service/gitea-postgresql 5432:5432`
5. Restore the DB cleanly (`-c`)
`pg_restore -c --username=gitea --host=localhost --port=5432 -d gitea Gitea-*-dump.sql`
6. Reupload one of the SSH-Keys to restore the SSH-configuration on disk
from DB.
My gitea-server is basically my safe harbor for private git-projects. It
is not meant to be public.
Even more important that would shift responsibilities a lot, especially
legal liabilities may become important suddenly, when the server is
open.
Furthermore I can't guarantee a process availability when I cannot make
any assumptions about the usage. And, I cannot make such assumptions for
an open and public project which I maintain in my spare-time.
By applying this change the kubernetes cluster gets a gitea-server
setup. Note, that I use a custom-image which I have to automate in
future. The customization is necessary since I use asciidoc very often
and the default-gitea doesn't render these files, so it becomes a bit
cumbersome to read them on the web.
