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

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

Привет! На связи Аниса Октябрь...🍂 Наиболее активный месяц, когда рынок труда достигает пика по открытым вакансиям. И вот мы готовы ворваться на всеми известный красный сайт с вакансиями, но... Нас таких много! А это значит, что нужно найти дополнительный путь – максимально целевой, быстрый и действенный. Нетворк! заиграли фанфары где-то на фоне Меня, как интроверта, хоть и с повышенными коммуникативными навыками, это слово вводит в некий ступор. Согласитесь, сразу в голове: «И как дальше? Мне прям идти и прям писать кому-то, с кем не общался 2 года? Они точно подумают, что я только из-за работы написал». Было, понимаю. Поэтому, вот: 3 ненапряжных способа развития сети контактов — с бережным отношением к своей социальной батарейке. ⏩ Периодически «показываемся» нашим новым контактам (рекрутеры, бывшие коллеги, знакомые). Всё как в жизни – лайк/ответ на пост в соцсетях, и вы уже более заметны = узнаваемы. ⏩ Развиртуализируемся. Переводим онлайн-общение в оффлайн. Совместный обед в 1.5 часа не утомит, а личный контакт всегда укрепляет социальную связь лучше переписок. ⏩ Писать бывшим коллегам по вопросу работы – нормально. Любой формат: от «Вот и я пишу тебе спустя 2 года с вопросом о работе 😁» до юморного «Привет, спишь?» комфортен, если это ваш стиль. Я сама по долгу профессии часто бываю на той стороне, кому пишут. Никаких грешных мыслей об адресантах не возникает, честно! А если кто и подумает что-то о вас – пусть. Это говорит лишь о них. Зато вы действуете, пока другие осуждают. И важно: пусть всё это будет в гармонии с вашими ощущениями. А если захотите попробовать себя в реальном интервью с рекрутером (прям реальном, без поблажек) и понять цель вопросов в стиле «расскажите про свой факап» и ожидания от него – я тут ✋

RAG в DevOps: смотрите запись вебинара и приходите на курс по AI Коллеги, хочу поделиться с вами записью вебинара по RAG, который мы провели в среду После вебинара я еще раз убедился: AI — это не будущее, а настоящее DevOps. В магистратуре тоже много говорят про LLM, слушаю с большим интересом. И если вы, как и я, хотите не просто следить за трендами, а реально внедрять AI в свою работу — очень рекомендую обратить внимание на курс Слёрма «AI в DevOps», который стартует 20 октября (‎возможно, я тоже пойду) Лично мне импонирует практический подход — здесь не будет сухой теории, только реальные инструменты и кейсы, которые можно сразу применять в работе. Я сам планирую углубиться в тему, потому что вижу, как это может упростить рутину и ускорить процессы. ⏩ Посмотреть запись вебинара: YouTube VK Видео Rutube ➡️ Узнать о курсе «AI в DevOps» — по ссылке

Нас уже 5000! 💥💥💥 Коллеги, канал вчера переступил отметку 5000 подписчиков — это супер круто! Хочу сказать спасибо каждому из вас за: - Ваши вопросы в комментариях - Активность и честную обратную связь - Совместное обсуждение сложных тем - Поддержку друг друга Для меня этот канал — не просто цифры, а настоящее комьюнити единомышленников. Особенно кайфово видеть, как вы помогаете друг другу в комментариях и делитесь опытом Дальше — больше!🥂

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 :)

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