Jak mogę zapewnić spójność między nowymi mikrousługami?

Moja organizacja przeżywa eksplozję mikrousług. Obecnie nie mamy sformalizowanego sposobu ładowania nowych projektów. Odkrywam, że zespół przyjdzie do mnie z błędem w procesie wdrażania lub kompilacji i spędzę na tym czas tylko po to, aby zdać sobie sprawę, że już go rozwiązałem w innym projekcie. Istnieje również duża niespójność między projektami, które chciałbym, aby były znormalizowane.

Zmiany często dotyczą jednego pliku (np. Serverless.yml lub Makefile), więc rozwiązanie obejmujące wspólne biblioteki, np. Podmoduły git, nie wydaje się wykonalne. Każdy projekt będzie miał własny zestaw konfiguracji, który musi być utrzymany, np. Dockerfiles lub serverless.yml, więc scentralizowane rozwiązania do zarządzania konfiguracją dla maszyn wirtualnych nie mają tak naprawdę zastosowania.

Jak mogę się upewnić, że nowe mikrousługi są zgodne ze standardami organizacji i zawierają poprawki / funkcje istniejących projektów w sposób łatwy i intuicyjny dla programistów, którzy chcą rozpocząć nowe projekty? Jakie są najlepsze praktyki dotyczące rozwiązywania tych problemów?

Obecny przepływ pracy polega na zapytaniu osoby znajdującej się obok Ciebie „z którego projektu mam sklonować, aby użyć go jako szablonu?” a następnie usuń wszystkie rzeczy, które nie są konieczne dla tego projektu.

Dodam odpowiedź na temat mojego dotychczasowego rozwiązania, ale nadal bardzo interesuje mnie, jak inne organizacje rozwiązują ten problem i jakie są najlepsze praktyki.

Aby rozwiązać problem braku spójnej bazy do tworzenia projektów, moim pomysłem jest utworzenie repozytorium (repozytoriów?) Z szablonów / szablonów i użycie narzędzia Cookieutter jako narzędzia do tworzenia nowych mikrousług. W ten sposób każdy projekt jest tworzony ze standardowej bazy, z uwzględnieniem wszystkich lekcji, których nauczyliśmy się jako organizacja. Wszelkie wprowadzane przez nas zmiany można zintegrować z repozytorium płyty kotłowej. Wyobrażam sobie, że będziemy mieć szablony obrazów Dockera Nodejs, SPA bez serwera, lambda Python itp.

Aby rozwiązać problem zmian wprowadzanych w szablonach propagowanych poniżej każdego projektu, moim rozwiązaniem jest wdrożenie procesu, w którym właściciele mikrousług są świadomi zmian w szablonie, a następnie są odpowiedzialni za propagowanie tych zmian do swojej mikrousługi.

Użyj systemu zarządzania konfiguracją / automatycznego wdrażania. Do tego zostały zaprojektowane. Rzeczy takie jak Kubernetes, Puppet, Chef, Ansible i Salt Stack są zaprojektowane tylko do tego celu i mogą być używane z szablonami Golden Master, skryptami kickstart, Amazon AMI lub tylko pojemnikiem Docker. Pozwala to na użycie domyślnych szablonów podstawowych, a następnie nałożenie dodatkowych ról. Zapewni to pełne udokumentowanie kompilacji (jako kodu) oraz szybkie i łatwe wdrożenie w środowisku produkcyjnym, a także wdrożenie dokładnie identyczne z tym, co zostało zaprojektowane lub wdrożenie dodatkowych instancji, gdy pojawi się potrzeba skalowalności lub redundancji lub coś się zepsuje. Zmiany / aktualizacje można również zintegrować w ten sposób. Podobnie jak w przypadku aktualizacji oprogramowania, możesz wydać aktualizacje swojej konfiguracji, a kod konfiguracji może być zarządzany tak, jak zarządzany jest kod oprogramowania - w tych samych repozytoriach i przy tych samych przepływach pracy. A kiedy nadejdzie czas aktualizacji, nie ma tajemnicy, jak to jest zbudowane, spójrz na skrypt.

Jednym ze sposobów, w jaki systemy zarządzania konfiguracją to robią, jest intensywne stosowanie szablonów dla plików konfiguracyjnych. Na przykład, ogólnie istnieje wiele linii, które będą takie same lub podobne w twoim środowisku. SaltStack wykorzystuje szablony jinja, a marionetka korzysta z szablonów Embedded Ruby . Na przykładzie AWS może być konieczne ustawienie klucza, interfejsu API, roli IAM, regionu (lub losowego wyboru regionu z listy regionów), VPC itp., Które są takie same we wszystkich instancjach. Ale musisz mieć swoje funkcje i wyjścia unikalne. Lub jeszcze lepiej, możesz napisać moduł kukiełkowy lub formułę soli, która definiuje „kontrakty” i używać tych kontraktów (definicji interfejsu API) zarówno do wejść, jak i wyjść, co pozwala uniknąć konieczności konfigurowania mikrousług w dwóch lub trzech miejscach.

Na przykład SaltStack niedawno spotkał się w celu omówienia tego konkretnego scenariusza . Ponadto SaltStack jest również w stanie zarządzać i wdrażać kontenery dokerów natywnie . (Puppet ma również moduł dla Dockera) Podobnie Ansible ma podręczniki i dokumenty do pracy z wdrożeniami bez serwerów i kontenerami Docker .

Ponadto, jeśli chcesz kontynuować z motywem / paradygmatem bez serwerów , Puppet , Ansible i Saltstack są bez mistrzowskie lub obsługują tryb bez mistrza, jeśli chcesz kontynuować ten motyw.

To pytanie jest szerokie, więc jeśli moja odpowiedź jest trochę nie na temat, dodaj kontekst i konkretne przykłady, aby lepiej zrozumieć.

Użycie obrazu maszyny, takiego jak AWS AMI, pozwoliłoby ci stworzyć obraz bazowy lub złoty, który możesz następnie utrzymywać, dystrybuować lub wdrażać w ciągłej dostawie. Korzystając z tej architektury masz pewność, że każda mikrousługa jest wdrażana na spójnym sprzęcie o identycznej konfiguracji, więc wszelkie napotkane problemy są związane z konfiguracją mikrousługi / aplikacji.

Możesz zwiększyć tę niezmienność, dodając narzędzia konfiguracyjne, takie jak Ansible i Packer. Korzystając z zarządzania konfiguracją, możesz zaopatrzyć obraz maszyny we wszystko, co chcesz na nim (w tym w aplikację). Packer pozwoli ci wtedy zrobić migawkę obrazu tego komputera, a każde wdrożenie będzie identyczne.

Korzystając z tego przykładu, możesz „upiec” podstawowy AMI z zainstalowanymi poprawnymi pakietami, aktualizacjami i konfiguracją za pomocą Ansible i Packera. Dodatkowo możesz spojrzeć na „Ansible-Pull”, aby dokończyć wdrożenie, pobierając kod aplikacji, wprowadzając wszelkie zmiany i wdrażając mikrousługę na tym obrazie podstawowym.

Jednak najważniejszą radą, jaką mogę udzielić, jest po prostu znalezienie rozwiązania, które cała organizacja może wspierać i utrzymywać. Warto spróbować ustanowić SDLC, który rozwiązuje konkretny zestaw problemów, pasuje do kultury i postawy przywódczej oraz obejmuje nowoczesne praktyki architektoniczne.

Byłem w trzech organizacjach i zastosowaliśmy trzy bardzo różne podejścia.

Powodzenia!