📂 Шпаргалка по организации конфигурации DevOps окружений!

Грамотная структура конфигов помогает избежать путаницы между development, staging и production, снизить риск ошибок и упростить сопровождение инфраструктуры. На картинке 7 практик: от разделения конфигураций и секретов до использования переменных среды, слоёв и переопределений, автоматизации загрузки, документации и регулярных проверок окружений.

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

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

Знали, зачем для одноразовых контейнеров часто добавляют docker run --rm?

Когда контейнер запускают для короткой проверки, он после завершения остаётся в системе. Сам процесс уже не работает, но запись о контейнере и его writable layer остаются.

Например так:

docker run alpine echo ready

Если делать такие запуски часто, docker ps ничего лишнего не покажет, потому что контейнеры уже остановлены. Но они всё ещё видны через docker ps -a.

Проверить можно так:

docker ps -a

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

Для одноразовых команд добавляют --rm:

docker run --rm alpine echo ready

Теперь контейнер автоматически удалится после завершения команды. Это удобно для curl-проверок, временных shell-сессий, миграций, утилит и быстрых запусков.

Например для сетевой проверки:

docker run --rm curlimages/curl \
  curl -I https://example.com

Но --rm не стоит добавлять везде бездумно. Если контейнер падает и нужно посмотреть его состояние, логи или файлы после завершения, автоматическое удаление только помешает.

Для отладки иногда лучше оставить контейнер:

docker run --name debug-app my-image

Для коротких одноразовых команд --rm помогает держать Docker чистым. Для расследования падений лучше сначала сохранить контейнер и удалить его вручную позже.

➡️ DevOps Ready | #совет

Знали, зачем в скриптах использовать install вместо touch плюс chmod?

В shell-скриптах часто нужно создать файл или директорию сразу с правильными правами. Например, конфиг, lock-файл, каталог для данных или место под секреты.

Обычно пишут в несколько шагов:

touch /etc/myapp/token
chmod 600 /etc/myapp/token

На первый взгляд всё нормально, но между командами файл уже существует с правами по умолчанию. В плохом сценарии это короткое окно может быть лишним, особенно если речь про секреты.

Для таких случаев есть install:

install -m 600 /dev/null /etc/myapp/token

Команда создаёт файл и сразу выставляет нужные права. /dev/null здесь используется как пустой источник.

Для директорий тоже можно сразу указать режим:

install -d -m 750 /var/lib/myapp

А если нужно задать владельца и группу:

install -o app -g app -m 750 -d /var/lib/myapp

Это делает deploy-скрипт короче и безопаснее. Права, владелец и сам факт создания описаны в одной команде, а не размазаны по нескольким строкам.

➡️ DevOps Ready | #совет

Знали, почему порядок COPY в Dockerfile может сильно влиять на скорость сборки?

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

Проблема часто появляется в Node, Python, Java и других проектах, где зависимости устанавливаются до копирования всего исходного кода.

Неудачный Dockerfile может выглядеть так:

COPY . .
RUN npm ci
RUN npm run build

Теперь любое изменение в одном файле проекта сбивает кеш для COPY . . После этого npm ci запускается заново, даже если package.json вообще не менялся.

Лучше сначала копировать только файлы зависимостей:

COPY package*.json ./
RUN npm ci

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

Исходный код копируют уже после установки:

COPY . .
RUN npm run build

Такая же идея работает и для других стеков. В Python сначала копируют requirements.txt или pyproject.toml, в Java отдельно копируют pom.xml или gradle-файлы.

Например для Maven:

COPY pom.xml ./
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package

Редко меняющиеся файлы ставим выше, часто меняющийся код ниже. Тогда кеш Docker начинает реально помогать, а сборки в CI идут заметно быстрее.

➡️ DevOps Ready | #совет

K9s - удобный терминальный интерфейс для Kubernetes!

Этот репозиторий содержит CLI-инструмент, который открывает интерактивный terminal UI для работы с Kubernetes-кластерами. Через него удобно смотреть Pod, Deployment, Service, логи, события и состояние ресурсов без постоянного набора kubectl-команд.

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

➡️ DevOps Ready | #репозиторий

Шпаргалка по командам Helm!

Например, helm install ставит chart в кластер, helm upgrade обновляет релиз, а helm rollback помогает быстро откатиться на предыдущую рабочую версию.

На картинке собраны основные команды Helm. Есть установка и удаление приложений, работа с repo, поиск chart, обновление релизов, rollback, просмотр values, hooks, manifest и управление плагинами.

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

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

Делаем простой release через symlink!

Иногда приложение нужно выкладывать так, чтобы новая версия появлялась почти мгновенно, а откат занимал одну команду. Для этого часто используют директории releases и ссылку current.

Структура может быть такой:

/opt/app/releases/2026-08-29_1200
/opt/app/current -> /opt/app/releases/2026-08-28_1800

Сначала создаём новую папку релиза:

release="/opt/app/releases/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$release"

Потом копируем туда собранные файлы:

rsync -a ./dist/ "$release/"

До переключения current пользователи всё ещё смотрят на старую версию. Это удобно, потому что подготовка релиза не ломает рабочее приложение.

Переключение делается через ln -sfn:

ln -sfn "$release" /opt/app/current

Теперь current указывает на новую директорию. Само переключение происходит быстро, потому что меняется ссылка, а не копируются файлы поверх боевой папки.

Если нужен откат, можно вернуть ссылку на прошлый релиз:

ln -sfn /opt/app/releases/2026-08-28_1800 /opt/app/current

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

Такой подход полезен для простых серверов, статических сайтов, внутренних тулов и приложений без сложной deploy-платформы.

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

Linux Journey - маршрут по Linux с практическими темами!

На сайте собраны уроки по командной строке, файловой системе, процессам, permissions, пакетам, устройствам, networking, DNS, routing, logging и другим темам, которые нужны DevOps-инженеру и backend-разработчику.

Разделы идут как большая карта обучения. Можно открыть тему, пройти объяснение, перейти к упражнениям и потом двигаться дальше по связанным главам без обязательной регистрации.

Оставляю ссылочку на Linux Journey

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

📂 Шпаргалка по настройке оповещений в DevOps!

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

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

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

Penguin Gym Linux - тренировка Linux-команд!

На сайте можно практиковать Linux-команды прямо в браузере. Есть виртуальный terminal, пошаговые уроки, задания, квизы, материалы по beginner Linux, LPIC-1 и отдельный маршрут в сторону DevOps.

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

Оставляю ссылочку на Penguin Gym

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

📂 Напоминалка по распределению конфигурации между Git и переменными окружения!

Правильное разделение настроек помогает безопасно управлять разными окружениями, не хранить секреты в репозитории и не создавать хаос в конфигурации. На картинке показаны 7 практик: от классификации параметров и принципов 12-Factor до работы с секретами, разделения dev, staging и prod, автоматической проверки и документирования конфигурации. Главное правило: код хранится в Git, значения приходят через ENV, а секреты находятся в защищённом хранилище.

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

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

Знали, почему readinessProbe не стоит заменять livenessProbe?

В Kubernetes часто добавляют health checks, но readinessProbe и livenessProbe нужны для разных вещей.

livenessProbe нужна, чтобы понять, жив ли контейнер вообще. Если приложение зависло и уже не может восстановиться, Kubernetes перезапустит Pod.

Простой пример проверки:

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

readinessProbe решает другую задачу. Она говорит, можно ли прямо сейчас отправлять трафик в этот Pod.

Например, приложение уже запустилось, но ещё прогревает кэш, ждёт миграции, подключение к базе или загрузку конфигурации. Перезапускать его в этот момент не нужно.

Для этого лучше сделать отдельный endpoint:

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080

Если readiness падает, Pod просто убирается из endpoints сервиса. Новые запросы туда не идут, но контейнер продолжает работать и может вернуться в строй.

А если slow start долгий, добавляют startupProbe:

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

Она даёт приложению время на старт и не позволяет livenessProbe убить контейнер слишком рано.

Состояние проб удобно смотреть через describe:

kubectl describe pod api-7f9c

liveness отвечает за перезапуск, readiness отвечает за трафик, startupProbe отвечает за долгий старт.

➡️ DevOps Ready | #совет

Знали, зачем в shell-скриптах иногда задают umask?

Когда скрипт создаёт файлы, права зависят не только от chmod в самом скрипте. На итоговые права влияет umask текущего процесса.

Обычный временный файл может получиться доступнее, чем хотелось бы:

touch backup.env
ls -l backup.env

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

umask позволяет заранее запретить лишние права для новых файлов:

umask 077

После этого новые файлы обычно будут доступны только владельцу. Группа и остальные пользователи не получат чтение по умолчанию.

Например, так можно безопаснее создавать файл с секретами:

umask 077
printf '%s\n' "$TOKEN" > token.txt

Проверить результат можно через ls:

ls -l token.txt

Ожидаемый формат будет похож на 600. То есть владелец может читать и писать, а остальные не имеют доступа.

Для директорий это тоже работает:

mkdir private-backups

При umask 077 новая директория обычно получит права 700. Это удобно для backup, временных ключей, ssh-конфигов и артефактов деплоя.

Если файл уже создан с неправильными правами, umask его не исправит. Тогда нужен chmod:

chmod 600 token.txt

umask хорошо закрывает простой класс ошибок. Скрипт перестаёт случайно создавать приватные файлы слишком открытыми.

➡️ DevOps Ready | #совет

Шпаргалка по Infrastructure as Code!

Например, Docker помогает упаковать приложение в контейнер, Kubernetes управляет запуском контейнеров, Terraform описывает инфраструктуру, а Ansible настраивает серверы через playbook.

На картинке собрана общая схема IaC-подхода. Есть containerization, Kubernetes orchestration, Git как source of truth, CI/CD pipeline, Terraform, Ansible, cloud servers и on-premise servers.

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

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

Собираем Makefile для частых DevOps-команд!

В проектах часто есть набор повторяющихся команд. Запустить тесты, собрать образ, применить миграции или открыть shell.

Держать всё в голове не удобно. А с помощью Makefile можно приварить их в короткие сценарии.

Начнём с понятной цели для логов:

logs:
    docker compose logs -f app

Таб перед командой важен. В Makefile команда внутри target должна начинаться именно с tab.

Добавим перезапуск сервиса:

restart:
    docker compose restart app

Для проверки можно сделать отдельный target:

check:
    docker compose config
    docker compose ps

Теперь команды становятся короче:

make logs
make restart
make check

Для deploy лучше добавить dry-run или отдельный подготовительный шаг, чтобы случайно не выполнить опасную команду.

Например, можно сначала показать текущий git commit:

release-info:
    git rev-parse --short HEAD
    git status --short

Такой Makefile не заменяет CI/CD, но сильно снижает ручную работу. Особенно в маленьких командах, где одни и те же операции часто выполняют разные люди.

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