Развёртывание Caddy как обратного прокси для Docker-контейнеров на VPS с автоматическим HTTPS

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

В этом руководстве мы займёмся созданием надёжной и безопасной инфраструктуры для хостинга веб-приложений на собственном VPS. Основная задача — обеспечить доступ к приложениям, работающим внутри Docker-контейнеров, извне через доменное имя, при этом автоматически защитив соединение с помощью HTTPS. Для этого мы используем связку из трёх ключевых компонентов:

• Docker: Платформа для контейнеризации приложений. Docker позволяет упаковывать приложения со всеми их зависимостями в изолированные "контейнеры", что обеспечивает их переносимость и предсказуемость работы в любой среде. Мы будем использовать Docker Compose для оркестрации нескольких контейнеров, составляющих одно приложение или сервис.
• Caddy: Современный веб-сервер и обратный прокси. Caddy выделяется своей простотой конфигурации и, что самое главное, встроенной поддержкой автоматической выдачи и обновления SSL/TLS-сертификатов через Let's Encrypt. Это избавляет от необходимости вручную настраивать Certbot или другие инструменты для HTTPS, значительно упрощая процесс.
• VPS (Virtual Private Server): Виртуальный приватный сервер, который предоставит нам необходимую вычислительную мощность и сетевые ресурсы для размещения нашей инфраструктуры.

В итоге, читатель получит полностью настроенную систему, способную безопасно и эффективно размещать одно или несколько веб-приложений (например, GitLab, Mattermost, WordPress, или кастомные SaaS-приложения) в Docker-контейнерах, доступных по доменным именам с автоматическим HTTPS. Это идеальное решение для разработчиков, стартапов и энтузиастов, желающих иметь полный контроль над своей инфраструктурой без высоких затрат на облачные managed-сервисы.

Альтернативы: Cloud-managed vs. Self-hosted на VPS

Существует два основных подхода к развёртыванию веб-приложений:

• Cloud-managed сервисы: Такие платформы, как Heroku, Netlify, AWS Elastic Beanstalk, Google App Engine, предлагают высокую автоматизацию, масштабируемость и минимальные усилия по администрированию. Вы просто загружаете свой код, а платформа заботится о серверах, масштабировании, базах данных и HTTPS.
  Преимущества: Простота, высокая доступность, автоматическое масштабирование.
  Недостатки: Высокая стоимость при росте, меньший контроль над инфраструктурой, привязка к конкретному провайдеру, иногда ограниченные возможности кастомизации.
• Self-hosted на VPS/Dedicated сервере: Этот подход подразумевает аренду "голого" сервера (виртуального или физического) и самостоятельную настройку всего стека — операционной системы, веб-сервера, базы данных, контейнеризации и т.д.
  Преимущества: Полный контроль над каждым аспектом системы, значительно более низкая стоимость в долгосрочной перспективе (особенно при умеренных нагрузках), гибкость в выборе технологий и конфигураций, конфиденциальность данных.
  Недостатки: Требует технических знаний и времени на настройку и обслуживание, ответственность за безопасность и бэкапы лежит на вас.

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

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

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

Минимальные требования для базовой установки (Caddy + 1-2 лёгких контейнера)

• CPU: 1-2 ядра (например, Intel Xeon E3/E5 или AMD EPYC). Для большинства веб-приложений одно ядро достаточно, но два дадут запас производительности и лучшую отзывчивость.
• RAM: 2 ГБ. Docker и Caddy сами по себе потребляют немного, но каждое приложение в контейнере требует своей памяти. 2 ГБ — это комфортный минимум для ОС, Docker-демона и пары нетребовательных сервисов (например, небольшой блог на WordPress без тяжелой СУБД или простой API-сервис).
• Диск: 40-60 ГБ NVMe SSD. SSD значительно ускоряет операции ввода-вывода, что важно для баз данных и быстрого запуска контейнеров. NVMe предлагает ещё большую скорость. 40-60 ГБ достаточно для ОС, Docker-образов, контейнеров и небольшого объёма данных. Если планируются большие объёмы данных (например, файловые хранилища, логи, бэкапы), потребуется больше места.
• Сеть: 100-200 Мбит/с. Для большинства задач этого более чем достаточно. Важнее стабильность канала и низкая задержка.

Конкретный VPS-план под задачу

Для развёртывания Caddy с 3-5 Docker-контейнерами (например, GitLab, Mattermost или несколько микросервисов) рекомендуется следующий конфигурационный план:

• CPU: 2-4 ядра (например, Intel Xeon E5-2690v4 или AMD EPYC 7002 series). Это обеспечит достаточную производительность для обработки запросов и фоновых задач контейнеров.
• RAM: 4-8 ГБ. Для более требовательных приложений, таких как GitLab, Mattermost или Minecraft-сервер, 4 ГБ — это минимум, 8 ГБ дадут значительно больше свободы и стабильности.
• Диск: 80-160 ГБ NVMe SSD. GitLab, Minecraft и другие подобные приложения могут занимать значительное место на диске. NVMe SSD обеспечит высокую скорость работы с данными.
• Сеть: 500 Мбит/с - 1 Гбит/с. Высокая пропускная способность будет полезна для приложений с большим количеством пользователей или интенсивным трафиком.

Можно рассмотреть VPS с указанными характеристиками, чтобы получить оптимальное соотношение цены и производительности для такой задачи. Убедитесь, что выбранный план включает публичный IPv4-адрес, который необходим для доступа к вашим сервисам из интернета и работы Let's Encrypt.

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

Выделенный сервер (dedicated server) становится предпочтительным выбором, когда:

• Высокая производительность и стабильность: Требуется максимальная и предсказуемая производительность без "шумных соседей" на одном физическом сервере.
• Большие объёмы данных: Планируется хранение сотен гигабайт или терабайт данных.
• Сложные вычисления: Нужны специализированные процессоры (например, GPU для машинного обучения) или очень большое количество ядер.
• Строгие требования к безопасности/комплаенсу: Необходим полный физический контроль над оборудованием.
• Масштабный трафик: Ожидается очень высокий сетевой трафик (десятки ТБ в месяц).

Для большинства задач, описанных в этом руководстве (GitLab для команды, Mattermost, Minecraft для друзей), мощный VPS будет достаточен. Однако, если вы запускаете крупный SaaS-проект с тысячами пользователей или высоконагруженную криптоноду, рассмотрите подходящий dedicated сервер.

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

Выбор локации VPS имеет несколько ключевых аспектов:

• Задержка (Latency): Чем ближе сервер к вашей основной аудитории, тем ниже будет задержка и быстрее будут загружаться страницы для конечных пользователей. Для европейской аудитории выбирайте сервер в Европе, для американской — в Северной Америке.
• Регуляторные требования: В некоторых юрисдикциях существуют строгие законы о хранении данных (например, GDPR в ЕС). Выбор локации сервера может влиять на соответствие этим требованиям.
• Стоимость: Цены на VPS могут незначительно различаться в зависимости от региона.

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

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

После получения доступа к вашему новому VPS необходимо выполнить ряд первоначальных настроек для обеспечения безопасности и удобства работы. Мы будем использовать Ubuntu Server 24.04/26.04 LTS как операционную систему.

Предполагается, что вы получили доступ к серверу по SSH под пользователем root или другим пользователем с правами sudo.

1. Обновление системы

Первым делом обновим все пакеты до актуальных версий.

sudo apt update          # Обновляем списки доступных пакетов
sudo apt upgrade -y      # Обновляем все установленные пакеты
sudo apt autoremove -y   # Удаляем ненужные пакеты

2. Создание нового пользователя с правами sudo (если вы работаете под root)

Работа под пользователем root небезопасна. Создадим нового пользователя и дадим ему права sudo.

sudo adduser username    # Замените 'username' на желаемое имя пользователя. Следуйте инструкциям для создания пароля.
sudo usermod -aG sudo username # Добавляем пользователя в группу sudo для получения прав администратора.

Теперь выйдите из текущей SSH-сессии (exit) и войдите под новым пользователем:

ssh username@your_vps_ip # Замените 'username' и 'your_vps_ip'

3. Настройка SSH-ключей для безопасного доступа

Использование SSH-ключей гораздо безопаснее, чем паролей. Если у вас ещё нет SSH-ключа, сгенерируйте его на вашей локальной машине:

ssh-keygen -t ed25519 -C "[email protected]" # Создаем новый SSH-ключ (ed25519 более безопасен)

Затем скопируйте публичный ключ на ваш VPS:

ssh-copy-id username@your_vps_ip # Копируем публичный ключ на сервер

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

sudo nano /etc/ssh/sshd_config # Открываем конфигурационный файл SSH-сервера

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

PermitRootLogin no
PasswordAuthentication no

Сохраните изменения (Ctrl+X, Y, Enter) и перезапустите SSH-сервер:

sudo systemctl restart sshd # Перезапускаем службу SSH

Важно: Убедитесь, что вы можете войти по SSH-ключу, прежде чем отключать вход по паролю! Иначе вы можете потерять доступ к серверу.

4. Установка и настройка межсетевого экрана (UFW)

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

sudo apt install ufw -y # Устанавливаем UFW
sudo ufw allow OpenSSH  # Разрешаем SSH (порт 22)
sudo ufw allow http     # Разрешаем HTTP (порт 80)
sudo ufw allow https    # Разрешаем HTTPS (порт 443)
sudo ufw enable         # Включаем UFW. Подтвердите 'y'.
sudo ufw status verbose # Проверяем статус UFW

5. Установка Fail2ban для защиты от брутфорса

Fail2ban сканирует логи сервисов (SSH, веб-серверов и т.д.) на предмет подозрительной активности (например, многократные неудачные попытки входа) и временно или перманентно блокирует IP-адреса злоумышленников с помощью правил фаервола.

sudo apt install fail2ban -y # Устанавливаем Fail2ban
sudo systemctl enable fail2ban # Включаем автозапуск Fail2ban при загрузке
sudo systemctl start fail2ban  # Запускаем службу Fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Создаем локальную копию конфига для изменений
sudo nano /etc/fail2ban/jail.local # Редактируем конфигурацию

В файле jail.local вы можете настроить параметры, такие как bantime (время блокировки), findtime (период, в течение которого учитываются неудачные попытки) и maxretry (максимальное количество попыток). Убедитесь, что секция [sshd] включена (enabled = true). Можете увеличить bantime, например, до 1h или даже 1d.

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

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

Сохраните изменения и перезапустите Fail2ban:

sudo systemctl restart fail2ban # Перезапускаем Fail2ban для применения изменений
sudo fail2ban-client status sshd # Проверяем статус защиты SSH

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

Теперь, когда сервер подготовлен, перейдём к установке основного программного обеспечения: Docker, Docker Compose и Caddy.

1. Установка Docker Engine (актуально на 2026 год)

Мы будем устанавливать Docker из официального репозитория Docker, чтобы всегда иметь актуальные версии. Актуальные версии Docker Engine на 2026 год будут, вероятно, в диапазоне 25.x-26.x.

# Обновляем пакеты и устанавливаем зависимости
sudo apt update && sudo apt install -y ca-certificates curl gnupg lsb-release

# Добавляем официальный 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
sudo chmod a+r /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

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

# Устанавливаем Docker Engine, Docker CLI и containerd
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Добавляем текущего пользователя в группу docker для работы без sudo
sudo usermod -aG docker "$USER"

# Применяем изменения для группы Docker (нужно перелогиниться или перезагрузить)
# Но лучше просто перелогиниться или выполнить 'newgrp docker'
newgrp docker

# Проверяем установку Docker
docker run hello-world

Команда docker run hello-world должна успешно загрузить и запустить тестовый контейнер, подтверждая корректную установку Docker.

2. Установка Docker Compose

Docker Compose — это инструмент для определения и запуска многоконтейнерных Docker-приложений. Он поставляется как часть Docker Engine с версии 2.x.

# Проверяем версию Docker Compose (Docker Compose v2.x поставляется как плагин Docker CLI)
docker compose version

Если команда docker compose version возвращает ошибку или очень старую версию, возможно, вам потребуется установить его отдельно. Однако, для Ubuntu 24.04/26.04 и Docker Engine 25.x+ он должен быть доступен по умолчанию.

3. Установка Caddy (актуально на 2026 год)

Caddy можно установить из официального репозитория Caddy, что гарантирует получение последних стабильных версий (Caddy 2.x).

# Устанавливаем зависимости для добавления репозитория HTTPS
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

# Добавляем GPG ключ Caddy
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

# Добавляем репозиторий Caddy в APT источники
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

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

# Устанавливаем Caddy
sudo apt install -y caddy

# Проверяем статус службы Caddy
sudo systemctl status caddy

Служба Caddy должна быть установлена и запущена. Если она не запущена, запустите её: sudo systemctl start caddy.

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

Теперь, когда все компоненты установлены, пришло время настроить их взаимодействие. Мы настроим Caddy как обратный прокси для Docker-контейнеров, используя Docker Compose для определения наших приложений.

1. Подготовка сетевой инфраструктуры Docker

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

# Создаем пользовательскую сеть Docker для Caddy и приложений
docker network create caddy_network

Эту сеть мы будем указывать в файлах docker-compose.yml для наших приложений и для самого Caddy.

2. Конфигурация Caddyfile

Caddy использует файл Caddyfile для своей конфигурации. Мы настроим его для проксирования трафика к нашим Docker-контейнерам.

sudo nano /etc/caddy/Caddyfile # Открываем основной конфигурационный файл Caddy

Удалите существующее содержимое и вставьте следующее. Замените your-app.example.com и another-app.example.com на ваши реальные доменные имена, а app_container_name и another_app_container_name на имена ваших Docker-конконтейнеров.

# Глобальные настройки Caddy
{
    # Указываем, что Caddy должен использовать DNS-серверы Google для Let's Encrypt
    # Это может быть полезно, если у вашего VPS есть проблемы с резолвингом DNS
    # acme_dns google # Раскомментируйте, если используете DNS-провайдера, поддерживающего ACME DNS challenge
    # email [email protected] # Укажите ваш email для уведомлений Let's Encrypt
}

# Конфигурация для первого приложения
your-app.example.com {
    # Проксируем весь трафик на Docker-контейнер
    reverse_proxy app_container_name:80

    # Дополнительные заголовки для лучшей совместимости и безопасности
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options DENY
        X-Content-Type-Options nosniff
        X-XSS-Protection "1; mode=block"
    }

    # Логирование запросов
    log {
        output file /var/log/caddy/your-app.log
        format json
    }

    # Сжатие Gzip (опционально, но рекомендуется)
    encode gzip
}

# Конфигурация для второго приложения (пример)
another-app.example.com {
    reverse_proxy another_app_container_name:8080 # Укажите порт, на котором слушает ваше второе приложение

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options DENY
        X-Content-Type-Options nosniff
        X-XSS-Protection "1; mode=block"
    }

    log {
        output file /var/log/caddy/another-app.log
        format json
    }

    encode gzip
}

# Вы также можете добавить директиву для статических файлов, если Caddy будет их обслуживать
# example.com {
#     root  /var/www/html
#     file_server
# }

sudo mkdir -p /var/log/caddy
sudo chown caddy:caddy /var/log/caddy # Даем права пользователю caddy
sudo systemctl restart caddy # Перезапускаем Caddy для применения нового Caddyfile
sudo systemctl status caddy  # Проверяем, что Caddy успешно запустился

mkdir ~/my_web_app
cd ~/my_web_app
nano docker-compose.yml

version: '3.8'

services:
  # Имя сервиса, которое будет использоваться Caddy для проксирования
  # Убедитесь, что оно совпадает с именем в Caddyfile (например, 'app_container_name')
  mywebapp:
    image: nginx:latest # Используем актуальный образ Nginx
    container_name: mywebapp_container # Явное имя контейнера
    restart: unless-stopped
    ports:
      - "80" # Nginx слушает на порту 80 внутри контейнера
    networks:
      - caddy_network # Подключаем контейнер к сети Caddy

networks:
  caddy_network:
    external: true # Указываем, что сеть уже существует и была создана вручную

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

sudo nano /etc/caddy/Caddyfile

# ... другие настройки ...

# Конфигурация для вашего нового приложения
my-nginx-app.example.com { # Замените на ваш реальный домен
    reverse_proxy mywebapp:80 # Имя сервиса из docker-compose.yml и внутренний порт
    log {
        output file /var/log/caddy/my-nginx-app.log
        format json
    }
    encode gzip
}

# ... остальные настройки ...

sudo systemctl reload caddy # Перезагружаем конфигурацию Caddy без остановки сервиса

nano ~/my_web_app/.env

DB_PASSWORD=MyStrongPassword123
API_KEY=supersecretkeyabc123

version: '3.8'

services:
  mywebapp:
    image: mycustomapp:latest
    container_name: mywebapp_container
    restart: unless-stopped
    environment:
      - DB_PASSWORD=${DB_PASSWORD} # Передаем переменную из .env
      - API_KEY=${API_KEY}
    networks:
      - caddy_network

networks:
  caddy_network:
    external: true

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

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

1. Что бэкапить

Для Docker-контейнеров и Caddy необходимо бэкапить следующие данные:

• Docker Volumes: Это самая важная часть. Все постоянные данные ваших приложений (базы данных, загруженные файлы, пользовательские данные) должны храниться в Docker Volumes. Убедитесь, что вы правильно мапируете их из контейнеров на хостовую систему.
• Конфигурационные файлы Caddy: Файл /etc/caddy/Caddyfile и любые другие файлы, на которые он ссылается.
• Конфигурационные файлы Docker Compose: Файлы docker-compose.yml для всех ваших приложений.
• SSL-сертификаты Caddy: Caddy хранит свои сертификаты в /var/lib/caddy/.local/share/caddy/. Хотя Caddy автоматически их восстановит, бэкап может ускорить восстановление.
• Системные конфигурации: SSH-конфигурация, правила UFW, настройки Fail2ban.

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

Мы создадим простой скрипт, который будет архивировать важные данные и отправлять их в безопасное место. Для примера будем использовать tar для архивации и rsync для копирования на удалённый сервер. Для более надёжных и инкрементальных бэкапов рассмотрите restic или borgbackup.

Создайте директорию для скриптов и сам скрипт:

mkdir -p ~/scripts
nano ~/scripts/backup_script.sh

Содержимое backup_script.sh (замените /path/to/your/docker_volumes и user@remote_backup_server:/path/to/backups на ваши значения):

#!/bin/bash

# Настройки
BACKUP_DIR="/var/backups/my_vps"
DATA_TO_BACKUP="/path/to/your/docker_volumes /etc/caddy /etc/ssh /etc/ufw /etc/fail2ban /home/username/my_web_app"
REMOTE_BACKUP_TARGET="user@remote_backup_server:/path/to/backups" # S3-совместимое хранилище или другой VPS

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

# Имя файла бэкапа
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILENAME="vps_backup_${TIMESTAMP}.tar.gz"
FULL_BACKUP_PATH="${BACKUP_DIR}/${BACKUP_FILENAME}"

echo "Starting backup at ${TIMESTAMP}..."

# Создаем архив
sudo tar -czf "$FULL_BACKUP_PATH" $DATA_TO_BACKUP

if [ $? -eq 0 ]; then
    echo "Backup archive created: $FULL_BACKUP_PATH"
    # Копируем архив на удаленный сервер
    rsync -avz --remove-source-files "$FULL_BACKUP_PATH" "$REMOTE_BACKUP_TARGET"

    if [ $? -eq 0 ]; then
        echo "Backup successfully transferred to remote: $REMOTE_BACKUP_TARGET"
        # Очистка старых бэкапов (например, храним 7 последних)
        find "$BACKUP_DIR" -type f -name ".tar.gz" -mtime +7 -delete
        echo "Old local backups cleaned up."
    else
        echo "ERROR: Failed to transfer backup to remote."
    fi
else
    echo "ERROR: Failed to create backup archive."
fi

echo "Backup process finished."

Сделайте скрипт исполняемым:

chmod +x ~/scripts/backup_script.sh

Настройте cron для автоматического запуска скрипта (например, ежедневно в 3:00 ночи):

crontab -e # Открываем crontab для текущего пользователя

Добавьте строку в конец файла:

0 3   * /home/username/scripts/backup_script.sh >> /var/log/backup.log 2>&1

Это будет запускать скрипт каждый день в 3:00 утра и записывать вывод в /var/log/backup.log.

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

Никогда не храните бэкапы на том же сервере, что и исходные данные. Это критически важно. Варианты:

• Внешнее S3-совместимое хранилище: Облачные хранилища, такие как Amazon S3, DigitalOcean Spaces, Backblaze B2, Yandex Object Storage, предлагают надёжное и экономичное хранение. Инструменты вроде rclone или restic могут напрямую работать с S3.
• Отдельный VPS: Недорогой VPS с большим диском, используемый исключительно для хранения бэкапов. Доступ по SSH/SCP/RSync.
• Локальное хранилище: Если это домашний сервер, можно использовать сетевое хранилище (NAS).

4. Обновления: Rolling vs. Maintenance Window

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

• Rolling Updates (непрерывные обновления): Подходит для систем с высокой доступностью, где есть несколько экземпляров приложения. Обновление происходит по очереди, без остановки всего сервиса. Для одного VPS это обычно не применимо.
• Maintenance Window (окно обслуживания): Стандартный подход для одиночных серверов. Выбирается время (обычно ночью или в выходные), когда нагрузка минимальна, и проводятся обновления.
  1. Обновление ОС: Ежемесячно или раз в несколько месяцев:

     
     sudo apt update && sudo apt upgrade -y
     sudo reboot # Перезагрузка после обновления ядра или важных системных компонентов
                         

  2. Обновление Docker-образов: Раз в несколько недель или по мере выхода новых версий ваших приложений:

     
     cd ~/my_web_app # Перейдите в директорию с docker-compose.yml
     docker compose pull # Скачиваем новые версии образов
     docker compose up -d # Пересоздаем контейнеры с новыми образами
                         

  3. Обновление Caddy: Caddy обновляется вместе с системными пакетами (sudo apt upgrade). После обновления Caddy всегда проверяйте его статус и логи.

Всегда делайте бэкап перед крупными обновлениями или изменениями конфигурации.

Troubleshooting + FAQ

В этом разделе собраны типичные проблемы и часто задаваемые вопросы, которые могут возникнуть при развёртывании Caddy и Docker.

Что делать, если Caddy не запускается или не получает сертификат?

Проблема: Caddy не запускается, или вы получаете ошибку "TLS handshake error" / "certificate provisioning failed".

Что проверить:

1. Логи Caddy: Это первое, что нужно проверить.

   
   sudo journalctl -u caddy --since "5 minutes ago"
               

   Ищите ошибки, связанные с синтаксисом Caddyfile или проблемами с Let's Encrypt.
2. DNS-записи: Убедитесь, что A-запись вашего домена (например, my-nginx-app.example.com) указывает на публичный IP-адрес вашего VPS. Проверить можно с помощью dig или nslookup:

   
   dig +short my-nginx-app.example.com
               

3. Открытые порты: Убедитесь, что порты 80 (HTTP) и 443 (HTTPS) открыты в вашем фаерволе (UFW) на VPS. Let's Encrypt использует порт 80 для HTTP-01 challenge.

   
   sudo ufw status verbose
               

4. Синтаксис Caddyfile: Используйте команду для проверки синтаксиса Caddyfile:

   
   sudo caddy validate --config /etc/caddy/Caddyfile
               

5. Занятые порты: Убедитесь, что никакой другой процесс не слушает на портах 80 или 443.

   
   sudo lsof -i :80
   sudo lsof -i :443
               

Как фиксить: Исправьте DNS-запись, откройте порты в UFW, поправьте синтаксис Caddyfile согласно логам. Если Let's Encrypt выдаёт ошибку о превышении лимитов, подождите некоторое время (обычно час) и попробуйте снова.

Контейнер Docker не запускается или недоступен через Caddy.

Проблема: Контейнер не стартует, или Caddy не может до него достучаться (ошибка 502 Bad Gateway).

Что проверить:

1. Статус контейнера:

   
   docker ps -a # Показывает все контейнеры (запущенные и остановленные)
               

   Если контейнер не запущен, проверьте его логи:

   
   docker logs mywebapp_container
               

   Ищите ошибки, которые могут указывать на проблемы с приложением внутри контейнера.
2. Сеть Docker: Убедитесь, что контейнер и Caddy находятся в одной сети Docker (caddy_network).

   
   docker network inspect caddy_network
               

   Ищите ваш контейнер и контейнер Caddy в списке Containers.
3. Имя сервиса и порт: Убедитесь, что имя сервиса в Caddyfile (например, mywebapp) точно совпадает с именем сервиса в docker-compose.yml, и что указанный порт (например, :80) соответствует порту, на котором приложение слушает внутри контейнера.

Как фиксить: Исправьте ошибки в docker-compose.yml, перезапустите контейнер. Проверьте, что имя сервиса и порт в Caddyfile корректны и перезагрузите Caddy.

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

Для Caddy и одного-двух лёгких Docker-контейнеров (например, персональный блог, небольшой API) минимально подойдёт VPS с 1 CPU ядром, 2 ГБ RAM и 40-60 ГБ NVMe SSD диска. Этого достаточно для стабильной работы базовых сервисов, но при росте нагрузки или добавлении более ресурсоёмких приложений (например, баз данных, игровых серверов) потребуется апгрейд.

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

Для большинства задач, связанных с развёртыванием Caddy и Docker-контейнеров (личные проекты, небольшие команды, тестовые среды), VPS является оптимальным выбором из-за своей гибкости, масштабируемости и низкой стоимости. Выделенный сервер (dedicated) становится оправданным, если вам требуется максимальная и предсказуемая производительность, очень большие объёмы дискового пространства, специфическое аппаратное обеспечение (например, GPU) или строгие требования к изоляции и комплаенсу. Начните с VPS и рассмотрите переход на dedicated при значительном росте требований.

Как обновить Docker или Caddy?

Для обновления Docker и Caddy, установленных из официальных репозиториев, используйте стандартные команды менеджера пакетов:

sudo apt update          # Обновляем списки пакетов
sudo apt upgrade -y      # Обновляем все установленные пакеты, включая Docker и Caddy
sudo systemctl restart docker # Перезапускаем Docker после обновления
sudo systemctl restart caddy  # Перезапускаем Caddy после обновления

Рекомендуется выполнять эти действия в "окно обслуживания" и предварительно создавать бэкапы.

Могу ли я использовать Caddy для нескольких доменов?

Да, Caddy отлично подходит для хостинга множества доменов на одном VPS. Просто добавьте новые блоки конфигурации в ваш Caddyfile для каждого домена, указывая, на какой Docker-контейнер нужно проксировать трафик. Caddy автоматически позаботится о выдаче HTTPS-сертификатов для всех указанных доменов. Не забудьте обновить DNS-записи для каждого нового домена, чтобы они указывали на ваш VPS.

# ...
your-first-app.example.com {
    reverse_proxy first_app_container:80
}

your-second-app.example.com {
    reverse_proxy second_app_container:8080
}
# ...

Как добавить базовую аутентификацию (логин/пароль) через Caddy?

Caddy поддерживает базовую HTTP-аутентификацию. Вы можете добавить её в блок вашего домена в Caddyfile:

my-protected-app.example.com {
    reverse_proxy protected_app_container:80
    basicauth / {
        username JDUyJDEwJEQ1R015VjR2bVluYmF1Wk9kSjF4dC5tT1I0L2d6LzZqRTlRSDh3c3B0ZlJ1c05xV0o0NEdwYQ== # Пароль 'SecurePassword123'
    }
}

Замените username и хеш пароля на свои. Хеш можно сгенерировать командой caddy hash-password --plaintext "Your_Secure_Password". Это полезно для защиты внутренних инструментов или админок.

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

Мы успешно развернули Caddy как обратный прокси для Docker-контейнеров на VPS, обеспечив автоматическое получение HTTPS-сертификатов. Эта настройка предоставляет мощную, гибкую и безопасную основу для хостинга ваших веб-приложений, сочетая простоту Caddy с изоляцией и переносимостью Docker.

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

Следующие шаги для развития вашей инфраструктуры:

• Мониторинг и логирование: Интегрируйте системы мониторинга (например, Prometheus + Grafana) для отслеживания состояния сервера и контейнеров. Настройте централизованное логирование (например, ELK Stack или Loki + Grafana) для эффективного анализа логов всех ваших приложений.
• CI/CD пайплайны: Автоматизируйте развёртывание ваших приложений с помощью CI/CD систем (например, GitLab CI, GitHub Actions, Jenkins). Это позволит вам быстрее и надёжнее доставлять новый код в продакшн.
• Увеличение отказоустойчивости и масштабирование: Для высоконагруженных проектов рассмотрите использование Docker Swarm или Kubernetes для оркестрации контейнеров на нескольких VPS, обеспечения высокой доступности и горизонтального масштабирования.