Раньше у Слёрма было два варианта обучения: интенсивы и видеокурсы. Но участники не проходили курсы до конца и мы стали думать, как помочь. Ввели формат прохождения в группах с куратором и сразу увидели результаты.
Как куратор помогает не отложить очередной видеокурс на полку, рассказали три наших эксперта.
Спикер курса «Python для инженеров», Денис Наумов, поделился своим пониманием DevOps с двумя примерами из практики: собственной и коллег.
DevOps-инженер Константин Кулишов рассказал, как создал свой ChatOps, чтобы дать разработчикам возможность вносить изменения в проект в любое время. Константин выложил ChatOps на GitHub и подробно описал процесс создания.
DevOps-инженеры компании inDriver Радик Сейфуллин и Александр Плотников распилили старое монолитное приложение и создают новое, а Евгений Бутырин, технический редактор Слёрма, пообщался с ребятами об этом: опыте с Kafka, проблемах, решениях и обучении.
Фото Florencia Viadana, Unsplash.com
После почти пятилетних разработок протокол HTTP/3 наконец приближается к окончательному выпуску. Предыдущие итерации уже доступны как экспериментальная функция, но в 2021 году мы ждём широкого распространения протокола. Что такое HTTP/3? Зачем выпускать его так рано после HTTP/2? Как его можно или нужно использовать? Как он влияет на производительность?
1 октября начнется Вечерняя Школа Kubernetes для разработчиков от Слёрма при поддержке Mail Cloud Solutions и Intel. 24 онлайн-лекции и 22 практические работы в кластере MCS, и все это бесплатно.
Научим использовать преимущества и учитывать ограничения Kubernetes, поднимать инфраструктуру для тестирования и экспериментов, выкатывать и эксплуатировать сервис не дожидаясь команды DevOps. Сможете быстро спасти продакшн и влиять на успешность сервиса, уменьшая time-to-market.
В преддверии запуска Вечерней школы по Kubernetes, в этот раз для разработчиков, подготовили интервью с Павлом Селивановым архитектором в Mail.ru Cloud Solutions и Марселем Ибраевым CTO Слёрма. Речь пойдет о том, какие конкретно знания нужны разработчику в компаниях с Kubernetes, Павел и Марсель поделятся кейсами из своей практики.
Фото Bertrand Bouchez, Unsplash.com
В прошлой статье мы с помощью Prometheus AlertManager настроили правила, чтобы отправлять уведомления через Slack при срабатывании алертов. И хотя алерты и уведомления — это удобно и полезно, сами по себе метрики не до конца объясняют проблему. Они просто показывают, что значения одного экземпляра вышли за установленные лимиты, но в распределённых системах метрики не могут отследить запрос, который проходит через несколько компонентов. С распространением микросервисов системы усложняются, поэтому мы должны проследить весь путь запроса, чтобы понять, что пошло не так. Для этого можно использовать распределённую трассировку, которая записывает действия, выполняемые в связи с запросом, и дает контекст, который мы не найдем в метриках и логах.
В этой статье мы расширим возможности observability (наблюдаемости) приложения — создадим спаны (span) и экспортируем их в распределённую опенсорс-систему Jaeger. Но сначала разберемся, что такое трейс.
Иван Чувашов, DBA Okko и Southbridge, поделился жизненными кейсами с PostgreSQL, которые помогут решить ваши проблемы.
Разберем случаи из PostgreSQL: запросы в статусе idle in transaction, выключенные контрольные суммы данных, переполнение int4, убивающие базу временные файлы и загрузку CPU.
Фото Ricardo Gomez Angel, Unsplash.com
В предыдущей статье мы задеплоили оператор Prometheus с помощью helm-чарта и на примере набора сервисов увидели, как можно собирать метрики через prom-client и экспортеры. Как вы помните, цель observability (наблюдаемости) — узнать статус системы, поэтому нужные люди должны получать уведомления, когда значения метрик выходят за установленные пределы. Для этого надо настроить алерты.
Стажёрскую программу в Southbridge мы запустили три с половиной месяца назад, чтобы найти новых коллег и поделиться знаниями и опытом с теми, кому интересно развиваться в DevOps-направлении. За это время на стажировку было принято 54 начинающих инженера, большая часть из них ещё проходит программу. Первый поток завершен, в этом посте делимся итогами и историей Михаила Снеткова, который теперь работает в одной из команд Southbridge.
В первом потоке стажёрской программы участвовало девять специалистов. До конца дошло шесть. Михаил Снетков получил оффер в Southbridge, Александр Зольников — в Слёрм, еще три инженера получили офферы в другие компании во время стажировки.
Привет, Хабр! Мы, командой Слёрм, 21–22 августа 2021 года проводим обучение по Terraform.
Обучение пройдёт в онлайне, задать вопросы спикеру можно будет в Zoom, чате курса в телеграм, а практические задания выполняются в инфраструктуре AWS, каждый участник получит доступ к стендам. На интенсиве 7-8 заданий, каждое задание примерно на полчаса, то есть 4 часа практики из 10 часов интенсива.
В Bestmile мы используем Terraform для AWS IaC. Но чем больше развивалась наша инфраструктура, тем запутаннее становился код Terraform.
Код Terraform стало сложнее обслуживать. Он терял эффективность. Terraform — отличный инструмент, но нуждается в дополнениях. Здесь-то и пригодится Terragrunt.
Terragrunt — это обертка (wrapper) для Terraform, которая расширяет его функционал и устраняет некоторые ограничения. Terragrunt взаимодействует с Terraform с помощью кода HCL (HashiCorp Configuration Language), поэтому Terragrunt будет выполнять код Terraform в зависимости от того, как вы определите код HCL. Именно он дает дополнительные преимущества, как описано ниже, и превращает Terragrunt в волшебный инструмент.
Фото ETA+, Unsplash.com
Представьте себе человека, который бьется над решением загадки, а вокруг собралось с десяток советчиков, которые помогают ему «найти убийцу». Знакомая ситуация? В таких случаях возникает больше вопросов, чем ответов, и если отвечать на все эти вопросы, ни на что другое времени уже не останется.
Сложно найти то, чего не знаешь и не понимаешь. Вот тут-то на помощь и приходит observability (наблюдаемость). Она помогает понять, что сломалось или плохо работает, и даже позволяет найти причину, чтобы вы могли постоянно вносить улучшения.
Под observability мы подразумеваем показатель того, насколько эффективно можно определить внутреннее состояние системы по ее выходным данным (телеметрии). Ничего нового в этом нет — мы пытаемся разобраться в работе приложений по логам с начала времен, но сейчас все осложняется облаками, контейнерами, микросервисами, многоязычными средами и т. д.
Observability основана на трех главных компонентах. Это данные телеметрии, которые можно агрегировать и анализировать, чтобы понять состояние системы:
В этой серии статей мы рассмотрим все три компонента с примерами. Начнем с метрик и опенсорс-проекта Prometheus.
Статья подготовлена на основе уроков из открытой темы "Установка LEMP стека с помощью Ansible" курса по Ansible от Слёрм. Автор – Всеволод Севостьянов, Lead Engineer в Vene.io (Affiliate marketing solution). Первые две темы курса доступны на Youtube.
Материал этого урока будет интересен тем, кто разобрался с установкой Ansible и готов написать свой первый плейбук. Результатом будет плейбук, устанавливающий nginx на удалённой машине.
Все мы знаем про микросервисы и проблемы, возникающие между этими сервисами. Укрепился за последние годы и один из подходов к решению проблем – service mesh.
Слёрм проводит второй интенсив по service mesh, на котором спикеры помогут понять необходимость внедрения и подготовиться к нему без костылей в архитектуре.
В этом году это будет последний онлайн-интенсив по service mesh, стартуем 24 сентября.
Kubernetes API развиваются и периодически обновляются. Когда готов улучшенный API на замену старому, старый удаляют. См. политику Kubernetes по удалению API.
Скоро будет удалено несколько API. Это беты, которые еще можно использовать в текущих версиях Kubernetes, но они уже deprecated. Им на смену придут обновленные стабильные версии API ("GA", General availability).
В Kubernetes 1.22 (релиз ожидается в августе 2021 года) будет удалено несколько deprecated API. На странице релиза Kubernetes 1.22 можно посмотреть его график.
Павел Селиванов почти 3 года прожил на Балканах. Сначала в Черногории, потом в Сербии. Мы побеседовали с Павлом, и он рассказал о жизни в Европе, черногорских квартирах и сербской кухне, а еще почему баня с пельменями — это вам не СПА с равиоли.
Фото Cenk Batuhan Özaltun, Unsplash.com
На конференции QCon в марте я рассказывал об эволюции распределённых систем в Kubernetes. Главный вопрос: что будет после микросервисов? У вас наверняка есть мнение на этот счет. У меня оно тоже есть. В конце вы узнаете, что я думаю. Но для начала давайте обсудим потребности распределённых систем. Как эти потребности развиваются с годами, начиная с монолитных приложений до Kubernetes и таких новых проектов, как Dapr, Istio, Knative, и как они меняют наши методы работы с распределёнными системами. Попробуем сделать несколько прогнозов на будущее.
