Еще один RoadMap для DevOps 2025

Эта схема отображает ключевые концепции безопасности в Kubernetes — от RBAC, PodSecurity и аудита до изоляции контейнеров — помогая командам визуализировать точки применения политик.

Разработана Telenor для on-prem кластеров, отлично подходит для моделирования угроз и проведения ревью.

https://kubesec-diagram.github.io/

Привет, 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 становится вашим лучшим другом для бесшовных обновлений.

Если у вас вдруг сегодня падает npm install или npm ci, то это потому что команда npm-security выпилила пакет stylus из npm, заявляя, что в нём найдена зловредная уязвимость.

Весь ваш enterprise-проект, построенный на сотнях зависимостей, оказался карточным домиком, из которого вытащили одну пыльную картонку.

https://github.com/advisories/GHSA-fh4q-jc76-r59p
https://github.com/stylus/stylus/issues/2938

Кстати, DevOps – это не только про харды, но и про софты. Оставлю топ-10 советов, как быстро развить софты, потому что софты, в последнее время, выходят на передний план с появлением всяких там ИИ/LLM и прочего 😊

Для отладки bash-скриптов существует инструмент set -xve. Это мастхев фича именно на момент, создания чего-либо т. к. не всегда логика может работать правильно, а с set -xve, можно вовремя увидеть все значения переменных и т.п. не используя мусорные конструкции, например, echo «Error in function xxx».

Применяется так:

#!/bin/bash -xve
set -xve

Основные флаги set:

x — вывести команды и их аргументы по мере их выполнения.
v — вывести строки ввода командной строки по мере их считывания.
e — выход, если команда завершается с ненулевым статусом.

Пример:

Изменяем PS4 и добавляем вывод номера строки во включенный дебаг режим:

#!/bin/bash -xve

PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

bar=10
echo ${bar}
echo $((6 + 6))

После выполнения мы видим:

bar=10
+(./script.sh:6): foo=10
echo ${bar}
+(./script.sh:7): echo 10
10
echo $((6 + 6))
+(./script.sh:8): echo 12
4

Теперь если скрипт где-то вылетает с плохим статусом, всегда можно узнать в какой строке это приключилось

Немного украшательств, экспортируем PS4:

PS4='\033[0;33m+(${BASH_SOURCE}:${LINENO}):\033[0m ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

Происходит подкрашивание запускаемых строчек.

С помощью PS4 можно отладить shell-скрипт, задав при его выполнении set -x, что позволяет выводить каждую команду, а затем ее результаты. Перед каждой командой ставится знак +, эту строку подсказки «+» можно изменить, определив переменную PS4.