👀 Умеете строить предсказуемую архитектуру с ИИ? Станьте спикером Proglib academy

Мы в Proglib.academy запускаем курс по Spec-Driven Development (SDD) — учим разработчиков управлять ИИ-агентами (Cursor, Copilot, Claude) через спецификации, контекст и тесты, чтобы не перепроверять за нейросетью каждую строку.

Для этого курса мы ищем классных спикеров-практиков.

➡️ Что требуется от вас?

● BigTech бэкграунд: опыт работы разработчиком, тимлидом или архитектором в крупных технологических компаниях.
● Опыт управляемой разработки с ИИ: вы на практике знаете, как встроить AI-инструменты в личный или командный workflow (от постановки задачи до ревью AI-кода).
● Системный подход: умение превращать хаотичную генерацию кода в предсказуемый инженерный процесс (работа с архитектурой, чек-листами, легаси и покрытием тестами).

➡️ Что мы предлагаем?

● Достойную оплату за подготовку материалов и проведение занятий.
● Мощное продвижение личного бренда через медиаресурсы Proglib (наша аудитория — 1 млн+ айтишников).
● Возможность публиковать свои экспертные материалы и статьи на наших площадках.
● Доступ к сильному и закрытому профессиональному сообществу.

Также мы ищем консультанта программы.

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

➡️ Как с нами связаться:

Telegram: @alinaa_kh
E-mail: alina@proglib.io

🐸 Библиотека devops'a

#пятничный_деплой

Какова цель меток Kubernetes?

👾 — Хранить переменные среды
👍 — Шифровать данные контейнера
🥰 — Определить архитектуру приложения
⚡️ — Группировать и организовывать модули и другие ресурсы

🐸 Библиотека задач по DevOps

🧑‍💻 uv — инструмент, который объединяет pip, venv, pyenv и pipx

Вместо нескольких утилит для управления Python-окружениями можно использовать один инструмент — uv. Он объединяет работу с зависимостями, окружениями и версиями Python.

🔢 Что умеет:

Управление виртуальными окружениями:

uv venv
uv pip install -r requirements.txt

Создание окружения и установка зависимостей из lockfile одной командой:

uv sync

Запуск проекта без ручной активации окружения:

uv run python script.py

Управление версиями Python без pyenv:

uv python install 3.13
uv python pin 3.13

Запуск CLI-инструментов без установки в систему:

uv tool run ruff check .

❓ Почему это удобно в CI/CD

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

Пример для GitHub Actions:

- uses: astral-sh/setup-uv@v6
- run: uv sync --frozen
- run: uv run pytest

Флаг --frozen гарантирует воспроизводимую сборку: зависимости устанавливаются строго из uv.lock без их пересчёта.

Не забывайте про uv.lock

uv создаёт lockfile с зафиксированными версиями и хэшами зависимостей. Его стоит хранить в репозитории так же, как package-lock.json или Cargo.lock.

⚠️ И ещё одна хорошая практика

Закрепляйте версии GitHub Actions (@v6, а не @latest). Это делает пайплайны более предсказуемыми и защищает от неожиданных изменений после обновлений.

🔗 Ссылка на GitHub

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🔒 Запустите контейнер с минимально необходимыми правами

docker run \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  nginx

🔴 --cap-drop ALL отключает все Linux Capabilities.

🔴 --cap-add NET_BIND_SERVICE возвращает только право слушать привилегированные порты (<1024).

Чем меньше привилегий у контейнера — тем меньше потенциальная поверхность атаки.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt #docker #security

🔥 Большой open source-гайд по Linux

Если хотите системно разобраться в Linux или освежить знания, обратите внимание на этот репозиторий.

Внутри собраны материалы по самым разным темам:

🔹 основы Linux и работа с терминалом;
🔹 файловые системы и управление пакетами;
🔹 безопасность и hardening;
🔹 WireGuard;
🔹 облачные технологии;
🔹 популярные дистрибутивы (Ubuntu, Debian, Fedora, Kali и другие).

Подойдёт DevOps-инженерам, разработчикам, администраторам и всем, кто хочет глубже понимать Linux.

🔗 GitHub

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера #linux

Как вы объясняете, зачем обновлять Kubernetes, если «и так всё работает» ❓

Kubernetes 1.33 уже вышел из поддержки. Но задача на обновление нередко встречает вопрос:

«Зачем? Всё же работает».

Какие аргументы помогают убедить стейкхолдеров?

🈂️ Безопасность. После EOL исправления новых уязвимостей для этой версии больше не выходят.

🈂️ Технический долг. Чем дольше откладывать обновление, тем сложнее и дороже будет миграция.

🈂️ Совместимость. Новые версии операторов, Helm-чартов и других компонентов постепенно перестают поддерживать старые релизы Kubernetes.

🈂️ Compliance. Для многих компаний использование неподдерживаемого ПО — дополнительный риск при аудитах.

💬 А какие аргументы работают у вас? Поделитесь в комментариях.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#dev_null

😕😕

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

⌨️ Почему root в Docker — это не совсем root

Контейнер может работать от UID 0, но это не означает, что у него есть все привилегии root на хосте.

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

🈂️ Например, контейнер получает только необходимый минимум, а опасные capability вроде SYS_ADMIN, SYS_MODULE или SYS_PTRACE по умолчанию исключаются.

Это снижает риск компрометации хоста, даже если процесс внутри контейнера запущен от имени root.

💡 Проверить список capabilities можно командой:

docker inspect <container> | jq '.[0].HostConfig.CapAdd, .[0].HostConfig.CapDrop'

А при необходимости добавить или убрать capability:

docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

Чем меньше привилегий у контейнера — тем безопаснее окружение.

🔗 Читать подробнее

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

💡 Выжимка отчёта ReversingLabs 2026: почему одного SBOM уже недостаточно

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

📈 Что изменилось

🔹 Количество вредоносных пакетов в открытых репозиториях выросло на 73%.

🔹 Среднее число известных уязвимостей на один репозиторий увеличилось с 280 до 581.

🔹 AI-пайплайны становятся такой же целью атак, как и традиционные процессы сборки и доставки ПО.

📄 SBOM — это только начало

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

По данным отчёта, 48% организаций не выполняют требования по работе с SBOM: не обновляют его, не связывают со сканированием уязвимостей и не используют при анализе рисков.

🤖 AI требует нового подхода

Авторы отдельно выделяют ML-BOM — аналог SBOM для моделей машинного обучения.

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

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#локализация

⭐️ Интересная закономерность: чем опытнее инженер, тем чаще у него открыт терминал

Неважно, работаете вы с Docker, Kubernetes, облаками или обычным Linux-сервером — большинство задач всё равно решается через консоль.

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

❓ Вопрос от подписчика: стоит ли сейчас переходить с Terraform на OpenTofu

Получили вопрос:

«Мы используем Terraform 1.5, S3 backend, без Terraform Cloud и HCP. Есть ли смысл переходить на OpenTofu?»

Что предлагает OpenTofu уже сегодня:

🔹 нативное шифрование state и plan-файлов;
🔹 dynamic prevent_destroy через переменные (с версии 1.12);
🔹 for_each для конфигурации провайдеров;
🔹 более быстрый цикл релизов и регулярное появление новых возможностей.

Когда с миграцией лучше не спешить:

— используете Terraform Stacks;
— есть зависимость от Terraform Cloud/HCP;
— существуют корпоративные требования или vendor-контракты, связанные с HashiCorp.

Если вы работаете с обычным S3 backend и не завязаны на Terraform-специфичные возможности, OpenTofu уже выглядит зрелой альтернативой. Но решение зависит от вашей инфраструктуры и используемых функций.

💬 А что выбрали вы?

❤️ — Уже перешли на OpenTofu
😁 — Пока остаёмся на Terraform
👍 — Планируем миграцию

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#dev_null