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

Если запускать 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 | #практика

🖥 0nix - место встречи тех, кто в IT

Пишешь код, изучаешь информационную безопасность или только выбираешь своё направление? На 0nix.cc есть место и новичкам, и опытным специалистам.

🛡 ИБ и приватность — пентест, OSINT, защита данных и разбор инструментов.
⚙️ Разработка — обсуждение задач, поиск специалистов и предложения своих услуг.
📕 Обучение — статьи, гайды и разборы, к которым удобно возвращаться.
💡 Возможности — работа, партнёры и проекты в профильных разделах.

Задавай вопросы, делись опытом и находи своих.
Твоя следующая полезная тема — на 0nix.

Знали, почему find и xargs нужно соединять через NUL-разделитель?

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

В GNU find используем print0, чтобы завершать каждое имя нулевым байтом:

find /srv/uploads -type f -print0

xargs -0 читает тот же формат и сохраняет каждое имя целиком. Например, так безопасно передаём найденные файлы на проверку контрольной суммы:

find /srv/uploads -type f -print0 | \
  xargs -0 -r sha256sum --

Ключ -r у GNU xargs не запускает sha256sum, если find ничего не нашёл. Завершающий -- отделяет параметры команды от имён файлов, которые могут начинаться с дефиса.

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

find /srv/uploads -type f -print0 | \
  xargs -0 -r -n 1 -P 4 sha256sum --

Здесь одновременно работают не более четырёх процессов, а -n 1 передаёт каждому ровно один путь. Число процессов подбирают по нагрузке и возможностям команды.

➡️ DevOps Ready | #совет