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 | #совет

Знали, как обработать фоновые задачи по мере их завершения?

Если запускать wait для PID по очереди, shell будет ждать именно выбранный процесс, даже когда другой уже закончил работу. В Bash 5.1 и новее wait -n возвращает статус первой завершившейся задачи, а -p записывает её PID в переменную:

./build-api.sh &
./build-web.sh &

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

if wait -n -p finished; then
    printf 'PID %s: ok\n' "$finished"
fi

Переменная finished содержит PID завершившегося дочернего процесса. Проверка через if важна при включённом set -e, потому что ненулевой код дочерней команды не должен прервать обработку раньше времени.

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

failed=0
for _ in 1 2; do
    if wait -n -p finished; then
        printf '%s ok\n' "$finished"
    else
        failed=1
    fi
done

Так ошибка первой команды не скрывает результат второй. Для другого числа задач меняется число повторов, а wait -n -p требует Bash 5.1 или новее.

➡️ DevOps Ready | #совет

Шпаргалка по основным командам Terraform!

На картинке собраны init, validate, plan, apply и destroy. Схема показывает, на каком шаге Terraform подготавливает рабочую папку, проверяет конфигурацию, показывает будущие изменения и действительно меняет инфраструктуру.

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

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

Готовим Kubernetes-ноду к обслуживанию!

Перед обновлением ядра или заменой диска сначала проверяем размещённые Pod и доступность реплик. Затем запрещаем новые назначения, эвакуируем рабочие нагрузки через Eviction API и только после завершения drain начинаем обслуживание.

Смотрим ноду и Pod, которые на ней размещены:

kubectl get node worker-3
kubectl get pods -A -o wide --field-selector spec.nodeName=worker-3

Проверка помогает заметить одиночные экземпляры и Pod без контроллера до остановки ноды.

Снимаем ноду с планирования новых Pod:

kubectl cordon worker-3
kubectl get node worker-3

Существующие Pod продолжают работать, а новые на эту ноду не назначаются. Перед drain дополнительно проверяем PodDisruptionBudget и запас ёмкости на остальных узлах.

Запускаем штатное выселение с ограничением по времени:

kubectl drain worker-3 \
  --ignore-daemonsets --timeout=10m

После обслуживания возвращаем узел в планирование:

kubectl uncordon worker-3
kubectl get node worker-3

Нода должна быть Ready, а системные и прикладные Pod должны восстановиться. Проверяем распределение реплик и события кластера.

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