DevOps Ready | IT

Знали, зачем в Bash-скриптах включать set -u?

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

Проблема в том, что Bash по умолчанию спокойно подставляет пустую строку, если переменная не задана.

Например, такой код может выглядеть безобидно.
rm -rf "$TARGET_DIR"/*

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

Для защиты от таких ошибок включают set -u.
set -u

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

Пример.
set -u
echo "$DEPLOY_ENV"

Если DEPLOY_ENV не задана, скрипт остановится сразу. Это намного лучше, чем продолжить деплой в непонятное окружение.

Но иногда переменная может быть необязательной. Тогда для неё лучше явно задать значение по умолчанию.
LOG_LEVEL="${LOG_LEVEL:-info}"

Так код говорит, что отсутствие LOG_LEVEL допустимо, и в этом случае используется info.

Для обязательных переменных удобно использовать проверку с понятным сообщением.
: "${DEPLOY_ENV:?DEPLOY_ENV is required}"
: "${TARGET_DIR:?TARGET_DIR is required}"

Такая запись завершит скрипт, если переменная не задана или пустая, и сразу покажет нормальную причину ошибки.

В реальных скриптах set -u часто используют вместе с set -e и pipefail.
set -euo pipefail

Но важно не включать режимы механически. Если в скрипте есть необязательные переменные, для них нужно использовать безопасные формы вроде ${VAR:-default}.

➡️ DevOps Ready | #совет

Разбираем TLS-сертификаты через консоль!

При проблемах с HTTPS важно быстро понять, какой сертификат отдаёт сервер, когда он истекает, какая цепочка пришла и что именно видит клиент.

В этой шпоре собраны openssl s_client, openssl x509, curl -vI, curl --cacert, update-ca-certificates, keytool и nmap ssl-enum-ciphers.

➡️ DevOps Ready | #шпора

Шпаргалка по Ansible!

Например, ad-hoc команды помогают быстро выполнить действие на группе серверов, inventory описывает хосты, а playbook позволяет хранить автоматизацию в YAML-файле.

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

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

📂 Напоминалка по постепенному внедрению мониторинга в проект!

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

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

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

40 собесов и оффер за 1 месяц

Алексей разработчик.

Искал работу с декабря - написание сопроводов и отклики занимали очень много времени.

Выхлоп - почти нулевой.

В какой-то момент понял:
так можно искать бесконечно.

И по совету друга попробовал ии-ассистента для автооткликов - Софи.

▫️За ~1 месяц прошел около 40 собеседований
▫️Получил оффер с вакансии, на которую, по его словам, не откликнулся бы сам

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

Весь процесс - от первого собеседования до оффера - занял 4 дня.

Зарегистрироваться и попробовать Софи можно здесь.

3 дня - бесплатно.

Знали, зачем перед rsync --delete почти всегда делать dry-run?

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

Ключ --delete полезен, когда целевая папка должна точно совпадать с источником. Например, в dist удалили старый JS-файл, значит на сервере он тоже должен исчезнуть.

Обычный деплой может выглядеть так.
rsync -av --delete ./dist/ server:/var/www/app/

Но именно --delete делает команду опасной. Если перепутать путь, слеш или переменную окружения, можно удалить не те файлы на удалённой стороне.

Особенно часто ошибаются с завершающим слешем. Эти две команды выглядят почти одинаково, но смысл у них разный.
rsync -av ./dist/ server:/var/www/app/
rsync -av ./dist server:/var/www/app/

В первом случае копируется содержимое папки dist. Во втором случае внутрь назначения может попасть сама папка dist.

Перед реальным запуском лучше посмотреть план изменений.
rsync -av --delete --dry-run ./dist/ server:/var/www/app/

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

Для более читаемого вывода можно добавить --itemize-changes.
rsync -av --delete --dry-run --itemize-changes ./dist/ server:/var/www/app/

Так проще увидеть, какие файлы будут добавлены, изменены или удалены. Особенно полезно смотреть строки удаления перед запуском без --dry-run.

Если команда собирается из переменных, dry-run становится ещё важнее.
SRC="./dist/"
DST="server:/var/www/app/"
rsync -av --delete --dry-run "$SRC" "$DST"

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

Когда вывод выглядит нормально, можно запустить ту же команду без --dry-run.
rsync -av --delete ./dist/ server:/var/www/app/

В CI/CD удобно делать dry-run отдельным ручным шагом для новых deploy-команд. А для регулярных задач стоит хотя бы использовать его при первом запуске после изменения путей.

Перед опасной синхронизацией можно отдельно проверить, сколько удалений планируется.
rsync -av --delete --dry-run --itemize-changes "$SRC" "$DST" | grep "^\*deleting"

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

Ещё полезно держать источник и назначение в логах.
echo "SRC=$SRC"
echo "DST=$DST"

Это звучит просто, но в реальном deploy-скрипте такая печать часто экономит много времени при разборе инцидента.

➡️ DevOps Ready | #совет

Test Your Sysadmin Skills - большая база вопросов для Linux и DevOps!

В этом репозитории собраны сотни вопросов и ответов по Linux, сетям, безопасности, webops, базам данных, системным задачам и диагностике. Материал удобно использовать для самопроверки, подготовки к собеседованиям и поиска тем, которые стоит подтянуть.

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

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

Разбираем SSH 7 команд для подключения и диагностики!

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

Полезно для ежедневной работы с серверами, staging-средами, приватными сетями и диагностики доступа.

➡️ DevOps Ready | #шпора

Шпаргалка по Linux permissions!

Например, chmod 755 даёт владельцу полный доступ, а группе и остальным оставляет чтение и запуск. А chmod 600 часто используют для приватных ключей и конфигов с секретами.

На картинке разобраны права владельца, группы и остальных пользователей, числовые значения r/w/x, а также SUID, SGID и sticky bit.

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

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

Знали, зачем в curl использовать --fail вместе с проверками в скриптах?

Обычный curl может завершиться успешно даже тогда, когда сервер вернул HTTP-ошибку:
curl https://example.com/missing

Если сервер ответил 404, команда всё равно может вернуть exit code 0, потому что сетевой запрос технически выполнился.

В shell-скриптах это опасно:
curl "$URL" -o app.tar.gz
tar -xzf app.tar.gz

Можно скачать HTML-страницу с ошибкой вместо архива и узнать об этом только на следующем шаге.

Для таких случаев добавляют --fail:
curl --fail "$URL" -o app.tar.gz

Теперь HTTP-коды 400/500 будут считаться ошибкой команды.

Чаще всего это комбинируют с --silent и --show-error:
curl --fail --silent --show-error \
"$URL" -o app.tar.gz

Для CI/CD или deploy-скриптов удобно сразу останавливать выполнение:
curl --fail --silent --show-error "$URL" -o app.tar.gz
tar -xzf app.tar.gz

Если нужен retry:
curl --fail --retry 3 --retry-delay 2 \
"$URL" -o app.tar.gz

Так временные сетевые ошибки можно пережить, а настоящие HTTP-ошибки не будут замаскированы под успешную загрузку.

➡️ DevOps Ready | #совет

📂 Напоминалка по архитектуре минимального, но рабочего CI/CD-пайплайна!

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

На этой схеме — пошаговый гайд о том, как спроектировать лаконичный и стабильный CI/CD-пайплайн для одного микросервиса, который закроет 80% потребностей команды и не будет перегружен лишней логикой.

Сохрани в закладки, чтобы использовать как готовый шаблон для своих проектов!

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

kube-prometheus — готовая база для мониторинга Kubernetes!

В этом репозитории собран полноценный monitoring stack для Kubernetes: Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics, готовые dashboards и alert rules. Хороший вариант, чтобы посмотреть, как в реальности собирают наблюдаемость кластера не из одного контейнера, а из набора Kubernetes-манифестов и связанных компонентов.

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

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

Знали, как не дать cron-задаче запуститься второй раз поверх первой?

Иногда скрипт запускается по расписанию, но предыдущий запуск ещё не закончился. Например, backup, импорт данных, rsync или очистка логов могут выполняться дольше обычного.

Обычный cron выглядит так:
* * * * * /opt/jobs/backup.sh

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

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

Для таких случаев используют flock:
flock -n /tmp/backup.lock /opt/jobs/backup.sh

Файл /tmp/backup.lock здесь не хранит данные. Он нужен как точка блокировки.

Ключ -n означает: если lock уже занят, не ждать, а сразу выйти:
flock -n /tmp/backup.lock ./backup.sh

В cron это можно записать так:
* * * * * flock -n /tmp/backup.lock /opt/jobs/backup.sh

Если первый запуск ещё работает, второй просто не стартует.

Для более явного варианта можно использовать shell:
flock -n /tmp/backup.lock \
bash -c 'echo start; ./backup.sh'

А если нужно немного подождать lock, есть timeout:
flock -w 10 /tmp/backup.lock ./backup.sh

Так команда подождёт до 10 секунд, а потом завершится, если блокировка всё ещё занята.

➡️ DevOps Ready | #совет

📂 Напоминалка по организации безопасного отката релизов!

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

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

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

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