Установка Gitea на VPS: Легковесный self-hosted Git-сервер с Docker и SSL

Что мы настраиваем и зачем

В современном мире разработки Git стал стандартом де-факто для контроля версий кода. Однако, полагаться на сторонние сервисы, такие как GitHub, GitLab.com или Bitbucket, не всегда оптимально. Для многих команд и индивидуальных разработчиков возникает потребность в собственном, полностью контролируемом Git-сервере. Именно эту задачу решает Gitea.

Gitea — это легковесный, открытый и самохостируемый (self-hosted) сервис Git, написанный на Go. Он предоставляет полноценный функционал, аналогичный GitHub или GitLab, но при этом потребляет значительно меньше ресурсов, что делает его идеальным выбором для развертывания на VPS или даже на мини-компьютере вроде Raspberry Pi. Вы получите интуитивно понятный веб-интерфейс для управления репозиториями, пользователями, командами, запросами на слияние (pull requests), отслеживанием задач (issues) и многим другим.

Что получит читатель в итоге

После прохождения этого руководства у вас будет полностью настроенный и работающий Git-сервер Gitea, доступный по вашему доменному имени с защищенным HTTPS-соединением. Вы сможете создавать публичные и приватные репозитории, приглашать коллег для совместной работы, управлять доступом и использовать все привычные Git-операции через веб-интерфейс или командную строку. Ваша инфраструктура будет полностью под вашим контролем, обеспечивая конфиденциальность и независимость.

Какие альтернативы есть и почему self-hosted на VPS

Существует несколько основных подходов к хостингу Git-репозиториев:

• Cloud-managed сервисы (GitHub, GitLab.com, Bitbucket): Это наиболее простой вариант с точки зрения обслуживания. Вы просто регистрируетесь и начинаете работать. Однако, вы зависите от политики и инфраструктуры провайдера, можете столкнуться с ограничениями бесплатных планов, а также с вопросами конфиденциальности данных, которые хранятся на сторонних серверах.
• Self-hosted GitLab Community Edition (CE): GitLab CE — это мощное решение, предлагающее не только Git-хостинг, но и полный DevOps-цикл: CI/CD, контейнерный реестр, мониторинг и многое другое. Однако, GitLab CE требует значительно больше ресурсов (минимум 4 ГБ RAM для комфортной работы), что делает его менее подходящим для небольших VPS и команд.
• Self-hosted Gitea: Gitea занимает нишу между простыми облачными сервисами и ресурсоемким GitLab. Он предлагает богатый функционал Git-хостинга при минимальном потреблении ресурсов. Это идеальный выбор, если вам нужен полноценный Git-сервер без лишних функций и без больших затрат на инфраструктуру. Развертывание на VPS дает вам полный контроль над данными, возможность кастомизации и интеграции с вашей собственной экосистемой. Кроме того, Docker значительно упрощает развертывание и управление Gitea, изолируя его от основной системы и делая переносимым.

Выбор Gitea на VPS позволяет объединить преимущества самохостинга (контроль, приватность) с эффективным использованием ресурсов и простотой развертывания благодаря Docker.

Какой VPS-конфиг нужен под эту задачу

Для установки Gitea на VPS с Docker и Caddy, как правило, не требуются экстремально мощные ресурсы. Gitea оптимизирован для работы на скромном оборудовании, но наличие Docker и Caddy добавляет небольшие накладные расходы. Важно учитывать, сколько пользователей будет активно работать с Gitea и сколько репозиториев планируется размещать.

Минимальные требования

• CPU: 1 vCore (например, Intel Xeon E3/E5 или AMD EPYC). Для небольших команд до 5-10 человек этого будет достаточно.
• RAM: 2 ГБ. Этого хватит для операционной системы, Docker-демона, контейнеров Gitea и Caddy. Если планируется очень активное использование или другие сервисы на том же VPS, лучше рассмотреть 4 ГБ.
• Диск: 40-60 ГБ SSD. SSD критичен для производительности Git-операций. 40 ГБ хватит для ОС, Docker-образов и нескольких десятков репозиториев. Если репозитории будут очень большими или их будет много, рассмотрите 80-100 ГБ.
• Сеть: 100 Мбит/с. Для большинства сценариев этого более чем достаточно. Важнее стабильность канала и низкая задержка.

Конкретный VPS-план под задачу (актуально на 2026 год)

Для комфортной работы Gitea с Docker и Caddy для команды до 10-20 разработчиков и десятков репозиториев, рекомендуется следующий конфигурации VPS:

• CPU: 2 vCore (например, Intel Xeon E5-2690v4 или AMD EPYC 7002 series).
• RAM: 4 ГБ DDR4.
• Диск: 80 ГБ NVMe SSD. NVMe обеспечит максимальную скорость дисковых операций, что важно для Git.
• Сеть: 1 Гбит/с порт с неограниченным трафиком или большим объемом.

Такой VPS-конфиг обеспечит отличную производительность и запас на будущее. Например, можно взять VPS с указанными характеристиками.

Когда нужен dedicated, а не VPS

Dedicated-сервер стоит рассматривать, если:

• Очень большая команда: Более 50-100 активных пользователей.
• Крайне большие репозитории: Репозитории с гигабайтами бинарных файлов (LFS).
• Критичные требования к производительности: Высокая нагрузка на Git-операции в режиме 24/7.
• Строгие требования к безопасности/изоляции: Полная изоляция от "соседей" по гипервизору.
• Планируется множество других сервисов: Кроме Gitea на сервере будут работать CI/CD-агенты, базы данных, веб-серверы для других проектов и т.д.

Для большинства задач Gitea, особенно для стартапов, небольших команд и личных проектов, VPS будет оптимальным и экономически выгодным решением.

Локация: на что влияет

Выбор локации VPS имеет значение для:

• Задержки (Latency): Чем ближе сервер к вашей команде и основным пользователям, тем меньше будет задержка при выполнении Git-операций и работе с веб-интерфейсом. Это особенно критично для разработчиков, находящихся далеко от сервера.
• Соответствие законодательству: В некоторых случаях, особенно для компаний, могут быть требования к хранению данных в определенной юрисдикции.
• Доступность: Выбирайте локацию с надежной сетевой инфраструктурой и хорошими каналами связи.

Оптимально выбирать дата-центр, расположенный географически близко к большинству ваших пользователей.

Подготовка сервера

Перед тем как приступить к установке Gitea, необходимо выполнить базовую настройку вашего VPS. Мы будем использовать Ubuntu Server 24.04 LTS, так как это актуальная и стабильная версия операционной системы на 2026 год.

Минимальная настройка после провижининга

После получения доступа к вашему VPS (обычно через SSH под пользователем root), первым делом обновите систему и создайте нового пользователя с правами sudo.

# Обновление списка пакетов и их обновление до последних версий
sudo apt update && sudo apt upgrade -y

# Создание нового пользователя (замените 'ваш_пользователь' на желаемое имя)
sudo adduser ваш_пользователь

# Добавление пользователя в группу sudo для получения административных прав
sudo usermod -aG sudo ваш_пользователь

Выйдите из сессии root и войдите под новым пользователем:

exit
# Затем войдите снова с вашим_пользователем
ssh ваш_пользователь@ваш_ip_сервера

Настройка SSH-ключей (рекомендуется)

Для повышения безопасности рекомендуется использовать SSH-ключи вместо паролей. Сгенерируйте ключ на вашей локальной машине (если еще нет):

# На вашей локальной машине
ssh-keygen -t ed25519 -C "ваш[email protected]"

Скопируйте публичный ключ на сервер:

# На вашей локальной машине
ssh-copy-id ваш_пользователь@ваш_ip_сервера

После этого отключите вход по паролю для SSH (файл /etc/ssh/sshd_config):

# На сервере
sudo nano /etc/ssh/sshd_config

Найдите и измените следующие строки:

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no

Перезапустите SSH-сервер:

sudo systemctl restart sshd

Установка Fail2Ban

Fail2Ban защищает ваш сервер от атак методом подбора паролей, блокируя IP-адреса, с которых происходят многочисленные неудачные попытки входа.

# Установка Fail2Ban
sudo apt install fail2ban -y

# Копирование стандартного конфига для его настройки
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Открытие файла для редактирования (опционально, для более тонкой настройки)
sudo nano /etc/fail2ban/jail.local

Обычно достаточно дефолтных настроек, но вы можете изменить bantime, findtime и maxretry. Убедитесь, что секция [sshd] включена.

# Пример содержимого jail.local (убедитесь, что enabled = true)
[DEFAULT]
bantime  = 1d
findtime = 10m
maxretry = 5

[sshd]
enabled = true
mode   = aggressive
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

# Перезапуск Fail2Ban для применения изменений
sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

Настройка Firewall (UFW)

Uncomplicated Firewall (UFW) — это простой в использовании интерфейс для iptables. Настроим его, чтобы разрешить только необходимые порты.

# Установка UFW
sudo apt install ufw -y

# Разрешить SSH (по умолчанию порт 22)
sudo ufw allow ssh

# Разрешить HTTP (порт 80) и HTTPS (порт 443) для веб-сервера (Caddy)
sudo ufw allow http
sudo ufw allow https

# Включить UFW
sudo ufw enable

Подтвердите включение, нажав y. Проверить статус фаервола можно командой sudo ufw status verbose.

Теперь ваш сервер готов к установке Docker и Gitea.

Установка ПО — пошагово

Мы будем использовать Docker и Docker Compose для развертывания Gitea. Это обеспечивает изоляцию приложения, упрощает управление зависимостями и облегчает обновление.

1. Установка Docker Engine

Для установки Docker Engine на Ubuntu 24.04 LTS (Noble Numbat) следуйте официальным рекомендациям, актуальным на 2026 год.

# Удаление старых версий Docker, если они есть
for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; do sudo apt remove $pkg; done

# Обновление списка пакетов
sudo apt update

# Установка необходимых пакетов для работы с репозиториями
sudo apt install ca-certificates curl gnupg -y

# Добавление официального GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Добавление репозитория Docker в APT-источники
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Обновление списка пакетов после добавления репозитория Docker
sudo apt update

# Установка Docker Engine, Docker CLI, containerd и Docker Compose плагина
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

Проверка установки Docker:

# Проверка версии Docker
docker --version

# Проверка статуса Docker-сервиса
sudo systemctl status docker

# Запуск тестового контейнера 'hello-world'
sudo docker run hello-world

Добавьте вашего пользователя в группу docker, чтобы не использовать sudo для каждой команды Docker:

# Добавление пользователя в группу docker
sudo usermod -aG docker ваш_пользователь

# Примените изменения группы (выйдите и войдите заново или перезагрузите систему)
newgrp docker

2. Создание структуры каталогов для Gitea

Мы создадим директории для хранения данных Gitea и конфигурации Docker Compose. Это обеспечит персистентность данных и чистоту структуры.

# Создание корневой директории для проекта Gitea
mkdir -p ~/gitea

# Переход в созданную директорию
cd ~/gitea

# Создание директории для хранения постоянных данных Gitea
mkdir -p ./data

3. Создание файла docker-compose.yml для Gitea и Caddy

Этот файл определит сервисы Gitea и Caddy, их зависимости, тома и сетевые настройки. Мы будем использовать SQLite в качестве базы данных для простоты, что идеально для небольших установок. Для больших проектов рассмотрите PostgreSQL или MySQL.

Создайте файл docker-compose.yml в директории ~/gitea:

# Создание файла docker-compose.yml
nano docker-compose.yml

Вставьте следующее содержимое, заменив your.domain.com на ваш фактический домен:

# docker-compose.yml
version: "3.8"

services:
  gitea:
    image: gitea/gitea:1.22.0 # Актуальная версия на 2026 год, проверьте https://dl.gitea.io/gitea/
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__DATABASE__DB_TYPE=sqlite3 # Используем SQLite для простоты
      - GITEA__DATABASE__PATH=/data/gitea.db # Путь к файлу базы данных SQLite
      - GITEA__SERVER__DOMAIN=your.domain.com # Ваш домен
      - GITEA__SERVER__SSH_DOMAIN=your.domain.com # Домен для SSH-доступа
      - GITEA__SERVER__HTTP_PORT=3000 # Внутренний порт Gitea
      - GITEA__SERVER__APP_DATA_PATH=/data # Путь для данных Gitea внутри контейнера
      - GITEA__SERVER__ROOT_URL=https://your.domain.com/ # Базовый URL для Gitea
      - GITEA__SECURITY__INSTALL_LOCK=true # Блокировка страницы установки после первой настройки
      - GITEA__SERVICE__DISABLE_REGISTRATION=false # Разрешить регистрацию новых пользователей (true для приватного сервера)
      - GITEA__SERVICE__REQUIRE_SIGNIN_VIEW=false # Требовать вход для просмотра репозиториев (true для приватного сервера)
      - GITEA__SESSION__PROVIDER=db # Используем базу данных для сессий
      - GITEA__CACHE__ADAPTER=redis # Рекомендуется для производительности
      - GITEA__CACHE__HOST=redis:6379 # Хост Redis
      - GITEA__QUEUE__TYPE=redis # Очередь задач через Redis
      - GITEA__QUEUE__CONN_STR=redis://redis:6379/0 # Строка подключения к Redis
    restart: always
    volumes:
      - ./data:/data # Маппинг локальной директории данных к контейнеру
      - /etc/timezone:/etc/timezone:ro # Синхронизация часового пояса
      - /etc/localtime:/etc/localtime:ro # Синхронизация локального времени
    ports:
      - "3000:3000" # Внутренний HTTP-порт Gitea (для Caddy)
      - "2222:22" # SSH-порт Gitea (маппим на 2222, чтобы не конфликтовать с хостом)
    networks:
      - gitea-network

  caddy:
    image: caddy:2.7.5 # Актуальная версия Caddy на 2026 год
    container_name: caddy
    restart: always
    ports:
      - "80:80" # HTTP для Let's Encrypt challenge и перенаправления
      - "443:443" # HTTPS
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile # Файл конфигурации Caddy
      - ./caddy_data:/data # Хранилище Caddy для сертификатов и состояния
    environment:
      - GITEA_DOMAIN=your.domain.com # Передача домена в Caddyfile через переменную
    networks:
      - gitea-network
    depends_on:
      - gitea # Caddy зависит от Gitea

  redis:
    image: redis:7.2-alpine # Легковесная версия Redis
    container_name: redis
    restart: always
    volumes:
      - ./redis_data:/data # Хранилище данных Redis
    networks:
      - gitea-network
    command: redis-server --appendonly yes # Включение персистентности данных

networks:
  gitea-network:
    driver: bridge

Важно: Замените your.domain.com на ваш реальный домен. Убедитесь, что для вашего домена (например, gitea.example.com) создана A-запись, указывающая на IP-адрес вашего VPS.

Примечание по версиям: Версии gitea/gitea:1.22.0, caddy:2.7.5 и redis:7.2-alpine указаны как актуальные на 2026 год. Всегда проверяйте официальные репозитории Docker Hub для получения самых свежих и стабильных версий.

4. Создание файла Caddyfile для Caddy

Caddy автоматически управляет SSL-сертификатами через Let's Encrypt. Создайте файл Caddyfile в той же директории ~/gitea:

# Создание файла Caddyfile
nano Caddyfile

Вставьте следующее содержимое:

# Caddyfile
{env.GITEA_DOMAIN} {
    # Автоматическое HTTPS
    tls {
        # Используем Let's Encrypt
        acme_challenge http
    }

    # Обратный прокси для Gitea
    reverse_proxy gitea:3000 {
        # Проксируем заголовки, необходимые Gitea
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-Proto {scheme}
        header_up X-Forwarded-For {remote_ip}
    }

    # Настройки для больших файлов (Git LFS)
    # Gitea сам обрабатывает LFS, но Caddy должен пропускать большие запросы
    # Если у вас будут очень большие LFS файлы, может потребоваться увеличение body_size
    # (по умолчанию Caddy обрабатывает до 10MB)
    # Для Gitea это обычно не требуется, так как он сам принимает данные
}

Переменная {env.GITEA_DOMAIN} будет автоматически заменена на значение из docker-compose.yml.

5. Запуск Gitea и Caddy с Docker Compose

После создания обоих файлов, вы готовы запустить Gitea.

# Переход в директорию с файлами
cd ~/gitea

# Запуск всех сервисов в фоновом режиме
docker compose up -d

Эта команда загрузит необходимые Docker-образы (Gitea, Caddy, Redis), создаст контейнеры и запустит их. Первый запуск может занять некоторое время, пока загружаются образы.

Проверить статус запущенных контейнеров можно командой:

# Проверка статуса контейнеров
docker compose ps

Вы должны увидеть, что все контейнеры (gitea, caddy, redis) находятся в статусе running.

На этом этапе установка основных компонентов завершена. Теперь перейдем к финальной конфигурации.

Конфигурация

После успешного запуска контейнеров Gitea и Caddy, вам нужно выполнить первоначальную настройку Gitea через веб-интерфейс, а также убедиться, что все параметры соответствуют вашим требованиям.

1. Первоначальная настройка Gitea через веб-интерфейс

Откройте ваш домен (например, https://your.domain.com) в веб-браузере. Вы должны увидеть страницу первоначальной настройки Gitea.

На этой странице проверьте и при необходимости измените следующие параметры:

• Настройки базы данных:
  • Тип базы данных: SQLite3 (должно быть выбрано по умолчанию).
  • Путь к файлу базы данных: /data/gitea.db (должно быть установлено из переменных окружения).
• Настройки общих параметров приложения:
  • Домен: your.domain.com (установлено из переменных окружения).
  • Базовый URL: https://your.domain.com/ (установлено из переменных окружения).
  • Путь к корневому каталогу Gitea: /data (установлено из переменных окружения).
  • Порт для SSH-сервера: 2222 (установлено из переменных окружения).
  • Путь к логам Gitea: /data/log.
• Настройки администратора:

  Создайте первого административного пользователя. Введите имя пользователя, пароль и адрес электронной почты. Это будет основной аккаунт для управления Gitea.

• Настройки почтового сервера (SMTP): Если вы хотите, чтобы Gitea отправлял уведомления (например, о регистрации, сбросе пароля, упоминаниях), настройте SMTP-сервер.

  
  # Пример настроек SMTP для Gitea (в веб-интерфейсе)
  [mailer]
  ENABLED = true
  HOST = smtp.yourprovider.com:587
  FROM = [email protected]
  USER = [email protected]
  PASSWD = ваш_пароль_smtp
  PROTOCOL = smtps # или smtp+tls
  

После проверки всех параметров нажмите кнопку "Установить Gitea". Если все прошло успешно, вы будете перенаправлены на страницу входа.

2. Конфигурационный файл app.ini

Большинство настроек Gitea можно изменить через веб-интерфейс администратора, но некоторые параметры хранятся в файле app.ini внутри контейнера. Этот файл находится по пути /data/gitea/conf/app.ini. Поскольку мы смонтировали ./data в /data, вы можете получить к нему доступ на хосте:

# Доступ к app.ini на хосте
nano ~/gitea/data/gitea/conf/app.ini

После первоначальной установки Gitea автоматически заполнит этот файл. Вот некоторые важные секции, которые вы можете захотеть проверить или изменить:

# app.ini (пример важных секций)
[server]
DOMAIN = your.domain.com
SSH_DOMAIN = your.domain.com
HTTP_PORT = 3000
ROOT_URL = https://your.domain.com/
DISABLE_SSH = false
SSH_PORT = 2222 # Внутренний порт Gitea для SSH
LFS_START_SERVER = true
LFS_HTTP_HOST = https://your.domain.com/ # URL для Git LFS

[database]
DB_TYPE = sqlite3
PATH = /data/gitea.db

[repository]
ROOT = /data/git/repositories # Путь для хранения репозиториев
DEFAULT_BRANCH = main # Ветка по умолчанию для новых репозиториев

[service]
REGISTER_EMAIL_ACTIVE = false # Требуется ли активация по email при регистрации
DISABLE_REGISTRATION = false # Разрешить ли регистрацию (true для приватного сервера)
REQUIRE_SIGNIN_VIEW = false # Требовать вход для просмотра репозиториев (true для приватного сервера)
NO_REPLY_ADDRESS = [email protected] # Адрес для "no-reply" коммитов

[session]
PROVIDER = db

[cache]
ADAPTER = redis
HOST = redis:6379

[queue]
TYPE = redis
CONN_STR = redis://redis:6379/0

[security]
INSTALL_LOCK = true # Важно: после установки должен быть true
SECRET_KEY = ваш_сгенерированный_ключ # Генерируется автоматически

Если вы внесете изменения в app.ini вручную, не забудьте перезапустить контейнер Gitea:

# Перезапуск контейнера Gitea
docker compose restart gitea

3. TLS/HTTPS через Caddy

Caddy автоматически получил и настроил SSL-сертификаты для вашего домена. Это подтверждается тем, что вы смогли получить доступ к Gitea по HTTPS. Caddy будет автоматически обновлять сертификаты до истечения срока их действия.

Вы можете проверить статус сертификатов Caddy:

# Просмотр логов Caddy для проверки статуса сертификатов
docker compose logs caddy | grep -i "certificate"

Вы должны увидеть записи о получении и/или обновлении сертификатов Let's Encrypt.

4. Проверка работоспособности

Убедитесь, что Gitea полностью функционален:

• Доступ по HTTPS: Откройте https://your.domain.com в браузере. Убедитесь, что соединение защищено (зеленый замочек).
• Вход и создание репозитория: Войдите под созданным администратором, создайте новый репозиторий.
• Клонирование по HTTPS: Попробуйте клонировать репозиторий через HTTPS с вашей локальной машины:

  
  git clone https://your.domain.com/ваш_пользователь/ваш_репозиторий.git
  

  Вам будет предложено ввести имя пользователя и пароль Gitea.

• SSH-доступ: Gitea использует порт 2222 для SSH. Чтобы настроить SSH-доступ, вам нужно добавить публичный SSH-ключ вашего пользователя Gitea через веб-интерфейс (Настройки профиля -> SSH/GPG ключи). Затем вы можете клонировать репозиторий по SSH:

  
  git clone ssh://[email protected]:2222/ваш_пользователь/ваш_репозиторий.git
  

  Важно: Убедитесь, что порт 2222 открыт в вашем фаерволе на VPS. Если вы используете UFW:

  
  sudo ufw allow 2222/tcp
  sudo ufw reload
  

• Healthcheck: Проверьте статус контейнеров:

  
  docker compose ps
  

  Все должно быть running и healthy.

Поздравляем! Ваш Gitea-сервер полностью настроен и готов к работе.

Бэкапы и обслуживание

Наличие работающего Git-сервера — это только половина дела. Крайне важно иметь надежную стратегию резервного копирования и план обслуживания для обеспечения долгосрочной стабильности и безопасности ваших данных.

Что бэкапить

Для Gitea необходимо резервировать три основных компонента:

1. База данных Gitea: В нашем случае это файл gitea.db. Он содержит всю информацию о пользователях, репозиториях, issue, pull requests, комментариях и т.д.
2. Файлы репозиториев Git: Сами Git-репозитории, включая LFS-объекты. Они хранятся в /data/git/repositories.
3. Конфигурационный файл app.ini: Содержит все настройки Gitea. Находится в /data/gitea/conf/app.ini.
4. SSH-ключи Gitea: Если Gitea генерирует свои собственные SSH-ключи для внутренних операций или для SSH-доступа, они также находятся в /data/gitea/.ssh.
5. Данные Caddy: Сертификаты Let's Encrypt и другая конфигурация Caddy хранятся в ./caddy_data. Хотя их можно восстановить автоматически, их бэкап ускорит восстановление.

Все эти данные находятся в директории ~/gitea/data и ~/gitea/caddy_data на вашем хосте.

Простой скрипт автобэкапа

Создадим простой скрипт, который будет создавать архив с необходимыми данными. Для SQLite достаточно просто скопировать файл базы данных, но Gitea также предоставляет утилиту gitea dump, которая создает полный дамп всех данных в одном архиве.

Создайте файл backup_gitea.sh в домашней директории:

# Создание скрипта бэкапа
nano ~/backup_gitea.sh

Вставьте следующее содержимое:

#!/bin/bash

# Настройки
BACKUP_DIR="/var/backups/gitea"
GITEA_DIR="/home/ваш_пользователь/gitea" # Путь к директории с docker-compose.yml
DATE=$(date +%Y%m%d%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/gitea_backup_${DATE}.zip"

# Создание директории для бэкапов, если ее нет
mkdir -p ${BACKUP_DIR}

echo "--- Начинаем резервное копирование Gitea (${DATE}) ---"

# 1. Дамп Gitea с помощью встроенной утилиты (внутри контейнера)
# Это создаст zip-архив в /tmp внутри контейнера Gitea
echo "Создание дампа Gitea..."
docker exec gitea gitea dump -c /data/gitea/conf/app.ini

# 2. Копирование созданного дампа из контейнера на хост
echo "Копирование дампа на хост..."
DUMP_CONTAINER_PATH=$(docker exec gitea find /tmp -name "gitea-dump-.zip" -print -quit)
if [ -z "$DUMP_CONTAINER_PATH" ]; then
    echo "Ошибка: Дамп Gitea не найден в контейнере."
    exit 1
fi
docker cp gitea:${DUMP_CONTAINER_PATH} ${BACKUP_FILE}

# 3. Удаление дампа из контейнера
echo "Удаление временного дампа из контейнера..."
docker exec gitea rm ${DUMP_CONTAINER_PATH}

# 4. Копирование данных Caddy (сертификаты)
echo "Копирование данных Caddy..."
tar -czf ${BACKUP_DIR}/caddy_data_backup_${DATE}.tar.gz -C ${GITEA_DIR}/caddy_data .

echo "Резервное копирование завершено: ${BACKUP_FILE} и ${BACKUP_DIR}/caddy_data_backup_${DATE}.tar.gz"

# Очистка старых бэкапов (например, хранить последние 7 дней)
echo "Очистка старых бэкапов..."
find ${BACKUP_DIR} -type f -name "gitea_backup_.zip" -mtime +7 -delete
find ${BACKUP_DIR} -type f -name "caddy_data_backup_.tar.gz" -mtime +7 -delete

echo "--- Резервное копирование Gitea завершено ---"

chmod +x ~/backup_gitea.sh

# Открытие crontab для редактирования
crontab -e

# Ежедневный бэкап Gitea в 03:00
0 3    /home/ваш_пользователь/backup_gitea.sh >> /var/log/gitea_backup.log 2>&1

Куда складывать бэкапы

Хранить бэкапы на том же сервере, что и основной сервис, крайне рискованно. Если VPS выйдет из строя или будет скомпрометирован, вы потеряете и данные, и бэкапы. Рекомендуется использовать внешние хранилища:

• S3-совместимое хранилище: Облачные хранилища, такие как Amazon S3, DigitalOcean Spaces, Backblaze B2. Это экономичный и надежный вариант. Вы можете использовать утилиты типа s3cmd, rclone или restic для автоматической синхронизации бэкапов.
• Отдельный VPS: Небольшой, дешевый VPS, расположенный в другом дата-центре, может служить хранилищем для бэкапов, куда вы будете копировать архивы по SCP/RSYNC.
• Локальное хранилище: Для очень малых проектов можно временно хранить бэкапы локально и вручную скачивать их на свою машину.

Для автоматической отправки на S3, вы можете интегрировать rclone в ваш скрипт:

# Пример добавления rclone в скрипт backup_gitea.sh
# ... (после создания бэкапа)
echo "Отправка бэкапа на S3..."
/usr/bin/rclone copy ${BACKUP_FILE} my-s3-remote:gitea-backups/
/usr/bin/rclone copy ${BACKUP_DIR}/caddy_data_backup_${DATE}.tar.gz my-s3-remote:gitea-backups/caddy-data/

# ... (очистка старых бэкапов на S3, если настроено в rclone или через политики S3)

Не забудьте настроить rclone с вашими S3-учетными данными командой rclone config.

Обновления: rolling vs maintenance window

Регулярные обновления критичны для безопасности и получения новых функций.

• Обновление операционной системы: Регулярно запускайте sudo apt update && sudo apt upgrade -y. Это можно делать ежемесячно или при выходе важных патчей безопасности.
• Обновление Docker-образов (Gitea, Caddy, Redis):

  Для Docker-контейнеров рекомендуется использовать стратегию "maintenance window" (окно обслуживания), а не "rolling update" (постоянное обновление), так как изменения могут быть существенными.

  1. Перед обновлением сделайте свежий бэкап.
  2. Остановите сервисы Gitea: docker compose down
  3. Загрузите новые образы: docker compose pull
  4. Запустите сервисы: docker compose up -d

  Всегда проверяйте changelog Gitea на предмет breaking changes перед обновлением до новой мажорной версии. Например, если вы обновляетесь с 1.21.x до 1.22.x, убедитесь, что нет специальных инструкций по миграции базы данных.

• Обновление Docker Engine: Также требует осторожности. Обычно достаточно обновлять Docker Engine раз в несколько месяцев, или при необходимости устранения уязвимостей. После обновления Docker Engine потребуется перезагрузить сервер, чтобы все контейнеры стартовали корректно.

Всегда тестируйте обновления на тестовом сервере, если это возможно, прежде чем применять их к продакшн-окружению.

Troubleshooting + FAQ

Даже при самой тщательной настройке могут возникнуть проблемы. Вот список типичных вопросов и проблем, с которыми можно столкнуться при развертывании Gitea с Docker и Caddy.

Какой VPS-конфиг минимально подойдёт?

Для базовой установки Gitea (без Docker) на небольшое количество пользователей (1-5) можно обойтись 1 vCore CPU, 1 ГБ RAM и 20-30 ГБ SSD. Однако, если вы используете Docker и Caddy, а также планируете до 10-15 пользователей, минимально рекомендуется 2 vCore CPU, 2 ГБ RAM и 40 ГБ SSD. Это обеспечит стабильную работу и достаточный запас ресурсов для операционной системы, Docker-демона и всех контейнеров.

Что выбрать — VPS или dedicated для этой задачи?

Для большинства сценариев использования Gitea (личные проекты, команды до 50 человек, умеренное количество репозиториев) VPS является оптимальным выбором. Он предлагает достаточную производительность, гибкость и значительно ниже по стоимости, чем dedicated-сервер. Dedicated-сервер следует рассматривать только в случаях очень высокой нагрузки (сотни пользователей, тысячи репозиториев), строгих требований к изоляции или при необходимости запуска множества других ресурсоемких сервисов на той же машине.

Gitea не запускается или контейнер постоянно перезапускается. Что делать?

Первым делом проверьте логи контейнера Gitea: docker compose logs gitea. Частые причины:

• Конфликт портов: Убедитесь, что порт 3000 (внутренний порт Gitea) не занят другим процессом внутри контейнера или на хосте (хотя в нашей конфигурации он не открыт напрямую наружу).
• Проблемы с базой данных: Если Gitea не может подключиться к Redis или SQLite-файл поврежден. Проверьте логи Gitea на ошибки, связанные с database или cache.
• Неверные разрешения на файлы: Убедитесь, что пользователь Docker внутри контейнера (UID/GID 1000) имеет права на запись в директорию ./data. Вы можете проверить права на хосте: ls -la ~/gitea/data.
• Неправильный app.ini: Синтаксические ошибки или неверные значения в конфигурационном файле Gitea.

Caddy не получает SSL-сертификат или не перенаправляет трафик.

Проверьте логи Caddy: docker compose logs caddy. Возможные причины:

• Проблемы с DNS: Убедитесь, что A-запись вашего домена (например, your.domain.com) корректно указывает на IP-адрес вашего VPS. Это можно проверить с помощью dig your.domain.com.
• Фаервол блокирует порты 80/443: Убедитесь, что UFW (или другой фаервол) разрешает входящие соединения на портах 80 и 443. Проверьте sudo ufw status.
• Другой процесс занимает порты 80/443 на хосте: Убедитесь, что нет другого веб-сервера (Apache, Nginx) или другого Caddy, запущенного на хосте и использующего эти порты.
• Неправильный Caddyfile: Синтаксические ошибки или неверные настройки прокси.
• Лимиты Let's Encrypt: Если вы многократно пытались получить сертификат с одного домена за короткое время, вы могли попасть под лимит Let's Encrypt. Подождите несколько часов.

Не работает SSH-доступ к репозиториям Gitea.

Проверьте следующее:

• Порт 2222 открыт в фаерволе: sudo ufw status должен показывать разрешение для порта 2222.
• SSH-ключ добавлен в Gitea: Убедитесь, что ваш публичный SSH-ключ добавлен в настройки вашего профиля Gitea через веб-интерфейс.
• Правильная команда клонирования: Используйте git clone ssh://[email protected]:2222/ваш_пользователь/ваш_репозиторий.git. Обратите внимание на git@ и порт :2222.
• Gitea SSH-сервер запущен: Проверьте логи Gitea на предмет ошибок, связанных с SSH.

После обновления Docker-образов Gitea не запускается.

Это может быть связано с изменениями в новой версии Gitea или Docker. Всегда проверяйте официальные changelogs. Если Gitea требует миграции базы данных, она обычно выполняется автоматически при первом запуске. Если нет, проверьте логи. Возможно, потребуется откатиться к предыдущей версии образа (например, gitea/gitea:1.21.10 вместо gitea/gitea:1.22.0) и изучить инструкции по миграции.

Как обновить Gitea?

Для обновления Gitea (и других контейнеров) выполните следующие шаги в директории ~/gitea:

# 1. Сделайте бэкап! Это критически важно.
# 2. Остановка текущих контейнеров
docker compose down
# 3. Обновление Docker-образов до последних версий, указанных в docker-compose.yml
#    Если вы хотите обновить до более новой версии, измените тег образа в docker-compose.yml
docker compose pull
# 4. Запуск обновленных контейнеров
docker compose up -d

После запуска проверьте логи и веб-интерфейс.

Как изменить настройки Gitea после первоначальной установки?

Большинство настроек можно изменить через веб-интерфейс, войдя как администратор: "Панель администратора" -> "Конфигурация сайта". Некоторые специфические настройки могут потребовать ручного редактирования файла ~/gitea/data/gitea/conf/app.ini с последующим перезапуском контейнера Gitea (docker compose restart gitea).

Выводы и следующие шаги

Вы успешно настроили и развернули собственный Git-сервер Gitea на вашем VPS, используя Docker и Caddy для автоматического получения SSL-сертификатов. Теперь у вас есть полностью контролируемая и безопасная платформа для управления вашими репозиториями, которая обеспечивает конфиденциальность и независимость от сторонних сервисов. Этот self-hosted Git-сервер является мощным инструментом для индивидуальных разработчиков, команд и стартапов, предоставляя функциональность, аналогичную крупным Git-провайдерам, при значительно меньших затратах ресурсов.

Следующие шаги

После базовой настройки Gitea, вы можете рассмотреть следующие шаги для расширения его функциональности и интеграции в ваш рабочий процесс:

1. Интеграция с CI/CD: Настройте интеграцию Gitea с системами непрерывной интеграции/непрерывной доставки (CI/CD), такими как Drone CI, Jenkins, GitLab CI (используя Gitea в качестве источника кода) или самописными скриптами. Это позволит автоматически тестировать и развертывать ваш код при каждом коммите.
2. Мониторинг и логирование: Внедрите системы мониторинга (например, Prometheus + Grafana) для отслеживания состояния вашего VPS и контейнеров Gitea/Caddy/Redis. Настройте централизованное логирование (например, ELK Stack или Loki + Promtail) для удобного анализа логов всех сервисов.
3. Масштабирование и оптимизация: Если ваша команда растет или количество репозиториев увеличивается, рассмотрите переход с SQLite на PostgreSQL или MySQL для базы данных Gitea, а также оптимизацию ресурсов VPS. Для очень крупных инсталляций можно рассмотреть выделение Gitea, базы данных и кэша на отдельные серверы.
4. Дополнительные функции Gitea: Изучите богатый функционал Gitea, такой как встроенная вики, отслеживание времени, метки, проекты, пакетный менеджер (Gitea Packages) и интеграции с внешними сервисами через вебхуки.