DevOps -- это не сколько технология, сколько культурный сдвиг внутри команды.

В статье поговорим о том:
- Что не так в существующих "форматах" DevOps
- Как делать полезные для разработки Гайды
- Как как внедрить DevOps для всех членов команды
- Как делиться экспертизой

https://habr.com/ru/articles/920788/

#статья
#мнение

Организация инфраструктурного кода. Пост [1/2]

Недавно, на личном опыте столкнулся с тем, что команда не может организовать верхнеуровневую архитектуру для хранения и работы с инфраструктурным кодом.
Сегодня я бы хотел подробнее погрузиться в эту тему, и рассказать о том, как можно уложить инфраструктурные блоки по полочкам, и какие паттерны для этого существуют.
Пост поделен на две части. Сегодня мы поговорим о том, что такое инфраструктурный модуль, а также как этим модули могут выглядеть. В следующей части мы поговорим о том, как организовать работу с инфраструктурными репозиториями.
Поехали!

Модуль — это проект который описывает конфигурацию каких-либо инфраструктурных компонентов и их связи между собой. Деплоится как единое целое.

В данном посте, я намеренно даю такое общее описание модуля, чтобы его можно было рассматривать в отрыве от реализации (Terraform, Pulumi, Cloud SDK).

1. Monolith Module

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

Пример "Монолитного модуля"
Вся инфраструктура описана внутри одного проекта. В нём одновременно описаны вычислительные ресурсы, сети, хранилища, доступы и приложения. Всё хранится в одном или нескольких файлах. Нет разделения на логические блоки. Любое изменение требует работы с целым проектом.

infra/
├── database.yaml
├── main.yaml
└── vpc.yaml

2. Application Group Module

Application Group Module — Способ организации кода, когда инфра для всех сервисов команды помещается в один общий модуль.
Если ваше приложение состоит из нескольких микросервисов, и вы управляете их инфраструктурой с помощью одного модуля — у вас Application Group Module.
Если ваша команда разрабатывает несколько приложений, и вы управляете ими как одним целым — у вас Application Group Module.

Иметь Application Group Module привлекательно, потому что позволяет думать, обо всем приложении как о чем-то цельном, плюс, хорошо работает, если вся инфраструктура для приложения находиться в управлении одной команды.
Также, может быть хорошим промежуточным состоянием при "распиле" Монолитных Модулей.

Пример "Application Group Module"

infra/
├── team-a
│   ├── service-1
│   │   ├── db.yaml
│   │   └── main.yaml
│   ├── service-2
│   │   ├── db.yaml
│   │   └── main.yaml
│   └── service-3
│       ├── db.yaml
│       └── main.yaml
└── team-b
    ├── service-1
    │   ├── db.yaml
    │   └── main.yaml
    ├── service-2
    │   ├── db.yaml
    │   └── main.yaml
    └── service-3
        ├── db.yaml
        └── main.yaml

3. Application Module

Application Module — Данный способ организации кода, когда один модуль ограничивает одно приложение, или один микросервис.
Все, что нужно одному кокретному микросервису или приложению собрано в один модуль, без внешних зависимостей.

Идеально ложиться на микросервисную архитектуру приложений.
Ровно до тех пор, пока у вас не появится общесервисной шины, или у всех микросервисов как зависимость будет кластер Kubernetes...

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

Пример "Application Module"

infra/
├── microservice-1
│   ├── db.yaml
│   └── main.yaml
├── microservice-2
│   ├── db.yaml
│   └── main.yaml
├── microservice-3
│   ├── db.yaml
│   └── main.yaml
├── microservice-4
│   ├── db.yaml
│   └── main.yaml
└── microservice-5
    ├── db.yaml
    └── main.yaml

4. Service Module

Service Module — Способ организации кода, когда каждую сервисную часть для нашего приложения мы оборачиваем в отдельным модуль.
Например:

- Отдельный модуль для Базы данных
- Отдельный модуль для Application Server
- Отдельный модуль для сети
- Отдельный модуль для кеша и т.д.

Данный способ показывает самую высокую гибкость из всех возможных способов организации IaC. Дополнительно, ошибки при таком подходе будут влиять только на конкретное приложение.
При этом, из минусов данного подхода — Большое количество модулей привносит сложность само по себе.

Пример "Service Module"

infra/
├── db
│   └── main.yaml
├── ecs
│   └── main.yaml
├── iam
│   └── main.yaml
├── kubernetes
│   └── main.yaml
├── s3
│   └── main.yaml
└── vpc
    └── main.yaml

#iac
#личный_опыт
#мнение

#k8s
#meme
Эх... Если все было так просто

Организация инфраструктурного кода. Пост [2/2]

Продолжаем разговор о том, как сделать разделение IaC более логичным.
Как же организовать код с модулями по репозиториям?
Монорепа? Гит модули? Микро-репозитории?
Давайте разбираться!

1. Моно-репозиторий
Вся инфраструктура — в одном репозитории. Независимо от количества модулей, команд и окружений.
Хорошая архитектура для старта.
Позволяет быстро и просто стандартизировать работу с разными окружениями и модулями.
Также, хорошо работает с CI.
Удобно, что все проекты во всех окружениях используют один и тот же процесс деплоя.

Пример:

infra/
├── modules/
│   ├── app/
│   ├── db/
│   └── vpc/
├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
└── README.md

Можно немного модернизировать использовав правила для запуска CI, которые будут отслеживать изменения только в определенных директориях.
Например:

  rules:
    - if:
      changes:
        - $PROJECT_DIR/

Из минусов такого подхода:

- Если несколько команд захотят внести изменения в общие модули неизбежны конфликты
- Невозможность корректно контролировать доступы.
- Если не разделять CI по проектам, то применение всех модулей для всей инфраструктуры будет занимать кучу времени.

Подходит, для небольшой инфраструктуры и для самого старта автоматизации, когда скорость изменений важнее модульности.


2. Мультирепозиторй
Каждая команда или каждое приложение имеет свой отдельный репозиторий.
Общие модули могут жить в отдельном репозитории и использоваться как зависимости.

На самом деле долгоживущий вариант, на котором можно выстраивать большую инфраструктуру.
Здесь, решены проблемы, с доступами и CI. Конфликтом могут послужить shared модули.
Также встает вопрос, организации CI, но во многих CI системах есть опция "CI пайплайн по-умолчанию".
Получается, что пока в новом проектом репозитории, не будет своего CI будет наследоваться дефолтный, добиваясь единообразия.

Пример:

infra/
├── dev
│   ├── project-a
│   ├── project-b
│   └── project-c
├── prod
│   ├── project-a
│   ├── project-b
│   └── project-c
├── shared
└── stage
    ├── project-a
    ├── project-b
    └── project-c

Минусы:

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

3. Инфраструктура внутри проекта

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

Пример:

infra/
└── modules
    ├── dns
    ├── eks
    ├── s3
    └── vpc
  ...

В продуктовом проекте можно будет встретить такой код:

# Тут Python используется как самый читаемый. Terraform, Helm, Pulumi, Не важно

from infra.modules import eks

eks_instance = eks.Cluster(
      name="my-cluster",
    version="1.33",
    
  )

Идеально подходит при:

- Микросервисной архитектуре
- Большом количестве команд
- self-service решений
- При использовании платформенного подхода.

#iac
#личный_опыт
#мнение

Обожаю этот канал.
Теперь они ещё и выпустили update по devops
https://youtu.be/rXPpkzdS-q4?si=j3GV73Pf10EqY2Es

Всем привет!

В связи с ростом подписчиков имеет смысл чуть подробнее представиться, учитывая, что до этого это был блог больше "из кейсов знакомых и для знакомых".
Хочу чуть подробнее рассказать о себе, о своем бекграунде, и каких-то специфических предпочтениях.
Также расскажу, о том, какие топики я бы хотел освещать.

Немного о себе:

🟠 DevOps Culture First.
Начём с того, что изначально мой путь виделся мне, как путь "Linux engineer"! Я копался в Linux, разбирался в сетях, бился головой, изучая, как работает инфраструктурный софт типа nginx или MySQL.
Больше всего мне нравилась автоматизация... Bash-скрипты, cron, немного Python, сама мысль, что с помощью автоматизации можно строить по-настоящему крутые и автономные системы.
При этом, мне нравилось и программировать, я разбирался в том, как работают бекенды, базы данных, как устроена большая разработка.
Пока рос я и мои компетенции, развивалась и сама индустрия. У нас появились контейнеры, Infrastructure as Code инструменты, и целая культура, которая призвана объеденить все то, что мне так нравится. DevOps!
Когда я услышал о DevOps впервые, кажется, я сразу же почувствовал, что это резонирует с тем, что мне искренне нравится.

Я всегда оставался сторонником мнения, что культура и процессы первичны, и только потом идут конкретные паттерны или инструменты. Я всегда старался быть get in touch с командами разработки, хоть рынок старательно пытался выделить DevOps в отдельную роль.

🟠 Kubernetes Enjoyer.
Признаюсь честно — я большой фанат Kubernetes :)
Иногда, когда ко мне приходят с проблемой X, я шучу: "Просто поставь Kubernetes — и всё будет!" Конечно, это сильное преувеличение. Но правда в том, что Kubernetes — технология, которую я искренне люблю. Видно, как она стала стандартом в индустрии. Она закрывает массу задач "из коробки", а возможности по расширению...

Немного о топиках и о том, какого рода контент здесь будет.

🟧: Разбор культурного аспекта работы DevOps и взаимодействия с командой(беки, фронты, QA, PM).
🟧: Практические кейсы из разряда: "Ко мне пришли с проблемой Х и я хочу поделиться решением со всеми"
🟧: Мои эксперименты и отражение моего пути обучения новым технологиям

Я рад видеть всех пристутствующих на моем канале!

Один из культурных аспектов DevOps — это мотивация, с которой инженеры совершают те или иные изменения.
Продвигая data-driven decisions, мы всё чаще смотрим на цифры, а не на ощущения.
Я бы хотел рассказать о четырёх основных метриках, которые двигают DevOps.
О четырёх метриках, из-за которых у вас опять перепиливаются пайплайны снова и снова.

Речь идёт о DORA метриках.
DORA – DevOps Research and Assessment
Это исследовательская группа, которая вывела 4 метрики по которым можно понять "девопсовость" команды.

Вот эти 4 метрики:
1. Deployment Frequency
Частота деплоев в прод. Больше лучше.
2. Lead Time for Changes
Время от момента, когда задача получила статус "В работе", до момента когда задача оказалась на проде. Меньше лучше.
3. Change Failure Rate
Процент деплоев на прод, которые привели к ошибкам(С какой частотой у нас падает прод после релиза). Меньше лучше.
4. Time to Restore Service.
Время, которое требуется, чтобы упавший сервис, снова начал работать. Менньше Лучше.

Именно на эти показатели ориентируются devops в своей работе.

Deployment Frequency

Девопс: У нас stage вообще не соответствует проду. Давайте за неделю стабилизируем stage.
И все изменения сначала будут попадать туда.

Стабилизация stage может повлиять на количество доставленных фич, но на самом деле
Стабильный прод -> тестирование на актуальном stage -> меньше страха -> чаще катимся в прод, быстрее доставляем фичи.

Lead Time for Changes

Девопс: давайте внедрим codeowners чтобы при открытии MR в него автоматически призывали всех, кто должен сделать ревью.
Все MR без аппрувов будут закрываться по истечению срока.

Данный пример показывает, как изменение, которое кажется наоборот замедляющим(автозакрытие MR)
Может спровоцировать ускорение ревью.

Change Failure Rate(CFR)
Процент деплоев на прод, которые завершились ошибкой.

Девопс: Нам нужно добавить endpoint /healthz
Который будет отдавать 200 OK если сервис работает корректно.

Казалось бы это не несёт никакого value, и опять какое-то странное требование, но на самом деле мониторинг этого эндпоинта напрямую влияет на CFR

Time to Restore Service

Девопс: Нам нужно добавить smoke-тесты
В случае провала которых мы будем откатывать прод автоматически

По-сути, это изменение, которое может очень сильно сократить время которое требуется, на восстановление сервиса.

Когда DevOps приходит с идеей:
- Давайте настроим stage
- Давайте добавим smoke-тесты
- Давайте перепишем пайпы
Это не прихоть и не абстрактное желание "сделать красиво".
Почти каждое такое изменение призвано улучшить одну из DORA метрик.
И такие предложения являются ответом на проблемы, которые появляются в общем процессе доставки и эксплуатации кода.

А у вас отслеживаются DORA метрики?
Как вы считаете пайпланы должны постоянно меняться/улучшаться?
Или работает и не трогаем?