Astroklient zbudował się poprawnie, ale jego obraz nie schodził do klastra.
Przyczyna nie leżała ani w CI, ani w rejestrze: CRD ImageUpdater w klastrze miał
CZTERY obrazy (data, logic, presentation, render), a plik w gicie sześć.
Brakowało astrodemo I astroklienta.
`image-updater.yaml` nie był w kustomization.yaml, więc ArgoCD go nie nakładał.
Dopisanie usługi do pliku nie robiło zatem nic — listy nikt nie stosował.
ODWRACAM DECYZJĘ UDOKUMENTOWANĄ W TYM REPO. README twierdziło, że wyłączenie jest
celowe: resource stoi w ns argocd, poza namespace docelowym aplikacji, i jest
konfiguracją kontrolera, a nie aplikacji. Rozumowanie nie było głupie, ale nie
wytrzymało praktyki — ręczny krok zapomniano dwa razy w ciągu dwóch tygodni,
najpierw dla astrodemo, potem dla astroklienta.
Najgorsza była CICHOŚĆ rozjazdu. Plik w gicie wyglądał poprawnie, git log
pokazywał dopisanie usługi, a objawem był obraz, który „się nie deployuje" — co
kieruje podejrzenia na CI albo na rejestr, czyli wszędzie poza właściwe miejsce.
Diagnoza wymaga porównania pliku ze stanem klastra, a nikt nie porównuje rzeczy,
o której nie wie, że mogą się różnić.
Przeszkody technicznej nie było: projekt ArgoCD dopuszcza dowolną przestrzeń nazw
(destinations: '*'), a dry-run serwerowy przyjmuje resource bez zastrzeżeń.
W README zostaje wyjaśnienie, dlaczego jest w kustomization mimo wcześniejszego
uzasadnienia — razem z prośbą, żeby przy ewentualnym wyjmowaniu usunąć też ten
akapit. Inaczej następna osoba przeczyta powód, którego już nie ma.
Zweryfikowane: kustomize build 38 obiektów (było 37), dry-run serwerowy
aktualizuje istniejący CRD.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Domyka drabinę produktów: astrodemo (dwie funkcje) → astroklient → astrololo.
Host astroklient.czernobog.pl, obraz astrololo-astroklient, port 8006.
WŁASNY STOS, NIE WSPÓLNY. Nowa para data-astroklient + logic-astroklient
i nowy udział /mnt/Tank1/astrololo-klient. Pule kont izolują klientów od siebie
w każdym wariancie, ale to izolacja PROGRAMOWA — opiera się na poprawności
mechanizmu pul. Granica na poziomie systemu plików nie zależy od tego, czy
w kodzie niczego nie przeoczono, a przy sprzątaniu demo nie da się przez pomyłkę
skasować cudzych danych, bo leżą gdzie indziej.
Klaster ma zapas (węzły na 24–38% pamięci), więc koszt dwóch podów nie był
argumentem przeciw.
Silnik własny (permisywny) — silnik B (AGPL) nie wchodzi do produktu
oddawanego klientom.
data-astroklient dostaje nodeAffinity na etykietę zdolności procesora, jak
pozostałe warstwy danych: ciągnie pandas, a przez nią NumPy z bazą x86-64-v2.
WPIS W LIŚCIE OBSERWOWANYCH OBRAZÓW od razu, z komentarzem dlaczego. Bez niego
usługa nie deployuje się sama: obraz powstaje w rejestrze, kustomization zostaje
na starym tagu, i wygląda to na zepsute CI. Tak zawisł kiedyś render.
Certyfikat obejmuje trzeci host; DNS już wskazuje (wildcard).
RUNBOOK: udział NFS ze WSZYSTKIMI CZTEREMA węzłami, konta jako hashe scrypt,
własny SESSION_SECRET i własna nazwa ciasteczka (trzy produkty nie mają powodu
uznawać nawzajem swoich sesji), unieważnianie dostępu bez wolumenu stanu, oraz
sprawdzenie po wdrożeniu.
W sprawdzeniu poprawiona rzecz, którą najpierw napisałem błędnie: BEZ SESJI
każdy adres oddaje 303, także nieistniejący, bo bramka logowania działa przed
trasowaniem. Pętla curl bez ciasteczka pokazywałaby 303 dla wszystkiego
i sugerowała, że nieobecne ekrany „są". Sprawdzenie ma sens dopiero z sesją —
i wtedy dają 404, nie 403.
Zweryfikowane: kustomize build (37 obiektów), dry-run serwerowy przyjmuje
wszystkie osiem nowych obiektów, kody odpowiedzi sprawdzone na złożonym drzewie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
data-demo wpadał w pętlę restartów na k3s-agent3:
RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2).
DIAGNOZA — to NIE jest różnica sprzętu. Wszystkie cztery węzły to maszyny
wirtualne. Trzy widzą procesor jako „QEMU Virtual CPU 2.5+" i mają komplet
rozszerzeń x86-64-v2; agent3 widzi „Common KVM processor" (kvm64) i nie ma
popcnt, ssse3, sse4_1 ani sse4_2. Fizyczny i7-3770 pod spodem obsługuje nawet
x86-64-v3 — te flagi są MASKOWANE przez domyślny model CPU w Proxmoksie.
agent3 ma 14 dni, pozostałe 52. Został dołożony później i pominięto przy nim
krok `--cpu host`, odnotowany w pamięci projektu 2 sierpnia. Nikt tego nie
zauważył, dopóki scheduler nie postawił tam akurat warstwy danych — jedynej,
która ciągnie pandas, a przez nią NumPy.
ZABEZPIECZENIE: data i data-demo wymagają etykiety
`astrololo.czernobog.pl/cpu-x86-64-v2`. Świadomie ETYKIETA, a nie wykluczenie
agent3 po nazwie: wykluczanie po nazwie znaczyłoby, że każdy KOLEJNY źle
postawiony węzeł znów zbiera się przez awarię. Nowy węzeł jest domyślnie
nieoznaczony, więc nie dostanie tych podów, dopóki ktoś go nie sprawdzi
i nie oznaczy. Pending z czytelnym powodem bije pętlę restartów z komunikatem
o „baseline optimizations".
KOLEJNOŚĆ: węzły trzeba oznaczyć PRZED wdrożeniem tej zmiany. Dziś etykietę ma
zero węzłów, więc samo zmergowanie posłałoby data w Pending.
RUNBOOK: skrypt sprawdzający węzły, naprawa u źródła (`qm set --cpu host` plus
pełne wyłączenie i włączenie maszyny — sam restart z gościa nie wystarcza),
oraz zastrzeżenie, że `--cpu host` blokuje migrację na żywo między hostami
o różnych procesorach.
PUŁAPKA PRZY CZYTANIU FLAG, udokumentowana bo kosztowała fałszywą diagnozę:
Linux raportuje SSE3 jako „pni", nie „sse3". Pierwsza wersja kontroli wskazała
przez to trzy zdrowe węzły jako niesprawne.
Przy okazji: lista węzłów w eksportach NFS obejmuje wszystkie cztery. Runbooki
wymieniały trzy, a klaster ma cztery — ten sam mechanizm, ta sama przyczyna.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '10ade555' to 'fd79513c'
updates image gitea/astrololo-logic tag '10ade555' to 'fd79513c'
updates image gitea/astrololo-presentation tag '10ade555' to 'fd79513c'
CI pcha obrazy wyłącznie pod tagiem ośmioznakowym i NIGDY nie pcha `latest`,
a manifest demo wskazywał `latest`. Pod zatrzymałby się na ImagePullBackOff —
objaw wygląda na problem z rejestrem albo z siecią, a jest zwykłym brakiem tagu.
Pozostałe usługi tego nie pokazują, bo image-updater dawno podmienił im tagi na
SHA. Nowa usługa startuje od zera i nie ma czego podmienić.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zastępuje gałąź feat/astroklient. Tamta była odbita od mastera sprzed jedenastu
commitów i miała przypięte obrazy `ee3c515d`, podczas gdy master stoi na
`320a0ab2` — merge w tamtej postaci COFNĄŁBY klaster o kilka wersji. Zamiast
przepychać cztery commity przez rebase (każdy konfliktował na README), gałąź
jest odtworzona jednym commitem na aktualnym masterze, z zachowanymi tagami.
ZMIANA NAZWY. astroklient-demo → astrodemo, wraz z nazwą obrazu, zmiennymi
(ASTRODEMO_USERS) i sekretem (astrololo-astrodemo). Nazwa „astroklient" jest
zarezerwowana dla warstwy pośredniej: pełne funkcje astrologiczne, bez
generowania tekstu i bez administracji.
BRAKOWAŁO WEJŚCIA Z ZEWNĄTRZ. Manifesty tworzyły Deployment i Service, ale żadnej
reguły w Ingressie — usługa wstałaby i nie dałoby się do niej wejść. Dołożony
host astrodemo.czernobog.pl z przekierowaniem z http, a certyfikat obejmuje teraz
oba hosty.
Osobny host, a nie ścieżka `/demo` pod adresem astrololo, CELOWO: ścieżka
dzieliłaby z pełną aplikacją pochodzenie w rozumieniu przeglądarki, czyli
i ciasteczka — wejście do jednej ruszałoby sesję w drugiej.
OBRAZ NA LIŚCIE OBSERWOWANYCH. Bez wpisu w image-updater.yaml obraz nigdy się nie
podbije, choćby CI go budowało. Tak przez chwilę wisiał render na :latest.
POPRAWKI W RUNBOOKU. Opis twierdził, że demo pracuje na produkcyjnej warstwie
danych — nieprawda od PRE-29, ma własny stos i własny udział. Ponadto zmiana nazw
rozjechała ścieżkę udziału: `zfs create Tank1/astrololo-astrodemo` przy manifeście
montującym `/mnt/Tank1/astrololo-demo` utworzyłby inny zbiór niż ten, którego pod
szuka. Ścieżka jest stanem na dysku, nie nazwą w kodzie — zostaje jak była.
Sprawdzone: `kubectl kustomize astrololo/` buduje 29 obiektów, tagi obrazów
pozostają na 320a0ab2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '320a0ab2' to '10ade555'
updates image gitea/astrololo-logic tag '320a0ab2' to '10ade555'
updates image gitea/astrololo-presentation tag '320a0ab2' to '10ade555'
updates image gitea/astrololo-data tag '1d0ff2f7' to '320a0ab2'
updates image gitea/astrololo-logic tag '1d0ff2f7' to '320a0ab2'
updates image gitea/astrololo-presentation tag '1d0ff2f7' to '320a0ab2'
updates image gitea/astrololo-data tag 'f0d07ee8' to '1d0ff2f7'
updates image gitea/astrololo-logic tag 'f0d07ee8' to '1d0ff2f7'
updates image gitea/astrololo-presentation tag 'f0d07ee8' to '1d0ff2f7'
Po zmergowaniu LOG-34 pody prezentacji nie wstały:
Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth
Runbook opisywał wyłącznie ścieżkę instalacji OD ZERA — SESSION_SECRET pojawiał
się tylko w komendzie `create secret`. Na działającym wdrożeniu sekret już
istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać.
Gorzej: opisana rotacja też by tam nie zadziałała. Używała JSON Patch z
`op: replace` na /data/SESSION_SECRET, a `replace` wymaga, żeby ścieżka już
istniała — czyli jedyna komenda, po którą sięgnąłby ktoś w tej sytuacji, też
odmawia.
Teraz obie potrzeby obsługuje JEDNA komenda: `--type=merge` ze `stringData`
dokłada albo nadpisuje i nie wymaga wcześniejszego istnienia klucza. Dopisane
sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie
w runbooku demo, gdzie czeka dokładnie ta sama pułapka.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '71bb3b9c' to 'f0d07ee8'
updates image gitea/astrololo-logic tag '71bb3b9c' to 'f0d07ee8'
updates image gitea/astrololo-presentation tag '71bb3b9c' to 'f0d07ee8'
SESSION_SECRET w sekrecie astrololo-auth. Pod bez niego CELOWO nie wstaje:
usługa z kontami, ale bez klucza, nie odróżniłaby ważnej sesji od podrobionej.
W README dopisana rotacja klucza jako awaryjny wyłącznik — podmiana unieważnia
wszystkie sesje naraz, co jest właściwą reakcją na podejrzenie przechwycenia
cudzej sesji.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pody przestały wstawać z komunikatem „bad option ... you might need
a /sbin/mount.<type> helper program". To NIE jest problem z udziałem ani
z uprawnieniami — serwer w ogóle nie został zapytany; jądro nie znalazło programu
pomocniczego, bo na węźle brakowało nfs-common.
Wymogu klienta NFS nie było w żadnym runbooku, choć wszystkie trzy warstwy
montują udziały z NAS-a. Luka była uśpiona: wszystko stało na jednym węźle, który
klienta miał, więc braku na pozostałych nie było jak zauważyć. Ujawniło się
dopiero, gdy zejście do zera replik — przy zupełnie innej naprawie —
przeplanowało pody gdzie indziej.
Dopisana tabela odróżniająca trzy komunikaty, które łatwo pomylić, bo wszystkie
kończą się niewstającym podem: brak klienta na węźle, odmowa serwera i brak praw
do zapisu. Każdy ma inną przyczynę i inne miejsce naprawy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag 'ee3c515d' to '71bb3b9c'
updates image gitea/astrololo-logic tag 'ee3c515d' to '71bb3b9c'
updates image gitea/astrololo-presentation tag 'ee3c515d' to '71bb3b9c'
updates image gitea/astrololo-data tag 'ac8a0e9f' to 'ee3c515d'
updates image gitea/astrololo-logic tag 'e2b50b28' to 'ee3c515d'
updates image gitea/astrololo-presentation tag 'e2b50b28' to 'ee3c515d'
updates image gitea/astrololo-data tag '003deb94' to 'b838cf47'
updates image gitea/astrololo-logic tag '003deb94' to 'e2b50b28'
updates image gitea/astrololo-presentation tag '003deb94' to 'e2b50b28'
updates image gitea/astrololo-data tag 'baf4e0e3' to '003deb94'
updates image gitea/astrololo-logic tag 'baf4e0e3' to '003deb94'
updates image gitea/astrololo-presentation tag 'a8339659' to '003deb94'
Treść powstała jako commit na gałęzi feat/pliki-zapis JUŻ PO zmergowaniu jej
PR-a, więc nigdy nie trafiła na master — został tam wyłącznie manifest.
Sam manifest jest w porządku (readOnly zdjęte), brakowało tylko opisu, co z tym
zrobić po stronie NAS-a.
Runbook zawiera: komendy midclt otwierające udział z bazami na zapis, sprawdzenie
przez exportfs (bo konfiguracja udziału i stan eksportu to dwie różne rzeczy),
ostrzeżenie, że przeładowanie musi iść przez zero replik zamiast rollout restart,
oraz listę kontrolną po wdrożeniu — z wyszukiwaniem jako punktem NAJWAŻNIEJSZYM,
bo to jedyne miejsce, w którym ta zmiana mogłaby przejść niezauważona.
Osobno wyliczone, co świadomie tracimy: DAN-25 dawał gwarancję, że baz nie da się
zmienić przez NFS, i tych dwóch rzeczy nie da się mieć naraz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Manifest, wpięcie w kustomization i runbook krok po kroku.
DECYZJE ZAPISANE W MANIFEŚCIE, ŻEBY NIE TRZEBA ICH BYŁO ODTWARZAĆ Z GŁOWY:
local-path, NIE NFS. Postgres zakłada semantykę blokad i fsync, której NFS nie
gwarantuje — to klasyczne źródło uszkodzenia bazy przy nagłym restarcie. Ceną
jest przywiązanie do węzła; przy luście odtwarzalnym z Excela to akceptowalne.
strategy: Recreate. Wolumen jest ReadWriteOnce, a dwa procesy Postgresa na jednym
katalogu danych to uszkodzona baza — rolling próbowałby wstać z nowym podem,
zanim stary zejdzie.
PGDATA w PODKATALOGU wolumenu: katalog główny potrafi zawierać wpisy systemu
plików, a initdb odmawia pracy w niepustym katalogu.
Wersja PRZYPIĘTA i poza image-updaterem: podbicie majora wymaga migracji katalogu
danych, więc nie może się zdarzyć samo, w nocy, przy okazji builda aplikacji.
C.UTF-8 zamiast pl_PL.UTF-8: dopasowanie tekstu robimy przez unaccent i pg_trgm,
nie przez collation, a pl_PL wymagałby obrazu z wygenerowanymi lokalizacjami.
DATA_PROVIDER zostaje na `excel`. Postgres można wdrożyć i obejrzeć BEZ ryzyka
dla działającego wyszukiwania; przełączenie to osobna, późniejsza decyzja.
SPRAWDZONE PRZED ODDANIEM: `kubectl kustomize astrololo` składa komplet 21
zasobów bez błędu, YAML parsuje się poprawnie, audyt odwołań potwierdza, że
jedynym brakującym sekretem jest astrololo-postgres (oba klucze), a DSN
postgresql+psycopg:// jest rozpoznawany przez SQLAlchemy z psycopg 3.
NIE SPRAWDZONE: skrypt inicjalizujący nie biegł przeciwko prawdziwemu Postgresowi
— na maszynie, na której to powstawało, nie ma Dockera. Zapisane wprost
w runbooku; krok 4 jest tam prawdziwym testem.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Pliki" pozwala wgrywać bazy, archiwizować je i (dla administratora)
kasować, a stan użycia jest klikany, więc musi przetrwać restart poda. Warstwa
danych musi zatem móc pisać na udziale — dotąd był montowany read-only.
ŚWIADOMY KOSZT: znika jedna warstwa obrony w głąb. Przejęcie warstwy danych
pozwala teraz nie tylko odczytać bazy, ale i je zmienić. Zostaje reszta: token
międzywarstwowy, szyfrowane łącze, ograniczenie eksportu NFS do konkretnych
hostów (DAN-25) oraz to, że kasować może wyłącznie konto administracyjne (PRE-27).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pod presentation nie wstawał: CreateContainerConfigError, „failed to create
subPath directory for volumeMount state".
MÓJ BŁĄD, NIE ZAGADKA. Udział z bazami jest wyeksportowany `ro: true`
z `root_squash` — ustawiłem to runbookiem DAN-25 i sam tam napisałem ostrzeżenie,
że po tej zmianie nikt nic nie wgra. Dokładając wolumen na konta zmieniłem
`readOnly` przy MONTOWANIU w podzie i uznałem sprawę za załatwioną, nie sprawdzając
eksportu po stronie serwera.
Przyczyna była zresztą podwójna i za każdym razem ta sama:
1. kubelet nie mógł utworzyć podkatalogu, bo udział jest tylko do odczytu,
2. a gdyby nawet mógł — kontenery działają jako root, a root_squash mapuje
roota na nobody, więc aplikacja i tak nie zapisałaby tam pliku kont.
ROZWIĄZANIE BEZ RUSZANIA DAN-25: osobny, mały udział /mnt/Tank1/astrololo-state,
zapisywalny, zawężony do tych samych trzech węzłów, z mapall_user na
nieuprzywilejowanego użytkownika (bezpieczniejsze niż no_root_squash, bo nie
oddaje roota). Udział z bazami ZOSTAJE tylko do odczytu.
Przy okazji znika subPath, czyli znika potrzeba, żeby kubelet cokolwiek zakładał —
katalog istnieje, bo jest korzeniem udziału.
Runbook README-stan-prezentacji.md zawiera test zapisu Z WĘZŁA do wykonania PRZED
wdrożeniem — dokładnie ten, którego zabrakło za pierwszym razem.
UWAGA: DAN-27 (zarządzanie plikami baz) uderzy w tę samą ścianę, bo wymaga zapisu
do udziału z BAZAMI. Ten commit tego nie rozwiązuje i celowo nie rusza DAN-25 —
to osobna decyzja, opisana na końcu runbooka.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ekran „Konta" zapisuje konta do pliku, więc prezentacja potrzebuje trwałego
miejsca — inaczej wszystkie konta znikałyby przy restarcie poda.
subPath, NIE cały udział: prezentacja dostaje wyłącznie własny podkatalog
`presentation-state` i nie widzi baz interpretacyjnych. Zamontowanie tu całego
/mnt/Tank1/astrololo dałoby jej wgląd w bazy i obeszłoby bokiem zamknięcie
dostępu z DAN-25.
Konto administracyjne zostaje w APP_USER/APP_PASSWORD z sekretu — celowo poza
plikiem, żeby nie dało się go skasować ani ograniczyć z aplikacji.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
updates image gitea/astrololo-data tag 'aec3f843' to 'baf4e0e3'
updates image gitea/astrololo-logic tag '8b6ecc72' to 'baf4e0e3'
updates image gitea/astrololo-presentation tag '8b6ecc72' to 'baf4e0e3'
updates image gitea/astrololo-data tag '40f5e459' to 'aec3f843'
updates image gitea/astrololo-logic tag '1be57a47' to 'aec3f843'
updates image gitea/astrololo-presentation tag '40f5e459' to 'aec3f843'
updates image gitea/astrololo-render tag 'latest' to 'aec3f843'
updates image gitea/astrololo-data tag 'e3114f3e' to '40f5e459'
updates image gitea/astrololo-logic tag '86a0f16f' to '40f5e459'
updates image gitea/astrololo-presentation tag 'e3114f3e' to '40f5e459'
updates image gitea/astrololo-data tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-logic tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-presentation tag 'bc80745a' to 'e3114f3e'
updates image gitea/astrololo-data tag '70c83cfc' to 'bc80745a'
updates image gitea/astrololo-logic tag '70c83cfc' to 'bc80745a'
updates image gitea/astrololo-presentation tag '70c83cfc' to 'bc80745a'
Wszystkie cztery usługi biegły na koncie `default` z AUTOMATYCZNIE montowanym
tokenem API Kubernetesa. Żadna z nich nie rozmawia z API klastra — sekrety dostają
przez `secretKeyRef`, który wstrzykuje kubelet, nie pod. Token był więc zbędny,
a leżał w każdym kontenerze jako gotowy punkt wyjścia do klastra dla kogoś, kto
przejmie proces (np. przez lukę w zależności).
`automountServiceAccountToken: false` w szablonie poda data/logic/presentation/
render. Zweryfikowane `kubectl kustomize` — pole trafia do `.spec.template.spec`,
nie do specu Deploymentu (tam byłoby ciche i bez efektu).
Zero wpływu na działanie: nic w kodzie nie woła API Kubernetesa.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
updates image gitea/astrololo-data tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-logic tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-presentation tag '4c1e7f88' to '70c83cfc'
updates image gitea/astrololo-data tag 'dd32f7e8' to '4c1e7f88'
updates image gitea/astrololo-logic tag 'dd32f7e8' to '4c1e7f88'
updates image gitea/astrololo-presentation tag 'd3d9b365' to '4c1e7f88'
updates image gitea/astrololo-data tag '78af6d47' to 'dd32f7e8'
updates image gitea/astrololo-logic tag '7b435d42' to 'dd32f7e8'
updates image gitea/astrololo-presentation tag '7b435d42' to 'dd32f7e8'
argocd-image-updater
gitea