Знали, почему docker compose restart не применяет изменения из compose.yaml?

Команда restart запускает тот же контейнер с теми же настройками. Она полезна, когда процесс внутри завис или завершился, но не применяет новую конфигурацию сервиса.

Например, после изменения переменной окружения restart оставит старое значение:

docker compose restart api

Переменные окружения контейнера задаются при его создании. Поэтому после правки compose.yaml сервис нужно обновить через up:

docker compose up -d api

Compose сверит описание сервиса с существующим контейнером и применит изменённые параметры. Данные в именованных volumes при этом сохраняются.

Если менялся код, включённый в Docker-образ, добавь сборку:

docker compose up -d --build api

Флаг --build пересобирает образ перед запуском контейнера. Если используется образ из registry, сначала скачай его:

docker compose pull api

Затем запусти сервис на новой версии образа:

docker compose up -d --no-deps api

Флаг --no-deps не трогает зависимые сервисы, поэтому используй его только если они уже запущены и не требуют обновления.

До деплоя проверь, какую конфигурацию Compose получил после объединения файлов и подстановки переменных:

docker compose config

В выводе могут оказаться подставленные значения переменных, поэтому не публикуй его без проверки на секреты. Пересоздание может прервать соединения, так что в production учитывай health checks и порядок обновления зависимых сервисов.

➡️ DevOps Ready | #совет

📂 Напоминалка по тестированию инфраструктурных изменений в CI!

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

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

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

Знали, зачем в Git использовать worktree вместо постоянного переключения веток?

Иногда нужно срочно поправить hotfix, но в текущей ветке уже лежит незавершённая работа. Обычный checkout заставляет stash, commit или вручную прятать изменения.

git worktree позволяет открыть другую ветку в отдельной папке, используя тот же репозиторий.

Например, можно создать отдельную директорию для hotfix:

git worktree add ../hotfix hotfix/login

cd ../hotfix

Теперь основная рабочая папка остаётся на своей ветке, а hotfix живёт рядом. Можно собирать проект, запускать тесты и делать commit независимо.

Посмотреть все рабочие деревья можно так:

git worktree list

Когда отдельная папка больше не нужна, её лучше удалить через Git:

git worktree remove ../hotfix

Если ветка была удалена руками или папка пропала, список можно почистить:

git worktree prune

Этот приём полезен для релизных веток, срочных багфиксов, code review и параллельной проверки нескольких версий проекта.

Главное не забывать, что каждая worktree имеет свою рабочую директорию, но общую историю репозитория. Поэтому большие сборочные артефакты и зависимости лучше держать под контролем, чтобы не раздувать диск.

➡️ DevOps Ready | #совет

pg_activity - мониторинг PostgreSQL в терминале!

pg_activity показывает активность PostgreSQL в виде интерактивной таблицы. В одном окне можно смотреть запросы, ожидания, блокировки, длительность транзакций и системную нагрузку.

Репозиторий и инструкции по установке: pg_activity

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

Проверяем конфигурацию Nginx перед перезагрузкой!

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

Проверка читает активные конфигурационные файлы и завершится с ненулевым кодом, если найдёт ошибку:

sudo nginx -t

Перезагрузка должна произойти только после успешного теста. Связка через && останавливает цепочку, если nginx -t завершился ошибкой:

sudo nginx -t && sudo systemctl reload nginx

Reload просит Nginx перечитать настройки без обычной полной остановки сервиса. После команды проверь состояние юнита:

sudo systemctl is-active nginx

Для приложения полезно дополнительно проверить реальный endpoint, потому что успешный reload ещё не подтверждает доступность backend:

curl --fail --silent --show-error --max-time 5 \
  http://127.0.0.1/healthz

Для production-деплоя добавь мониторинг внешнего адреса и заранее подготовленный откат конфигурации.

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

SOPS помогает хранить секреты в Git без открытых паролей!

В репозитории находится инструмент для редактирования зашифрованных файлов с конфигурацией. SOPS понимает YAML, JSON, ENV и INI, поэтому подходит для секретов приложения, переменных окружения и настроек инфраструктуры.

Для шифрования можно использовать age или PGP, а также облачные KMS. Это позволяет хранить зашифрованный файл рядом с обычной конфигурацией и расшифровывать его только там, где есть нужный ключ. Удобно для командной работы и GitOps-процессов, но доступ к ключам всё равно нужно выдавать аккуратно.

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

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

Как проверить, какой IP возвращает DNS и откуда берётся устаревший ответ?

После изменения DNS-записей разные серверы могут продолжать получать прежний IP-адрес или возвращать разные результаты для одного и того же домена.

Для диагностики необходимо определить, на каком уровне возникает расхождение: в авторитативных DNS-данных, кэше рекурсивного резолвера или системном механизме разрешения имён.

Начнём с обычного DNS-запроса:

dig example.com A

В секции ANSWER SECTION увидим IP-адрес и TTL записи, например:

example.com.  240  IN  A  192.0.2.10

TTL определяет допустимое время кэширования DNS-записи в секундах. В ответе рекурсивного резолвера это обычно оставшееся время жизни записи.

Узнаем, какие DNS-серверы обслуживают домен:

dig example.com NS +short

Но этот запрос сам может быть обработан рекурсивным резолвером. Чтобы проследить цепочку делегирования от корневых DNS-серверов:

dig +trace example.com A

+trace позволяет проследить DNS-делегирование, но не воспроизводит полностью поведение обычного рекурсивного резолвера.

Теперь запросим запись непосредственно у авторитативного сервера:

dig @a.iana-servers.net example.com A +norecurse

Для собственного домена вместо a.iana-servers.net необходимо указать один из его авторитативных DNS-серверов. В ответе проверим наличие флага aa — он указывает, что сервер возвращает авторитативный ответ.

Сравним ответы публичных рекурсивных резолверов:

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

Различия могут возникать из-за кэширования, географически зависимых ответов или особенностей DNS-инфраструктуры. При этом приложения Linux не обязательно используют DNS так же, как dig.

Проверим разрешение имени через системный механизм NSS:

getent ahostsv4 example.com

getent использует настройки Name Service Switch, включая /etc/nsswitch.conf. В зависимости от конфигурации ответ может поступать из /etc/hosts, DNS или других источников.

Посмотрим порядок разрешения имён:

grep '^hosts:' /etc/nsswitch.conf

На системах с systemd-resolved дополнительно проверим его конфигурацию:

resolvectl status

И выполним разрешение имени через systemd-resolved:

resolvectl query example.com

При необходимости можно очистить локальный DNS-кэш systemd-resolved:

sudo resolvectl flush-caches

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

При этом отдельные приложения могут использовать собственные DNS-клиенты, кэши или DNS-over-HTTPS, поэтому их фактическое поведение не всегда совпадает с результатами getent.

🔥 При диагностике DNS важно разделять авторитативные данные, кэш рекурсивного резолвера и разрешение имён на уровне ОС. Разные ответы не всегда означают ошибку DNS: сначала проверьте источник ответа, TTL, делегирование и настройки системного резолвера.

🚪 Linux Ready | #практика

📂 Напоминалка по базовым командам kubectl!

Например, kubectl get pods показывает список подов, kubectl logs помогает быстро посмотреть логи контейнера, а kubectl exec — зайти внутрь контейнера и выполнить команду.

На картинке — 7 основных команд kubectl, которые чаще всего используются в ежедневной работе с Kubernetes: просмотр ресурсов, диагностика, логи, применение конфигов и управление контейнерами.

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

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

zram в Linux как альтернатива обычному swap!

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

Особенно полезен zram на небольших VPS, контейнерных серверах и устройствах с ограниченным объёмом RAM, где нужно переживать кратковременные пики нагрузки без резкого падения производительности.

Перед настройкой проверяем текущий swap:

swapon --show
free -h

Загружаем модуль ядра:

sudo modprobe zram

Проверяем появившееся устройство:

zramctl

Задаём размер zram, например 4 GB:

echo 4G | sudo tee /sys/block/zram0/disksize

Размер zram не означает немедленное выделение 4 GB RAM. Фактически память занимает только сжатый объём реально используемых данных.

Выбираем алгоритм сжатия. Чаще всего используют lz4 или zstd: lz4 быстрее, zstd обычно даёт лучшее сжатие. Пример с lz4:

echo lz4 | sudo tee /sys/block/zram0/comp_algorithm

Доступные алгоритмы:

cat /sys/block/zram0/comp_algorithm

Создаём swap и включаем:

sudo mkswap /dev/zram0
sudo swapon /dev/zram0

Проверяем:

swapon --show
zramctl

Теперь Linux использует zram как swap-устройство, но данные находятся внутри RAM в сжатом виде, без постоянной записи на диск.

Для сохранения после перезагрузки обычно используют systemd-zram-generator или zram-tools. В Debian/Ubuntu при использовании zram-tools настройки обычно находятся в:

/etc/default/zramswap

Также стоит учитывать параметр ядра vm.swappiness, который влияет на активность использования swap:

cat /proc/sys/vm/swappiness

zram и zswap — разные механизмы. zram создаёт отдельный swap внутри RAM. zswap работает как кэш перед обычным swap на диске.

Проверка zswap:

cat /sys/module/zswap/parameters/enabled

🔥 Подведем итог: zram не добавляет физическую память, но позволяет эффективнее использовать доступную RAM, уменьшает обращения к дисковому swap и помогает системе стабильнее переживать кратковременные пики нагрузки.

🚪 Linux Ready | #практика

Шпаргалка по команде dig для проверки DNS!

На картинке собраны десять конкретных запросов dig. Есть проверка A-, MX- и NS-записей, обратный поиск по IP, просмотр TTL и трассировка делегирования зоны.

Например, dig example.com +short быстро покажет адрес, а dig MX example.com +short поможет узнать почтовые серверы домена. Если ответы отличаются у разных резолверов, можно запросить каждый сервер отдельно и сравнить результат.

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

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

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

Docker Compose может запустить контейнер базы раньше приложения, но это не означает, что база уже принимает подключения. Добавим healthcheck и заставим приложение ждать состояния healthy.

Для PostgreSQL команда pg_isready проверяет, что сервер готов принимать соединения:

services:
  db:
    image: postgres:17
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 12
      start_period: 10s

Двойной знак доллара оставляет переменные для окружения контейнера, не подставляя их при разборе файла Compose. start_period даёт серверу время на первую инициализацию.

Связываем запуск приложения с успешной проверкой:

  api:
    build: .
    depends_on:
      db:
        condition: service_healthy

condition: service_healthy ждёт именно успешный healthcheck, а не только создания контейнера. Приложению всё равно стоит уметь повторять соединение при временном обрыве уже после запуска.

Проверяем итоговую конфигурацию и запускаем сервисы с ожиданием готовности:

docker compose config
docker compose up -d --wait
docker compose ps

Так порядок запуска становится явным, а ошибка проверки видна до того, как API начнёт принимать запросы.

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

📂 Базовый подход к созданию среды для тестирования инфраструктуры!

Например, на этапе дизайна важно использовать VLAN или отдельные аккаунты для изоляции, для автоматизации (IaC) отлично подойдут Terraform или Ansible, а при настройке среды нельзя забывать про заполнение тестовыми данными и валидацию.

На картинке — пошаговое руководство из 5 этапов (от определения целей до эксплуатации и улучшения) с ключевыми инструментами, лучшими практиками и частыми ошибками при построении надежного тестового контура.

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

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

Ограничиваем доступ systemd-сервиса к системе!

Сервису часто не нужны права на изменение всей файловой системы и доступ к домашним каталогам. Добавим ограничения через drop-in, сохранив запись только в каталоги, которые приложению действительно необходимы.

Сначала оцениваем текущую конфигурацию и создаём отдельный файл переопределения:

systemd-analyze security myapp.service
sudo systemctl edit myapp.service

Команда edit создаёт drop-in, поэтому настройки пакета остаются нетронутыми. До включения ограничений уточни рабочие каталоги, пользователя и места, куда сервис записывает данные.

Добавляем базовые ограничения в секцию Service:

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/myapp

ProtectSystem=strict делает файловую систему только для чтения, кроме перечисленных исключений. Замени /var/lib/myapp на реальный каталог данных, иначе приложение может перестать сохранять файлы.

Проверяем unit, применяем изменения и анализируем результат:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
systemctl cat myapp.service
systemd-analyze security myapp.service

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

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

Kubernetes Goat - площадка по безопасности Kubernetes!

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

Материалы полезны DevOps-инженерам, backend-разработчикам и тем, кто хочет понимать не только как запустить pod, но и как не оставить кластер открытым для очевидных атак.

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

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

Передаём секрет в Docker build без записи в образ!

Для сборки иногда нужен токен приватного npm-реестра или доступ к закрытому пакету. Если передать его через ARG или ENV, значение может сохраниться в метаданных образа или слоях и попасть в кеш сборки.

Подготовь локальный файл .npmrc с токеном и исключи секреты из build context:

.env
.npmrc
*.pem

Файл не попадёт в обычный контекст сборки. Храни его вне репозитория и не добавляй в git даже временно.

Сначала задай образ и рабочую папку:

# syntax=docker/dockerfile:1
FROM node:22-alpine
WORKDIR /app

Копируй lock-файл и подключай секрет только на шаге установки:

COPY package*.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

BuildKit подключит файл на время конкретного RUN, а не сохранит его как обычный слой. Не копируй секрет в другой файл и не печатай его содержимое в лог.

Передай файл сборщику отдельно:

DOCKER_BUILDKIT=1 docker build \
  --secret id=npmrc,src="$HOME/.npmrc" \
  -t demo-app:local .

Идентификатор после id должен совпадать с id в Dockerfile. При использовании Buildx команда принимает тот же флаг --secret.

В CI можно передать значение из переменной окружения, не создавая файл в репозитории:

docker buildx build \
  --secret type=env,id=npmrc,env=NPMRC_CONTENT \
  -t demo-app:ci .

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

После сборки проверь обычную конфигурацию и историю образа:

docker image inspect demo-app:local
docker history --no-trunc demo-app:local

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

Glance собирает рабочие панели и ленты в одном дашборде!

Виджеты показывают RSS, GitHub, Hacker News, YouTube, погоду, котировки, статистику сервера и состояние Docker-контейнеров. Страницы и их расположение настраиваются через YAML, а отдельные вкладки можно собрать под разные задачи.

Проект написан на Go. В репозитории есть конфигурация, инструкции по запуску и список готовых интеграций.

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

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

Знаете, где systemd-сервису хранить постоянные данные и временные файлы?

В unit-файле можно описать назначение директорий, а systemd подготовит их при старте.

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

StateDirectory=orders

Для system-сервиса это создаёт /var/lib/orders и назначает владельцем пользователя из User и Group. Каталог сохраняется после остановки службы, поэтому сюда подходят база-файлы, состояние очереди и другие рабочие данные.

Временные файлы размещай отдельно:

RuntimeDirectory=orders
RuntimeDirectoryMode=0750

Так появится /run/orders с правами только для владельца и его группы. По умолчанию systemd удаляет этот каталог при остановке службы, поэтому не складывем туда данные, которые нужно сохранить после перезагрузки.

Кэш можно выделить в собственный путь:

CacheDirectory=orders
LogsDirectory=orders

Это создаёт стандартные каталоги под /var/cache и /var/log и выставляет владельца службы. Разделение помогает понять, что можно пересоздать, что нужно сохранить и что попадёт в ротацию логов.

После изменения unit-файла проверим его и перечитаем конфигурацию:

systemd-analyze verify /etc/systemd/system/orders.service
systemctl daemon-reload

systemd также задаёт переменные STATE_DIRECTORY, RUNTIME_DIRECTORY и другие для настроенных путей. Использем их в приложении, если расположение каталога не должно быть зашито в конфигурации.

➡️ DevOps Ready | #совет