Как да хоствате Gitea самостоятелно през 2026 г.: хранилища, SSH и безопасни надстройки

Ако вече сте опитвали да хоствате Gitea самостоятелно, вероятно познавате това неприятно състояние: интерфейсът се отваря, но ROOT_URL генерира localhost връзки за клониране или SSH портът не е препратен. Повторното създаване на контейнера рядко решава несъответствие между URL адреси, състояние и зависимости.

Това ръководство използва един конкретен критерий за завършеност — клониране през HTTPS и SSH, push на commit и LFS обект, отваряне на issue и изпълнение на една задача върху отделно регистриран Actions runner. Всяко конфигурационно решение се оценява спрямо този критерий, а не спрямо зеления индикатор на контейнера.

Открийте всеки устойчив байт в Gitea

Опишете състоянието, преди да бъде създаден първият реален запис: хранилища, LFS обекти, прикачени файлове, конфигурация и база данни. Монтирайте /data преди началното конфигуриране, запишете безвредни примерни данни и заменете контейнера, за да докажете, че този път наистина е устойчив. Потвърдете монтирането, като запишете безвредни данни, замените Gitea и ги прочетете отново.

Snapshot-ите са ценни за бързо връщане назад, но е необходимо независимо резервно копие, ако хостът или томът изчезне. Възстановете в празна среда с фиксирания image и проверете дали хранилищата преминават fsck, LFS обектите се изтеглят, а issue-ите, release-ите и потребителските права съвпадат със състоянието преди резервното копие. Използвайте устойчиви томове и snapshot-и, за да поддържате тези два механизма за възстановяване отделни.

Създайте заменяем Gitea контейнер

Следващата команда прави границата на контейнера видима, без да претендира, че осигурява всяка външна услуга.

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, проверете разрешената environment конфигурация, монтиранията и listener-а. Добавете прегледаните настройки за връзка с Postgres или MySQL при по-натоварена инсталация, както и SSH маршрут, ако е необходим; използвайте частни имена за частни услуги. Успешното стартиране е налице, когато можете да клонирате през HTTPS и SSH, да изпратите commit и LFS обект, да отворите issue и да изпълните една задача върху отделно регистриран Actions runner, а не когато docker ps отпечата Up.

Разделете Gitea от зависимостите му

Здравето на процеса и здравето на продукта са отделни понятия при Gitea. Порт 3000 може да отговаря, докато транзакцията от гледна точка на потребителя все още се проваля. Мрежовият договор за Gitea включва Postgres или MySQL при по-натоварена инсталация и SSH маршрут, ако е необходим. Дръжте частните endpoint-и във вътрешен DNS, разрешавайте само необходимите изходящи връзки и предоставете на Gitea service credential с ограничен обхват.

Използвайте това упражнение за проверка на готовността след съществени конфигурационни промени: клонирайте през HTTPS и SSH, изпратете commit и LFS обект, отворете issue и изпълнете една задача върху отделно регистриран Actions runner. Не включвайте скъпи външни проверки в liveness probe-ите, за да не предизвика прекъсване на външен доставчик цикъл от рестартирания. Работата по капацитета трябва да следи броя на хранилищата, Git object packing, LFS storage, database latency и runner workload, а не обикновените заявки към страници — това отразява реалното натоварване на Gitea по-добре от заявките към страници.

TLS е лесен; генерираните URL адреси — не

Публикувайте един HTTPS hostname за Gitea и дръжте суровия порт 3000 частен. Задайте ROOT_URL и SSH_DOMAIN към адресите, от които потребителите действително клонират. Така браузърите и API клиентите няма да научат два конкуриращи се адреса.

От чист клиент изпълнете работещата транзакция и проверете първата заявка, която се проваля. Използвайте ръководството за custom domain, когато DNS или TLS е конфигуриран неправилно. Разглеждайте „ROOT_URL генерира localhost връзки за клониране или SSH портът не е препратен“ като отделна application диагностика, след като маршрутът е доказано работещ.

Докажете работата на Gitea deployment-а от край до край

Не използвайте трафика от първия потребител като acceptance test за Gitea. Подгответе безвредно примерно състояние и изпълнете цялото действие „клониране през HTTPS и SSH, изпращане на commit и LFS обект, отваряне на issue и изпълнение на една задача върху отделно регистриран Actions runner“. Отбележете точния публичен URL, резултата, image reference-а и интервала от логове, свързани с изпълнението.

Заменете контейнера и повторете, без да възстановявате данните от нулата. След това възстановете върху празен хост; условието за успешно възстановяване е хранилищата да преминат fsck, LFS обектите да се изтеглят, а issue-ите, release-ите и потребителските права да съвпадат със състоянието преди резервното копие. При всяко изпълнение наблюдавайте броя на хранилищата, Git object packing, LFS storage, database latency и runner workload, а не обикновените заявки към страници, и дефинирайте alert при влошаване на транзакцията, а не при idle metrics на контейнера.

Една финална проверка трябва умишлено да се провали: временно забранете на тестовата идентичност достъпа до Postgres или MySQL при по-натоварена инсталация и до SSH маршрута, ако е необходим. Проверете дали полученото съобщение от Gitea идентифицира съответната граница, вместо да задейства изтриване на данни или безкраен рестарт. Възстановете валидното състояние и потвърдете, че същата примерна транзакция отново завършва успешно. Включете това кратко упражнение в release checklist-а.

Репетирайте рисковата промяна в Gitea

При Gitea наблюдавайте транзакция, а не процес: клониране през HTTPS и SSH, изпращане на commit и LFS обект, отваряне на issue и изпълнение на една задача върху отделно регистриран Actions runner. Комбинирайте нейните latency и error rate с броя на хранилищата, Git object packing, LFS storage, database latency и runner workload, а не с обикновените заявки към страници, така че alert-ът да идентифицира ограничения компонент.

Репетицията на upgrade-а трябва да обхваща факта, че schema migration-ите, repository hook-овете, package-ите и third-party runner-ите изискват поетапен Gitea upgrade. Възстановете, мигрирайте и изпълнете транзакцията преди замяната в production. Ако ROOT_URL генерира localhost връзки за клониране или SSH портът не е препратен, не изтривайте данни, за да направите стартирането успешно; сравнете version, variables, mounts и достижимостта на зависимостите в този ред.

Защитете ценната част на Gitea

След първото влизане прегледайте какво могат да правят анонимен посетител, обикновен потребител и администратор. Проблемът с Gitea, който трябва да избегнете, е да оставите installer-а или първия admin акаунт достъпни по-дълго от необходимото. Предвидената политика е да затворите installer-а след началното конфигуриране, да ограничите site administration и да използвате краткотрайни runner registration token-и.

Третирайте GITEA__security__SECRET_KEY съобразно ролята му в Gitea: съхранявайте чувствителните стойности извън Git, документирайте ефектите от ротацията и никога не заменяйте публичен пример със стойност в production. Дръжте акаунтите за зависимости отделно от човешките акаунти, забранявайте неизползвания egress, когато е практично, и ограничавайте работата, повлияна от броя на хранилищата, Git object packing, LFS storage, database latency и runner workload, а не от обикновените заявки към страници.

Какво Dockup трябва да автоматизира за Gitea

За Gitea Dockup може да създаде маршрута и TLS сертификата, да запази mount-овете, да достави secrets и да разположи Postgres или MySQL при по-натоварена инсталация и SSH маршрут, ако е необходим, в частна мрежа, като deployment-ът може да бъде към Dockup или към свързани сървъри.

Release gate-ът все още е конкретната Gitea транзакция: клониране през HTTPS и SSH, изпращане на commit и LFS обект, отваряне на issue и изпълнение на една задача върху отделно регистриран Actions runner. Проверете също условието за възстановяване — хранилищата преминават fsck, LFS обектите се изтеглят, а issue-ите, release-ите и потребителските права съвпадат със състоянието преди резервното копие. Тези две проверки показват дали deployment-ът работи и дали може да бъде възстановен.

Често задавани въпроси

От какво се нуждае Gitea за production deployment?

Маршрутизирайте Gitea контейнера на порт 3000 през един HTTPS origin. Поддържащото мрежово изискване е Postgres или MySQL при по-натоварена инсталация и SSH маршрут, ако е необходим. Не считайте Gitea за готова, докато не можете да клонирате през HTTPS и SSH, да изпратите commit и LFS обект, да отворите issue и да изпълните една задача върху отделно регистриран Actions runner.

Кои данни на Gitea трябва да бъдат включени в резервно копие?

Запазете /data и включете хранилищата, LFS обектите, прикачените файлове, конфигурацията и базата данни в един и същ recovery manifest. Чистото възстановяване на Gitea е успешно само когато хранилищата преминават fsck, LFS обектите се изтеглят, а issue-ите, release-ите и потребителските права съвпадат със състоянието преди резервното копие.

Необходим ли е HTTPS за Gitea зад reverse proxy?

Използвайте HTTPS за публичния Gitea origin и оставете порт 3000 във вътрешния маршрут. Прилагайте настройката на Gitea правилно: задайте ROOT_URL и SSH_DOMAIN към адресите, от които потребителите действително клонират. При Gitea HTTPS защитава идентификационните данни или потребителското съдържание при пренос и поддържа съгласувано поведение на клиентите, зависещо от origin.

Как трябва да бъде тестван Gitea upgrade?

Възстановете текущото състояние на Gitea в изолиран deployment, приложете кандидат-версията и повторете acceptance транзакцията. Обърнете особено внимание, тъй като schema migration-ите, repository hook-овете, package-ите и third-party runner-ите изискват поетапен Gitea upgrade. Запазете предишния Gitea image, докато не изясните границите на миграцията на данните и rollback-а.