Эта статья является прямым продолжением вот этой статьи про мой проект ServeHub-2, которое охватывает релиз 1.4.0 и отчасти 2.0.0, 2.1.0 (а также определенные подробности, которые не упоминались в прошлой статье). Здесь будут подробно объясняться моменты в том порядке, в котором они появлялись в проекте.

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

Сборка amnezia контейнера для клиента

Так как amnezia не предоставляет готовые cli решения для клиента, для сервера пришлось собирать все самостоятельно. Ниже будут файлы с пояснениями

docker-compose.local.yaml:

amnezia-client:
    build:
      context: .
      dockerfile: Dockerfile.amnezia # dockerfile в котором билдится образ
    container_name: amnezia-client
    restart: unless-stopped
    cap_add: # выдаем контейнеру конкретные привилегии Linux ядра, вместо того чтобы выдавать полные root права
      - NET_ADMIN # позволяет контейнеру управлять сетевыми настройками хоста (создание интерфейсов, настройка таблиц маршрутизации, настраивать правила фильтрации трафика)
      - SYS_MODULE # дает возможность загружать и выгружать модули ядра Linux на хостовой системе (для работы Ansible заранее скачивает нужные модули ядра amnezia: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module)
    privileged: true # дает возможность получать root права
    devices:
      - /dev/net/tun:/dev/net/tun # специальный виртуальный файл в Linux. Используется программами для создания соединений. Вместо отправки данных через физический кабель, программы отправляют их в этот файл, где они шифруются
    volumes:
      - ./apps-data/amnezia:/config # прокидываем файл awg0.conf
      - /lib/modules:/lib/modules:ro # прокидываем модули ядра
    logging: *default-logging
    network_mode: "host" # контейнер использует сетевой стек компьютера напрямую
    healthcheck:
      test: ["CMD-SHELL", "awg show | grep interface || exit 1"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

Dockerfile.amnezia:

FROM golang:1.24.5 AS builder # первый этап сборки, используем go для установки amnezia-go (нужен на всякий случай, если что-то случится с модулем ядра, так как он запускается полностью самостоятельно)
ARG TARGETARCH # переменные сборки, docker автоматически подставляет туда архитектуру процессора
ARG TARGETVARIANT

WORKDIR /amneziawg-go # рабочая директория

RUN git clone https://github.com/amnezia-vpn/amneziawg-go.git . --depth=1 \
    && go mod download \ # после клонирования качаем зависимости
    && go mod verify \
    && CGO_ENABLED=0 GOOS=linux GOARCH=$TARGETARCH GOARM=${TARGETVARIANT#v} \ # Отключает использование библиотек Си. Также указывает компилятору, под какую целевую ОС и архитектуру процессора нужно собрать файл
       go build -ldflags '-s -w' -v -o amneziawg-go # компилируем бинарник. Флаг -ldflags '-s -w' удаляет из готового файла отладочную информацию.

FROM alpine:3.22.1 # собираем финальный образ

ARG TARGETARCH
ARG AWGTOOLS_RELEASE=1.0.20250706 #версия

RUN apk --no-cache add \
    iproute2 \
    iptables \
    bash \
    openresolv \
    dumb-init \
    && apk --no-cache add --virtual .build-deps \
    dpkg \
    wget \
    unzip \
    git \
    build-base \
    linux-headers # устанавливаем зависимости

RUN git clone https://github.com/amnezia-vpn/amneziawg-tools.git /amneziawg-tools --depth=1 \ # клонируем консольные утилиты
    && cd /amneziawg-tools/src \
    && make \ # компилируем утилиты из исходного кода
    && make install \
    && ln -s /usr/local/bin/awg /usr/bin/wg \ # создаем ярлыки (если будет вызываться wg, перенаправим на awg)
    && ln -s /usr/local/bin/awg-quick /usr/bin/wg-quick \
    && cd / \
    && rm -rf /amneziawg-tools \ # удаляем исходники
    && apk del .build-deps # удаляем компиляторы, которые ставили временно

COPY --from=builder /amneziawg-go/amneziawg-go /usr/bin/ # копируем бинарник go версии с предыдущего этапа сборки

COPY scripts/amnezia-client_init.sh /init.sh
RUN chmod +x /init.sh

ENTRYPOINT ["/usr/bin/dumb-init", "/init.sh"] # запускаем скрипт. dumb-init встает на место главного процесса PID 1 и запускает скрипт, слушает команды Docker и транслирует внутрь клиента. Dumb-init нужен, так как bash скрипты сами по себе не умеют управлять дочерними процессами и обрабатывать системные сигналы.

amnezia-client_init.sh

#!/bin/bash
find /etc/amnezia/amneziawg -mindepth 1 -delete # удаляем все файлы в директории, гарантирует чистый старт

COUNTER=0 # для проверки удалось ли что-нибудь найти
for s in $(find /config -name "*.conf") # ищем конфиги
do
  if test -f ${s} # убеждаемся что это файл
  then
    COUNTER=$(( COUNTER + 1 ))
    basename=$(basename ${s}) # извлекаем имя файла
    name=${basename%.conf}
    echo awg interface "${name}" will be created from config file "${basename}"
    cp ${s} /etc/amnezia/amneziawg/${name}.conf # копируем себе
    chmod 600 /etc/amnezia/amneziawg/${name}.conf # выдаем права: чтение и запись только для root
    awg-quick up ${name} # главная команда, которая создаем виртуальный сетевой интерфейс с именем файла
  fi
done

if [[ $COUNTER -lt 1 ]]
then
  echo "There are no config files in the /config folder"
fi

sleep infinity # контейнер живет до тех пор, пока работает главный процесс PID 1

Появление Gitea + настройки в Nginx

docker-compose.local.yaml:

 gitea:
    image: gitea/gitea:1.26
    container_name: gitea
    logging: *default-logging
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__server__ROOT_URL=https://${SERVER_NAME}/gitea/ # эти переменные служат для генерации файла конфига .ini (формат GITEA__SECTION__KEY)
      - GITEA__server__DISABLE_SSH=true # отключам ssh чтобы не пробрасывать через nginx, так как работает в vpn сети, можно спокойно пользоваться https
      - GITEA__database__DB_TYPE=sqlite3
      - GITEA__database__PATH=/data/gitea/gitea.db
      - GITEA__security__INSTALL_LOCK=true # отключаем страницу первоначальной установки, сразу запуская gitea в рабочем режиме
    volumes:
      - ./apps-data/gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
      - 3000 # даем доступ только в docker сети для nginx
    restart: unless-stopped

nginx.remote.conf.template: (location который перенаправляет трафик на локальные сервисы)

location ~* ^/(navidrome|audiobookshelf|nextcloud|gitea|vaultwarden|grafana|portainer|borg-ui|v2) {  
	# перенаправляем запрос на Nginx локального сервера внутри vpn
	# оригинальный путь (URI) передается автоматически, что позволит локальному Nginx распределить запросы по сервисам
	proxy_pass http://10.8.0.2:80; 
	
	proxy_http_version 1.1; 
	# пробрасываем заголовки для поддержки WebSockets (необходимо для Vaultwarden, Portainer и др.)
	proxy_set_header Upgrade $http_upgrade; 
	proxy_set_header Connection $connection_upgrade; 
	
	# передаем оригинальные данные клиента, чтобы конечные сервисы знали реальный IP и домен
	proxy_set_header Host $host; 
	proxy_set_header X-Real-IP $remote_addr; 
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
	proxy_set_header X-Forwarded-Host $host; 
	
	# сообщаем сервисам, что внешнее соединение защищено https (предотвращает проблемы с безопасностью и редиректами)
	proxy_set_header X-Forwarded-Proto https; 

	# отключаем буферизацию, чтобы данные передавались мгновенно в реальном времени 
	# это критично для стриминга медиа и загрузки больших файлов через Nextcloud.
	proxy_buffering off; 
	proxy_request_buffering off; 
	
	# увеличиваем таймауты до 1 часа, чтобы не рвались веб-сокеты и долгие загрузки файлов
	proxy_read_timeout 3600; 
	keepalive_timeout 3600; 
}

Также вы могли заметить v2 путь. Он нужен для того, чтобы использовать gitea registry, так как docker push по спецификации всегда добавляет в путь /v2/, а так как gitea в моем случае находится не в корне домена, без этого все ломается.

К примеру: docker делает запрос и получается путь https://server.name/v2/, при этом gitea находится на https://server.name/gitea/. Соответственно нужно просто “обмануть” docker чтобы /v2/ шел на локальный сервер, и там уже шел в gitea, как если бы docker обратился по /gitea/.

nginx.local.conf.template: (location для gitea на локальном сервере)

# ведем оба пути в ту же самую gitea, только тут есть небольшой нюанс, который позволяет всему этому работать
 location /gitea/ { 
        # слэш на конце "http://gitea:3000/" отрезает префикс "/gitea/" из запроса.
        # например, запрос к "/gitea/explore" уйдет в контейнер как "/explore".
        proxy_pass http://gitea:3000/; 
        
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_buffering off;
        
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
    
    location /v2 {
        # слэша на конце нет, поэтому Nginx проксирует путь "/v2" без изменений.
        # запрос "/v2/token" уйдет в контейнер именно как "/v2/token", где его обработает реестр Gitea.
        proxy_pass http://gitea:3000; 
        
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }

Redis для Nextcloud

Здесь кратко пройдусь по финальному виду docker-compose файла для Nextcloud с описанияеми

docker-compose.local.yaml:

nextcloud-db:
    image: postgres:18
    container_name: nextcloud-db
    logging: *default-logging
    restart: unless-stopped
    volumes:
      - ./apps-data/postgres/nextcloud:/var/lib/postgresql
    environment:
      - POSTGRES_DB=${POSTGRES_DB_NEXTCLOUD}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    expose:
      - 5432
    healthcheck:
      # проверка здоровья БД: pg_isready проверяет, готов ли сервер принимать подключения
      test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB"]
      interval: 5s
      timeout: 5s
      retries: 5
    deploy:
      resources:
        limits:
          memory: 1G
  
  nextcloud-redis:
    image: redis:8.8.0
    container_name: nextcloud-redis
    restart: unless-stopped
    # устанавливаем пароль прямо в команде запуска сервера для безопасности
    command: redis-server --requirepass ${NEXTCLOUD_REDIS_PASS}
    logging: *default-logging
    deploy:
      resources:
        limits:
          memory: 1G

  nextcloud:
    image: nextcloud:34.0.0-apache
    container_name: nextcloud
    logging: *default-logging
    restart: unless-stopped
    expose:
      - 80
    depends_on:
      # запуск Nextcloud начнется только тогда, когда база пройдет проверку здоровья (healthcheck)
      nextcloud-db:
        condition: service_healthy
      nextcloud-redis:
        condition: service_started
    environment:
      - POSTGRES_HOST=nextcloud-db
      # OVERWRITEWEBROOT важен, так как Nextcloud запущен не в корне домена, а в /nextcloud
      - OVERWRITEWEBROOT=/nextcloud
      - OVERWRITEPROTOCOL=https
      # список доверенных прокси (включая ваш VPN 10.8.0.0/24), чтобы Nextcloud 
      # корректно определял IP клиента через заголовки X-Forwarded-For
      - TRUSTED_PROXIES=172.16.0.0/12 10.8.0.0/24
      # настройка кэширования: APCu для локального кэша, Redis для блокировки файлов
      - 'NC_memcache.local=\OC\Memcache\APCu'
      - 'NC_memcache.locking=\OC\Memcache\Redis'
    volumes:
      - ./apps-data/nextcloud/html:/var/www/html
      - /home/${LOCAL_USER}/PersonalData/NextcloudData:/var/www/html/data
    deploy:
      resources:
        limits:
          memory: 3G
    healthcheck:
      # проверка: существует ли конфиг и работает ли PHP-утилита OCC (Nextcloud CLI)
      test: ["CMD-SHELL", "test -f /var/www/html/config/config.php && php occ status"]
      interval: 1m30s
      timeout: 30s
      retries: 5
      start_period: 30s

  nextcloud-cron:
    image: nextcloud:34.0.0-apache
    container_name: nextcloud-cron
    restart: unless-stopped
    # этот контейнер только для запуска фоновых задач (очистка кэша, превью, индексация)
    # это разгружает основной процесс веб-сервера
    entrypoint: /cron.sh
    logging: *default-logging
    depends_on:
      nextcloud-db:
        condition: service_healthy
      nextcloud:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M

Исправления ошибок

Cборка модулей для 7.1.3-arch1-2

Проблема заключалась в том, что при обновлении ядра Linux одна из внутренних функций изменила свое название, из-за чего модуль amneziawg перестал компилироваться (он все еще пытался использовать старый вызов). Стоит отметить, что из-за быстрого обновления ядра в Arch Linux подобные ситуации с внешними модулями случаются, и проект не всегда может корректно собраться автоматически без вмешательства.

Чтобы это исправить я добавил в Ansible такой шаг:

- name: "[AmneziaWG] Arch: исправление совместимости с ядром 7.x+ (ipv6_stub)"
  block:
    - name: "[AmneziaWG] Arch: проверяем наличие исходников в /usr/src"
      ansible.builtin.stat:
        path: /usr/src/amneziawg-1.0.0/socket.c
      register: amneziawg_source # записываем результат есть ли исходники

    - name: "[AmneziaWG] Arch: замена ipv6_stub на ip6_dst_lookup_flow"
      ansible.builtin.replace:
        path: /usr/src/amneziawg-1.0.0/socket.c
        regexp: 'ipv6_stub->ipv6_dst_lookup_flow' # находим функцию и меняем название
        replace: 'ip6_dst_lookup_flow'
      register: patch_result # пишем удалось ли перезаписать
      when: amneziawg_source.stat.exists # выполняется только если найдены исходники

    - name: "[AmneziaWG] Arch: принудительная пересборка модуля после патча"
      ansible.builtin.shell: |
        dkms remove amneziawg/1.0.0 --all || true # удаляем загруженный в оперативку модуль
        dkms add -m amneziawg -v 1.0.0 || true # добавляем обратно
        dkms build -m amneziawg -v 1.0.0 # билдим
        dkms install -m amneziawg -v 1.0.0 # устанавливаем
      become: true # используем root
      when: patch_result.changed
  when: ansible_facts['os_family'] == "Archlinux"

Если что dkms - это фреймворк, который позволяет автоматически пересобирать модули ядра при каждом обновлении самого ядра в системе. Ansible-скрипт в данном случае просто патчит код и инициирует пересборку.

Nginx и Loki не запускаются после перезагрузки сервера

Проблема заключалась в том, что в docker-compose файле Nginx и Loki были привязаны к IP-адресу VPN-туннеля (10.8.0.2). При старте системы Docker пытался запустить контейнеры раньше, чем сетевой интерфейс VPN успевал подняться. Из-за отсутствия нужного IP на хосте контейнеры аварийно завершались.

Чтобы это решить я добавил в Ansible такой шаг:

- name: "[Net] Разрешить привязку к несуществующим IP (ip_nonlocal_bind)"
  ansible.posix.sysctl: # используем sysctl
    name: net.ipv4.ip_nonlocal_bind
    value: '1' # ставим значение 1 (раньше было 0)
    state: present # Убеждаемся, что параметр установлен 
    reload: yes # Применяем изменения параметров ядра немедленно

Заключение

Подробно рассказал про все изменения, которые были сделаны и про исправления ошибок, а также про то, что упустил в предыдущей части. Следующая статья будет полностью посвящена Go Wails установщику, который автоматизирует установку и разворачивание сервисов на серверах.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Буду рад вашему фидбеку в комментариях!

ЧАСТЬ 2. Своя self-hosted двухсерверная VPN-архитектура: Gitea, сборка Amnezia, проблемы 7.1.3-arch1-2 и многое другое