🚩 Интерфейсы всех осей, объединяйтесь! 🚩 Сидишь ты, значит, пишешь скрипт деплоя на своём Ubuntu. Всё работает, красота. Закидываешь в CI/CD - билд проходит. А потом образ собирается на Alpine, а в контейнере /bin/sh оказывается busybox ash, и твой вызов source выдаёт not found. Почему так? Потому что ты писал для bash, а не для POSIX. И сегодня разберём, что это за зверь и почему без него никуда. Что такое POSIX Portable Operating System Interface (или POSIX) довольно старый стандарт IEEE. Такой старый, что конец его бороды уходит аж в 1988 году. Зачем придумали? В 80-х Unix-фрагментация была такой, что программа, написанная для System V, не собиралась на BSD. POSIX - попытка навести порядок: "если система POSIX-compliant, то вот этот набор вызовов и утилит работает одинаково". Что именно стандартизирует POSIX? 👉🏻 Системные вызовы (C API): open(), read(), write(), fork(), exec(), wait()- как процесс создаёт файлы, запускает дочерние процессы, ждёт завершения 👉🏻 Утилиты командной строки: ls, ps, kill, find, grep, awk, sed, test, echo - какие флаги есть, какой вывод ожидать 👉🏻 Shell: синтаксис pipes (|), redirections (>, <, >>), subshell ($()), командные списки (&&, ||), переменные 👉🏻 Файловая система: иерархия /bin, /etc, /tmp, права доступа (rwx) Что POSIX НЕ гарантирует? ⛔️ GNU-расширения: find . -printf, sed -i, date -d, grep -P ⛔️ bashisms: arrays, [[ ]], source, <<<, |& ⛔️ macOS/BSD-варианты: ps aux работает, но ps -ef выглядит по-другому ⛔️ Специфичные для Linux вещи: cgroups, namespaces, epoll Shell: POSIX vs bashism #!/bin/sh # ❌ Не POSIX: source — это bashism, не работает в dash/busybox source /etc/default/myapp # ✅ POSIX: . (точка) — работает везде . /etc/default/myapp # ❌ Не POSIX: [[ ]] — bash-only if [[ "$ENV" == "prod" ]]; then     echo "production" fi # ✅ POSIX: [ ] — работает в sh, dash, ash, bash if [ "$ENV" = "prod" ]; then     echo "production" fi Почему это важно DevOps-инженеру ➡️CI/CD runners - ты не контролируешь, какой там дистрибутив. GitHub Actions может быть на Ubuntu, а самописный runner — на CentOS. Скрипт должен работать везде ➡️ Docker-контейнеры - Alpine (busybox), Debian (dash/bash), scratch - разные /bin/sh, разное поведение. Без POSIX ты пишешь скрипт «для своей машины», а не «для любой машины» (помнишь, мы разбирали namespaces — вот это всё та же экосистема) ➡️ Макбук коллеги - macOS = BSD coreutils, sed -i '' вместо sed -i. Рукапашка в 3 ночи, когда сервер упал, - последнее, что тебе нужно, это выяснять, почему readlink -f не работает Теперь ты точно знаешь, что никакой новомодный изм не заменит старый добрый POSIX! Ставь реакцию, если узнал что-то новое. А если хочешь разобрать, как ядро понимает shebang - пиши в комментах shebang. Если интересно, чем bash отличается от sh — пиши bashvs. Я слежу за комментами и по спросу выбираю следующую тему. А на этом у меня всё. Всем добра, коллеги😊 🥷 Devops Senpai 🥷

😏 Однока, двока, трока.. пока-ёка 😏 Сижу я такой однажды вечером, отмокаю от очередного "Нужно срочно релизить". И тут звонит продакт: «У нас заказы оформляются, а цены с ошибкой считаются». В чатике инцедентов разраб подытожил - ошибка в формуле рассчета стоимости... Pipeline собрал образ и вроде юнит-тесты прогнали, да только в спешке забили/забыли доработать юнит-тесты и запедалили впродЪ. Пересобирать? Ещё минут 15 + тестирование фикса + деплой и проверка. А могли поймать на unit-тесте за 2 минуты. И тут я вспомнил свое студенческое прошлое, когда я работал на небольшом производстве. Причем тут вонючий завод и наше смузихлебное АйТи, спросите вы? А при том, что все мы с вами на самом деле заводчане. Только вместо производства болтов мы кладем их на юнит-тесты производим цифровой продукт! Так вот о чем я? На производстве уже давным давно известна такая проблема и там же ее научились решать. Есть такая концепция как Бережливое производство, один из постулатов которой - внедрение "защиты от дурака" или пока-ёкэ. "Защита от дурака" это формат построения процесса, который физически не даёт ошибиться. Штекер USB-C не вставишь неправильно, крышка бензобака не закроется без ключа. Не надо инструкций - сам процесс не даёт сделать ошибку и передать ее дальше. А если ошибка и случилась, то обнаружилось это до того как дошло до конечного пользователя. В CI/CD пока-ёкэ = проверки ДО сборки. Пока код не прошёл линтер, unit-тесты, security scan и dependency check - образ не запушится или даже не закоммитится код. Дешевле остановить за 30 секунд, чем пересобирать 15 минут или откатывать из продакшена. Смотри, вот наивный путь - собираем всё подряд, проверяем потом: pipeline { ... stages { stage('Build') { steps { sh 'docker build -t myapp:latest .' } } stage('Test') { steps { sh 'pytest' // падает — пересобирать? } } stage('Lint') { steps { sh 'flake8 .' // падает — образ уже собран } } stage('Scan') { steps { sh 'trivy fs .' // скан зависимостей: нет CVE (15 сек) } } } } А вот правильный путь - пока-ёкэ проверяет ДО, сборка только если всё чисто: pipeline { ... stage('Poka-Yoke') { steps { // делаем в этом шаге все проверки sh 'flake8 .' sh 'pytest' sh 'trivy fs .' } } stage('Build') { when { expression { currentBuild.resultIsBetterOrEqualTo('SUCCESS') } } steps { // запускается только при успехе предыдущих sh 'docker build -t myapp:$BUILD_NUMBER .' } } } ... } В чем ключевая разница? 👉🏻 В первом случае pipeline собирает мусор и тратит время. Если код изначально говно, то зачем нам тратить вычислительные ресурсы агентов на его сборку?? 👉🏻 Во втором - ошибка ловится за 30 секунд, образ не собирается, и ты не сидишь в 3 часа ночи, молясь на пересборку. Три нюанса, которые тебя убьют, если забудешь: 💊 Пока-ёкэ ≠ просто «тесты есть». Это тесты ДО дорогой операции. Если линтер запускается после сборки - это не защита, это мазохизм. 💊 Быстрые проверки ДО, медленные ПОСЛЕ. Линтер - 10 секунд, unit-тесты - 2 минуты, интеграционные тесты — 15 минут. Пока-ёкё ловит 80% известных ошибок за 30 секунд. 💊 Без быстрой обратной связи бесполезно. Если разработчик пушит код, а ошибку видит через 2 часа - он уже забыл, что менял. Ставь свои реакты, если пост зашел. Если хочешь узнать без чего защита от дурака никогда не будет работать - пиши в комментах Andon. Если тебе интересно узнать больше про применение бережливого производства в ИТ - пиши lean. А на этом у меня все. Всем добра, коллеги😊 🥷 Devops Senpai 🥷

☕️ Дохлебываем и уе****** ☕️ Однажды с коллегой из разработки чекали работает ли его свеже-реализованный graceful shutdown. Ожидаемое поведение для такой аппликухи при docker stop это закрытие всех соединений, сброс файлов и тд. Как говорится, попрощается с миром красиво. На деле же вышло совсем не то... Запускаем docker stop myapp и ждем. Раз, два, десять секунд. Контейнер выходит с кодом 137, а graceful shutdown так и остался на уровне идеи. Как так? А вот сейчас следите за руками. В Linux PID 1 - особенный процесс. Ядро шлёт ему сигналы напрямую, но если у процесса нет обработчика SIGTERM, сигнал просто игнорируется. docker stop работает по схеме: SIGTERM -> ждёт 10 секунд (по умолчанию) -> SIGKILL. Если контейнер выходит мгновенно - значит скорее всего graceful отработал быстро. А если ровно 10 секунд - значит, SIGTERM дошёл не туда. В нашем случае коллега написал ENTRYPOINT sh -c "python app.py". То есть sh стал PID 1, а python - PID 2. SIGTERM пришёл sh, а sh дочерним процессам сигналы по умолчанию не пересылает. Результат: 10 секунд ожидания + SIGKILL с кодом 137. Проверить это можно двумя способами, выбирай любой: # Способ 1: просто засеки время docker stop myapp # Ровно 10 секунд? Значит SIGTERM проигнорирован, добил SIGKILL # Способ 2: сократи таймаут до 2 секунд docker stop -t 2 myapp # Всё ещё тормозит ровно на указанное время? # Graceful shutdown не работает — проверяй, кто у тебя PID 1 Такие вот пироги с огурцами. Итого, теперь мы знаем ➡️ Как за 10 секунд понять, остановился ли контейнер по graceful shutdown ➡️ Что во всем виноват PID 1 и SIGTERM - теперь не надо тратить часы на поиск ошибки в коде приложения ➡️ Что graceful shutdown лишь красивая идея, пока в ENTRYPOINT сидит sh А главное - теперь мы имеем прочную почву для правильного решения такой проблемы. Если хочешь узнать что такое exit code 137, где его можно увидеть и как еще можно диагностировать данную проблему ставь свои реакты. PS: Обрати внимание, комменты к постам теперь открыты, поэтому пиши свои вопросы, предложения и пожелания туда. На этом вынужден раскланяться, Хороших выходных!👋🏻 🥷 Devops Senpai 🥷