DevOps на минималках

Из вашего резюме вообще понятно, что вы умеете как DevOps-инженер?

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

Опыт может быть - но по резюме этого не видно.

Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker

А полный анализ резюме с правками доступен на: https://updatecv.me

Настраиваем простой healthcheck для Docker-контейнера!

Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.

Представим простой HTTP-сервис, который отвечает на /health:

curl -f http://localhost:8080/health

Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.

В Dockerfile можно добавить HEALTHCHECK:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

Параметры задают частоту проверки, максимальное время ожидания и число неудачных попыток.

Соберём образ:

docker build -t app-with-health .

Запустим контейнер:

docker run -d --name app app-with-health

Теперь статус будет виден прямо в списке контейнеров:

docker ps

В выводе можно увидеть состояние:

Up 2 minutes (healthy)

Если нужно посмотреть healthcheck подробнее, используем inspect:

docker inspect --format '{{json .State.Health}}' app

А чтобы вывести только текущий статус:

docker inspect --format '{{.State.Health.Status}}' app

Ожидаемый результат:

healthy

Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.

Когда ты уже станешь настоящим DevOps?

Открываешь вакансию: Linux, Docker, Kubernetes, CI/CD, сети…
Закрываешь вакансию.

Полгода учишься и всё ещё не понимаешь: «А меня уже возьмут?»

Проверь это в бесплатном тесте Pigeon Careers.

За 4–5 минут узнаешь:

✅ что уже знаешь
✅ где пробелы
✅ что учить дальше
✅ сколько примерно осталось до первой работы

Можно также сравнить DevOps с аналитикой и Python.

Без покупки курса и многочасовых лекций.

Кстати, Pigeon Careers помогли устроиться 20+ ребятам за последний год. Средний оффер — 245к.

Пройти тест: @test

Знали, зачем в Bash иногда используют exec вместо обычного запуска команды?

Обычно команду запускают так:

nginx -g 'daemon off;'

Shell остаётся родительским процессом, а nginx запускается как дочерний процесс.

В обычном терминале это почти незаметно. Но в Docker-контейнерах, entrypoint-скриптах и service-wrapper’ах это может стать проблемой: сигналы приходят в shell, а не напрямую в основной процесс.

Например, такой entrypoint выглядит рабочим:

#!/usr/bin/env bash

nginx -g 'daemon off;'

Но если контейнер останавливают через docker stop, сигнал SIGTERM сначала получает shell. Если он не передаст сигнал дочернему процессу корректно, приложение может завершаться не так, как ожидается.

Для основного процесса лучше использовать exec:

#!/usr/bin/env bash

exec nginx -g 'daemon off;'

exec не создаёт новый дочерний процесс, а заменяет текущий shell указанной командой.

То есть nginx становится главным процессом:

PID 1 -> nginx

А не так:

PID 1 -> bash -> nginx

Это особенно важно для контейнеров:

docker stop app

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

exec также полезен в скриптах-обёртках:

#!/usr/bin/env bash

export APP_ENV=prod
exec ./server

После подготовки окружения shell больше не нужен, поэтому его можно заменить настоящим процессом приложения.

➡️ DevOps Ready | #совет

Сколько времени вы тратите на отчеты, которые можно собрать автоматически?

Если каждый месяц вы открываете таблицы, переносите цифры, раскладываете показатели и вручную собираете из этого отчет – эту работу уже можно отдать ИИ.

18 сентября Зерокодер покажет, как это работает на практике на первой бесплатной лаборатории вайб-кодинга.

Не будем разбирать теорию или просто показывать заранее готовый результат. Возьмем задачу с отчетом и соберем рабочий инструмент прямо в Zoom – с нуля и в реальном времени.

За 1.5 часа разберемся, как:

– забрать данные из исходной таблицы;
– автоматически распределить метрики по нужным категориям;
– собрать из них готовый отчет;
– сохранить привычный формат отчета;
– убрать лишние ручные действия и снизить количество ошибок.

Причем покажем весь процесс, а не только красивый финал: если инструмент где-то ошибется – разберемся почему и исправим это прямо на встрече.

Можно задавать вопросы по ходу и сразу понять, как применять такой подход к своим рабочим задачам.
Первое участие в Лаборатории – бесплатно.

Забрать первое участие в лаборатории бесплатно – по ссылке

Делаем безопасный backup конфига перед изменением!

Перед правкой nginx, systemd unit, docker-compose.yml или любого важного конфига полезно сначала сохранить копию. Это занимает секунды, но сильно упрощает откат.

Зададим путь к файлу:

file="/etc/nginx/nginx.conf"

Добавим timestamp:

stamp="$(date +%Y%m%d-%H%M%S)"

Соберём имя backup-файла:

backup="${file}.${stamp}.bak"

Перед копированием проверим, что файл существует:

test -f "$file" || {
  echo "Файл не найден: $file"
  exit 1
}

Теперь создаём копию с сохранением прав и владельца:

sudo cp -a "$file" "$backup"

После этого можно редактировать конфиг:

sudo nano "$file"

Если это nginx, сначала проверяем конфигурацию:

sudo nginx -t

И только потом перезагружаем сервис:

sudo systemctl reload nginx

Если что-то пошло не так, откат простой:

sudo cp -a "$backup" "$file"
sudo systemctl reload nginx

Для удобства можно посмотреть последнюю копию:

ls -lt /etc/nginx/nginx.conf.*.bak | head

Backup перед изменением конфига это маленькая привычка, которая часто экономит часы восстановления после неудачной правки.

Проверяем HTTP endpoint из shell-скрипта!

Иногда нужно быстро понять, жив ли сервис: API, health endpoint, nginx location или внутренний backend.

Начнём с URL:

url="https://example.com/health"

Получим только HTTP-код:

code="$(curl -s -o /dev/null -w "%{http_code}" "$url")"

Теперь проверим диапазон:

if [ "$code" -ge 200 ] && [ "$code" -lt 300 ]; then
  echo "OK: $code"
else
  echo "FAIL: $code"
fi

Добавим timeout, чтобы скрипт не завис:

code="$(curl -sS --max-time 5 \
  -o /dev/null -w "%{http_code}" "$url")"

Если нужен retry:

for i in 1 2 3; do
  code="$(curl -s --max-time 5 -o /dev/null -w "%{http_code}" "$url")"

  [ "$code" = "200" ] && break
  sleep 2
done

После этого можно вернуть exit code для CI:

[ "$code" = "200" ] || exit 1

Такую проверку удобно использовать в deploy-скриптах, cron, CI/CD и простом мониторинге.

Docker Docs — официальный гид по Docker, контейнерам и образам!

На сайте собраны материалы по установке Docker, первым контейнерам, Dockerfile, образам, volumes, networking, Docker Compose, registry, best practices и деплою приложений. Это хороший ресурс для тех, кто хочет не просто выучить пару команд, а нормально понять весь путь: как собрать образ, запустить контейнер, связать сервисы, сохранить данные и подготовить приложение к запуску в реальной инфраструктуре.

Оставляю ссылочку: Docker Docs

📂 Напоминалка по организации безопасного отката релизов!

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

На картинке — 7 шагов построения процесса отката: подготовка стратегии и предыдущей версии, настройка автоматических проверок, определение триггеров для rollback, выполнение отката одной командой, проверка состояния системы после восстановления, разбор причин инцидента и улучшение процесса, а также простой пайплайн отката с чек-листом готовности.

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

Знали, как не дать cron-задаче запуститься второй раз поверх первой?

Иногда скрипт запускается по расписанию, но предыдущий запуск ещё не закончился. Например, backup, импорт данных, rsync или очистка логов могут выполняться дольше обычного.

Обычный cron выглядит так:

* * * * * /opt/jobs/backup.sh

Если backup занимает больше минуты, следующий запуск начнётся параллельно:

backup.sh
backup.sh
backup.sh

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

Для таких случаев используют flock:

flock -n /tmp/backup.lock /opt/jobs/backup.sh

Файл /tmp/backup.lock здесь не хранит данные. Он нужен как точка блокировки.

Ключ -n означает: если lock уже занят, не ждать, а сразу выйти:

flock -n /tmp/backup.lock ./backup.sh

В cron это можно записать так:

* * * * * flock -n /tmp/backup.lock /opt/jobs/backup.sh

Если первый запуск ещё работает, второй просто не стартует.

Для более явного варианта можно использовать shell:

flock -n /tmp/backup.lock \
  bash -c 'echo start; ./backup.sh'

А если нужно немного подождать lock, есть timeout:

flock -w 10 /tmp/backup.lock ./backup.sh

Так команда подождёт до 10 секунд, а потом завершится, если блокировка всё ещё занята.

kube-prometheus — готовая база для мониторинга Kubernetes!

В этом репозитории собран полноценный monitoring stack для Kubernetes: Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics, готовые dashboards и alert rules. Хороший вариант, чтобы посмотреть, как в реальности собирают наблюдаемость кластера не из одного контейнера, а из набора Kubernetes-манифестов и связанных компонентов.

Оставляю ссылочку: GitHub

Список удалённых вакансий исключительно для DevOps

Только удалёнка, только для Junior/Middle.

Claude Code за месяц стал мощнее. Большинство использует его на 10%

Как превратить Claude Code не в помощника для кода, а в автономного агента?
Чтобы он сам анализировал проект, писал код, запускал тесты, исправлял ошибки и одновременно вел до 15 задач. То, с чем обычно справляется целая команда разработки.

CEO университета Зерокодер Кирилл Пшинник проводит открытый практикум. Собираем вживую:

– 15 агентов одновременно – как распределять задачи и держать контекст проекта;
– Проект с нуля за 15 минут – от пустой папки до готовой страницы на эфире;
– Дашборд и аналитика таблиц – на чистом коде, без сторонних сервисов;
– Доступ из России – рабочая схема оплаты и установки 2026, если ещё не подключили.

И самое главное – расскажем, как получить Claude Code бесплатно.
🎁 Бонус всем участникам: набор лучших навыков для Claude Code, чтобы сразу начать работать без задержек и ограничений.

Регистрация на бесплатное занятие по ссылке.

👩‍💻 Наглядно: Как работает Docker

👉 DevOps на минималках

🔥 Открытый практикум по Claude Code без теории

Ты слышал, что Claude Code — один из лучших инструментов вайб-кодинга в мире. Зашёл попробовать — а там оплата картой, которая из России не проходит. Ограничения, виртуалки, чужие аккаунты, и фоновый страх, что завтра всё отвалится.

CEO университета Зерокодер, Кирилл Пшинник, проведет открытый практикум. Что вы узнаете:

— Доступ к Claude Code из России — как установить, оплатить и настроить. Без блокировок — рабочая схема 2026 года;
— 15 ИИ-агентов одновременно — прямая демонстрация: как выполняются задачи, как работает переключение, контекст проекта;
— Сайт с нуля за 15 минут — прямо на практикуме, от пустой папки до готовой страницы;
— Дашборд и обработка таблиц — аналитика на чистом коде, без сторонних сервисов.

И самое главное – расскажем как получить Claude Code бесплатно.

🎁 Бонус всем участникам: набор лучших навыков для Claude Code, чтобы вы сразу начали работать, без задержек и ограничений.

😀 Крутая шпаргалка по командам Git на русском

echo "# название" >> README.md - создание файла README.md
git init - инициализация репозитория
git add README.md - добавления файла README.md в проект
git commit -m "first commit" - получает проиндексированный снимок состояния и выполняет его коммит в историю проекта
git remote add origin https://github.com/stanruss/название.git - команда, которой устанавливается подключение к удаленному серверу и git репозиторию, размещающемуся на нем.
git push -u origin master - кзменения отправляются на удаленный сервер

git log --oneline - посмотреть все коммиты.
git checkout . - восстановить все.
git checkout "код коммита" - вернуть до состояния этого коммита.
git checkout master - вернуться в ветку мастер.

Восстановить файлы на локальном компьютере:

git fetch --all
git reset --hard origin/master или git reset --hard origin/<название_ветки>

git add text.txt - Добавить файл в репозиторий
git rm text.txt - Удалить файл
git status - Текущее состояние репозитория (изменения, неразрешенные конфликты и тп)
git commit -a -m "Commit description" - Сделать коммит
git push origin - Замерджить все ветки локального репозитория на удаленный репозиторий
git push origin master - Аналогично предыдущему, но делается пуш только ветки master
git push origin HEAD - Запушить текущую ветку, не вводя целиком ее название
git pull origin - Замерджить все ветки с удаленного репозитория
git pull origin master - Аналогично предыдущему, но накатывается только ветка master
git pull origin HEAD - Накатить текущую ветку, не вводя ее длинное имя
git fetch origin - Скачать все ветки с origin, но не мерджить их в локальный репозиторий
git fetch origin master - Аналогично предыдущему, но только для одной заданной ветки
git checkout -b some_branch origin/some_branch - Начать работать с веткой some_branch (уже существующей)
git branch some_branch - Создать новый бранч (ответвится от текущего)
git checkout some_branch - Переключиться на другую ветку (из тех, с которыми уже работаем)
git branch # звездочкой отмечена текущая ветвь - Получаем список веток, с которыми работаем
git branch -a # | grep something - Просмотреть все существующие ветви
git merge some_branch - Замерджить some_branch в текущую ветку
git branch -d some_branch - Удалить бранч (после мерджа)
git branch -D some_branch - Просто удалить бранч (тупиковая ветвь)
git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4 - Изменения, сделанные в заданном коммите
git push origin :branch-name - Удалить бранч из репозитория на сервере
git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4 - Откатиться к конкретному коммиту и удалить последующие (хэш смотрим в «git log»)
git push -f - Залить на сервер измененные коммиты
git clean -f - Удаление untracked files

👉 DevOps на минималках