Привет!)
Расскажу немного о себе
Меня зовут Владимир @Mrgreyves
Работаю тимлидом в Magnit Tech, где стараюсь нанести побольше пользы =)
Веду лекции и выступаю на митапах
Когда нибудь начну писать статьи, но это не точно (c)
В этом году умудрился отметиться на паре-тройке митапов и подкастов
Рекомендую к просмотру
Yandex Kuber Conf 2023
Магнитное поле №6 – Что такое InnerSource и зачем он нужен IT-компаниям
DevOops Conf 2023 - Эффективное управление инфраструктурой

7 декабря 2023
Буду на оффлайн митапе в Selectel
Трансляция так же будет
Расскажу как можно организовать Service Discovery в связке Hashicrop Consul и Prometheus
Приходи, будет интересно

И в продолжение темы про Observability и все вот эти штуки
В 2022 году на DevOps Conf рассказывал как мы у себя его и строили
Получился у нас достаточно большой комбайн, который мы в дальнейшем стали распространять по другим домена Magnit Tech
Видео доклада тут
Если вы предпочитаете читать, то расшифровка тут
ЗЫ - материал полностью актуален на 2022 год, но в 2023 году многие вещи были переосмыслены и координально перестроены, однажды я расскажу об этом =)

Если вы любите подкасты и хотите узнать что-то новое
Особенно внутри Magnit Tech
Рекомендую посмотреть выпуск подкаската "Магнитное поле" с Юрием Мисников (CTO)
и Татьяной Коваль (Директор по архитектуре и инфраструктуре)
Коллеги рассказывают как все устроено у нас и делятся своим опытом
https://youtu.be/khDzaLQdcr0

Скоро начнётся митап
Кто в Питере, приходите
Ссылку на трансляцию приложу позже

https://www.youtube.com/live/HQntkIDRjC4?si=z-npH1mxf9cAHNTU
А вот и ссылка на трансляцию, присоединяйтесь
Я выступаю после 20-00

По следам Selectel Admin Meetup: GitOps
Антон рассказывал о том как они готовят ML инфраструктуру для клиентов

Что хочу отметить сразу:
- интересно посмотреть как ресурсы связаны между собой
- как ресурсы упакованы в pipeline и как он вызывается

Был интересный вопрос о том, а что будет если Gitlab, который является
источником правды упадет?

Тут достаточно все просто - падание Gitlab не так страшно, так как в
моменте на "скорость полета" это не повлияет. Все ресурсы уже созданы.
Если надо что-то обновить/добавить, а Gitlab "валяется", станет несколько сложнее.
Думаю что команда которая отвечает за Gitlab как сервис вполне себе озаботилась
и отказоустойчивостью, и резервированием, и резервными копиями.
А вот потеря terraform state со всеми его ресурсами - это уже беда.
Так как частей инфраструктуры которые были созданы при помощи terraform много.
Соотвественно state нужно бекапить, часто, в надежное место, и иногда еще и проверять.
"Секретные данные" которые используются в Gitlab pipeline, скорее всего хранятся в Vault,
так что его отказоустойчивостью тоже стоит заняться.

Из несовсем очевидных историй, которые стоит подсветить, это то что количество downstream pipeline не бесконечно и в определенных случаях, когда вложенность pipeline становится больше 3х,
все это может сломаться =(
Мы в своем infra pipeline как раз с этим и столкнулись, решение вроде и простое, переделать структуру репозитория, но достаточно трудоемкое.

Что еще можно посмотреть/интегрировать:
- Terragrunt - как раз таки позволит переиспользовать код и добавить ооочень крутую шаблонизацию
- Atlantis - возможно тоже стоит посмотреть, выглядит так что он достаточно просто интегрируется с CI/CD системами

Антон, спасибо большое за доклад, было очень интересно! ^_^
А в этом посте просто мои рассуждения =)

Презентация Антона тут

Если вы любите подкасты и воскресным вечером вам стало скучно.
Рекомендую посмотреть/послушать 12 выпуск подкаста "Магнитное поле"
Мой коллега Антон Огородников рассказывает как у нас устроена разработка,
какие подходы мы используем и тд.
А еще он рассказывает про PaaS и весь наш туллинг для разработчиков.
В разработке которого я, в том числе, тоже принимаю участие ^_^

Сам подкаст можно найти тут

По следам Selectel Admin Meetup: ChatGPT
Маша рассказывала о том как ChatGPT помогает в инфраструктурной разработки

Что хочу отметить сразу:
- хорошо что были добавлены промпты и результаты ответов
- разбор истории ожидания vs. реальность
- акценты на том как стоит использовать различные ИИ "помогаторы"

Полностью согласен с Машей в том что ChatGPT это не панацея, а скорее дополнительный инструмент.
Он врятли решит за тебя поставленную задачу, но может, вполне себе, подкинуть пару-тройку идей.
Насколько часто я пользуюсь ChatGPT?
Не часто, хотя вчера он мне помогал с конфигурированием echoprometheus middleware ^_^

Был интересный вопрос о том, на каких датасетах, то есть данных, учить различные ИИ что бы он,
в инженерном плане, стал сильно умнее?
Конечно же в "интернетах" есть большое количество весьма неплохих примеров решения тех или иных задач.
Но самый крутой код, наработки и тд конечно же внутри компаний, в закрытых контурах и щедро смазанный NDA.
Если такие компания хотят своего ИИ "помогатора" выход для них это только selfhosted модели и дообучение
на своих датасетах.

Что еще можно посмотреть:
- LocalAI - сборник ИИ альтернатив ChatGPT которые можно запустить локально хоть на своем ноуте

Маша, спасибо большое, было круто ^_^
А в этом посте просто мои рассуждения =)

Презентация Маши тут

По следам Selectel Admin Meetup: Prometheus Service Discovery
Пришло время рассказать о своем докладе =)

Кажется что удалось раскрыть тему и она оказалось вполне себе нужной.
После митапа ребята говорили что некоторым из них уже пора строить что-то подобное
и инфа из моего доклада им как раз подойдет.
Надеюсь что "нормально" ответил на все вопросы из зала =)

А вот что я упустил, так это историю с DrillDown dashboard, про которую были вопросы.
Да и по количесту рук было видно что не все знают что это за подход и точно не пользуются им.
Постараюсь это исправить, в планах как будет чуть больше свободного времени,
собрать небольшой стенд который как раз и позволит раскрыть историю с DrillDown dashboard.
Пока что в голове идея о том что этот стенд должен быть с использованием Docker, что бы
каждый мог запустить его локально и что-то потыкать.
Как стенд будет готов, обязательно сделаю отдельный пост.

Моя презентация тут

Среда сборки != Среда выполнения => или про то, о чем стоит помнить во время сборки Docker образов

За всю свою инженерную бытность я повидал всякое, особенно в Dockerfile`ах.
Там были и ssh сервера, и MSSQL Server, и systemd, и много чего еще.
Всегда стоит помнить о том, что в готовом образе должна должно быть только ваше приложение и только те библиотеки и зависимости, которые необходимы для его работы.
Такая история хорошо ложится на компилируемые языки программирования, а именно на многими любимый Golang.
Мы вполне можем применить multistage, в котором соберем наш "бинарь" в образе в котором есть все необходимое
для сборки, а дальше мы наш бинарь отправим в более легковесный образ, например, в Alpine.
По итогу мы получим небольшой образ, в котором нет ничего лишнего.
Его достаточно просто распространять, да и вектор атаки существенно ниже.
А еще мы можем "конкретно угореть" и собрать образ на базе scratch =)
Диагностические утилиты, точно стоит оставить за бортом =)

Не забывайте про это ^_^