Всех, кто ответил неправильно (или колебался при выборе ответа), приглашаю на курс Слёрма «Docker для админов и разработчиков».

Чему вы научитесь:

➡️ Использовать Docker для разработки микросервисов
➡️ Упаковывать в Docker образы приложения, основанные на разных языках
➡️ Управлять сетями в Docker
➡️ Обеспечивать безопасность ваших контейнеров
➡️ Контролировать контейнеры и образы с помощью Docker CLI

В конце курса вы попробуете себя в роли дежурного инженера, отвечающего за внутренний Docker-сервер компании.

Это не продакшен, но задачи — вполне реальные: обеспечить рабочую среду для разработчиков, разобраться с контейнерами, восстановить процессы, если что-то пошло не так.

Старт — 21 июля. Подробности ➡️ на странице курса.

Почему возникает путаница с auth_config.json?

Да, коллеги, я тоже ошибся. Спасибо, что заметили! Подумаю насчет курса по докеру 😅

Термин auth_config часто упоминается в документации Docker API как структура данных (не файл!). В Docker SDK (Python/Go) объект auth_config используется для передачи логина/пароля программно.

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

➡️ В итоге:
Для повседневного использования (CLI): данные хранятся только в ~/.docker/config.json. Правильный вариант — третий.

Файл auth_config.json — это всегда ручная кастомная реализация (например, для скриптов или CI). Docker CLI его автоматически не создаёт и не читает.

Зачем DevOps-инженеру мониторинг, если всё и так работает?

В проектах вопросы мониторинга часто откладываются на потом, но по важности эти процессы точно одни из первых. Мы делаем мониторинг и логирование не для того, чтобы узнать о проблеме ночью и быстрее починить, а для того чтобы коллеги SRE и разработчики быстрее получали фидбек о том, что приложение изменило свое поведение.

⭐️ 23 июля приглашаю вас на вебинар, на котором будем обсуждать:

➡️ Как выбрать мониторинг под свой проект: от простых решений до продвинутых систем — поэтапный разбор на реальных кейсах

➡️ Что используют крупные компании: подход к мониторингу в распределённых командах и на общих ресурсах (по опыту спикера)

➡️ Нужен ли сложный мониторинг всем: обсуждаем, кому подойдёт простой стек, а где без Kafka, Prometheus и алертов не обойтись

➡️ От логов к бизнес-индикаторам: зачем DevOps-инженеру понимать, что важно бизнесу и как это мониторить

➡️ Типовые ошибки при внедрении мониторинга: что ломает стабильность, и как не утонуть в алертах

Специальный гость: Станислав Левин, Senior DevOps\SRE, underlay kubernetes infra team

Когда: 23 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.

Неочевидные проблемы Kubernetes, которые вы могли пропустить

↘️ бесплатный вебинар через 15 минут.

Ведущий: Виталий Лихачев, SRE в крупнейшем голландском тревелтехе
Спикер: Руслан Гайнанов, главный инженер DevOps, T1 Иннотех

Вместе они разберут типовые ошибки, которые можно допустить при деплое сервисов в кластер, от некорректной настройки лимитов ресурсов, до более сложных кейсов с admission webhooks.

🟠 В конце вебинара — рекомендации по настройке вашего кластера и приложений для безотказной работы.

Когда: 16 июля в 19:00 мск

➡️ Занять место на вебинаре — через бота.

Если пайплайн всегда зеленый, это не значит, что он эффективный.

На что стоит смотреть в первую очередь:

🪩 Узкие места

Сколько длится build? Какие тесты можно распараллелить? Какие шаги убрать?

🪩 Скрытые риски

Есть ли rollback на случай, если прод рухнет? Что будет, если закончатся лимиты раннеров?

Другие важные нюансы:
➡️ Сборка и деплой должны быть отделены
➡️ Переменные окружения и секреты не должны хардкодиться
➡️ Конфиги должны быть читаемы и понятны
➡️ Обязательно присутствие промежуточных проверок, а тесты должны запускаться без полного прогона пайплайна

В хорошем пайплайне новый разработчик разберется без месячного онбординга.

Как сделать пайплайн поддерживаемым, а процесс быстрым и предсказуемым, рассказываю на CI/CD-практикуме — начать учиться можно в любой момент.

Подробности — по ссылке.

Что спросить у работодателя на интервью?

Подготовил чек-лист вопросов, которые помогут понять, насколько компания и команда вам подходят.

➡️ О работе и проектах
- Как выглядит типичный день DevOps-инженера у вас?
- Какие актуальные боли в инфраструктуре или процессах нужно закрыть в первую очередь?
- Можете показать примеры задач, которые будут в моем бэклоге? (Например: поднять кластер k8s, настроить мониторинг, перевести деплой на GitOps?)

➡️ О развитии и грейдах
- Какие хардскиллы критичны для этой роли? (Terraform? Ansible? Golang?)
- Выделяется ли бюджет на курсы/сертификации (AWS, Kubernetes, etc.)?
- Есть ли карьерный трек от мидла до сеньора/архитектора?

➡️ О метриках и испытательном сроке
- Какие KPI будут в первые 3/6/12 месяцев? (Например: снижение downtime на 20%, автоматизация N% деплоев?)
- Что закроет испытательный срок? (Реальный пример: «Настроите CI/CD для двух сервисов»)

➡️ О команде и процессах
- Кто будет моим тимлидом/ментором?
- Сколько человек в команде? Как распределены зоны ответственности?
- Как устроен онколл? Есть ли компенсация за дежурства?

➡️ О культуре
- Как принимаются решения по инфраструктуре? (Советы архитекторов, голосование, единолично CTO?)
- Dev vs Ops — есть ли конфликты? Как вы их решаете?

➡️ Финал
- Нужны ли вам дополнительные данные от меня? (Ссылки на пет-проекты, разбор кейса?)
- Какие следующие шаги? Когда ждать фидбек?

Сохраните себе и не забудьте задать эти вопросы на следующем собеседовании.

#карьера

Коллеги, приветствую!

Вижу среди вас много новых подписчиков — добро пожаловать! Как насчет добить 5к?🙃

Хочу лучше узнать, кто находится по ту сторону экрана — чем вы занимаетесь, и на каком сейчас этапе. Ниже короткий опрос, жмите на свой вариант или напишите пару слов в комментариях ⬇️

Как развернуть HashiCorp Vault в Yandex Cloud

HashiCorp Vault — инструмент, который многие применяют, и сегодня я расскажу вам, как можно легко его развернуть в Yandex Cloud. Да, там его уже можно развернуть в ваш k8s просто выбрав из маркетплейса, но иногда хочется лучше.

➡️ В чем проблема развертывания Vault в k8s?

Vault хранит критичные секреты в зашифрованном виде, но после перезапуска требует ручную разблокировку (unseal). В k8s это рушит преимущества и наши любимые подходы автоматизации. Поэтому для того, чтобы автоматизировать этот процесс есть вариант развертывания еще одного «распечатывающего» Vault, и так можно значительно все усложнить. В Yandex Cloud есть KMS, и это поможет нам решить эту проблему.

🍀 За основу возьмем инструкцию для развертывания из маркетплейса:

1. Создаем сервис аккаунт
2. Создаем kms ключ
3. Назначаем сервис аккаунту роль для работы с kms

Чтобы поставить Vault из маркетплейса, нам больше ничего не нужно. Но так он развернется без души, то есть, без UI.

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

🍀 Чего в инструкции нет:

➡️ Нам потребуется заранее развернуть ALB контроллер, если он еще не был развернут в вашем кластере. Про это можно обсудить отдельно, но пока пропустим.

➡️ Создаем кластер postgres любым удобным способом: Если у вас terraform, то и пункты выше надо будет делать там, или можно к консоли сделать. Если у вас действительно стабильное решение и k8s уже распределен в разные зоны доступности, сделаем такой же postgres. Создаем также пользователя, базу.

➡️ Дальше по вкусу можно добавить сервис, чтобы вносить конкретный хост в конфиг, или что вам еще захочется. Добавим в секрет сертификат или возможно он там уже есть.

Сделал чарт, который может решить простую задачу: развернуть в Yandex Сloud HashiCorp Vault в отказоустойчивом варианте. Для этого взял чарт, который лежит в маркетплейсе, он является чуть измененным чартом для Yandex Cloud. Структуру немного поменял, убрал чарт в папку — мне так больше нравится, делать это необязательно.

Сделал разными коммитами, чтобы было вам удобнее смотреть, что изменилось:

1. Добавляю настройки для работы с ALB, так-же tls. Выключаю ненужное, включаю нужное. Настраиваю на использование с postgres.

2. Отдельным коммитом добавил ci — он совсем уж простой. Можете сделать любой удобный.

А теперь проверим вашу внимательность. Что я специально упустил? И какие еще решения можно считать спорными?

Честные вакансии: второму сезону быть

Весной мы с вами много говорили про карьеру в DevOps с экспертами из бигтеха и подробно разбирали требования индустрии со стороны работодателя.


🍀 Сейчас мы планируем запуск второго сезона, и хотим поговорить с вами — нашими студентами и подписчиками. Мы ищем DevOps-инженеров, которые готовы поделиться внутрянкой своей работы и рассказать про:

⭐️ грейд;
⭐️ обязанности;
⭐️ зарплатную вилку (можно с шагом 100 000₽).

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

➡️ Формат участия: короткое (примерно 15 минут) интервью под запись.
Ведущим второго сезона будет Сева Севостьянов, Staff engineer в Lokalise и спикер курсов Слёрма.

⭐️ Интервью пройдет в формате карьерной консультации — Сева будет задавать вам вопросы, подсветит ваши навыки и подскажет, куда двигаться дальше.

Интервью будут смонтированы и опубликованы на всех наших площадках.

Хотите стать частью проекта? Напишите Кате в телеграм, чтобы узнать подробности. Ждём ваших откликов!

#devops_middle

Зачем DevOps-инженеру мониторинг, если всё и так работает?

🍀 обсуждаем сегодня на бесплатном вебинаре!

Вместе со Станиславом Левиным, Senior DevOps\SRE, underlay kubernetes infra team мы обсудим:

➡️ Как выбрать мониторинг под свой проект
➡️ Что используют крупные компании
➡️ Нужен ли сложный мониторинг всем
➡️ Зачем DevOps-инженеру понимать, что важно бизнесу и как это мониторить
➡️ Типовые ошибки при внедрении мониторинга

Стартуем в 19:00. Ссылки на трансляцию, как всегда, будут в боте.

Всех жду!

⭐️Стартуем через 5 минут⭐️

Подключайтесь!

3 вопроса рекрутеру, которые спасут вас от токсичной компании в DevOps

Вы приходите на собеседование — офис стильный, HR улыбается, на столе печеньки и манго. Но через месяц понимаете: процессы разваливаются, команда меняется каждые полгода, а продакшн горит чаще, чем деплой.

👉 Как вычислить адскую текучку до того, как подпишете оффер? Задайте эти три вопроса:

1. «Как у вас проходит онбординг DevOps-инженеров?»
Если адаптация — это «разбирайтесь сами в наших 200 терраформ-модулях», бегите. В нормальных компаниях новичков не бросают в бой без подготовки.

🚩 Тревожные звоночки:

«У нас гибкий подход — коллеги помогут» (читай: никто ни за что не отвечает)

«Обычно инженеры быстро вливаются» (потому что те, кто не влился, ушли через месяц)

✅ Хороший ответ:
«Первые две недели — погружение в инфраструктуру и CI/CD, доступ к документации и ментору. Через месяц — проверочный проект (например, настроить мониторинг для тестового сервиса). Наставник сопровождает первые 3 месяца».

2. «Как изменился ваш DevOps-отдел за последний год?»
Резкий рост или сокращение — красный флаг.

🚩 Подозрительно:

«Команда выросла с 3 до 20 человек за квартал» → вероятно, админы превращаются в пожарных.

«Было 10 инженеров, осталось 4» → либо автоматизировали всё, либо бюджет режут, а выгорание растет.

✅ Адекватный вариант:
«Расширились с 5 до 8 человек — взяли еще двух SRE под нагрузку на k8s» или «Состав тот же, но перешли с самописных скриптов на ArgoCD и сократили рутину».

3. «Какие возможности для роста у DevOps в вашей компании?»
Если в ответе только «учитесь сами» — значит, карьера зависит только от вашего упорства (и везения).

🚩 Шляпа:

«У нас плоская структура, но можно прокачиваться» (но как? за чей счет? куда?)

«Карьера зависит от инициативы» (то есть никаких гарантий)

✅ Что хотим услышать:
«Раз в полгода — performance review с roadmap: например, переход от поддержки к архитектуре облака. Есть бюджет на сертификации (CKA, AWS) и внутренние митапы».

Если рекрутер туманно отвечает на эти вопросы — в компании либо хаос, либо менеджмент не ценит специалистов. А вам это надо?

🚨 Код красный: Аэрофлот атакован, небо — под вопросом

Работа авиакомпании «Аэрофлот» полностью парализована из-за взлома IT-систем. Отменены десятки рейсов, компьютеры в офисах и аэропортах выключены, корпоративные аккаунты заблокированы, работа идёт вслепую.

Группа хакеров Silent Crow взяла на себя ответственность, заявив, что они в течение года внедрялись в систему и устроили масштабную диверсию: уничтожили 7000 серверов и выгрузили более 22 Тб информации, от баз клиентов до внутренней почты, аудиозаписей совещаний и доступа к системам слежения за персоналом.

С момента падения прошло уже 4 часа, но критические сервисы до сих пор не ожили. Кажется, настало время задуматься о безопасности своих проектов…

Для тех, кто хочет пересмотреть свой подход к безопасности и встроить ее в процессы грамотно, мы создали:

⭐️ Видеокурс «Основы информационной безопасности»: учимся делать безопасный прод, обеспечивать секьюрность на самых начальных этапах и менять майндсет коллег.

Сейчас со скидкой 50% по промокоду LETO2025

⭐️ Интенсив «DevSecOps Bootcamp: безопасность для бизнеса»: 4 дня теории и неделя практики, чтобы выстроить единый подход к безопасности — от кода до эксплуатации — и внедрить его в процессы без потерь в скорости и качестве.
Старт интенсива — 11 октября.

Безопасность — это не набор инструментов для «галочки». Это культура и осознанный подход к выстраиванию процессов.

Сборка Docker-образов в 2025: Почему Kaniko уступает место другим инструментам

Эволюция сборки образов: Что изменилось?

Сборка Docker-образов давно вышла за рамки простого docker build. Требования к безопасности, мультиархитектурности (arm64/amd64), необходимость в скорости и воспроизводимости заставляют пересматривать инструменты. Kaniko, когда-то популярный за свою безопасность и то, что он не требует демона Docker, теперь теряет позиции. Почему?

Kaniko всегда имело определенные сложности:

➡️ Скорость сборки
Kaniko не поддерживает распределённое кеширование слоёв из коробки. При больших образах сборка выполняется дольше, чем у инструментов на базе BuildKit

➡️ Ограниченная мультиплатформенность
Для сборки под arm/amd нужны сложные костыли. В эпоху гибридных сред (AWS Graviton, Apple Silicon) это критично

➡️ Отладка
Логи Kaniko менее детализированы при ошибках

➡️ Сложность интеграций
Может требовать специфических настроек Kubernetes (например, монтирование Volume). В serverless-средах (GitHub Actions, GitLab CI) это избыточно.

Но появились новые сложности и репозиторий в архиве, почти 2 месяца назад.

Внедрять Kaniko на новые проекты смысла нет, и скорее всего лучше переводить с него старые.

Gitlab рекомендует использовать Dind (опять?) или использовать другие варианты.

🍀 Buildah — инструмент для бесдемонный сред.

В чем плюсы:

➡️ Безопастность
Не требудет docker демона, rootless сборка

➡️ Гибкость
Тонкий контроль работы над слоями. Монтирование контейнера при сборке

➡️ Совместимость
Работает и с Podman и в Kubernetes

Собирать мультиплатформенные сборки можно за счет ci. И тут можно посмотреть сам синтаксис.

Или рассмотрим другой интрумент:

Docker Buildx + BuildKit

➡️ Быстрая сборка
Кеширование слоев, параллельное выполнение инструкций

➡️ Мультиархитектурность
Один ключ
--platform linux/amd64,linux/arm6
создает мультиплатформенный образах

➡️ Безопастность
rootless режим, секреты при сборке

➡️ Экосистема
Инструмент Docker и нативная поддерка

Инструкции от gitlab и  отдельно как выполнить миграцию с Kaniko.

Это не все варианты которые работают несколько иначе. Есть Earthly, но тоже остановлена разработка. Можно использовать и Dagger. Но я так не пробовал, мне кажется в случае проблем с ним будет перейти сложнее чем с Kaniko.

Kaniko был революционным инструментом в 2018-2023, но в 2025 окончание его поддержки и наличие других инструментов изменили подходы

А расскажите что используете вы, на что перешли с Kaniko (если уже перешли).