Привет, DevOps-инженеры! Если вы уже освоили азы NGINX, давайте углубимся в его мощь и рассмотрим, как он становится незаменимым инструментом в сложных архитектурах. Сегодня разберем кейс: обслуживание статического фронтенда и проксирование запросов к бэкенд API через NGINX.

Представьте: у вас есть SPA (Single Page Application) на React/Vue/Angular, который нужно отдавать пользователям, и REST API на Python/Node.js, к которому этот фронтенд обращается. NGINX идеально подходит для этой задачи.

Пример конфигурации: nginx.conf

server {
    listen 80;
    server_name your-domain.com www.your-domain.com;

    # Отдача статических файлов фронтенда
    location / {
        root /var/www/your-frontend-app/build; # Путь к скомпилированному фронтенду
        try_files $uri $uri/ /index.html; # Важно для SPA: все запросы, не являющиеся файлами, ведут на index.html
    }

    # Проксирование запросов к API
    location /api/ {
        proxy_pass http://your-backend-service:8000/api/;
        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-Proto $scheme;
    }

    # Опционально: редирект HTTP на HTTPS (для продакшена)
    # listen 443 ssl;
    # ssl_certificate /etc/nginx/ssl/your-domain.crt;
    # ssl_certificate_key /etc/nginx/ssl/your-domain.key;
    # return 301 https://$host$request_uri;
}

Разберем ключевые моменты:

location /

- Отвечает за отдачу статических файлов вашего фронтенда. root указывает на директорию со скомпилированным приложением. try_files — это магия для SPA, которая гарантирует, что при прямом заходе на роут (например, your-domain.com/users) NGINX отдаст index.html, а не 404.

location /api/

- Здесь мы настраиваем проксирование всех запросов, начинающихся с /api/, на ваш бэкенд-сервис. proxy_pass указывает адрес и порт бэкенда. Заголовки proxy_set_header критически важны для корректной работы бэкенда, так как они передают информацию об оригинальном запросе (хост, IP клиента, протокол).

💡 DevOps Лайфхак: Горячая перезагрузка NGINX без простоя!
В продакшене каждая секунда простоя — это деньги. При изменении конфигурации NGINX не обязательно его полностью останавливать и запускать заново. Используйте команду:

sudo nginx -s reload

Эта команда заставляет NGINX загрузить новую конфигурацию, не прерывая обработку текущих запросов. Старые воркеры продолжают обслуживать активные соединения, а новые начинают использовать обновленную конфигурацию. После завершения старых соединений, старые воркеры корректно завершают работу. Это позволяет обновлять конфигурацию NGINX без единого простоя!

Почему это важно? В CI/CD пайплайнах, когда вы деплоите новую версию фронтенда или бэкенда, или меняете маршрутизацию, nginx -s reload становится вашим лучшим другом для бесшовных обновлений.