Как я могу обеспечить согласованность между новыми микросервисами?

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

Изменения часто затрагивают один файл (например, serverless.yml или Makefile), поэтому решение с использованием общих библиотек, например, подмодулей git, не представляется жизнеспособным. Каждый проект будет иметь свой собственный набор конфигурации, который необходимо поддерживать, например, Dockerfiles или serverless.yml, поэтому решения по централизованному управлению конфигурациями для виртуальных машин на самом деле не применимы.

Как я могу гарантировать, что новые микросервисы соответствуют стандартам организации и включают исправления / функции из существующих проектов таким образом, чтобы это было легко и интуитивно понятно для разработчиков, которые хотят начать новые проекты? Каковы некоторые передовые методы решения этих проблем?

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

Я добавлю ответ о том, какое у меня решение до сих пор, но мне все еще интересно узнать, как другие организации решают эту проблему и какие у них есть лучшие практики.

Чтобы решить проблему отсутствия согласованной базы для создания проектов, моя идея состоит в том, чтобы создать хранилище (репозитории?) Шаблонов / шаблонов и использовать cookiecutter в качестве инструмента для создания новых микросервисов. Таким образом, каждый проект создается из стандартной базы со всеми уроками, которые мы извлекли как организация, интегрированная в него. Любые изменения, которые мы делаем, могут быть интегрированы в репозиторий. Я предполагаю, что у нас будут шаблоны для образов Nodejs Docker, бессерверных SPA, Python-лямбд и т. Д.

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

Используйте систему управления конфигурацией / автоматического развертывания. Это то, для чего они были разработаны. Такие вещи, как Kubernetes, Puppet, Chef, Ansible и Salt Stack, предназначены именно для этой цели и могут использоваться с шаблонами Golden Master, сценариями кикстарта, Amazon AMI или просто контейнером Docker. Это позволяет использовать базовые шаблоны по умолчанию, а затем накладывать дополнительные роли. Это обеспечит полное документирование сборок (в виде кода), а также быстрое и простое развертывание в рабочей среде, и развертывание будет точно таким же, как было разработано, или развертывание дополнительных экземпляров, когда возникнет необходимость в масштабируемости или избыточности или что-то сломается. Изменения / обновления также могут быть интегрированы таким образом. Так же, как вы выпускаете обновления программного обеспечения, Вы можете выпускать обновления для своей конфигурации, а кодом конфигурации можно управлять так же, как и программным кодом, - в тех же репозиториях и с теми же рабочими процессами. И когда наступает время обновления, нет никакой загадки, как это делается, просто посмотрите на сценарий.

Один из способов, которым системы управления конфигурацией делают это, - интенсивное использование шаблонов для ваших файлов конфигурации. Например, как правило, в вашей среде много строк, которые будут одинаковыми или похожими. SaltStack использует шаблоны jinja, а puppet использует шаблоны Embedded Ruby . Используя AWS в качестве примера, вам может понадобиться установить ключ API, роль IAM, регион (или случайным образом выбрать регион из списка регионов), VPC и т. Д., Которые одинаковы для всех экземпляров. Но тогда вам нужно, чтобы ваши функции и выходы были уникальными. Или, что еще лучше, вы можете написать кукольный модуль или формулу соли, которая определяет «контракты» и использовать эти контракты (определения API) для входов и выходов, избавляя вас от необходимости конфигурировать ваши микросервисы в двух или трех местах.

Например, у SaltStack недавно была встреча для обсуждения этого конкретного сценария . Кроме того, SaltStack также может самостоятельно управлять и развертывать док-контейнеры . (В Puppet также есть модуль для Docker ). В Ansible также есть книги и документы для работы с безсерверными развертываниями и контейнерами Docker .

Кроме того, если вы хотите продолжить с вашей серверной темой / парадигмой, Puppet , Ansible и salttack все не имеют мастерской поддержки или поддерживают режим без мастерской, если вы хотите продолжить эту тему.

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

Использование образа машины, такого как AWI, позволит вам создать базовый или золотой образ, который затем можно будет поддерживать, распространять или реализовывать в процессе непрерывной доставки. Используя эту архитектуру, вы гарантируете, что каждый микросервис развернут на согласованном оборудовании с идентичной конфигурацией, поэтому любые проблемы, с которыми вы сталкиваетесь, связаны с конфигурацией микросервиса / приложения.

Вы можете продвинуть эту неизменность с добавлением инструментов конфигурации, таких как Ansible и Packer. Используя управление конфигурацией, вы можете снабдить образ машины всем необходимым (включая приложение). Затем Packer позволит вам сделать снимок этого образа машины, и каждое развертывание будет идентичным.

Используя этот пример, вы можете «испечь» базовый AMI с правильными пакетами, обновлениями и конфигурацией, установленными с помощью Ansible и Packer. Кроме того, вы можете посмотреть на «Ansible-Pull», чтобы завершить развертывание, потянув код приложения, внеся любые изменения и развернув микросервис поверх этого базового образа.

Однако самый важный совет, который я могу дать, - это просто найти решение, которое вся организация может поддерживать и поддерживать. Стоит попытаться создать SDLC, который решает ваш конкретный набор проблем, соответствует культуре и отношению руководства и охватывает современные методы архитектуры.

Я был с тремя организациями, и мы выбрали три совершенно разных подхода.

Удачи!