Библиотека девопса | DevOps, SRE, Sysadmin

🔒 Безопасный контейнер Запуск контейнеров с правами root считается плохой практикой безопасности, поскольку при компрометации процесса внутри контейнера злоумышленник получает расширенные права на хосте. Чтобы минимизировать риски, всегда рекомендуется создавать в образе отдельного пользователя и запускать контейнер под ним. Пример Dockerfile с запуском не от root:

FROM node:22

# Создаем пользователя appuser
RUN useradd -m appuser

# Переключаемся на пользователя appuser
USER appuser

CMD ["node", "server.js"]

Такой подход соответствует принципу наименьших привилегий и помогает защитить вашу систему от потенциальных угроз. 🐸 Библиотека devops'a #root@prompt

🐸 Библиотека devops'a #пятничный_деплой

🔄 Вышел Helm 4.0.0 Helm 4 получил переработанную систему плагинов, теперь поддерживается Web Assembly для расширений. Пост-рендереры вынесены в отдельные плагины, добавилась поддержка server side apply, а обработка ресурсов теперь использует kstatus для отслеживания состояния и ожидания объектов Локальное кэширование ускоряет работу с чартами, а логирование через slog даёт интеграцию со стандартными логгерами. Архивы чартов теперь собираются воспроизводимо, улучшился и сам SDK: теперь появился экспериментальный v3 chart API и продвинутая поддержка нескольких версий chart API. Если работаете с Helm — обновляйтесь, тестируйте свои пайплайны и чартовые сборки. 🐸 Библиотека devops'a #пульс_индустрии

📘 Хочешь в Data Science, но есть пробелы в знаниях математики? Мы сделали экспресс-курс «Математика для Data Science», который за 2 месяца даст тебе фундамент, без которого ни одна ML-модель не взлетит 🚀 Что тебя ждёт: 🔹 живые вебинары с экспертами (НИУ ВШЭ, SberAI, Wildberries&Russ); 🔹 практика в Python, квизы и проверка заданий экспертами; 🔹 матрицы, регрессии, вероятности и статистика: всё на примерах из реальных задач; 🔹 старт — 4 декабря. 🔥 Не упусти халяву: сейчас 40% до 30 ноября 👉 Записаться на курс

👀 Что действительно скрывают обещания гибкого графика и карьерного роста в IT Вакансии часто содержат привлекающие фразы, которые на деле означают совсем другое. Гибкий график нередко превращается в непредсказуемый режим работы без чётких часов, с неожиданными звонками в позднее время. Обещания карьерного роста обычно подразумевают, что сами будете решать все проблемы в условиях авралов и большого объёма работы. Чтобы избежать неприятных сюрпризов, важно уточнить у работодателя все ключевые моменты: какие задачи предстоят, как организован отпуск и из чего складывается оплата труда. ➡️ Узнать, что работодатели имеют в виду 🐸 Библиотека devops'a

📎 Что такое systemd и зачем он нужен в Linux systemd — это система инициализации и менеджер сервисов, которая отвечает за запуск, остановку и управление процессами в Linux. Он запускается первым после загрузки ядра и держит под контролем все службы и задачи, которые нужны системе и приложениям. До появления systemd в Linux популярны были разные init-системы, например, SysVinit. Они работали по очереди и запускали сервисы последовательно. Это приводило к долгой загрузке и сложностям с управлением зависимостями. systemd изменил подход — он запускает сервисы параллельно и учитывает зависимости. Его модульная архитектура позволяет расширять функциональность, а удобные команды systemctl и journalctl сделали администрирование проще и понятнее. systemd также заменяет многие отдельные утилиты и скрипты, объединяя возможности таймеров, монтирования устройств и управления сетевыми настройками. Кроме инициализации systemd управляет сервисами через понятные unit-файлы — они описывают, как запускать и перезапускать службы, какие ресурсы выделять и как реагировать на ошибки. Пример простого юнита службы:

[Unit]
Description=Пример сервиса

[Service]
ExecStart=/usr/bin/your-app
Restart=always

[Install]
WantedBy=multi-user.target

systemd стал де-факто стандартом для большинства дистрибутивов Linux благодаря своей функциональности и удобству. Он избавляет от множества рутинных операций и упрощает управление системой. 🐸 Библиотека devops'a #арсенал_инженера

🛠 Управление политикам в Kubernetes по-человечески Kyverno — это policy engine, работающий внутри Kubernetes. Он позволяет проверять, изменять и создавать ресурсы на основе заданных политик. Можно управлять безопасностью контейнеров, автоматически добавлять необходимые метки, следить за стандартами именования и ресурсными лимитами. Kyverno поддерживает проверку подписей образов, что помогает контролировать цепочку поставок и предотвращать запуск неподписанных или скомпрометированных образов. В недавнем обновлении 1.16.0 появились новые фичи и фиксы: • Добавлен vigilant mode, который запрещает использование celPreconditions без validate.cel. • Исправлены ошибки в тестах generate VAP chainsaw. • Добавлены функции генерации отчетов для MAPs. • Исправлены проблемы с обновлением статуса, вызванные разным форматом времени. • В Helm chart добавлена поддержка рендера Openreports ресурсов и возможность включения соответствующих флагов. И другие изменения. ➡️ Репозиторий ➡️ Release Notes 🐸 Библиотека devops'a #арсенал_инженера

📉 Главные тренды DevOps в России Новый отчет State of DevOps Россия 2025 раскрывает ключевые направления развития практики DevOps в России. Cloud-трансформация — отдельный важный тренд. Managed- и PaaS-сервисы меняют подходы к инфраструктуре и автоматизации процессов. DevSecOps в отчете рассматривается как необходимый элемент безопасности, внедряемый без ущерба для скорости разработки. Искусственный интеллект становится помощником, снимая нагрузку с специалистов и оптимизируя бизнес- и продуктовые процессы. 🐸 Библиотека devops'a #пульс_индустрии

😊 AI-помощник, который всегда под рукой В современном ритме работы переключения между задачами и поиском ответов сильно тормозят продуктивность. Seeva решает эту проблему, появляясь мгновенно в любом приложении по нажатию горячей клавиши. Вы просто кликаете «Watch Screen», и помощник анализирует ваш экран, помогая разобраться с любыми вопросами без излишних переключений. Это экономит время и позволяет сохранить концентрацию на важном. ➡️ Поспрашивать про свой экран 🐸 Библиотека devops'a #арсенал_инженера

❓ Как внедрить zero-trust между микросервисами Для внедрения zero-trust между микросервисами в DevOps нужно последовательно наложить несколько ключевых слоёв безопасности. Первое — включить mTLS с распределённой идентичностью на уровне ворклоадов с помощью SPIFFE/SPIRE. Это значит каждой службе присваивается короткоживущий X.509-сертификат (SVID), который автоматически ротацируется и используется для взаимной аутентификации и шифрования трафика. Такой подход исключает хранение статичных сертификатов и полностью автоматизирует управление ими. Далее — построить авторизацию по идентичности, используя RBAC или Open Policy Agent (OPA). Это даёт возможность задавать политики доступа в зависимости от конкретной сущности-сервиса, а не на уровне IP или сети. Ещё слой сетевых ограничений добавляют Kubernetes NetworkPolicy, которые ограничивают коммуникацию только разрешёнными путями. В Kubernetes для реализации zero-trust-mTLS удобно использовать сервис-меши типа Istio, Linkerd или Ambient Mesh (sidecarless). Для мультикластера нужна федерация trust domains, чтобы распространять доверие и идентификацию между кластерами, а также централизованный аудит для мониторинга и инцидент-реакции. 🐸 Библиотека devops'a #задача_со_звёздочкой

🔒 Статистика паролей за 2025 год В 2025 году наибольший слив паролей случился с утечкой 16 миллиардов паролей — одна из крупнейших в истории. При этом 94% пользователей повторяют пароли на разных сервисах, что усиливает риски. Три четверти паролей не соответствуют базовым требованиям безопасности, а простые пароли типа «123456» до сих пор в лидерах по использованию. 💬 Какие практики применяются у вас на проекте? Находили листочки с паролями на мониторе? Делитесь в комментах👇 ➡️ Статистика по паролям 🐸 Библиотека devops'a #разбор_полётов

🤩 MX Linux наконец стал systemd-friendly Вышла MX Linux 25 «Infinity» — первая версия, построенная на Debian 13 «Trixie». Главное изменение: если раньше MX позиционировал себя как systemd-free дистрибутив, то теперь все ISO идут с systemd по умолчанию. Это не значит, что сторонников sysVinit выгнали — для Xfce и Fluxbox есть sysVinit варианты. Инсталлятор получил поддержку 64-bit UEFI Secure Boot. Теперь можно ещё и настроить zram swap-устройства. Доступны три десктопа: Xfce 4.20, KDE Plasma 6.3.6 и Fluxbox 1.3. ➡️ Release notes 🐸 Библиотека devops'a #пульс_индустрии

🛠 Изоляция тестовых данных Изоляция тестов — критичный момент в стабильном тестировании с базами данных. Проблемы возникают когда тесты используют общие ресурсы или порядок запуска влияет на результат из-за утечки состояния. Лучшим решением будет создавать уникальные временные схемы в базе данных для каждого прогона тестов. Они полностью изолируют данные, исключая конфликты и зависимости между тестами.

export TEST_SCHEMA="t_$(uuidgen | tr -d '-')"
psql -c "CREATE SCHEMA ${TEST_SCHEMA};"
pytest --db-schema="${TEST_SCHEMA}" ; rc=$?
psql -c "DROP SCHEMA ${TEST_SCHEMA} CASCADE;"
exit $rc

Схема создаётся перед тестами, используется, например, в pytest через параметр --db-schema, а затем удаляется. 🐸 Библиотека devops'a #root@prompt

💾 На полке в университете нашли Unix В хранилище Университета Юты нашли магнитную ленту 1973 года с надписью «UNIX Original From Bell Labs V4». Если это действительно четвёртая версия Unix, то это один из самых важных артефактов в истории программирования. V4 — это первая версия Unix, написанная на языке C вместо ассемблера. Именно это сделало Unix портируемым: код можно было скомпилировать для разных компьютеров почти без изменений. Полная копия V4 долго считалась потеряной. Остались только куски кода и справочные страницы. Третья и пятая версии хорошо документированы, а четвёртая — пропуск в истории. Между тем она знаменует момент, когда операционная система превратилась из эксперимента Bell Labs в систему, которую можно переносить и учиться на ней. ➡️ Источник 🐸 Библиотека devops'a #пульс_индустрии

🛒 Black Friday от Proglib.academy! Только до 30 ноября — скидка 40% на ВСЕ курсы. Пора добавить в корзину не носки, а новые скиллы: Python, математика для Data Science, AI, алгоритмы и структуры данных, ML. 🎓 Выбирай курс, который реально двинет тебя в карьере, и учись со скидкой. 👉 Учиться со скидкой

🐸 Библиотека devops'a #пятничный_деплой

💻 Хочешь MacBook Pro? Просто начни учиться! Да-да, вы не ослышались: Proglib.academy дарит макбук за учёбу! Всё просто: — купи любой курс Академии до 15 ноября; — пройди 2 недели обучения (можно за два дня); — напиши куратору в чате курса хэштег #розыгрыш. 📚 Выбирай свой курс: ▫️ «Математика для DS» — для тех, кто хочет уверенно работать с данными; ▫️ «Основы Python» — чтобы начать писать код с нуля; ▫️ «Алгоритмы и структуры данных» — для будущих инженеров; ▫️ «AI-агенты» или «Машинное обучение» — для тех, кто хочет прокачаться в ИИ. 👉 Участвовать в розыгрыше

▶️ Запуск CI из Jira Часто нужно запустить специфичную джобу для конкретной задачи: пересчитать метрики, перепроверить безопасность, прогнать дополнительные тесты. Обычно мы идём в Jenkins или GitHub Actions, ищем нужную джобу, вводим параметры. Информация о нужном действии находится в Jira, но инструмент для его выполнения — отдельно. Хочется проще: добавил лейбл к задаче и всё запустилось автоматически. Что можно сделать: Jira отправляет вебхук с информацией о лейблах в GitHub через repository_dispatch. GitHub Actions ловит это событие, парсит лейблы и запускает нужные шаги. На примере ниже: если в Jira добавили лейбл rebuild-docker, GitHub Actions пересобирает Docker образ. После выполнения можно написать результат комментарием обратно в Jira.

name: Jira Triggered Job

on:
  repository_dispatch:
    types: [jira-trigger]

jobs:
  handle-trigger:
    runs-on: ubuntu-latest
    steps:
      # Парсим labels из payload'a
      - name: Parse Jira event
        id: parse
        run: |
          LABELS="${{ fromJSON(github.event.client_payload).labels }}"
          ISSUE="${{ fromJSON(github.event.client_payload).issueKey }}"
          
          echo "issue=$ISSUE" >> $GITHUB_OUTPUT
          echo "labels=$LABELS" >> $GITHUB_OUTPUT
          echo "Получены labels: $LABELS для issue: $ISSUE"
      
      # Если в labels есть 'rebuild-docker', запускаем пересборку
      - name: Rebuild Docker
        if: contains(steps.parse.outputs.labels, 'rebuild-docker')
        run: |
          echo "🐳 Пересобираем Docker для ${{ steps.parse.outputs.issue }}"
          docker build -t myapp:latest .
          docker push myapp:latest
          echo "DOCKER_STATUS=✅ Docker образ успешно пересобран" >> $GITHUB_ENV
      
      # Если в labels есть 'run-tests', запускаем тесты
      - name: Run Tests
        if: contains(steps.parse.outputs.labels, 'run-tests')
        run: |
          echo "✅ Запускаем тесты для ${{ steps.parse.outputs.issue }}"
          npm test
          echo "TESTS_STATUS=✅ Тесты пройдены успешно" >> $GITHUB_ENV
      
      # Если в labels есть 'security-scan', запускаем проверку безопасности
      - name: Security Scan
        if: contains(steps.parse.outputs.labels, 'security-scan')
        run: |
          echo "🔒 Security scan для ${{ steps.parse.outputs.issue }}"
          npm audit
          echo "SECURITY_STATUS=✅ Security scan завершен" >> $GITHUB_ENV
      
      # Пишем результаты комментарием в Jira
      - name: Comment in Jira
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const issue = context.payload.client_payload.issueKey;
            const labels = context.payload.client_payload.labels;
            
            let comment = '🤖 Автоматизированные действия:\n\n';
            
            if (labels.includes('rebuild-docker')) {
              comment += '✅ rebuild-docker: Docker образ пересобран\n';
            }
            if (labels.includes('run-tests')) {
              comment += '✅ run-tests: Тесты запущены\n';
            }
            if (labels.includes('security-scan')) {
              comment += '✅ security-scan: Проверка безопасности завершена\n';
            }

Затем добавьте триггер в Jira, который будет отправлять пейлод:

{
  "event_type": "jira-trigger",
  "client_payload": {
    "issueKey": "{{issue.key}}",
    "labels": "{{issue.labels}}"
  }
}

на урл:

https://api.github.com/repos/ВАШ_НИК/ВАШ_РЕПО/dispatches

с headers:

Authorization: token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Accept: application/vnd.github.v3+raw+json
Content-Type: application/json

Замените ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx на ваш GitHub токен, который можно получить по пути GitHub → Settings → Developer settings → Personal access tokens → Tokens. Это особенно полезно в больших командах, где не все имеют доступ к GitHub Actions, но все работают с Jira. QA может добавить security-scan — и проверка запустится автоматически. 🐸 Библиотека devops'a #арсенал_инженера

🔄 Обновление firewalld Вышел релиз firewalld версии 2.4.0 — динамически управляемого межсетевого экрана для Linux. Основные новшества: • Добавлен набор правил gateway, обеспечивающий функциональность типового домашнего маршрутизатора: NAT, обработка conntrack и перенаправление трафика между зонами. • Введён флаг disable, который можно применять в XML-конфигурациях, через командную строку и D-Bus для отключения отдельных правил и наборов правил. • Максимальная длина имён правил увеличена с 17 до 128 символов. ➡️ Release notes 🐸 Библиотека devops'a #пульс_индустрии

👨‍💻 Как добить поды, если они зависли Вы удалили ReplicationController с дюжиной подов. Большинство исчезли. Но несколько упрямцев остались висеть в состоянии Terminating, игнорируя ваши попытки удаления. Когда Kubernetes удаляет под, kubelet выполняет аккуратное завершение: отправляет SIGTERM, ждёт до истечения terminationGracePeriodSeconds, останавливает контейнеры, размонтирует тома и сетевые пространства имён. Финальный шаг — удаление пода с ноды и из API. Но если размонтирование не удаётся из-за ошибки "device or resource busy", процесс завершения зависает. API-объект остаётся в лимбо состояния Terminating навсегда. Корень проблемы обычно один: рантайм контейнера оставил утечку — смонтированный том или процесс, который по-прежнему держит файловые дескрипторы. Быстрая диагностика Посмотреть есть ли на поде финализаторы:

kubectl get pod <POD> -o jsonpath='{.metadata.finalizers}'

Если они есть — не рубите их сплеча. Это обычно finalizer-ы хранилища (PVC, CSI), которые блокируют удаление до завершения очистки. Нет финализаторов? Тогда ищем утечку монтирования на уровне хоста. Подключитесь к ноде, где запускался под:

POD=pod-186o2
NS=default
UID=$(kubectl get pod $POD -n $NS -o jsonpath='{.metadata.uid}')

# На ноде смотрим, что смонтировано
grep -F "$UID" /proc/mounts || true
findmnt | grep "$UID" || true

Если видите записи типа /var/lib/kubelet/pods/<UID>/volumes/... — это ваш виновник. Теперь узнаем, кто держит монтирование:

lsof +D /var/lib/kubelet/pods/$UID 2>/dev/null | head

Чистим руками Для Docker:

docker ps --no-trunc | grep $POD
docker stop <containerID>
# Если совсем ничего не помогает (лаха!):
systemctl restart docker

Для containerd:

crictl ps | grep $POD
crictl stopp <containerID>
crictl rmp <containerID>
# Последняя линия защиты:
systemctl restart containerd

Если контейнер мёртв, но монтирование остаётся:

umount -l /var/lib/kubelet/pods/$UID/volumes/<driver>/<vol> || true

Теперь, когда освободили держание:

kubectl delete pod $POD -n $NS

Если всё ещё не уходит:

kubectl delete pod $POD -n $NS --grace-period=0 --force

Это API-уровневый молот. Безопасен для очистки зависшей записи, но используйте только после того, как разобрались с утечками на ноде. С особой осторожностью для StatefulSet. Видите Terminating, который не уходит? Не спешите с --force. В девяти случаях из десяти kubelet вам что-то говорит: что-то остаётся смонтированным или используется. 🐸 Библиотека devops'a #арсенал_инженера