Як я можу забезпечити узгодженість між новими мікросервісами?

Моя організація переживає вибух мікросервісів. Наразі у нас немає формалізованого способу завантаження нових проектів. Я виявляю, що команда прийде до мене з помилкою в процесі їх розгортання або збирання, і я витрачу час на це лише для того, щоб зрозуміти, що вже вирішив це в іншому проекті. Між проектами також існує велика невідповідність, яку я б хотів бачити стандартизованою.

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

Як я можу гарантувати, що нові мікросервіси відповідають стандартам організації та включають виправлення / функції з існуючих проектів таким чином, що це легко та інтуїтивно зрозуміло для розробників, які хочуть розпочати нові проекти? Які є найкращі практики щодо вирішення цих питань?

Поточний робочий процес, який ми маємо, - запитати у людини поруч із вами "який проект я повинен клонувати, щоб використовувати як шаблон?" а потім видаліть усі речі, які не потрібні для цього проекту.

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

Щоб вирішити питання про відсутність послідовної бази для створення проектів, моя ідея полягає у створенні сховища (сховищ?) Котлопластів / шаблонів і використання файлів cookie як інструменту для створення нових мікросервісів. Таким чином, кожен проект створюється зі стандартної бази з усіма уроками, які ми засвоїли як організація, інтегрована в нього. Будь-які зміни, які ми вносимо, можуть бути інтегровані до сховища котлованних панелей. Я думаю, у нас будуть шаблони для зображень Nodejs Docker, SPA без сервера, лямбдатів Python тощо.

Щоб вирішити проблему змін, внесених до шаблонів, що пропонуються нижче за кожним проектом, моє рішення полягає в тому, щоб реалізувати процес, коли власники мікросервісів інформують про зміни шаблону, а потім відповідають за поширення цих змін у їх мікросервіс.

Використовуйте управління конфігурацією / автоматизовану систему розгортання. Саме для цього вони були розроблені. Такі речі, як Kubernetes, Puppet, Chef, Ansible і Salt Stack призначені саме для цієї мети, і їх можна використовувати з шаблонами Golden Master, сценаріями швидкого запуску, AMIs Amazon або просто контейнером Docker. Це дозволяє використовувати базові шаблони за замовчуванням, а потім переходити на додаткові ролі. Це забезпечить, що збірки будуть задокументовані повністю (як код), і це буде швидко та легко розгортатися у виробництві, і буде розгорнуто точно однаково тому, що було розроблено, або розгортати додаткові екземпляри, коли виникає потреба в масштабованості чи надмірності або щось порушується. Зміни / оновлення також можна інтегрувати таким чином. Як випускаєте оновлення програмного забезпечення, ви можете випустити оновлення своєї конфігурації, а кодом конфігурації можна керувати так само, як керується вашим програмним кодом - у тих же репостах та з тими ж робочими процесами. А коли настає час оновлення, немає таємниці, як річ будується, просто подивіться на сценарій.

Один із способів, яким це роблять системи управління конфігурацією, - це через інтенсивне використання шаблонів для ваших конфігураційних файлів. Наприклад, зазвичай існує багато рядків, які будуть однаковими чи подібними у вашому оточенні. SaltStack використовує дзіндзя шаблони і лялькові використання вбудованих шаблонів на Ruby . Використовуючи AWS як приклад, можливо, вам знадобиться встановити ключ, api, роль IAM, область (або випадковим чином вибрати регіон зі списку регіонів), VPC тощо, що все однаково для всіх примірників. Але тоді вам потрібно, щоб ваші функції та результати були унікальними. Або ще краще, ви можете написати ляльковий модуль або формулу солі, яка визначає "контракти" і використовувати ці контракти (визначення api) як для входів, так і для виходів, що позбавить вас від необхідності налаштувати свої мікросервіси в два-три місця.

Наприклад, недавно SaltStack провів зустріч для обговорення цього конкретного сценарію . Крім того, SaltStack також може самостійно керувати та розгортати докерні контейнери . (У ляльці також є модуль для Docker ). Аналогічно, у Ansible є ігрові книги та документи для роботи з розгортанням без сервера та контейнерами Docker .

Крім того, якщо ви хочете продовжувати свою тему / парадигму без сервера , Puppet , Ansible та солянка, вони без мастерства або підтримують режим без мастер, якщо ви хочете продовжити цю тему.

Це питання є широким, тому, якщо моя відповідь є трохи позабазовою, не соромтесь додавати контекст і конкретні приклади, щоб я краще зрозумів.

Використання машинного зображення, такого як AMI AWS, дозволить вам створити базове або золоте зображення, яке ви могли б потім підтримувати та розповсюджувати чи реалізовувати під час постійної доставки. Використовуючи цю архітектуру, ви гарантуєте, що кожна мікросервіс буде розгорнута на постійному обладнанні з однаковою конфігурацією, тому будь-які проблеми, з якими ви стикаєтеся, пов'язані з конфігурацією мікросервісу / програми.

Ви можете додатково покращити цю незмінність за допомогою додавання інструментів конфігурації, таких як Ansible та Packer. Використовуючи управління конфігурацією, ви можете надати зображенню машини все, що вам потрібно (включаючи додаток). Потім Packer дозволить вам зробити знімок цього зображення машини, і кожне розгортання було б ідентичним.

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

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

Я був з трьома організаціями, і ми застосували три дуже різні підходи.

Удачі!