DevOps Ready | IT

Устраняем случайные падения пайплайна из-за нехватки ресурсов!

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

Добавим в конфигурацию CI автоматическую очистку старых Docker-объектов перед началом каждой сборки:

before_script:
  - docker system prune -f --volumes --filter "until=24h"
  - df -h | grep '/dev/'

Команда df покажет реальное наличие свободного места в логах пайплайна.

Используем механизм сервисов для изоляции базы данных, чтобы избежать конфликтов за порты на общем раннере:

services:
  - name: postgres:15-alpine
    alias: db_host
variables:
  DATABASE_URL: "postgresql://user:pass@db_host:5432/test_db"

Результат: база доступна по внутреннему DNS-имени db_host, не занимая порты хост-системы.

Настроим автоматический перезапуск шага только при системных ошибках связи или сбоях инфраструктуры:

# Умные ретраи для сетевых лагов
job_step:
  retry:
    max: 2
    when: runner_system_failure

🔥 Регулярно мониторьте объем логов и размер артефактов, чтобы они не забивали дисковое пространство раннеров.

➡️ DevOps Ready | #практика

📂 Напоминалка по DNS!

Например, когда домен вводится в браузере, он сначала проверяет кеш, если IP не найден — запускается цепочка DNS-запросов: Root - TLD - Authoritative сервер. В итоге браузер получает IP и только после этого отправляет HTTP-запрос на сервер.

На картинке — наглядная схема того, как именно работает DNS-резолв шаг за шагом.

Сохрани, чтобы не забыть!

➡️ DevOps Ready | #ресурс

Знали, что «битый» YAML-файл может уронить весь CI/CD пайплайн еще до того, как начнется деплой?

Лишний пробел или неверный отступ в манифестах Kubernetes или Ansible это классическая причина падений. Чтобы не тратить время на запуск тяжелых пайплайнов ради проверки синтаксиса, стоит использовать легковесные утилиты для локальной валидации.

Самый быстрый способ проверить файл без установки лишнего софта — встроенные возможности Python:

python3 -c 'import yaml, sys; yaml.safe_load(sys.stdin)' < deployment.yaml

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

Для продвинутой проверки с учетом лучших практик используй специализированный линтер:

yamllint -d relaxed config.yaml

Это подсветит не только ошибки синтаксиса, но и нарушение стилистики (слишком длинные строки, лишние пробелы в конце).

Добавь проверку в pre-commit хук своего репозитория, чтобы ошибки вообще не попадали в Git:

- repo: https://github.com/adrienverge/yamllint.git
  rev: v1.33.0
  hooks:
    - id: yamllint

🔥 Маленькая проверка на входе экономит десятки минут ожидания «красного» пайплайна в GitLab или GitHub.

➡️ DevOps Ready | #совет

Нагружаем приложение и смотрим, как оно себя ведёт!

Сегодня прогоняем тестовое веб‑приложение через обычную нагрузку и простейшую «атаку», чтобы увидеть разницу по метрикам и логам. Всё через терминал и пару утилит: hey/ab для нагрузки и curl для имитации агрессивного клиента.

Сначала замерим «здоровое» состояние с равномерной нагрузкой:

hey -z 30s -c 20 http://localhost:8080/

За 30 секунд получим средний RPS, latency и процент ошибок. Это будет базовый уровень, с которым будем сравнивать.

Теперь устроим «атаку» с одного IP — резкий всплеск запросов:

hey -z 30s -c 200 http://localhost:8080/login

Следим в это время за приложением:

tail -f app.log
htop

В логах увидишь частые обращения к одному эндпоинту и рост 5xx/4xx, а по ресурсам — скачок CPU/памяти.

Можно вынести это в простой скрипт:

load_test() {
  hey -z 20s -c 30 "$1"
  hey -z 20s -c 200 "$1"
}
load_test "http://localhost:8080/login"

🔥 Так удобно быстро смотреть, где приложение начинает «сыпаться» под нагрузкой: код, база или сеть.

➡️ DevOps Ready | #практика

🖼️ Приоритеты в автоматизации — выбираем, что внедрять в первую очередь, чтобы не выгореть и не уронить прод!

Автоматизировать всё подряд — плохая затея. Чтобы не тратить время впустую, нужно начинать с задач, которые дают максимум профита при минимуме рисков для инфраструктуры.

В этом посте:

• Разбираем формулу выбора задач: частота повторения vs риск ошибки.

• Пишем безопасные «скрипты-информаторы» для мониторинга ресурсов;

• Внедряем линтеры и валидаторы в CI/CD для отлова багов на взлете;

• Создаем удобные Makefile-обертки для сложных консольных команд;

Это пошаговый план, который поможет превратить рутинный хаос в стабильную и предсказуемую систему.

➡️ DevOps Ready | #гайд

🖼️ Отслеживаем «долгие» этапы пайплайна через отдельный job-логгер!

В типичном CI/CD непонятно, на каком шаге пайплайн реально тратит время: сборка, тесты, деплой или миграции. Отдельный job, который логирует длительность этапов, помогает быстро увидеть узкие места и понять, что оптимизировать в первую очередь.

В этом посте:

• Добавляем вокруг этапов обёртку, которая меряет время выполнения и пишет логи;

• Логируем только «долгие» шаги, которые превышают заданный порог (например, 30 или 60 секунд);

• Отправляем результаты в общий лог/мониторинг, чтобы строить графики и алерты по «медленным» job-ам.

Такой job превращает пайплайн из «чёрного ящика» в понятную шкалу времени, где видно, на каком шаге вы теряете минуты и деньги.

➡️ DevOps Ready | #задача

👍 Linux Kernel Documentation — официальная документация по ядру!

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

📌 Оставляю ссылочку: docs.kernel.org

➡️ DevOps Ready | #ресурс