Πώς να φιλοξενήσετε μόνοι σας το Gitea το 2026: repositories, SSH και ασφαλείς αναβαθμίσεις

Αν έχετε ήδη προσπαθήσει να φιλοξενήσετε μόνοι σας το Gitea, πιθανότατα γνωρίζετε αυτή την απογοητευτική κατάσταση: το UI εμφανίζεται, αλλά το ROOT_URL δημιουργεί συνδέσμους clone με localhost ή η θύρα SSH δεν προωθείται. Η αναδημιουργία του container σπάνια διορθώνει μια ασυμφωνία μεταξύ URLs, state και dependencies.

Αυτός ο οδηγός χρησιμοποιεί ένα συγκεκριμένο κριτήριο ολοκλήρωσης — clone μέσω HTTPS και SSH, push ενός commit και ενός LFS object, άνοιγμα ενός issue και εκτέλεση ενός job σε ξεχωριστά registered Actions runner. Κάθε επιλογή διαμόρφωσης αξιολογείται με βάση αυτό το κριτήριο και όχι με βάση μια πράσινη ένδειξη container.

Εντοπίστε κάθε durable byte στο Gitea

Καταγράψτε το state πριν δημιουργηθεί το πρώτο πραγματικό record: repositories, LFS objects, attachments, configuration και database. Κάντε mount το /data πριν από το bootstrap, γράψτε harmless sample data και αντικαταστήστε το container για να αποδείξετε ότι το path είναι πράγματι persistent. Επιβεβαιώστε το mount γράφοντας harmless data, αντικαθιστώντας το Gitea και διαβάζοντάς το ξανά.

Τα snapshots είναι χρήσιμα για γρήγορο rollback, αλλά χρειάζεται ανεξάρτητο backup όταν χαθεί ο host ή το volume. Κάντε restore σε ένα άδειο environment με το pinned image και επαληθεύστε ότι τα repositories περνούν fsck, τα LFS objects κατεβαίνουν και τα issues, releases και user permissions συμφωνούν με την κατάσταση πριν από το backup. Χρησιμοποιήστε τα persistent volumes και snapshots, ώστε να διατηρείτε ξεχωριστούς αυτούς τους δύο μηχανισμούς recovery.

Δημιουργήστε ένα replaceable Gitea container

Η παρακάτω εντολή κάνει ορατό το όριο του container, χωρίς να προσποιείται ότι κάνει provision κάθε εξωτερικής υπηρεσίας.

docker run -d \
  --name gitea \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v gitea-data:/data \
  -e GITEA__security__SECRET_KEY=replace-with-a-long-random-value \
  gitea/gitea:latest

Πριν ανοίξετε το ingress, ελέγξτε το resolved environment, τα mounts και τον listener. Προσθέστε τις ελεγμένες connection settings για Postgres ή MySQL σε μια πιο απαιτητική εγκατάσταση, καθώς και ένα SSH route αν χρειάζεται· χρησιμοποιήστε private names για private services. Ένα επιτυχημένο launch ολοκληρώνεται όταν μπορείτε να κάνετε clone μέσω HTTPS και SSH, να κάνετε push ενός commit και ενός LFS object, να ανοίξετε ένα issue και να εκτελέσετε ένα job σε ξεχωριστά registered Actions runner — όχι όταν το docker ps εμφανίζει Up.

Διαχωρίστε το Gitea από τα dependencies του

Το process health και το product health είναι διαφορετικά πράγματα για το Gitea. Η θύρα 3000 μπορεί να απαντά, ενώ η συναλλαγή που βλέπει ο χρήστης εξακολουθεί να αποτυγχάνει. Το network contract του Gitea περιλαμβάνει Postgres ή MySQL σε μια πιο απαιτητική εγκατάσταση και ένα SSH route αν χρειάζεται. Διατηρήστε τα private endpoints σε internal DNS, επιτρέψτε μόνο τα απαραίτητα outbound calls και δώστε στο Gitea ένα scoped service credential.

Χρησιμοποιήστε αυτή την άσκηση readiness μετά από σημαντικές αλλαγές configuration: clone μέσω HTTPS και SSH, push ενός commit και ενός LFS object, άνοιγμα ενός issue και εκτέλεση ενός job σε ξεχωριστά registered Actions runner. Κρατήστε τα ακριβά external checks εκτός των liveness probes, ώστε μια διακοπή λειτουργίας provider να μην προκαλέσει restart loop. Η capacity work θα πρέπει να παρακολουθεί το πλήθος των repositories, το Git object packing, το LFS storage, το database latency και το runner workload αντί για τα συνηθισμένα page requests, καθώς αυτά αποτυπώνουν καλύτερα την πραγματική πίεση στο Gitea.

Το TLS είναι εύκολο· τα generated URLs όχι

Εκθέστε ένα HTTPS hostname για το Gitea και κρατήστε το raw port 3000 private. Ορίστε τα ROOT_URL και SSH_DOMAIN στις διευθύνσεις από τις οποίες κάνουν πραγματικά clone οι χρήστες. Έτσι αποτρέπετε τα browsers και τα API clients από το να μαθαίνουν δύο ανταγωνιστικές διευθύνσεις.

Από ένα clean client, εκτελέστε τη known-good συναλλαγή και ελέγξτε το πρώτο request που αποτυγχάνει. Χρησιμοποιήστε τον οδηγό custom domain όταν υπάρχει πρόβλημα με το DNS ή το TLS. Αντιμετωπίστε το «το ROOT_URL δημιουργεί συνδέσμους clone με localhost ή η θύρα SSH δεν προωθείται» ως ξεχωριστή διάγνωση σε επίπεδο application, αφού αποδειχθεί ότι το route λειτουργεί.

Αποδείξτε τη λειτουργία του Gitea end to end

Μην χρησιμοποιήσετε την κίνηση του πρώτου χρήστη ως acceptance test για το Gitea. Προετοιμάστε harmless sample state και εκτελέστε την πλήρη ενέργεια «clone μέσω HTTPS και SSH, push ενός commit και ενός LFS object, άνοιγμα ενός issue και εκτέλεση ενός job σε ξεχωριστά registered Actions runner». Καταγράψτε το ακριβές public URL, το αποτέλεσμα, το image reference και το log interval που συνδέονται με την εκτέλεση.

Αντικαταστήστε το container και επαναλάβετε χωρίς να κάνετε rebuild τα data. Στη συνέχεια, κάντε recovery σε έναν άδειο host· η συνθήκη recovery είναι τα repositories να περνούν fsck, τα LFS objects να κατεβαίνουν και τα issues, releases και user permissions να συμφωνούν με την κατάσταση πριν από το backup. Σε κάθε pass, παρατηρείτε το πλήθος των repositories, το Git object packing, το LFS storage, το database latency και το runner workload αντί για τα συνηθισμένα page requests και ορίστε ένα alert γύρω από την υποβάθμιση της συναλλαγής, όχι γύρω από idle container metrics.

Ένας τελευταίος έλεγχος θα πρέπει να αποτύχει σκόπιμα: αρνηθείτε προσωρινά στην test identity την πρόσβαση στο Postgres ή το MySQL σε μια πιο απαιτητική εγκατάσταση και σε ένα SSH route αν χρειάζεται. Επαληθεύστε ότι το μήνυμα του Gitea προσδιορίζει το σχετικό boundary, αντί να προκαλεί διαγραφή data ή ατέρμονο restart. Επαναφέρετε τη σωστή συνθήκη και επιβεβαιώστε ότι η ίδια sample transaction ολοκληρώνεται επιτυχώς. Κρατήστε αυτή τη σύντομη άσκηση στη release checklist.

Κάντε rehearsal της επικίνδυνης αλλαγής στο Gitea

Για το Gitea, παρακολουθήστε μια συναλλαγή και όχι μια process: clone μέσω HTTPS και SSH, push ενός commit και ενός LFS object, άνοιγμα ενός issue και εκτέλεση ενός job σε ξεχωριστά registered Actions runner. Συνδυάστε το latency και το error rate της με το πλήθος των repositories, το Git object packing, το LFS storage, το database latency και το runner workload αντί για τα συνηθισμένα page requests, ώστε ένα alert να εντοπίζει το component που περιορίζει την απόδοση.

Το upgrade rehearsal πρέπει να καλύπτει το γεγονός ότι τα schema migrations, τα repository hooks, τα packages και τα third-party runners χρειάζονται staged upgrade του Gitea. Κάντε restore, migrate και εκτελέστε τη συναλλαγή πριν από την αντικατάσταση σε production. Αν το ROOT_URL δημιουργεί συνδέσμους clone με localhost ή η θύρα SSH δεν προωθείται, μην διαγράψετε data για να κάνετε το startup να εμφανίζεται ως επιτυχές· συγκρίνετε με αυτή τη σειρά την έκδοση, τις μεταβλητές, τα mounts και τη reachability των dependencies.

Προστατέψτε το πολύτιμο μέρος του Gitea

Μετά το πρώτο login, ελέγξτε τι μπορεί να κάνει ένας anonymous visitor, ένας ordinary user και ένας administrator. Το πρόβλημα του Gitea που πρέπει να αποφύγετε είναι να παραμείνουν προσβάσιμα το installer ή ο πρώτος admin account για περισσότερο από όσο χρειάζεται. Η προβλεπόμενη policy είναι να κλείσετε το installer μετά το bootstrap, να περιορίσετε το site administration και να διατηρείτε τα runner registration tokens short-lived.

Αντιμετωπίστε το GITEA__security__SECRET_KEY σύμφωνα με τον ρόλο του στο Gitea: κρατήστε τις ευαίσθητες τιμές εκτός Git, τεκμηριώστε τις επιπτώσεις του rotation και μην αντικαταστήσετε ποτέ ένα public example σε production. Διατηρήστε ξεχωριστά τα dependency accounts από τα human accounts, απαγορεύστε το unused egress όπου είναι πρακτικό και περιορίστε την εργασία που επηρεάζεται από το πλήθος των repositories, το Git object packing, το LFS storage, το database latency και το runner workload αντί για τα συνηθισμένα page requests.

Τι πρέπει να αυτοματοποιεί το Dockup για το Gitea

Για το Gitea, το Dockup μπορεί να δημιουργεί το route και το TLS certificate, να διατηρεί τα mounts, να παραδίδει secrets και να τοποθετεί Postgres ή MySQL για μια πιο απαιτητική εγκατάσταση, καθώς και ένα SSH route αν χρειάζεται, σε private networking, ενώ κάνει deploy είτε στο Dockup είτε σε attached servers.

Το release gate παραμένει η συγκεκριμένη συναλλαγή του Gitea: clone μέσω HTTPS και SSH, push ενός commit και ενός LFS object, άνοιγμα ενός issue και εκτέλεση ενός job σε ξεχωριστά registered Actions runner. Επαληθεύστε επίσης τη συνθήκη restore — τα repositories περνούν fsck, τα LFS objects κατεβαίνουν και τα issues, releases και user permissions συμφωνούν με την κατάσταση πριν από το backup. Αυτοί οι δύο έλεγχοι δείχνουν αν το deployment λειτουργεί και αν μπορεί να ανακτηθεί.

Συχνές ερωτήσεις

Τι χρειάζεται το Gitea για ένα production deployment;

Δρομολογήστε το Gitea container στη θύρα 3000 μέσω ενός HTTPS origin. Η υποστηρικτική network requirement είναι Postgres ή MySQL σε μια πιο απαιτητική εγκατάσταση και ένα SSH route αν χρειάζεται. Μην θεωρήσετε το Gitea έτοιμο πριν μπορέσετε να κάνετε clone μέσω HTTPS και SSH, να κάνετε push ενός commit και ενός LFS object, να ανοίξετε ένα issue και να εκτελέσετε ένα job σε ξεχωριστά registered Actions runner.

Ποια δεδομένα του Gitea πρέπει να περιλαμβάνονται σε backup;

Κάντε persist το /data και συμπεριλάβετε τα repositories, τα LFS objects, τα attachments, το configuration και τη database στο ίδιο recovery manifest. Ένα clean restore του Gitea θεωρείται επιτυχές μόνο όταν τα repositories περνούν fsck, τα LFS objects κατεβαίνουν και τα issues, releases και user permissions συμφωνούν με την κατάσταση πριν από το backup.

Απαιτεί το Gitea HTTPS πίσω από reverse proxy;

Χρησιμοποιήστε HTTPS για το public Gitea origin και κρατήστε τη θύρα 3000 στο internal route. Εφαρμόστε σωστά τη ρύθμιση του Gitea: ορίστε τα ROOT_URL και SSH_DOMAIN στις διευθύνσεις από τις οποίες κάνουν πραγματικά clone οι χρήστες. Για το Gitea, το HTTPS προστατεύει τα credentials ή το περιεχόμενο των χρηστών κατά τη μεταφορά και διατηρεί συνεπή τη συμπεριφορά των clients που εξαρτάται από το origin.

Πώς πρέπει να ελεγχθεί μια αναβάθμιση του Gitea;

Κάντε restore το τρέχον state του Gitea σε ένα isolated deployment, εφαρμόστε την υποψήφια έκδοση και επαναλάβετε τη συναλλαγή acceptance. Δώστε ιδιαίτερη προσοχή, επειδή τα schema migrations, τα repository hooks, τα packages και τα third-party runners χρειάζονται staged upgrade του Gitea. Διατηρήστε το προηγούμενο Gitea image μέχρι να κατανοήσετε τα όρια του data migration και του rollback.