Devops Bootcamp с Федосеевым

Docker: норм или стрем? Разбираемся с местом Docker в современном DevOps-стеке В конце 2020 года громом грянула новость: Kubernetes объявляет docker-shim устаревшим. Пресса подхватила, заголовки кричали: «Kubernetes бросает Docker!». Это породило массу недопонимания На деле же Kubernetes никогда не запускал ваши контейнеры напрямую через Docker. Для этого всегда использовался низкоуровневый containerd (или CRI-O), который является частью самого Docker. Docker выступал в роли «менеджера» поверх containerd Проблема была в том, что Docker не реализовывал напрямую CRI — стандартный интерфейс Kubernetes для работы с контейнерами. Для общения с Docker Kubernetes использовал специальный адаптер, называемый dockershim ➡️ Решение Kubernetes: Убрать этот адаптер и говорить с containerd напрямую через CRI. Это упрощало архитектуру и делало её более стандартной В итоге с точки зрения разработчика и DevOps-инженера, создающего образы, — ничего не поменялось. Но зачем тогда альтернативы? Podman, Buildah, Kaniko... Docker — это монолит. Он включает в себя всё: 🌟 Демон (dockerd) 🌟 Сборку образов (docker build) 🌟 Управление контейнерами (docker run) 🌟 Реестр (docker push/pull) 🌟 Оркестрацию (docker-compose, Docker Swarm) Современная философия Unix — это инструменты, делающие одну вещь, но делающие её хорошо Вот кто и зачем пришёл на эту сцену: 1️⃣ Podman — «Беспалубный» Docker Ключевое отличие: не требует демона. Запускает контейнеры от имени пользователя (rootless). Это серьезный плюс для безопасности Совместимость: CLI почти один в один с Docker. alias docker=podman — и многие даже не заметят разницы Зачем? Для безопасности, более простой интеграции с systemd и идеологии «без демона» 2️⃣ Buildah — Инструмент для сборки OCI-образов Ключевое отличие: позволяет собирать образы без Dockerfile и без демона. Даёт тонкий контроль над каждым слоем Зачем? Для создания минималистичных образов (сборка из scratch) и для CI/CD, где не хочется запускать целый Docker Daemon 3️⃣ Kaniko — Сборка образов в Kubernetes. Хоть и потеряла поддержку, можно использовать форки Ключевое отличие: Собирает образы контейнеров внутри контейнера или Pod в Kubernetes. Не требует привилегированного доступа (Docker Daemon-less) Зачем? Идеально для безопасных CI/CD пайплайнов, работающих прямо в Kubernetes. Больше не нужно маунтить /var/run/docker.sock в раннере, что является огромной дырой в безопасности 4️⃣ Nerdctl / containerd — Низкоуровневый контроль containerd — это и есть та самая среда выполнения, которая теперь используется в Kubernetes по умолчанию. nerdctl — это CLI для работы с ним Зачем? Для отладки и управления контейнерами прямо на нодах Kubernetes на низком уровне ⚡️ Docker для разработки — бесспорный король Docker Desktop, простой Dockerfile и docker-compose up — это по-прежнему самый быстрый и удобный способ поднять локальное окружение. Менять это на Podman ради идеологии — часто неоправданная трата времени Docker в продакшене — уступает место специализированным инструментам На нодах Kubernetes у вас уже работает containerd. Вам не нужен полноценный Docker. Для CI/CD использование Docker-in-Docker (dind) или маунта docker.sock считается антипаттерном с точки зрения безопасности. Здесь побеждает Kaniko или Buildah Для управления контейнерами на серверах (вне K8s) Podman — отличная и более безопасная альтернатива ⏩ Ваши навыки работы с Docker не обесценились Концепции, которые вы освоили с Docker: образы, слои, volumes, сети, Dockerfile — универсальны. Они переносятся на Podman, Buildah и Kaniko практически один в один. Вы учились не нажимать кнопки в docker, вы учились концепциям контейнеризации 📌 Docker не умер. Он повзрослел и занял свою чёткую нишу. Это как швейцарский нож: он невероятно удобен, когда вам нужно многое сделать быстро и без лишних инструментов (разработка). Но для серьёзной, высоконагруженной и безопасной работы на кухне продакшена шеф-повар будет использовать специализированные ножи: Kaniko для нарезки, Podman для чистки, а containerd — как мощную плиту

⭐️ Стартуем через 15 минут! ⭐️ Подключайтесь

⚡️⚡️⚡️ RAG-бот своими руками: вебинар через час! Коллеги, ровно в 19:00 встречаюсь в прямом эфире с Андреем Богомоловым на вебинаре по RAG — технологии, которая меняет работу с документацией и логами Тема очень интересная, поэтому планирую засыпать Андрея разными каверзными вопросами. Присоединяйтесь и тоже спрашивайте! ⏩ Занять место на вебинаре — через бота

Почему ваши процессы в Linux внезапно умирают? Коллеги, сегодня поговорим о проблеме, которая может незаметно гробить ваши приложения в продакшене. Речь о лимите одновременных процессов (nproc) ➡️ Что происходит: По умолчанию во многих дистрибутивах лимит nproc установлен в 4096 процессов на пользователя. Для высоконагруженных приложений (особенно в Go, Java, Python с асинхронностью) этого может не хватить. Процессы начинают падать с ошибкой fork: retry: Resource temporarily unavailable, хотя память и CPU в норме Почему это бесит: ⏩ Ошибка маскируется под другие проблемы ⏩ На тестовых стендах всё работает ⏩ В мониторинге нет явных аномалий ⏩ Расследование может занять часы Проверка и решение:

# Текущий лимит
ulimit -u

# Постоянное решение в /etc/security/limits.conf
* soft nproc 65536
* hard nproc 65536

# Для systemd-сервисов добавляем в сервис-файл
[Service]
LimitNPROC=65536

‼️ Важно: После изменения limits.conf нужен перелогин. Для systemd-сервисов — перезапуск сервиса В действительно нагруженных системах может недостаточно даже таких лимитов, поэтому вот пример подобного файла от действующего сервера:

*         hard    nproc           infinity
*         soft    nproc           infinity
root      hard    nproc           infinity
root      soft    nproc           infinity
*         hard    nofile          1048576
*         soft    nofile          1048576
root      hard    nofile          1048576
root      soft    nofile          1048576
*         hard    memlock         64
*         soft    memlock         64
root      hard    memlock         64
root      soft    memlock         64
*         hard    sigpending      infinity
*         soft    sigpending      infinity
root      hard    sigpending      infinity
root      soft    sigpending      infinity

Сталкивались с подобным? Делитесь в комментариях — какие лимиты выставляете, чтобы потом не ловить падения?

Как насчет вторничной задачи? #задача@devopsupgrade Сегодня просто, затронем базу Команда решила внедрить GitOps для управления инфраструктурой и деплоем. Какой сценарий наилучшим образом иллюстрирует принцип «Git — единственный источник истины»? 1️⃣ Разработчик делает хот-фикс напрямую в продакшен-кластере через kubectl edit, а затем коммитит изменения в Git 2️⃣ CI-пайплайн собирает образ, проставляет тег образа в GIT и сразу с помощью kubectl apply деплоит его в кластер 3️⃣ ArgoCD постоянно мониторит Git-репозиторий и автоматически синхронизирует состояние кластера с тем, что описано в манифестах в репозитории. Любые расшения будут перезаписаны из Git 4️⃣ CI-пайплайн собирает образ и сразу же с помощью kubectl apply разворачивает его в кластере, а затем пушит новый тег образа в Git 5️⃣ Инженеры используют helm upgrade --force для развертывания приложений, а чарты хранятся в Git

Помогите понять реальные задачи DevOps. Yandex Cloud ищет инженеров для исследования Про задачи DevOps Middle мы с вами говорим уже больше полугода — и на честных вакансиях разбирали, и на девопс про деньги Сейчас мы с командой Yandex Cloud проводим исследование рабочих задач DevOps-инженеров уровня Middle — интересно узнать, насколько результаты этого исследования будут близки к тому, что получилось в Слёрме ➡️ Приглашаю вас поучаствовать — ваш опыт поможет лучше понять потребности инженеров. Как проходит исследование: 🔴 Онлайн-встреча на 30 минут 🔴 Ответы на вопросы о ваших рабочих задачах 🔴 Все данные анонимизируются Требования к участникам: ✅ Опыт в IT от 2 лет ✅ Опыт в роли DevOps-инженера от 1 года ✅ Работа с Yandex Cloud от 6 месяцев ✅ Использование Yandex Cloud не реже 1 раза в месяц В благодарность за участие вы получите грант 3000₽ на инфраструктуру в Yandex Cloud (отличная возможность начать наконец выполнять мои задачки 😅) Если вы подходите под требования и хотите принять участие в исследовании — напишите в тг Полине Буду рад вашему участию!

SRE Day: 11 октября. Берите на вооружение готовые стратегии надежности от ведущих инженеров Коллеги, отмечу в своем календаре и вам рекомендую. 11 октября пройдет SRE Day — онлайн-мероприятие, полностью посвященное Site Reliability Engineering. Для тех, кто хочет не просто слушать, а сразу применять в работе, здесь будет много практики. В программе — интерактивная игра по разбору инцидента, взгляд на карьеру от джуна и сеньора, и круглый стол с 5 экспертами 🔥 Особенно прикольно, что можно будет задать вопросы и сразу получить обратную связь — обычно это самый дефицитный ресурс Если вы работаете с надежностью систем, мониторингом или дежурствами — рекомендую посмотреть. Как минимум, возьмете несколько рабочих методик для своих процессов ➡️ В общем, моя вам рекомендация — обязательно сходить на SRE Day. Подробнее про программу — по ссылке

Новый поток — новые лица: смотрите, как начинается путь в DevOps На прошлой неделе запустили новый поток DevOps Upgrade! Кайфуем от активности в общем чате — участники знакомятся, делятся опытом, целями и ожиданиями от курса ➡️ В этом потоке собрались системные администраторы, разработчики и инженеры из разных городов. Это еще раз доказывает, что в DevOps приходят совершенно разные люди, которые хотят развивать свои навыки Каждый старт — это особенное событие. Уникальное коммьюнити, которое собирается только раз в несколько месяцев 🔥 Начало положено — впереди 9 месяцев интенсивного роста. До конца недели вы еще можете присоединиться к потоку. Подробности — на сайте

Жду начало мотосезона 🔥

DevSecOps — это не про моду. Это про то, как перестать бояться релизов На эфирах и вебах неоднократно звучал вопрос — DevSecOps это просто очередной модный термин или действительно что-то важное? Прежде чем ответить на вопрос, предлагаю вспомнить эти ужасные моменты, когда безопасность в последний момент рубит ваш выстраданный релиз ➡️ Этого стресса можно избежать, если встроить безопасность в пайплайн с самого начала Я давно перестал относиться к DevSecOps как к модному слову. Для меня это вопрос спокойного сна перед релизами. Именно поэтому рекомендую интенсив «DevSecOps Bootcamp», где одним из спикеров будет любимый вами Андрей Сухоруков Если вы: ⭐️ Используете инструменты безопасности, но не знаете, что делать с результатами ⭐️ Сканируете код, но пропускаете образы, зависимости и конфиги ⭐️ Чувствуете, что безопасность скорее мешает, чем помогает ⭐️ Понимаете, что вам есть что защищать Приходите на интенсив «DevSecOps Bootcamp» 11 октября. Вы научитесь снижать количество инцидентов до 70% и ускорять релизы до 20%. Проверено на практике ➡️ Подробности — на сайте

⚡️⚡️⚡️ На этой неделе вышел заключительный эпизод «DevOps про деньги» В нем уже не было интервью — только подведение итогов. Сева поговорил с девятью девопсами, и теперь может точно сказать: ➡️ сколько платят в DevOps ➡️ какие бывают плюшки ➡️ какие скиллы прокачивать, чтобы зарабатывать больше Спойлер: общая вилка получилась от 190 до 800 тысяч рублей в месяц Где посмотреть: YouTube VK Видео Rutube Смотрите, делайте выводы и приходите к нам в DevOps — тут есть не только чай и печеньки. А всем необходимым навыкам научим на DevOps Upgrade :)

Не так давно делился с вами грустными новостями, а теперь принес хорошие Знакомьтесь — Маэстро 🐕

Я сам пойду на этот вебинар по RAG. Вот почему вам тоже стоит присоединиться Коллеги, я постоянно мониторю новые технологии, и RAG — одна из тех тем, которую стоит изучить каждому DevOps-инженеру прямо сейчас. Сам давно хотел разобраться в практическом применении, поэтому очень рад, что Слёрм позвал меня ведущим на очень крутой веб ➡️ 8 октября в 19:00 мск встречаемся на вебинаре «Что такое RAG и с чем его едят» Спикер: Андрей Богомолов — co-founder и CTO GenAI LAB, эксперт с более чем 10-летним опытом в AI Лично мне интересно посмотреть на реальные кейсы, особенно: 📌 Как собрать работающий RAG на базе телеграм-канала 📌 Автоматизацию через n8n — всегда полезно иметь в арсенале новые инструменты 📌 Что ломается в продакшене — самый ценный опыт, который обычно не найти в документации Андрей и команда GenAI LAB реализовали 100+ AI-проектов и обучили 300+ специалистов — определенно есть чему поучиться. Я планирую спросить про аи все, что мы с вами стеснялись спросить — даже самые «глупые» (все же помнят, что глупых вопросов не бывает?) Регистрируйтесь, разберемся в технологии вместе! 🔥 Занять место на вебинаре — через бота

GitLab Artifacts: скрытые настройки безопасности. Разбираем на примерах Коллеги, в последних заданиях я уже затрагивал тему артефактов в пайплайнах. И чем больше проверяю работы, тем больше вижу, что многие недооценивают артефакты как объект безопасности Артефакты — это не просто «файлы после сборки». Это потенциальная утечка: бинарники с прода, ключи, логи статического анализа с найденными уязвимостями, секреты. GitLab по умолчанию дает доступ к ним всем, у кого есть доступ к проекту — и это нужно менять Разберем поэтапно, как взять артефакты под контроль 1️⃣ Базовый контроль времени жизни expire_in — ваш главный союзник. Артефакты не должны жить вечно:

build:
  script:
    - mvn package
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 week  # Автоматическое удаление через неделю

2️⃣ Умное сохранение при разных сценариях Не все что упало — бесполезно. Сохраняем логи только при падении:

debug_build:
  script:
    - make build
  artifacts:
    paths:
      - build/logs/
      - core.dump
    when: on_failure  # Сохраняем только если пайплайн упал
    expire_in: 2 days

3️⃣ Удобство для разработчиков expose_as — показываем артефакты прямо в интерфейсе Merge Request:

generate_docs:
  stage: test
  script:
    - doxygen Doxyfile
  artifacts:
    paths:
      - public/docs/
    expose_as: 'Documentation Preview'  # Ссылка появится в MR

4️⃣ Специализированные отчеты для безопасности artifacts:reports — это мощный механизм для работы со специализированными отчетами, которые GitLab может автоматически обрабатывать и интегрировать в свой интерфейс

test:
  stage: test
  script:
    - mvn test
    - pytest --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml
      junit:
        - target/surefire-reports/TEST-*.xml
        - target/failsafe-reports/TEST-*.xml

sast:
  stage: test
  script:
    - echo "Running SAST..."
  artifacts:
    reports:
      sast: gl-sast-report.json

secret_detection:
  stage: test
  script:
    - echo "Detecting secrets..."
  artifacts:
    reports:
      secret_detection: gl-secret-detection-report.json

5️⃣ Управление доступом artifacts:public — контроль видимости артефактов

job_name:
  artifacts:
    paths:
      - path/to/files
    public: <true|false>

artifacts:access — тонкая настройка доступа к артефактам

test:
  script: 
    - ./run-tests.sh
  artifacts:
    paths:
      - test-results/
    access: <keyword> # Один из трех вариантов

⏩ Доступные варианты: - always (по умолчанию) — опасно для чувствительных данных - never — идеально для временных файлов с секретами - on_success — золотая середина Версия 18.4+: перед использованием проверьте актуальность вашего GitLab. Важно: artifacts:public и artifacts:access нельзя использовать вместе в одном job. Эти настройки — не просто «удобные фичи». Это ваш инструмент для построения безопасного CI/CD, где критичные данные не утекают через артефакты А какие настройки артефактов используете вы? Сталкивались ли с проблемами безопасности? Делитесь опытом в комментариях — обсудим лучшие практики!

Дайджест материалов сентября Коллеги, приветствую! За сентябрь вышло много классных постов, которые собрали большое количество ваших реакций и комментариев. Собрал все полезности в одном посте — сохраняйте! ⬇️ ⏩ 5 инструментов-антидепрессантов, которые спасают день девопса Инструменты, которые спасают ваше настроение с самого утра и не дают упасть в ноль к деплою в пятницу вечером ⏩ 3 слова, которые убивают ваши шансы на собеседовании Каковы ваши слабые стороны? Только не говорите, что вы перфекционист ⏩ Я пошёл в магистратуру спустя 11 лет О необходимости (или отсутствии необходимости) базового образования в IT ⏩ Выживают только те, кто мониторит: ваш путеводитель по инструментам, которые спасут репутацию и нервные клетки Про инструменты, без которых ваш прод — это тёмный лес, а каждый звонок ночью — игра в русскую рулетку ⏩ «Платите за скиллы, а не за года». Почему подход зумеров к поиску работы в DevOps — это новая норма Спойлер: разница в подходе бумеров и зумеров просто космическая ⏩ Выжмите всё из ИИ: как превратить ML в личного ассистента Готовые схемы, как заставить ИИ работать на вас ⏩ Обзор вакансий: исчезает ли удалёнка, и почему одни предложения пугают, а другие — радуют Измеряем температуру рынка: что реально предлагают инженерам ⏩ DevOps-рекрутинг: хаос, внезапные созвоны и кандидат, который знал всё... но ничего не знал Веселые истории про невероятные собесы ⏩ Внимание: ваше резюме теперь сначала читает робот. 5 правил, чтобы его «пройти» и попасть на живого HR Системы ATS автоматически отсеивают до 75% кандидатов, даже не показывая их резюме человеку. Как быть? ⏩ Топ инструментов-раздражителей, от которых у каждого девопса горит жопа Выплескиваем наболевшее и говорим об инструментах, которые ежедневно испытывают на прочность наше психическое здоровье ⏩ Ваше резюме уже улетело в спам, и вы об этом не знаете Продолжение поста про ATS — обсуждаем, как проверить свое резюме ⏩ Реальная картина со стажировками в DevOps Какие стажировки есть сейчас на рынке, а главное, для кого они ⏩ Git для DevOps: неочевидные команды, которые решают специфические проблемы Не базовый синтаксис, а инструменты для тех, кто работает с инфраструктурой как с кодом 🫡, если нужно делать такие дайджесты каждый месяц

Вопросы о карьере в DevOps, которые стесняются задать вслух. Отвечают эксперты из VK, Сбера, Avito и других топовых компаний Коллеги, на карьерных консультациях я часто слышу одни и те же вопросы от студентов. Не те, что про технологии, а про карьеру — те, что вызывают больше всего тревоги и неопределенности: ➡️ «Как объективно оценить свой уровень, если в компании нет четкой системы грейдов?» ➡️ «Должен ли DevOps-инженер уметь программировать, или достаточно скриптов?» ➡️ «Где проходит грань между DevOps и админом Linux? И насколько глубоко нужно погружаться в безопасность?» ➡️ «Как устроена работа DevOps в команде? Переход «по наследству» не дает полной картины» ➡️ «Куда смотреть тем, кто ищет стажировку? Платные варианты вообще существуют?» Это не теоретические вопросы — это реальные боли, которые мешают расти и уверенно чувствовать себя на рынке. Этой весной мы собрали 10+ экспертов из VK Tech, Сбера, Avito, Kaspersky, Selectel и других ведущих компаний, чтобы дать развернутые ответы именно на эти вопросы. В серии вебинаров мы разобрали: ❓ Как выстроить карьерный трек от Junior до Middle ❓ Какие требования действительно важны на собеседованиях ❓ Как работает DevOps в разных типах компаний ❓ Что делать, если вы зашли в тупик развития Это не просто теория — это опыт специалистов, которые ежедневно принимают решения о найме и формируют команды. ⏩ Посмотреть записи вебинаров можно здесь: YouTube VK Видео Rutube

А для тех, у кого нет времени, мы сделали краткие конспекты вебинаров в формате статей на хабре: Часть 1 Часть 2 Часть 3

Смотрите, читайте и выстраивайте эффективный карьерный трек. А если остались вопросы — пишите в чат, будем разбирать на карьерных эфирах ⚡️