Linux Ready | DevOps

Создаём изменяемую копию каталога без полного копирования через OverlayFS!

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

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

cp -a /opt/app /tmp/app-test

В Linux для такой задачи можно использовать OverlayFS: исходный каталог подключается как нижний слой lowerdir, а все изменения, выполняемые через объединённое дерево, записываются в отдельный верхний слой upperdir.

Подготовим каталоги для writable-слоя, служебного workdir и итоговой объединённой точки монтирования:

mkdir -p /tmp/overlay/{upper,work,merged}

Для writable OverlayFS каталоги upperdir и workdir должны находиться на одной файловой системе. Файловая система верхнего слоя также должна поддерживать необходимые OverlayFS extended attributes и корректный d_type.

Монтируем /opt/app как нижний слой:

sudo mount -t overlay overlay \
  -o lowerdir=/opt/app,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work \
  /tmp/overlay/merged

После монтирования /tmp/overlay/merged представляет объединённое дерево: неизменённые объекты читаются из lowerdir, а новые и изменённые объекты обслуживаются верхним слоем.

Работать с каталогом можно как с обычным writable-деревом:

echo "test=true" >> /tmp/overlay/merged/config.ini

При первой модификации существующего файла OverlayFS выполняет copy_up: файл копируется из lowerdir в upperdir, после чего операция записи применяется уже к верхней копии. Поэтому OverlayFS не исключает копирование отдельных изменяемых файлов, но устраняет необходимость заранее копировать весь каталог.

В результате изменённая версия файла будет находиться в верхнем слое:

/tmp/overlay/upper/config.ini

Запись через /tmp/overlay/merged при этом не изменяет исходный файл:

/opt/app/config.ini

Важно то, что сам каталог /opt/app от этого физически read-only не становится. Другой процесс по-прежнему может изменить его напрямую. Изменять содержимое используемого lowerdir напрямую во время работы смонтированного OverlayFS не следует — это может привести к неопределённому поведению overlay.

Для завершения работы достаточно размонтировать объединённое представление:

sudo umount /tmp/overlay/merged

Размонтирование не удаляет содержимое upperdir: накопленные изменения сохраняются там до явной очистки каталога. Если слой действительно нужен только на время эксперимента, после успешного umount его можно удалить:

rm -rf /tmp/overlay

🔥 OverlayFS полезен, когда исходное дерево велико, а изменяется только небольшая его часть: дисковое пространство расходуется преимущественно на новые и модифицированные объекты, а запись через объединённое дерево не затрагивает исходные файлы lowerdir. Этот же механизм copy-on-write лежит в основе многих работ с контейнерными слоями и изолированными файловыми окружениями.

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

Для временной смены каталога не обязательно потом возвращаться обратно!

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

В Bash есть более простой способ — выполнить команды в подоболочке:

(
  cd /etc || exit
  ls
)

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

После завершения блока текущая оболочка остаётся в том же каталоге:

pwd

Этот приём удобен, когда нужно последовательно обработать несколько каталогов:

(
  cd build || exit
  make
)

(
  cd tests || exit
  ctest
)

Не требуется сохранять текущий путь, использовать pushd/popd или помнить, где именно нужно выполнить обратный cd.

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

🚪 Linux Ready | #совет

🐱 RU Awesome DevOps — большая русскоязычная подборка материалов для DevOps и SRE-инженеров!

Здесь собрана документация по Linux, администрированию серверов, сетям и безопасности, Docker, Kubernetes, Ansible, Terraform, CI/CD, мониторингу, облачным платформам и базам данных. Отдельно есть книги, материалы по алгоритмам и вопросы для подготовки к техническим собеседованиям.

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

🚪 Linux Ready | #репозиторий

📂 Напоминалка для работы с Linux cgroup v2!

Например, cpu.max позволяет ограничить процессам доступное CPU-время, а memory.max — установить жёсткий лимит на использование оперативной памяти.

На картинке — устройство иерархии cgroup v2, основные контроллеры, системные файлы и команды для создания групп, ограничения ресурсов и перемещения процессов.

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

🚪 Linux Ready | #ресурс

GNU mv умеет атомарно менять два файла или каталога местами!

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

У mv теперь есть --exchange:

mv -T --exchange release-new release-current

Если оба пути находятся в одной файловой системе и она поддерживает атомарный обмен, mv меняет их местами одной операцией: release-current становится новым релизом, а прежнее содержимое оказывается в release-new.

Причём это не только для каталогов:

mv --exchange config.new config.conf

Поменять их обратно можно той же командой:

mv --exchange config.new config.conf

Для сценариев, где нельзя допустить незаметного перехода к копированию между файловыми системами, можно добавить --no-copy:

mv -T --exchange --no-copy release-new release-current

🔥 mv --exchange — случай, когда обычная Unix-команда даёт удобный интерфейс к атомарной операции файловой системы, что полезно для переключения релизов, деревьев сборки и быстрого отката без цепочки промежуточных переименований.

🚪 Linux Ready | #совет

📂 Напоминалка про переадресацию портов (Port Forwarding)!

Port Forwarding позволяет принимать соединение на одном адресе и порту и перенаправлять трафик на другой — например, с 127.0.0.1:8080 на 172.17.0.3:80.

На картинке показано, чем отличается обычное прямое соединение от переадресации портов, а также два основных подхода: через отдельный процесс в user space и средствами сетевого стека ядра в kernel space.

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

🚪 Linux Ready | #ресурс

Как umask определяет права файлов!

Почему новый файл обычно получает 644, каталог — 755, а один и тот же сервис при разных способах запуска может создавать их с другими правами? За этим стоит umask — маска, которая ограничивает разрешения в момент создания объекта.

umask
umask -S

umask не задаёт итоговые права напрямую. При обычном создании программы часто запрашивают 0666 для файлов и 0777 для каталогов, а маска исключает из запрошенного режима запрещённые биты.

Для чистоты эксперимента удалим объекты, если они остались от предыдущего запуска:

rm -f example.txt
rm -rf example_dir

umask 022

touch example.txt
mkdir example_dir

stat -c '%A %a %n' example.txt example_dir

При 022 запись запрещена для группы и остальных, поэтому получаем 644 для файла и 755 для каталога:

-rw-r--r-- 644 example.txt
drwxr-xr-x 755 example_dir

Популярное объяснение 666 - 022 = 644 удобно для некоторых масок, но технически неверно. Здесь работает побитовая маска:

0666 & ~0022 = 0644
0777 & ~0022 = 0755

И это важно не только теоретически. Например, арифметика ломается уже здесь:

rm -f example.txt

umask 033
touch example.txt

stat -c '%A %a %n' example.txt

Получим:

-rw-r--r-- 644 example.txt

Хотя арифметическое 666 - 033 дало бы 633.

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

rm -f test

umask 000
touch test

stat -c '%A %a %n' test

touch создаёт файл без execute-битов, поэтому результат — 666, а не 777:

-rw-rw-rw- 666 test

Для серверных процессов часто используют более строгий 027: владелец сохраняет запрошенные права, у группы убирается запись, а для остальных запрещаются все права.

rm -f config.txt
rm -rf private_dir

umask 027

touch config.txt
mkdir private_dir

stat -c '%A %a %n' config.txt private_dir

Получаем:

-rw-r----- 640 config.txt
drwxr-x--- 750 private_dir

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

Посмотреть настройку сервиса:

systemctl show nginx -p UMask

Для systemd-сервиса маску можно явно зафиксировать:

[Service]
User=www-data
UMask=0027
ExecStart=/usr/bin/example

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

systemctl daemon-reload
systemctl restart example.service

Но есть нюанс, из-за которого даже при ожидаемом umask можно получить другие права — default ACL родительского каталога.

Если у родительского каталога задан default ACL, при создании объекта umask не используется для обычного расчёта mode & ~umask. Вместо этого новый объект наследует default ACL, а унаследованные разрешения ограничиваются правами, которые запросил создающий процесс.

Проверить ACL:

getfacl /path/to/parent

Поэтому, если сервис создаёт файл не с теми правами, проверять нужно не только значение umask. Важны также mode, который запрашивает сама программа, реальная маска процесса, способ его запуска — shell, systemd, контейнер — и наличие default ACL у родительского каталога. Для диагностики:

umask
getfacl .
stat -c '%A %a %n' example.txt

🔥 umask не назначает права — он ограничивает разрешения, которые процесс запросил при создании объекта. А при наличии default ACL в расчёт вступает механизм наследования ACL.

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

👩‍💻 Находим, где тормозит HTTP-запрос!

Медленный API — не всегда проблема бекэнда. Задержка может возникнуть ещё на DNS, TCP или TLS, поэтому одного time curl для диагностики недостаточно.

В этом посте:

• Разбираем HTTP-запрос на отдельные этапы;

• Снимаем встроенные тайминги через curl;

• Считаем время DNS, TCP, TLS и ожидания первого байта;

• Добавляем HTTP-код и IP конечного сервера;

• Определяем, на каком участке появляется основная задержка.

В итоге получаем инструмент для анализа задержек HTTP без дополнительных утилит — полезный для быстрой диагностики API, сервисов и сетевых проблем.

🚪 Linux Ready | #задача

Знали, что systemd умеет запускать сервис автоматически при изменении файла?

Многие используют cron или пишут циклы с проверкой времени изменения:

while true; do
  check_file
  sleep 10
done

Но systemd уже имеет встроенный механизм наблюдения за файлами через .path units.

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

[Path]
PathChanged=/etc/myapp/config.yml
Unit=myapp-reload.service

Теперь при изменении файла systemd автоматически запустит нужный сервис.

Проверить активные path-наблюдатели:

systemctl list-paths

Запуск и остановка работают так же, как у обычных unit:

systemctl enable --now myapp.path
systemctl stop myapp.path

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

🔥 systemd.path заменяет самописные циклы с sleep и проверки файлов. Вместо опроса система реагирует только тогда, когда изменение действительно произошло.

🚪 Linux Ready | #совет

В Linux можно удалить файл, но продолжать читать из него или записывать в него данные!

Если процесс уже открыл файл, его можно удалить из каталога:

exec {LOG}>/tmp/debug.log
rm /tmp/debug.log

Имя /tmp/debug.log исчезнет, и открыть файл по этому пути уже нельзя. Но Bash продолжает держать открытый файловый дескриптор, поэтому запись работает:

printf '%s\n' "debug message" >&"$LOG"

Причина в семантике Unix: rm удаляет имя файла из каталога через unlink(), а открытый файловый дескриптор продолжает ссылаться на тот же объект файловой системы.

Пока дескриптор открыт, занятое файлом место также не освобождается. Это объясняет распространённую ситуацию, когда огромный лог уже удалили, ls его не показывает, а свободного места на диске не прибавилось.

Закрываем последний дескриптор:

exec {LOG}>&-

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

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

🔥 В Linux имя файла и открытый файл — не одно и то же. Понимание этой особенности помогает находить утечки дискового пространства и аккуратно работать с временными данными.

🚪 Linux Ready | #совет

Хакатон на космических данных. Санкт-Петербург, Красноярск или онлайн из любой точки страны.

Стартуем 18 сентября.

За выходные участники доводят одну из задач до рабочего решения.

Санкт-Петербург. К 2035 году над Землёй должен работать топливный узел, у которого заправляются корабли, и откуда он будет получать топливо - с Земли, с Луны или из резерва - пока не решил никто. Команде предстоит собрать схему поставок, посчитать резервы и решить, во что вкладываться сразу. Призовой фонд 1,2 млн ₽.

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

Лучшие забирают приз на площадке и билет в московский финал 25–27 сентября, где разыграют ещё 2,4 млн рублей.

Команда 3–5 человек, недостающих можно найти на платформе.

Регистрация по ссылке космохакатон.рф

👩‍💻 Находим, где тормозит HTTP-запрос!

Медленный API — не всегда проблема бекэнда. Задержка может возникнуть ещё на DNS, TCP или TLS, поэтому одного time curl для диагностики недостаточно.

В этом посте:

• Разбираем HTTP-запрос на отдельные этапы;

• Снимаем встроенные тайминги через curl;

• Считаем время DNS, TCP, TLS и ожидания первого байта;

• Добавляем HTTP-код и IP конечного сервера;

• Определяем, на каком участке появляется основная задержка.

В итоге получаем инструмент для анализа задержек HTTP без дополнительных утилит — полезный для быстрой диагностики API, сервисов и сетевых проблем.

🚪 Linux Ready | #задача