Деплой на Hetzner Cloud: Terraform, CI/CD, Docker Swarm

Ви купили VPS на Hetzner, встановили Ubuntu, запустили сайт через ручний scp. Через місяць розумієте: оновлення коду — це пекло, Nginx не налаштований під високе навантаження, а SSL-сертифікат прострочився в п'ятницю ввечері.

Кожен реліз перетворюється на багатогодинний стрес, замовники скаржаться на повільне завантаження. Ми налаштовуємо деплой так, щоб усе працювало автоматично: натиснули кнопку в GitHub — сайт оновився за хвилину, моніторинг надсилає алерт при збої.

Економія часу та нервів — наш пріоритет. Зв'яжіться з нами для консультації — розповімо, як прискорити ваш релізний цикл.

Проблеми які вирішуємо

• Ручний деплой через FTP/SCP — повільно, помилки, немає історії змін. Ми замінюємо на Git-based CI/CD з відкатом.
• Nginx без кешування та gzip — високий TTFB, провал Core Web Vitals. Оптимізуємо LCP та CLS.
• SSL-сертифікат спливає — налаштовуємо Let's Encrypt з автооновленням через systemd timer.
• Немає моніторингу — не знаєте про падіння сервера до ранку. Ставимо Prometheus + Node Exporter + Alertmanager.
• Масштабування — один сервер не витримує навантаження. Використовуємо Docker Swarm на декількох VPS з Load Balancer.

Як ми це робимо

Використовуємо infrastructure as code: весь конфіг — у Git. Terraform створює сервери, firewall, DNS, Object Storage. Packer збирає образи. Ansible — налаштування ПО. GitHub Actions — деплой після кожного push.

Реальний кейс: клієнт-маркетплейс із 50 000 товарів. Раніше деплой займав 2 години через ручний rsync. Ми побудували пайплайн:

1. GitHub Actions збирає Docker образи.
2. Завантажує їх у реєстр (GitHub Container Registry).
3. По SSH запускає docker stack deploy на Swarm-кластері з 3 нод.

Час релізу скоротився до 2 хвилин. Відкат — ще швидше: git revert і новий push.

Як працює CI/CD пайплайн?

Кожен push у main-гілку запускає збірку, тести (якщо є) та деплой на staging. Після ручного підтвердження — деплой на продакшн. Усі кроки описані в YAML-файлі в репозиторії, тому зміни відстежуються та відтворюються.

Terraform для інфраструктури

# main.tf (початок)
terraform {
  required_providers {
    hcloud = {
      source = "hetznercloud/hcloud"
      version = "~> 1.44"
    }
  }
}

provider "hcloud" { token = var.hcloud_token } resource "hcloud_server" "app" { name = "myapp-prod" image = "ubuntu-22.04" server_type = "cpx21" location = "nbg1" ssh_keys = [hcloud_ssh_key.default.id] user_data = file("cloud-init.yaml") labels = { env = "production" app = "myapp" } }

resource "hcloud_firewall" "app" {
  name = "myapp-firewall"
  rule {
    direction = "in"
    protocol = "tcp"
    port = "22"
    source_ips = ["10.0.0.0/8"]
  }
  rule {
    direction = "in"
    protocol = "tcp"
    port = "80"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
  rule {
    direction = "in"
    protocol = "tcp"
    port = "443"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
}

resource "hcloud_load_balancer" "lb" {
  name = "myapp-lb"
  load_balancer_type = "lb11"
  location = "nbg1"
}

resource "hcloud_load_balancer_target" "server" {
  type = "server"
  load_balancer_id = hcloud_load_balancer.lb.id
  server_id = hcloud_server.app.id
}

GitHub Actions для CI/CD

---
name: Deploy to Hetzner
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.HETZNER_IP }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            set -e
            cd /var/www/myapp
            git fetch origin main
            git reset --hard origin/main
            composer install --no-dev --optimize-autoloader
            npm ci --omit=dev
            npm run build
            php artisan migrate --force
            php artisan optimize
            sudo systemctl reload php8.3-fpm nginx
            php artisan queue:restart
---

Hetzner Object Storage для статики

aws configure set aws_access_key_id $HETZNER_S3_KEY
aws configure set aws_secret_access_key $HETZNER_S3_SECRET
aws configure set region eu-central
aws --endpoint-url https://fsn1.your-objectstorage.com s3 mb s3://myapp-assets
aws --endpoint-url https://fsn1.your-objectstorage.com s3 sync ./dist/assets s3://myapp-assets/assets --cache-control "public, max-age=31536000, immutable"

Що таке Docker Swarm і для чого він потрібен?

Docker Swarm — це нативний кластеризатор Docker, який об'єднує кілька серверів в єдиний обчислювальний простір. Він забезпечує автоматичний розподіл контейнерів, балансування навантаження та відновлення при збоях.

Для проєктів, яким потрібне горизонтальне масштабування та відмовостійкість без складності Kubernetes, Swarm — оптимальний вибір.

Кластер Docker Swarm

# Ініціалізація на першому сервері
ssh server1 "docker swarm init"
# Отримання токена
JOIN_TOKEN=$(ssh server1 "docker swarm join-token worker -q")
# Додавання робочих вузлів
ssh server2 "docker swarm join --token $JOIN_TOKEN server1:2377"
ssh server3 "docker swarm join --token $JOIN_TOKEN server1:2377"
# Деплой стека
docker -H ssh://deploy@server1 stack deploy -c docker-compose.prod.yml myapp

Процес роботи

• Аналіз — вивчаємо поточну інфраструктуру, вимоги до навантаження та бюджет.
• Проєктування — обираємо серверні типи, схему балансування, стек ПЗ.
• Реалізація — пишемо Terraform, Ansible, CI/CD, моніторинг.
• Тестування — перевіряємо деплой на staging-сервері, навантажувальне тестування.
• Деплой — переносимо на продакшн, налаштовуємо алерти та бекапи.

Орієнтовні терміни

Вартість розраховується індивідуально — пишіть, оцінимо ваш проєкт.

Типові проблеми та рішення

Що входить у роботу

• Розгорнута документація схеми та конфігурацій.
• Доступи до серверів і адмінки.
• Навчання вашої команди (1-2 години дзвінка).
• Підтримка протягом 1 місяця після здачі.

Як налаштувати деплой на Hetzner за 1 день?

Якщо сайт уже працює на одному сервері, ми додаємо:

• Автоматичний SSL (Certbot systemd timer).
• GitHub Actions зі швидким скриптом деплою.
• Моніторинг Uptime Kuma на окремому VPS.
• Щоденний бекап бази в Object Storage.

Усе це — з гарантією працездатності. За кілька років ми виконали понад 50 проєктів на Hetzner — від невеликих лендингів до високонавантажених маркетплейсів. Замовте налаштування під ключ — підберемо оптимальну конфігурацію та намалюємо roadmap міграції.

Чому варто обрати Hetzner для продакшену?

• Дата-центри в Європі, що відповідають GDPR.
• Ціна в 3–5 разів нижча за AWS/GCP за аналогічної продуктивності.
• Висока надійність: uptime 99.9% за SLA.
• Простий API та CLI для автоматизації.

Отримайте консультацію — розповімо, як оптимізувати ваш поточний деплой.