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