Встановлення та налаштування V

Що ми налаштовуємо і навіщо

У цьому посібнику ми займемося встановленням та детальним налаштуванням Varnish Cache на віртуальному приватному сервері (VPS). Varnish — це потужний HTTP-акселератор, який працює як зворотний проксі-сервер. Його основне завдання — кешування часто запитуваного контенту, що дозволяє йому віддавати відповіді клієнтам безпосередньо, не перевантажуючи ваш основний веб-сервер (Apache, Nginx тощо).

В результаті успішного налаштування ви отримаєте:

• Значне прискорення завантаження веб-сайту: Varnish обробляє запити набагато швидше, ніж традиційні веб-сервери, особливо для статичного контенту та сторінок, які рідко змінюються.
• Зниження навантаження на сервер: Менше запитів доходить до вашого веб-сервера та бази даних, що звільняє ресурси для обробки складніших завдань або більшої кількості унікальних запитів.
• Покращену масштабованість: Ваш сервер зможе витримувати значно більше навантаження та піки трафіку, оскільки Varnish бере на себе значну частину роботи.
• Підвищену відмовостійкість: У разі тимчасової недоступності бекенда, Varnish може продовжувати віддавати кешований контент, забезпечуючи часткову доступність сайту.

Альтернативи та чому self-hosted на VPS

Для прискорення веб-сайтів існують різні підходи:

• CDN (Content Delivery Network): Глобальні мережі серверів, які кешують контент і доставляють його користувачам з найближчого вузла. Чудово підходить для географічно розподіленої аудиторії. Приклади: Cloudflare, Akamai, Amazon CloudFront.
• Кешування на рівні веб-сервера: Nginx та Apache мають вбудовані модулі кешування. Вони ефективні, але менш гнучкі та продуктивні для чистого HTTP-кешування, ніж Varnish.
• Кешування на рівні застосунку: Плагіни для CMS (WordPress, Joomla), фреймворків (Laravel, Symfony) або кастомна логіка застосунку. Це дозволяє кешувати дані з бази даних або згенеровані сторінки.

Вибір self-hosted Varnish на VPS має низку переваг, особливо для власників серверів, яким потрібен повний контроль та оптимізація витрат:

• Повний контроль: Ви повністю контролюєте конфігурацію Varnish, VCL (Varnish Configuration Language), правила кешування та логіку. Це критично для складних застосунків.
• Економія: Для багатьох проєктів вартість VPS + Varnish може бути значно нижчою, ніж щомісячні платежі за CDN або керовані сервіси кешування, особливо при високих обсягах трафіку.
• Оптимізація під конкретне завдання: Ви можете тонко налаштувати Varnish під специфіку вашого застосунку, що часто неможливо із загальними CDN-рішеннями.
• Простота інтеграції: Varnish легко інтегрується з існуючою інфраструктурою на VPS.

У цьому туторіалі ми зосередимося на практичних кроках, щоб ви могли самостійно розгорнути та налаштувати Varnish, використовуючи актуальні версії ПЗ та найкращі практики.

Який VPS-конфіг потрібен для цього завдання

Вимоги до VPS для Varnish Cache залежать в основному від обсягу кешованого контенту, очікуваного трафіку та складності правил VCL. Varnish відомий своєю високою продуктивністю та ефективним використанням ресурсів, особливо оперативної пам'яті.

Мінімальні вимоги (для невеликих сайтів/проєктів)

• CPU: 1 ядро (наприклад, Intel Xeon E5 або аналогічний). Varnish не інтенсивно використовує CPU, якщо тільки не обробляє дуже великий обсяг запитів на секунду або складні VCL-правила.
• RAM: 1-2 GB. Основне споживання пам'яті Varnish припадає на зберігання кешу. Чим більше RAM, тим більше контенту можна кешувати в пам'яті, що забезпечує максимальну швидкість.
• Диск: 20-40 GB NVMe/SSD. Varnish може кешувати на диск, але це значно повільніше, ніж у RAM. Диск потрібен для ОС, логів та зберігання резервних копій. NVMe/SSD важливий для загальної чутливості системи.
• Мережа: 100 Mbps - 1 Gbps. Висока пропускна здатність мережі важлива, оскільки Varnish віддаватиме кешований контент безпосередньо клієнтам.

Рекомендований VPS-план (для середніх сайтів/проєктів)

Для більшості проєктів, включаючи SaaS-застосунки, GitLab, Mattermost або помірно відвідувані ігрові сервери (якщо Varnish використовується для веб-інтерфейсу), рекомендується наступний конфіг:

• CPU: 2-4 ядра (сучасний Intel Xeon або AMD EPYC). Забезпечить запас для обробки піків трафіку та роботи інших сервісів.
• RAM: 4-8 GB. Дозволить кешувати значний обсяг контенту в оперативній пам'яті, що критично для продуктивності.
• Диск: 80-160 GB NVMe/SSD. Достатньо місця для ОС, логів Varnish, резервних копій та інших системних файлів.
• Мережа: 1 Gbps. Стабільний та швидкий канал для віддачі контенту.

Можна взяти VPS із зазначеними характеристиками, щоб забезпечити оптимальну продуктивність та стабільність роботи Varnish Cache.

Коли потрібен dedicated, а не VPS

Dedicated сервер стає необхідним, якщо:

• Дуже високий трафік: Якщо ваш сайт або застосунок генерує сотні мільйонів запитів на місяць, і Varnish постійно працює на межі можливостей VPS.
• Великий обсяг кешу: Якщо вам потрібно кешувати сотні гігабайт даних у пам'яті для максимальної продуктивності, а VPS з таким обсягом RAM занадто дорогий або недоступний.
• Вимоги до ізоляції: Для критично важливих застосунків, де важлива повна ізоляція ресурсів та відсутність "сусідів" по гіпервізору.
• Специфічні апаратні вимоги: Якщо вам потрібні особливі мережеві карти, RAID-контролери або інші апаратні особливості, недоступні на VPS.

Для дуже великих проєктів, де Varnish є частиною складної інфраструктури, може знадобитися виділений сервер. Відповідний dedicated сервер забезпечить максимальну продуктивність та гнучкість.

Локація: на що впливає

Вибір локації VPS має прямий вплив на:

• Затримку (latency): Чим ближче сервер до вашої основної аудиторії, тим нижча затримка і швидше завантаження сторінок. Для Varnish це особливо критично, оскільки він знаходиться на передньому краї обробки запитів.
• Відповідність законодавству: Деякі регіони мають суворі вимоги до зберігання даних (наприклад, GDPR в Європі). Вибір локації сервера повинен враховувати ці аспекти.
• Вартість: Ціни на VPS можуть варіюватися залежно від регіону.

Завжди обирайте локацію, максимально близьку до вашої цільової аудиторії для досягнення найкращої продуктивності.

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

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

1. Підключення по SSH та створення користувача

Передбачається, що ви підключилися до сервера як користувач root. Насамперед створимо нового користувача з правами sudo для повсякденної роботи.

# Додаємо нового користувача (замініть 'ваш_пользователь' на бажане ім'я)
sudo adduser ваш_пользователь

Дотримуйтесь інструкцій, щоб встановити пароль та інформацію про користувача. Потім додайте користувача до групи sudo, щоб він міг виконувати команди з правами адміністратора.

# Додаємо користувача до групи sudo
sudo usermod -aG sudo ваш_пользователь

Вийдіть із сесії root та увійдіть під новим користувачем:

# Вихід із поточної сесії
exit
# Підключення під новим користувачем
ssh ваш_пользователь@ваш_ip_сервера

2. Налаштування SSH-ключів (рекомендується)

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

# На вашій локальній машині
ssh-keygen -t rsa -b 4096

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

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

Після цього вимкніть вхід за паролем для root та вашого користувача, відредагувавши файл /etc/ssh/sshd_config:

# Відкриваємо файл конфігурації SSH-сервера
sudo nano /etc/ssh/sshd_config

Знайдіть та змініть наступні рядки (або додайте, якщо їх немає):

# Вимикаємо вхід за паролем
PasswordAuthentication no
# Вимикаємо вхід для root (якщо ви не використовуєте його для інших цілей)
PermitRootLogin no

Збережіть файл (Ctrl+O, потім Enter) та вийдіть (Ctrl+X). Перезапустіть SSH-сервіс:

# Перезапускаємо SSH-сервіс, щоб застосувати зміни
sudo systemctl restart sshd

3. Налаштування файрволу (UFW)

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

# Оновлюємо список пакетів
sudo apt update
# Встановлюємо UFW
sudo apt install ufw -y
# Дозволяємо SSH-підключення (порт 22)
sudo ufw allow OpenSSH
# Дозволяємо HTTP (порт 80)
sudo ufw allow http
# Дозволяємо HTTPS (порт 443)
sudo ufw allow https
# Вмикаємо файрвол
sudo ufw enable
# Перевіряємо статус файрволу
sudo ufw status verbose

При ввімкненні файрволу вам буде запропоновано підтвердити дію. Введіть y та натисніть Enter.

4. Встановлення Fail2ban

Fail2ban сканує логи сервера на предмет підозрілої активності (наприклад, невдалих спроб входу SSH) та тимчасово блокує IP-адреси зловмисників.

# Встановлюємо Fail2ban
sudo apt install fail2ban -y
# Вмикаємо та запускаємо сервіс Fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
# Перевіряємо статус
sudo systemctl status fail2ban

Fail2ban за замовчуванням налаштований для захисту SSH. Ви можете створити файл конфігурації /etc/fail2ban/jail.local для більш тонкого налаштування, наприклад:

# Створюємо локальний файл конфігурації Fail2ban
sudo nano /etc/fail2ban/jail.local

Додайте наступний вміст:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h

Збережіть та вийдіть. Перезапустіть Fail2ban:

# Перезапускаємо Fail2ban для застосування нових правил
sudo systemctl restart fail2ban

5. Оновлення системи

Завжди підтримуйте вашу систему в актуальному стані.

# Оновлюємо список пакетів
sudo apt update
# Оновлюємо всі встановлені пакети
sudo apt upgrade -y
# Видаляємо невикористовувані пакети та залежності
sudo apt autoremove -y

Ваш сервер готовий до встановлення Varnish Cache та супутніх сервісів.

Встановлення ПЗ — покроково

Тепер, коли сервер підготовлений, приступимо до встановлення Varnish Cache, а також Nginx (як бекенд веб-сервер) та Caddy (як фронтенд для SSL-термінації та проксіювання).

1. Встановлення Nginx (бекенд веб-сервер)

Nginx буде слухати на внутрішньому порту та віддавати контент Varnish. Ми встановимо актуальну версію, доступну через репозиторії Ubuntu 24.04 LTS.

# Оновлюємо список пакетів
sudo apt update
# Встановлюємо Nginx (версія 1.25.x або новіша до 2026 року)
sudo apt install nginx -y
# Перевіряємо статус Nginx
sudo systemctl status nginx

Nginx має бути активним (active (running)).

2. Встановлення Varnish Cache

Встановимо Varnish Cache з офіційних репозиторіїв Ubuntu. До 2026 року очікується стабільна версія Varnish 7.x (наприклад, 7.4 або 7.5).

# Додаємо ключ GPG для офіційного репозиторію Varnish
sudo curl -s https://packagecloud.io/varnishcache/varnish7/gpgkey | sudo gpg --dearmor | sudo tee /usr/share/keyrings/varnishcache.gpg > /dev/null
# Додаємо репозиторій Varnish Cache
echo "deb [signed-by=/usr/share/keyrings/varnishcache.gpg] https://packagecloud.io/varnishcache/varnish7/ubuntu/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/varnishcache.list
# Оновлюємо список пакетів, щоб включити новий репозиторій
sudo apt update
# Встановлюємо Varnish Cache (версія 7.4.x або новіша)
sudo apt install varnish -y
# Перевіряємо статус Varnish
sudo systemctl status varnish

Varnish також має бути активним. За замовчуванням він може бути налаштований на прослуховування порту 6081 або 80. Ми змінимо це в наступному розділі.

3. Встановлення Caddy (SSL-термінатор та фронтенд)

Caddy — це сучасний веб-сервер з автоматичним HTTPS. Він буде прослуховувати порти 80 і 443, обробляти SSL та проксіювати запити до Varnish. До 2026 року Caddy 2.x буде основною стабільною версією.

# Встановлюємо залежності для Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
# Додаємо ключ GPG для репозиторію Caddy
sudo curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
# Додаємо репозиторій Caddy
sudo 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 (версія 2.x)
sudo apt install caddy -y
# Перевіряємо статус Caddy
sudo systemctl status caddy

Caddy також має бути активним.

4. Відкриття портів у файрволі для внутрішнього зв'язку

Нам потрібно буде відкрити внутрішні порти для зв'язку між Caddy, Varnish та Nginx. Varnish буде слухати на порту 8080, а Nginx на 8081. Ці порти не повинні бути доступні ззовні.

# Дозволяємо внутрішні порти 8080 та 8081 тільки для localhost (127.0.0.1)
sudo ufw allow in on lo to any port 8080
sudo ufw allow in on lo to any port 8081
# Перевіряємо, що правила застосувалися
sudo ufw status verbose

Тепер усі необхідні компоненти встановлені, і ми можемо перейти до їх конфігурації.

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

Цей розділ описує покрокове налаштування всіх компонентів: Nginx (бек-енд), Varnish Cache та Caddy (фронт-енд з SSL).

1. Конфігурація Nginx (бек-енд)

Nginx буде слухати на внутрішньому порту 127.0.0.1:8081. Створимо новий конфігураційний файл для вашого сайту.

# Створюємо новий конфігураційний файл для вашого сайту
sudo nano /etc/nginx/sites-available/ваш_домен.conf

Додайте наступний вміст, замінивши ваш_домен.com на ваш реальний домен та вказавши шлях до ваших веб-файлів (наприклад, /var/www/ваш_домен/html).

server {
    listen 127.0.0.1:8081; # Nginx слухає тільки на localhost
    server_name ваш_домен.com www.ваш_домен.com;

    root /var/www/ваш_домен/html; # Шлях до ваших файлів
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ =404;
    }

    # Приклад для PHP-додатків
    # location ~ \.php$ {
    #     include snippets/fastcgi-php.conf;
    #     fastcgi_pass unix:/var/run/php/php8.3-fpm.sock; # Вкажіть актуальну версію PHP-FPM
    # }

    # Додавання заголовка для Varnish, щоб він знав, що це бек-енд
    add_header X-Served-By $host;
}

Створіть символічне посилання на sites-enabled та видаліть дефолтний конфіг Nginx:

# Створюємо символічне посилання
sudo ln -s /etc/nginx/sites-available/ваш_домен.conf /etc/nginx/sites-enabled/
# Видаляємо дефолтний конфіг Nginx
sudo rm /etc/nginx/sites-enabled/default
# Перевіряємо синтаксис конфігурації Nginx
sudo nginx -t
# Перезапускаємо Nginx
sudo systemctl restart nginx

Переконайтеся, що немає помилок, і Nginx успішно перезапустився.

2. Конфігурація Varnish Cache

Налаштуємо Varnish для прослуховування порту 127.0.0.1:8080 та проксіювання запитів до Nginx на 127.0.0.1:8081.

2.1. Налаштування Systemd для Varnish

Відредагуйте файл конфігурації Systemd для Varnish, щоб змінити порт прослуховування. Замість зміни /etc/default/varnish (який може бути перезаписаний при оновленні), ми використовуємо Systemd override.

# Створюємо директорію для override-файлів Systemd
sudo mkdir -p /etc/systemd/system/varnish.service.d/
# Створюємо файл override
sudo nano /etc/systemd/system/varnish.service.d/override.conf

Додайте наступний вміст:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a 127.0.0.1:8080 -F -f /etc/varnish/default.vcl -s malloc,2G

Тут:

• -a 127.0.0.1:8080: Varnish буде прослуховувати порт 8080 тільки на локальному інтерфейсі.
• -f /etc/varnish/default.vcl: Вказує шлях до файлу VCL.
• -s malloc,2G: Виділяє 2 ГБ оперативної пам'яті для кешу Varnish. Відрегулюйте це значення відповідно до доступної RAM вашого VPS (наприклад, 4G для 4ГБ).

Збережіть та вийдіть. Перезавантажте конфігурацію Systemd та перезапустіть Varnish:

# Перезавантажуємо конфігурацію Systemd
sudo systemctl daemon-reload
# Перезапускаємо Varnish
sudo systemctl restart varnish
# Перевіряємо статус Varnish
sudo systemctl status varnish

Переконайтеся, що Varnish запущений і слухає на 127.0.0.1:8080.

2.2. Налаштування VCL (Varnish Configuration Language)

Файл /etc/varnish/default.vcl визначає логіку кешування Varnish. Відкрийте його для редагування:

# Відкриваємо файл VCL
sudo nano /etc/varnish/default.vcl

Замініть вміст на наступний. Цей VCL-файл є хорошою відправною точкою, яка кешує статичний контент, обробляє куки та заголовки кешування.

vcl 4.1;

# Визначаємо бек-енд (Nginx)
backend default {
    .host = "127.0.0.1";
    .port = "8081";
    .probe = {
        .url = "/health"; # Шлях для перевірки працездатності бек-енду
        .interval = 5s;
        .timeout = 1s;
        .window = 5;
        .threshold = 3;
    }
}

# Обробка вхідних запитів
sub vcl_recv {
    # Видаляємо непотрібні заголовки, які можуть перешкодити кешуванню
    unset req.http.Cookie;
    unset req.http.If-Modified-Since;
    unset req.http.If-None-Match;

    # Всі запити до бек-енду відправляються, якщо метод не GET або HEAD
    if (req.method != "GET" && req.method != "HEAD") {
        return (pipe); # Або pass, якщо потрібно обробляти POST/PUT/DELETE
    }

    # Не кешувати AJAX-запити або запити до API
    if (req.url ~ "^/api/" || req.url ~ "^/ajax/") {
        return (pass);
    }

    # Не кешувати запити до адмін-панелей
    if (req.url ~ "^/admin/" || req.url ~ "^/wp-admin/" || req.url ~ "^/gitlab/admin/") {
        return (pass);
    }

    # Все інше намагаємося кешувати
    return (hash);
}

# Обробка відповідей від бек-енду
sub vcl_fetch {
    # Не кешувати сторінки з кодом помилки
    if (beresp.status >= 500) {
        return (abandon);
    }

    # Не кешувати сторінки з певними заголовками (наприклад, Set-Cookie)
    if (beresp.http.Set-Cookie) {
        return (pass);
    }

    # Встановлюємо час життя кешу за замовчуванням, якщо бек-енд не вказав Cache-Control
    if (!beresp.http.Cache-Control && !beresp.http.Expires) {
        set beresp.ttl = 1h; # Кешувати 1 годину за замовчуванням
    }

    # Видаляємо куки для кешованих об'єктів, щоб уникнути проблем з персоналізацією
    unset beresp.http.Set-Cookie;

    # Додаємо заголовок X-Varnish для налагодження
    set beresp.http.X-Varnish = regsub(server.identity, "\(([^)]+)\)", "");

    return (deliver);
}

# Обробка відповідей Varnish клієнту
sub vcl_deliver {
    # Додаємо заголовок про те, що об'єкт був доставлений з кешу
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
    set resp.http.X-Cache-Hits = obj.hits;
    unset resp.http.Via; # Видаляємо Via заголовок
    return (deliver);
}

Збережіть та вийдіть. Тепер перевірте VCL-файл на синтаксичні помилки та перезапустіть Varnish:

# Перевіряємо синтаксис VCL
sudo varnishd -C -f /etc/varnish/default.vcl
# Перезапускаємо Varnish
sudo systemctl restart varnish

Для коректної роботи перевірки бек-енду (.probe) додайте у ваш Nginx-конфіг (/etc/nginx/sites-available/ваш_домен.conf) location для /health:

    location = /health {
        add_header Content-Type text/plain;
        return 200 "OK";
    }

Не забудьте перезапустити Nginx після цієї зміни: sudo systemctl restart nginx.

3. Конфігурація Caddy (SSL-термінатор та фронт-енд)

Caddy буде слухати на портах 80 та 443, автоматично отримувати SSL-сертифікати та проксіювати запити до Varnish на 127.0.0.1:8080.

# Відкриваємо файл конфігурації Caddy
sudo nano /etc/caddy/Caddyfile

Замініть вміст на наступний, вказавши ваш домен:

ваш_домен.com {
    # Автоматичний HTTPS (Let's Encrypt)
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN} # Приклад для Cloudflare DNS API. Використовуйте HTTP-challenge або інший DNS-провайдер.
    }

    # Проксіюємо всі запити до Varnish
    reverse_proxy 127.0.0.1:8080 {
        # Передаємо реальний IP клієнта
        header_up X-Forwarded-For {remote_host}
        header_up X-Real-IP {remote_host}
        header_up Host {host}
        # Передаємо інформацію про HTTPS
        header_up X-Forwarded-Proto {scheme}
    }

    # Вмикаємо стиснення Gzip (якщо Varnish не робить це самостійно)
    encode gzip zstd

    # Логування
    log {
        output file /var/log/caddy/access.log
    }
}

Важливе зауваження про TLS: У прикладі використовується DNS-challenge для Let's Encrypt з Cloudflare. Якщо ви не використовуєте Cloudflare або віддаєте перевагу HTTP-challenge, видаліть рядок dns cloudflare {env.CLOUDFLARE_API_TOKEN}. Caddy автоматично спробує використовувати HTTP-challenge, якщо порт 80 доступний.

Якщо ви використовуєте DNS-challenge, створіть файл /etc/caddy/.env для зберігання токена API Cloudflare:

# Створюємо директорію для .env файлу
sudo mkdir -p /etc/caddy
# Створюємо .env файл
sudo nano /etc/caddy/.env

Додайте ваш API-токен:

CLOUDFLARE_API_TOKEN=ВАШ_CLOUDFLARE_API_ТОКЕН

Переконайтеся, що права на файл .env обмежені:

# Встановлюємо права тільки для власника
sudo chmod 600 /etc/caddy/.env
# Встановлюємо власника Caddy
sudo chown caddy:caddy /etc/caddy/.env

Збережіть Caddyfile та .env. Перевірте синтаксис Caddy та перезапустіть його:

# Перевіряємо синтаксис Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
# Перезапускаємо Caddy
sudo systemctl restart caddy
# Перевіряємо статус Caddy
sudo systemctl status caddy

Переконайтеся, що Caddy запущений та успішно отримав SSL-сертифікати.

4. Перевірка працездатності

Після налаштування всіх компонентів, переконаємося, що все працює коректно.

# Перевіряємо доступність сайту через Curl
curl -I https://ваш_домен.com

У заголовках відповіді ви повинні побачити:

• HTTP/2 200 (або HTTP/1.1 200)
• server: Caddy
• x-cache: MISS (при першому запиті)
• x-cache-hits: 0 (при першому запиті)

Повторіть запит кілька разів:

# Повторний запит через Curl
curl -I https://ваш_домен.com

Тепер ви повинні побачити:

• x-cache: HIT
• x-cache-hits: 1 (або більше, якщо запитів було багато)

Це підтверджує, що Varnish успішно кешує контент. Ви також можете використовувати varnishlog та varnishstat для моніторингу Varnish:

# Перегляд логів Varnish в реальному часі
sudo varnishlog
# Статистика Varnish
sudo varnishstat

Натисніть Ctrl+C для виходу з varnishlog/varnishstat.

Резервне копіювання та обслуговування

Регулярне резервне копіювання та своєчасне обслуговування є критично важливими для стабільності та безпеки вашого веб-сайту, що працює з Varnish Cache.

1. Що резервувати

Для Varnish Cache та супутньої інфраструктури необхідно резервувати наступні елементи:

• Конфігураційні файли Varnish:
  • /etc/varnish/default.vcl (основний VCL-файл)
  • /etc/systemd/system/varnish.service.d/override.conf (конфігурація Systemd)
• Конфігураційні файли веб-сервера (Nginx):
  • /etc/nginx/nginx.conf
  • /etc/nginx/sites-available/ваш_домен.conf
  • /etc/nginx/sites-enabled/ (символічні посилання)
• Конфігураційні файли Caddy:
  • /etc/caddy/Caddyfile
  • /etc/caddy/.env (якщо використовується)
  • /var/lib/caddy/.local/share/caddy/ (сертифікати Let's Encrypt, якщо не використовуються DNS-плагіни)
• Файли веб-сайту: Весь контент вашого сайту (HTML, CSS, JS, зображення, PHP-скрипти тощо), зазвичай розташований у /var/www/ваш_домен/html.
• База даних: Якщо ваш сайт використовує базу даних (MySQL, PostgreSQL), обов'язково робіть її дамп.
• Системні конфігурації: /etc/ssh/sshd_config, /etc/ufw/, /etc/fail2ban/.

2. Простий скрипт авторезервування

Ви можете використовувати простий скрипт на bash у поєднанні з cron для автоматичного створення архівів. Для зберігання можна використовувати rsync для копіювання на інший сервер або restic/borg для дедуплікованих та зашифрованих резервних копій на S3-сумісне сховище.

Приклад простого скрипта для створення архівів (/usr/local/bin/backup_script.sh):

#!/bin/bash

# Налаштування
BACKUP_DIR="/var/backups/webserver"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
WEB_ROOT="/var/www/ваш_домен/html"
NGINX_CONF="/etc/nginx"
VARNISH_CONF="/etc/varnish"
CADDY_CONF="/etc/caddy"
DB_NAME="ваша_база_даних" # Замініть на ім'я вашої БД
DB_USER="ваш_пользователь_бд" # Замініть на користувача БД
DB_PASS="ваш_пароль_бд" # Замініть на пароль БД
MYSQL_CMD="/usr/bin/mysqldump" # Або pg_dump для PostgreSQL

# Створюємо директорію для резервних копій, якщо її немає
mkdir -p $BACKUP_DIR

# 1. Резервна копія веб-файлів
echo "Створення резервної копії веб-файлів..."
tar -czf $BACKUP_DIR/web_files_$DATE.tar.gz $WEB_ROOT

# 2. Резервна копія конфігурацій Nginx
echo "Створення резервної копії конфігурацій Nginx..."
tar -czf $BACKUP_DIR/nginx_config_$DATE.tar.gz $NGINX_CONF

# 3. Резервна копія конфігурацій Varnish
echo "Створення резервної копії конфігурацій Varnish..."
tar -czf $BACKUP_DIR/varnish_config_$DATE.tar.gz $VARNISH_CONF /etc/systemd/system/varnish.service.d/override.conf

# 4. Резервна копія конфігурацій Caddy
echo "Створення резервної копії конфігурацій Caddy..."
tar -czf $BACKUP_DIR/caddy_config_$DATE.tar.gz $CADDY_CONF /var/lib/caddy/.local/share/caddy/

# 5. Резервна копія бази даних (приклад для MySQL)
if [ -n "$DB_NAME" ]; then
    echo "Створення резервної копії бази даних..."
    $MYSQL_CMD -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/database_$DATE.sql.gz
fi

# Видалення старих резервних копій (старше 7 днів)
echo "Видалення старих резервних копій..."
find $BACKUP_DIR -type f -name ".tar.gz" -o -name ".sql.gz" -mtime +7 -delete

echo "Резервне копіювання завершено."

# Збережіть скрипт
sudo nano /usr/local/bin/backup_script.sh
# Зробіть його виконуваним
sudo chmod +x /usr/local/bin/backup_script.sh

Додайте завдання в cron для щоденного виконання (наприклад, о 3:00 ранку):

# Відкриваємо crontab
sudo crontab -e

Додайте наступний рядок:

0 3   * /usr/local/bin/backup_script.sh > /dev/null 2>&1

3. Куди зберігати резервні копії

Ніколи не зберігайте резервні копії на тому ж сервері, що й оригінальні дані. Це марно у випадку відмови диска або компрометації сервера.

• Зовнішнє S3-сумісне сховище: Amazon S3, DigitalOcean Spaces, Backblaze B2. Це економічний та надійний варіант. Використовуйте restic або borgbackup для шифрування та дедуплікації.
• Окремий VPS: Невеликий, недорогий VPS в іншій локації, призначений виключно для зберігання резервних копій. Використовуйте rsync по SSH.
• Локальне сховище на вашій машині: Для невеликих проєктів можна періодично завантажувати резервні копії на ваш комп'ютер.

4. Оновлення: rolling vs maintenance window

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

• Оновлення ОС та пакетів (Ubuntu, Nginx, Caddy, Varnish):
  • Rolling updates: Для некритичних систем або в тестовому середовищі можна налаштувати автоматичні оновлення безпеки. Однак для продакшн-серверів рекомендується ручне оновлення з попереднім тестуванням.
  • Maintenance window (вікно обслуговування): Плануйте регулярні вікна обслуговування (наприклад, раз на місяць) у найменш активний час. Перед застосуванням оновлень зробіть резервну копію.
• Оновлення Varnish:
  • Мажорні версії Varnish (наприклад, з 6.x на 7.x) можуть вимагати адаптації VCL-файлу через зміни в синтаксисі або API. Уважно читайте changelog.
  • Мінорні оновлення (7.4.0 на 7.4.1) зазвичай зворотно сумісні та безпечні.

# Оновлення системи
sudo apt update && sudo apt upgrade -y
# Перезапуск сервісів, якщо вони були оновлені
sudo systemctl restart nginx caddy varnish

Завжди перевіряйте працездатність сайту після будь-яких оновлень.

Усунення несправностей + FAQ

У цьому розділі зібрано типові проблеми та часто задавані питання, які можуть виникнути під час роботи з Varnish Cache.

Яка помилка: Varnish не кешує контент (X-Cache: MISS)

Що перевірити: Переконайтеся, що Varnish правильно налаштований і отримує запити. Перевірте ваш VCL-файл (/etc/varnish/default.vcl) на наявність правил, які можуть призводити до пропуску кешу (return (pass) або return (pipe)). Часто причиною є заголовки Set-Cookie, Cache-Control: private або запити з методом, відмінним від GET/HEAD. Використовуйте sudo varnishlog для аналізу запитів та відповідей.

Як виправити: Оптимізуйте VCL-файл. Якщо Set-Cookie надсилається бекендом, розгляньте можливість його видалення для об'єктів, що кешуються, у vcl_fetch. Перевірте, що ваш бекенд (Nginx) не надсилає заголовки, що забороняють кешування. Переконайтеся, що для сторінок, що кешуються, немає Cache-Control: no-cache або no-store.

Яка помилка: Сайт недоступний або видає помилку 502 Bad Gateway

Що перевірити: Це вказує на проблему з підключенням Varnish до бекенду (Nginx) або Caddy до Varnish. Перевірте логи Caddy (sudo journalctl -u caddy --since "5 minutes ago"), Varnish (sudo varnishlog) та Nginx (sudo tail -f /var/log/nginx/error.log). Переконайтеся, що всі сервіси (Caddy, Varnish, Nginx) запущені та слухають на правильних портах (Caddy: 80/443, Varnish: 127.0.0.1:8080, Nginx: 127.0.0.1:8081). Перевірте правила файрволу (UFW) на предмет блокування внутрішніх портів.

Як виправити: Перезапустіть сервіси в правильному порядку: спочатку Nginx, потім Varnish, потім Caddy. Переконайтеся, що в /etc/caddy/Caddyfile вказано правильну адресу Varnish (127.0.0.1:8080), а в /etc/varnish/default.vcl — правильну адресу Nginx (127.0.0.1:8081). Перевірте override.conf для Varnish, щоб переконатися, що він слухає на 8080.

Яка помилка: Проблеми з SSL-сертифікатами (Caddy)

Що перевірити: Перевірте логи Caddy. Якщо Caddy не може отримати сертифікат Let's Encrypt, це може бути пов'язано з помилками DNS-записів, блокуванням порту 80/443 файрволом, або невірною конфігурацією DNS-challenge (якщо використовується). Переконайтеся, що ваш домен вказує на IP-адресу сервера.

Як виправити: Переконайтеся, що порти 80 і 443 відкриті в UFW. Перевірте записи A/AAAA для вашого домену. Якщо використовуєте DNS-challenge, переконайтеся, що API-токен вказаний вірно і має необхідні права. Тимчасово відключіть DNS-challenge в Caddyfile і спробуйте HTTP-challenge (переконайтеся, що порт 80 відкритий).

Який VPS-конфіг мінімально підійде для Varnish Cache?

Для невеликого сайту з помірним трафіком мінімально підійде VPS з 1 ядром CPU, 1-2 ГБ ОЗУ та 20-40 ГБ NVMe/SSD диска. Цього достатньо для роботи Varnish, веб-сервера та ОС. Однак для отримання помітного виграшу в продуктивності та можливості кешувати більше контенту в пам'яті, рекомендується 2-4 ГБ ОЗУ.

Що вибрати — VPS чи dedicated для цього завдання?

Для більшості середніх та великих проєктів VPS буде чудовим вибором, пропонуючи хороший баланс між продуктивністю та вартістю. Dedicated сервер потрібен лише у випадках дуже високого навантаження (сотні мільйонів запитів на місяць), коли потрібно кешувати сотні гігабайт даних у пам'яті, або коли є суворі вимоги до апаратної ізоляції та специфічного обладнання. Почніть з VPS і масштабуйтеся до dedicated, якщо виникне реальна необхідність.

Чому Varnish не кешує сторінки для авторизованих користувачів?

Що перевірити: За замовчуванням Varnish уникає кешування сторінок, що містять куки (Cookie у запиті, Set-Cookie у відповіді), щоб запобігти показу персоналізованого контенту іншим користувачам. Це стандартна поведінка, спрямована на безпеку та коректність.

Як виправити: Якщо вам потрібно кешувати сторінки з куками, ви повинні явно видалити заголовок Cookie із запиту в vcl_recv для певних URL або типів контенту, а також Set-Cookie з відповіді в vcl_fetch. Це вимагає дуже обережного налаштування VCL, щоб не порушити функціональність сайту (наприклад, вхід у систему, кошик покупок). Розгляньте використання Edge Side Includes (ESI) для динамічних частин сторінок.

Як очистити кеш Varnish?

Що перевірити: Varnish надає кілька способів очищення кешу. Найпростіший — перезапуск сервісу, але це очистить весь кеш. Більш гранулярні методи включають використання HTTP-запитів PURGE або BAN.

Як виправити:

• Перезапуск Varnish: sudo systemctl restart varnish (очищає весь кеш).
• PURGE (очищення конкретного URL): Додайте до VCL правила для обробки методу PURGE. Наприклад, у vcl_recv:

  
      if (req.method == "PURGE") {
          if (!client.ip ~ "127.0.0.1") { # Дозволити PURGE лише з localhost
              return (synth(403, "Forbidden"));
          }
          return (hash);
      }
      sub vcl_hit {
          if (req.method == "PURGE") {
              return (synth(200, "Purged"));
          }
      }
      sub vcl_miss {
          if (req.method == "PURGE") {
              return (synth(200, "Purged"));
          }
      }
                  

  Після цього можна використовувати: curl -X PURGE http://127.0.0.1:8080/path/to/page.
• BAN (очищення за шаблоном): Також вимагає налаштування у VCL. Дозволяє видалити з кешу всі об'єкти, що відповідають регулярному виразу (наприклад, усі сторінки, що починаються з /blog/).

Висновок + Наступні кроки