Привет!)
Расскажу немного о себе
Меня зовут Владимир @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 =)
Диагностические утилиты, точно стоит оставить за бортом =)

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

В образе ничего лишнего быть не должно, а как дебажить то?!?!?!?!

Так как мы в моем канальчике будем говориться в основном про k8s, то на дебаге внутри pod`а мы и остановимся.
На помощь нам придет ephemerial containers который позволит нам подключиться к pod`у и посмотреть что там происходит.
Ephemerial-containers с нами с 1.25 версии.
Работают они следующим образом, у нас есть pod нашего приложения, в котором нет буквально ничего, кроме как самого приложения.
Даже оболочки там может и не быть, да и мы можем достаточными параноиками, что бы по-серьезному накрутить безопасность.
Ephemerial-containers позволяют нам добавить в наш pod еще один контейнер, который будет работать параллельно с нашим приложением.
И как раз в этом контейнере могут быть все необходимые утилиты для дебага.
Как это может выглядеть на примере. Все эксперименты проводятся на k8s 1.28.3, запускаем при помощи minikube.

Для начала запустим под нашего приложения:

apiVersion: v1
kind: Pod
metadata:
  name: simple-app
spec:
  containers:
  - name: simple-app
    image: mrgreyves/simple-app:0.3
    env:
      - name: VERSION
        value: "1"
    ports:
    - containerPort: 8000

После того как наш pod "поднимется" мы сделаем describe и увидим следующее
(нас интересует только раздел containers):

Containers:
  simple-app:
    Container ID:   docker://94339c2434b41ab2dc3b12e002f3d694f9aeeda60bd375851ddbc68997fecad4
    Image:          mrgreyves/simple-app:0.3
    Image ID:       docker-pullable://mrgreyves/simple-app@sha256:704a51301a1ab21b32f736c3d9db15cbfe2fe311b525a9e6e397c9195baeb33d
    Port:           8000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 17 Dec 2023 14:49:31 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      VERSION:  1
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c7f75 (ro)

В pod`e запущен только одни контейнер, пришло время добавить ephemerial-container для дебага.
Вполнить это мы можем следующей командой.

kubectl debug -it --attach=false simple-app --image=praqma/network-multitool --target=simple-app

Где первый simple-app это имя пода к которуму мы хотим добавить ephemerial-container, а второй simple-app это имя контейнера внутри pod`а к которому мы хотим подключиться.
praqma/network-multitool - образ со всем необходимым тулингом для дебага.

Повторно выполняем describe и видим следующее:

Containers:
  simple-app:
    Container ID:   docker://94339c2434b41ab2dc3b12e002f3d694f9aeeda60bd375851ddbc68997fecad4
    Image:          mrgreyves/simple-app:0.3
    Image ID:       docker-pullable://mrgreyves/simple-app@sha256:704a51301a1ab21b32f736c3d9db15cbfe2fe311b525a9e6e397c9195baeb33d
    Port:           8000/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 17 Dec 2023 14:49:31 +0300
    Ready:          True
    Restart Count:  0
    Environment:
      VERSION:  1
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c7f75 (ro)
Ephemeral Containers:
  debugger-v658k:
    Container ID:   docker://6813011cff1f7dd68758d9476a4c7237ba00b3e6c8e6e8e3094dfce6485ae936
    Image:          praqma/network-multitool
    Image ID:       docker-pullable://praqma/network-multitool@sha256:97b15098bb72df10f7c4e177b9c0e2435ec459f16e79ab7ae2ed3f1eb0e79d19
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Sun, 17 Dec 2023 14:52:52 +0300
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>

Теперь у нас два контейнера =)
Ну а подключиться ко второму контейнеру мы можем вот так:

k exec -it simple-app -c debugger-v658k -- bash

Вжух и мы внутри нашего debug контейнера, внутри которого есть все нужные нам инструменты.
Порой полезная вещь, рекомендую к использованию ^_^

Пссс, парень, немного "ускорения" не желаешь?

Сегодня хочу рассказать про одну интересную книгу, а именно "Ускоряйся! Наука DevOps : Как создавать и масштабировать высокопроизводительные цифровые организации"
(Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)

Несмотря на то что книга была написана в 2018 году, она не теряет актуальность и сейчас.
Если кому то сложно читать на английском, то есть перевод на русский язык.
В ней описаны основные принципы DevOps, а также приведены примеры реализации этих принципов в реальных компаниях.
В ней достаточно много примеров и, что важно, описаны они достаточно понятно.
Много про метрики как бизнеса, так и приложений. Ну и не забываем про культуру DevOps и вцелом роль "айтишечки" в больших организациях.
К прочтению рекомендую ^_^

Достать вы ее сможете сами, вы же сильные мальчики и девочки =)

Что делать если нужен k8s запущенный локально?

По долгу службы я тестирую достаточно много "новых штук".
И достаточно часто я делаю это локально, на своей машине.
Речь сейчас пойдет про запуск k8s локально.

Какие есть инструменты для запуска:

- minikube - отличный инструмент, пользуюсь им давно, есть множество вариантов запуска, драйверов, плагинов и т.д.

minikube start --cpus 6 --memory 8192 --kubernetes-version=1.28.3 --cni=calico --driver=hyperkit.  

На выходе получим k8s версии 1.28.3, с сетевым плагином calico, а hyperkit это как раз драйвер для запуска в MacOS (k8s будет внутри ВМ).

- kind - весьма неплохой инструмент, умеет в достаточно расширенный конфиг, декларативное описание конфигурации, и так как
кластер запускается в docker-контейнерах все это можно запустить в условной CI/CD пайплайне.
Пример описания кластера:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  image: kindest/node:v1.21.10@sha256:84709f09756ba4f863769bdcabe5edafc2ada72d3c8c44d6515fc581b66b029c
- role: worker
  image: kindest/node:v1.21.10@sha256:84709f09756ba4f863769bdcabe5edafc2ada72d3c8c44d6515fc581b66b029c

Ну и запустить мы можем следующей командой:

kind create cluster --config kind-config.yaml

- Не забываем о том что в Docker Desktop тоже есть возможность запуска k8s кластера, но его я не использовал ниразу ^_^
- Что еще - k3s, k0s, k3d, orbstack, etc.

Ну а что использовать - решать только вам =)
UPD - minikube, kind я запускал на маке x86

Всем, привет! =)

Прерываю пред/пост новогоднее молчание ^_^

Примерно как и Иван Василич я начал свой первый спринт в этому году

А самое интересное в этом то, что самая веселая таска в этом спринте - это обновление кластера k8s с elasticsearch внутри аж на 3 версии

Индексы в эластике не большие, эластик используем для полнотекстового поиска всяких штук в нашем мобильном приложении

Чуть больше деталей:
Elasticsearch мы крутим при помощи ECK operator

Конфигурируем при помощи ECK Custom Resource operator

В целом, в таком сетапе, гонять elk в нутри k8s достаточно приятно, проблем не замечали =)

Самое сложно в таком обновление было, обновлять через 3 версии k8s, и каждое обновление должно быть плавным.

То есть:
— обновили мастера
— создали новую нод группу, перенесли доп тулинг (Prometheus, Alertmanager, Certmanaget, NodeLocalDNS, Cert-updater, etc.)
— создали новую нод группу, перенесли ПО ОДНОМУ мастеру elasticsearch
— создали новую нод группу, перенесли ПО ОДНОЙ data ноде elasticsearch (в промежутках проверяя что с кластером и индексами все ок, все зеленое)
На все про все чуть более 6 часов, за один заход =)

Мораль этой истории в том, что обновляйтесь регулярно, не откладывайте на потом =)

Всех с пятничкой, коллеги ^_^

Немного ранее я рассказывал про свои приключения с обновлением кластера k8s с elasticsearch на борту
Пришло время рассказать как мы обновляем кластера с нашими backend-сервисами
Какие у нас есть особенности:
- у нас есть возможность делать кластера достаточно большими, не только на момент обновления
- все backend-сервисы у нас stateless (они не хранят свое состояние), даже если у них есть RabbitMQ, Redis, etc. - об этом мы заранее договорились с разработкой. Если нужно какое то хранение состояния (база, очередь), все необходимое выносится за пределы кластера k8s и берется managed в облаке (кстати у нас Ya.cloud)

Дизайн кластеров:
- мультимастер - мастера размазаны в разные зоны доступности (A,B,C)
- минимум 2 нод группы для приложений в зонах A и B с автоскейлингом
- может быть дополнительная нод группа для “определенных” задач

Первое с чего мы всегда начинаем, это проверка “что у нас там с API k8s? нет ли чего то удаленного в API?”

Для этого мы используем утилитку pluto от FairwindsOps
После проверки:
- Все хорошо - можно смело обновляться
- Есть какие то замечания - обновляем какие то компоненты, в общем решаем проблемы с API

Обновление происходит в несколько этапов:

1 - обновляем мастера на +1 версию
2 - добавляем новую нод группу с +1 версией в нужной нам зоне (A или B )
3 - “кордоним” все ноды в кластере
4 - первую/обновляемую нод группу “фиксируем” по размеру, что бы не начали создаваться новые ноды со старой версией k8s (напоминаю что у нас автоскейлинг)
5 - “дрейним” первую/обновляемую нод группу
6 - проверяем по телеметрии что все ок и все работает
7 - при необходимости - повторяем

Не раз уже делаем так и все ок ^_^

PS - RMQ, Redis, etc. внутри k8s у нас в кластерном режиме и PV. Но относимся мы к ним все равно как к стейтлесс сервисам. И как мы знаем (надеюсь что вы знаете), PV не реплицируются между зонами я Ya.Cloud, по этому мы обновляем зону за зоной, что бы “подики” могли примонтировать свои PV.

PSS - однажды я вам расскажу про то как мы меняли сетевой плагин в кластере, спойлер - ухххх было весело =)

Что там с fluxcd?

Коллеги, всем привет!)
Проскочила тут в интернетах вот такая новость

Если вкратце - у Flux проблемы, большинство разработчиков либо ушли, либо “навострили лыжи”, в том числе и Stefan Prodan который является мейнтейнером FluxCD

И тут мы резко всей командой задумались - “А что делать если FluxCD падет смертью храбрых?”
У себя FluxCD мы используем для бутстрапа и конфигурирования k8s кластеров как основной инструмент

Пути тут, казалось бы, два:

- FluxCD - опенсорс и имеет достаточно большое комьюнити, активных разработчиков там достаточно, даже если кор мейнтейнеры уйдут, по идеи проект подхватят и он продолжить жить/развиваться
- Если FluxCD все таки “погибнет” нам точно придется искать альтернативу, и “десять девяток”, что выбор падет на ArgoCD (развивается он семимильными шагами и мы уже местами его используем)

Несмотря на то что FluxCD мы любим и умеем, периодически с ним были и свои “приколы”:

- Как же было весело когда FluxCD прыгнул из 0.4 в 2.0.0 практически без совместимости
- Зависимостями управлять там ооочень не тривиально

Как говориться посидим посмотрим ^_^

PS - ArgoCD (а точнее Argo Rollouts) мы используем в связке с Istio Service Mesh и Prometheus для организации Canary Deployment и я об этом точно напишу =)

Коллеги, привет! =)
Готовлюсь к внутреннему митапчику и буду рассказывать как мы считаем DORA-метрики
Есть у меня такой слайд
Как вам?=)
Если понравился и ты понял о чем он, ставь - 🔥
Если не понял, ставь - 👍
Ну и всем хорошего понедельника ^_^