Wie kann ich die Konsistenz zwischen neuen Microservices sicherstellen?

10

Meine Organisation erlebt eine Explosion von Microservices. Wir haben derzeit keine formalisierte Möglichkeit, neue Projekte zu booten. Ich stelle fest, dass ein Team mit einem Fehler in der Bereitstellung oder im Erstellungsprozess zu mir kommt, und ich werde Zeit damit verbringen, nur um festzustellen, dass ich ihn bereits in einem anderen Projekt behoben habe. Es gibt auch viele Inkonsistenzen zwischen Projekten, die ich standardisiert sehen möchte.

Die Änderungen betreffen häufig eine einzelne Datei (z. B. serverless.yml oder ein Makefile), sodass eine Lösung mit gemeinsam genutzten Bibliotheken, z. B. Git-Submodulen, nicht realisierbar erscheint. Jedes Projekt verfügt über eine eigene Konfiguration, die verwaltet werden muss, z. B. Dockerfiles oder serverless.yml. Daher sind zentralisierte Konfigurationsverwaltungslösungen für VMs nicht wirklich anwendbar.

Wie kann ich sicherstellen, dass neue Microservices den Organisationsstandards entsprechen und Bugfixes / Features aus vorhandenen Projekten auf eine Weise enthalten, die für Entwickler, die neue Projekte starten möchten, einfach und intuitiv ist? Was sind einige bewährte Methoden zur Lösung dieser Probleme?

Der aktuelle Workflow besteht darin, die Person neben Ihnen zu fragen: "Aus welchem ​​Projekt soll ich klonen, um es als Vorlage zu verwenden?" und löschen Sie dann alle Inhalte, die für dieses Projekt nicht erforderlich sind.

user2640621
quelle

Antworten:

5

Ich werde eine Antwort auf meine bisherige Lösung hinzufügen, aber ich bin immer noch sehr daran interessiert zu hören, wie andere Organisationen dieses Problem lösen und welche Best Practices sie haben.

Um das Problem zu lösen, dass keine konsistente Basis zum Erstellen von Projekten vorhanden ist, ist es meine Idee, ein Repository (Repositorys?) Mit Boilerplates / Templates zu erstellen und den Cookiecutter als Tool zum Erstellen neuer Microservices zu verwenden. Auf diese Weise wird jedes Projekt auf einer Standardbasis erstellt, in die alle Lektionen, die wir als Organisation gelernt haben, integriert sind. Alle Änderungen, die wir vornehmen, können vorab in das Boilerplate-Repository integriert werden. Ich kann mir vorstellen, dass wir Vorlagen für Nodejs Docker-Images, serverlose SPAs, Python-Lambdas usw. haben werden.

Um das Problem von Änderungen an den Vorlagen zu lösen, die nach jedem Projekt übertragen werden, besteht meine Lösung darin, einen Prozess zu implementieren, bei dem Eigentümer von Microservices auf Änderungen an der Vorlage aufmerksam gemacht werden und diese Änderungen dann an ihren Microservice weitergeben.

user2640621
quelle
Dies tun wir in Kombination mit einer einfachen Hallo-Welt-App, die die Best Practices als konkretes Beispiel veranschaulicht.
Boykott SE für Monica Cellio
4

Verwenden Sie ein Konfigurationsmanagement- / automatisiertes Bereitstellungssystem. Dafür wurden diese entwickelt. Dinge wie Kubernetes, Puppet, Chef, Ansible und Salt Stack wurden genau für diesen Zweck entwickelt und können mit Golden Master-Vorlagen, Kickstart-Skripten, Amazon AMIs oder nur einem Docker-Container verwendet werden. Auf diese Weise können Sie Standardbasisvorlagen verwenden und dann zusätzliche Rollen überlagern. Dadurch wird sichergestellt, dass Builds vollständig (als Code) dokumentiert sind und schnell und einfach in der Produktion bereitgestellt werden können. Sie werden genau so bereitgestellt, wie sie entworfen wurden, oder stellen zusätzliche Instanzen bereit, wenn Skalierbarkeit oder Redundanz erforderlich sind oder etwas kaputt geht. Auf diese Weise können auch Änderungen / Updates integriert werden. So wie Sie Software-Updates veröffentlichen, Sie können Updates für Ihre Konfiguration veröffentlichen und der Konfigurationscode kann genauso verwaltet werden, wie Ihr Software-Code verwaltet wird - in denselben Repos und mit denselben Workflows. Und wenn die Upgrade-Zeit kommt, gibt es kein Rätsel, wie das Ding aufgebaut ist. Schauen Sie sich einfach das Skript an.

Ein Weg, wie Konfigurationsmanagementsysteme dies tun, ist die häufige Verwendung von Vorlagen für Ihre Konfigurationsdateien. Beispielsweise gibt es im Allgemeinen viele Zeilen, die in Ihrer Umgebung gleich oder ähnlich sind. SaltStack verwendet Jinja- Vorlagen und Puppet Embedded Ruby-Vorlagen . Am Beispiel von AWS müssen Sie möglicherweise einen API-Schlüssel, eine IAM-Rolle, eine Region (oder zufällig eine Region aus einer Liste von Regionen auswählen), eine VPC usw. festlegen, die für alle Instanzen gleich ist. Aber dann müssen Ihre Funktionen und Ausgänge eindeutig sein. Oder noch besser, Sie könnten ein Marionettenmodul oder eine Salzformel schreiben, die "Verträge" definiert, und diese Verträge (API-Definitionen) sowohl für Ein- als auch für Ausgänge verwenden, sodass Sie Ihre Microservices nicht an zwei oder drei Stellen konfigurieren müssen.

SaltStack zum Beispiel hatte kürzlich ein Treffen, um dieses spezielle Szenario zu besprechen . Darüber hinaus kann SaltStack Docker-Container nativ verwalten und bereitstellen . (Puppet hat auch ein Modul für Docker ) Ebenso verfügt Ansible über Playbooks und Dokumente für die Arbeit mit serverlosen Bereitstellungen und Docker- Containern .

Wenn Sie mit Ihrem serverlosen Thema / Paradigma fortfahren möchten , sind Puppet , Ansible und Saltstack alle masterless oder unterstützen einen masterless-Modus, wenn Sie dieses Thema fortsetzen möchten.

James Shewey
quelle
Ich habe meiner Frage einige Beispiele und Erläuterungen hinzugefügt. Das Konfigurationsmanagement hilft nicht wirklich, da jedes Projekt in seiner Konfiguration in sich geschlossen ist. Es gibt keine Probleme bei der Migration zur Konfiguration als Code. Es geht darum, die Konfiguration als Code und die Konfigurationsausbreitung beizubehalten, die auftreten könnten, wenn Sie 100 Microservices mit jeweils unterschiedlicher Konfiguration hätten. Wir verwenden derzeit CI / CD mit konsistenten Builds, daher ist dies auch kein Problem.
user2640621
1
@ user2640621 - Haben Sie jemals ein Konfigurationsmanagementsystem verwendet? Durch die Zentralisierung der "Konfigurationsausbreitung" können Sie sie einfacher und von einem Ort aus (anstelle von 100 verschiedenen Orten) verwalten. Obwohl jedes Projekt in sich geschlossen sein kann, gibt es eindeutig einige Überschneidungen, wenn Sie nach Vorlagen für Bereitstellungen fragen. Es könnte sich lohnen, ein Paar in einer Sanbox auszuprobieren, um ein Gefühl dafür zu bekommen, wie sie funktionieren, bevor Sie sie abschreiben. Dies automatisiert nicht nur die Verwaltung Ihrer Konfigurationsdateien, sondern macht noch viel mehr.
James Shewey
1
Ich habe SaltStack, Chef und Puppet verwendet, aber immer nur zum Verwalten von VMs. Vielen Dank für Ihre Antwort. Ich sehe definitiv, wie das Konfigurationsmanagement jetzt außerhalb der Verwaltung von VMs verwendet werden kann.
user2640621
2
@ user2640621: Wenn sie alle unterschiedlich sind: "Sie codieren es, Sie führen es aus". Lassen Sie die Teams die Operationen ihrer Dienste verwalten. Lass sie deinen Schmerz fühlen.
Monica wieder herstellen - M. Schröder
3

Diese Frage ist weit gefasst. Wenn meine Antwort etwas falsch ist, können Sie gerne Kontext und spezifische Beispiele hinzufügen, damit ich ein besseres Verständnis habe.

Wenn Sie ein Maschinenabbild wie AMI von AWS verwenden, können Sie ein Basis- oder Golden Image erstellen, das Sie dann verwalten und verteilen oder in Ihrer kontinuierlichen Bereitstellung implementieren können. Mit dieser Architektur stellen Sie sicher, dass jeder Microservice auf konsistenter Hardware mit identischer Konfiguration bereitgestellt wird, sodass alle Probleme, mit denen Sie konfrontiert sind, mit der Konfiguration des Microservices / der Anwendung zusammenhängen.

Sie können diese Unveränderlichkeit durch Hinzufügen von Konfigurationstools wie Ansible und Packer fördern. Mithilfe der Konfigurationsverwaltung können Sie das Computer-Image mit allen gewünschten Informationen (einschließlich der Anwendung) versehen. Mit Packer können Sie dann einen Snapshot dieses Computerabbilds erstellen, und jede Bereitstellung ist identisch.

Mit diesem Beispiel können Sie ein Basis-AMI mit den richtigen Paketen, Updates und Konfigurationen backen, die mithilfe von Ansible und Packer installiert wurden. Darüber hinaus können Sie sich "Ansible-Pull" ansehen, um die Bereitstellung abzuschließen, indem Sie den Anwendungscode abrufen, Änderungen vornehmen und den Microservice über diesem Basisimage bereitstellen.

Der wichtigste Rat, den ich geben kann, ist jedoch, eine Lösung zu finden, die das gesamte Unternehmen unterstützen und warten kann. Es lohnt sich, einen SDLC einzurichten, der Ihre speziellen Probleme löst, der Kultur und Haltung der Führung entspricht und moderne Architekturpraktiken umfasst.

Ich war bei drei Organisationen und wir haben drei sehr unterschiedliche Ansätze verfolgt.

Viel Glück!

Tschad
quelle
Wir verwenden keine VM-basierten Lösungen (meistens Serverless und ein bisschen Docker), aber ich werde versuchen, mein Problem auf Ihr Beispiel anzuwenden. Wo würde jemand anfangen, wenn er ein neues Packer-Image erstellen möchte? Wenn jedes Projekt in sich geschlossen ist und es kein zentrales Repository für die Packerkonfiguration gibt, was verwenden sie als Basis für die Erstellung von Images? Vielleicht besteht einer der Unterschiede darin, dass die Projekte, mit denen ich arbeite, versuchen, so eigenständig wie möglich zu sein, ohne von zentralisierten Diensten wie Ansible abhängig zu sein, bei denen Sie Ihre Konfiguration für alle Projekte gleichzeitig aktualisieren können.
user2640621
Mit der serverlosen und Docker-basierten Architektur können Sie diese Grundlagen weiterhin anwenden. Eine Strategie besteht darin, eine Basis-Docker-Datei zu verwalten. Sie können eine CentOS-basierte Docker-Datei erstellen, die einige der Konfigurationen enthält, die Sie für jeden Microservice erwarten. Anschließend kann jedes Team diese Docker-Datei abrufen und darüber hinaus eine eigene Microservice-spezifische Docker-Datei erstellen. Zur Unterstützung der Containerverwaltung und der kontinuierlichen Bereitstellung können Sie ein Tool wie Kubernetes verwenden.
Tschad