Rationalisierung der serverlosen Bereitstellung mit Docker

Serverlose Anwendungen und Docker sind in den letzten Jahren zum Buzzword geworden. Vor ein paar Jahren gab es nur eine primäre Option für die Bereitstellung einer Produktionsanwendung, nämlich das Aufsetzen einer EC2-Instanz und das Ausführen des Servers hinter einem Nginx/Load Balancer, um den Datenverkehr zu jedem einzelnen Anwendungsserver zu verwalten.

Dann kam Docker. Docker hat die Art und Weise, wie wir alle die Bereitstellung betrachten, völlig verändert.

Dieses nicht enden wollende Problem der umgebungsspezifischen Bugs begann schließlich zu verschwinden, weil der primäre Anwendungsfall, den Docker löste, dieser war:

Nach dem Einsatz von Docker müssen Sie sich keine Sorgen machen, dass etwas auf Ihrem Rechner funktioniert, aber nicht in der Produktionsumgebung. Es wäre genau derselbe Rechner mit genau derselben Konfiguration, der in allen verschiedenen Umgebungen läuft. Ihr Code wird immer nur einmal erstellt, und dann wird dasselbe Image ohne weitere Änderungen in die verschiedenen Umgebungen übertragen. Dies gab sowohl den SREs/Devops Engineers als auch den Entwicklern bei der Erstellung einer Anwendung immenses Vertrauen.

Zusammen mit dem Aufkommen von Docker gab es eine weitere erstaunliche Technologie, die ebenfalls immense Popularität erlangte: Serverlose Anwendungen. Serverlose Anwendungen auch bekannt als FaaS (Funktion als Dienstleistung) ist einer dieser kostenpflichtigen Dienste, bei denen Sie sich überhaupt keine Gedanken über die Kosten oder die Skalierbarkeit Ihrer Anwendung machen müssen. Die serverlose Architektur bietet Ihnen eine Plattform, auf der Sie ein bestimmtes Stück Code ausführen können. Sobald es mit der Ausführung fertig ist, zerstört es sich selbst, ohne dass Sie sich Gedanken über das Geld machen müssen, das es verschlingt, obwohl es nur eine lahme Ente ist. Dies gibt Entwicklern die Flexibilität, hoch skalierbare Dienste zu schreiben, ohne sich Gedanken über die horizontale Skalierung zu machen.

Pipeline für die Codebereitstellung

Jetzt, wo wir diese coolen Technologien wie Docker haben, war es super einfach, so viele Umgebungen zu erstellen, wie Sie wollen, ohne sich um die manuelle Einrichtung kümmern zu müssen. Alles, was Sie brauchen, ist ein auf dem System installiertes Docker, und Sie können loslegen mit Docker-Lauf.

Daher begannen die Menschen, mehrere Umgebungen für ihre Anwendungen zu entwickeln. Die Leute kamen oft mit einer dev,  Inszenierung, qa, Produktion In jeder Phase würden verschiedene Personen in der Organisation die Anwendung testen und sie zur Weiterführung freigeben.

Zum Beispiel:

1. dev - Wird im Allgemeinen von den Entwicklern intern verwendet. Sie pushen sehr häufig neue Code-Änderungen und testen sie auf einem entfernten Server untereinander.
2. Inszenierung - Sobald die Entwickler mit den Fehlern zufrieden sind, die sie als Funktionen verkaufen können, würden sie die Dinge in den Staging-Bereich verschieben. Dort können die Produktmanager wahrscheinlich über die Farben der Schaltflächen schimpfen.
3. qa - Sobald die Produktmanager mit den Farben zufrieden sind, geben sie sie frei und übergeben sie an die QA-Umgebung, wo das QA-Team die Funktionen auf die ungewöhnlichsten Arten testet, die man sich nur vorstellen kann.
4. Produktion - Wenn die Qualitätssicherung schließlich bestätigt, dass alles auf Herz und Nieren geprüft wurde, wird der neue Code in die Produktionsumgebung übertragen, damit er von den echten Benutzern verwendet werden kann.

Je nachdem, wie das Unternehmen strukturiert ist, werden verschiedene Unternehmen unterschiedliche Bereitstellungspipelines entwickeln. Wenn das Team sehr schlank ist und es kein QA-Team gibt, kann man diese Phase wahrscheinlich einfach überspringen.

Diese Pipeline bietet die Gewissheit, dass alles, was in die Endphase gelangt, ordnungsgemäß getestet wurde. Diese Deployment-Pipeline in Verbindung mit Docker bietet eine doppelte Sicherheit, da Sie immer wissen, dass das gleiche Image durch diese Pipeline propagiert wird und in allen Phasen genau die gleiche Umgebung repliziert wird.

Warum nicht serverlos mit Docker?

Jetzt, da wir verstehen, wie Docker zusammen mit einer Deployment-Pipeline uns so viel Sicherheit geben kann, stellt sich die Frage, warum nicht auch für serverlose Anwendungen etwas Ähnliches tun? Nun, diese Frage kam in unseren internen technischen Chats vor ein paar Monaten auf 😉 .

Es gibt dieses erstaunliche Werkzeug serverlosdie Ihnen hilft, serverlose Anwendungen bereitzustellen, indem Sie nur ein paar Befehle ausführen. Es würde Ihre Codebasis bündeln und Ihre serverlose Anwendung bei einem beliebigen Cloud-FaaS-Anbieter wie Google Cloud Function, AWS Lambda oder Azure Functions bereitstellen. Sie haben sogar die Möglichkeit, Folgendes zu integrieren CI/CD-Pipeline um Ihren Code bereitzustellen, sobald Sie ihn in einen bestimmten Zweig pushen. Aber wäre es nicht toll, denselben Pipeline-Mechanismus zu sehen, um Änderungen in verschiedenen Stadien zu genehmigen? Natürlich wäre es das, und es gibt bereits eine Möglichkeit, dies zu tun, nämlich das branchbasierte Deployment. Dabei wird der Code in einen bestimmten Zweig gepusht, und dieser Zweig stellt ihn dann in dieser Phase bereit. Das funktioniert zwar, führt aber zu einer Reihe von Problemen:

1. Sie müssen immer den Überblick darüber behalten, wie die Pipeline in den Zweigen verläuft. Wenn Sie also 4 Stufen haben, sollten Sie immer diese 4 Zweige in Ihrem Versionskontrollsystem haben. Und Sie müssen manuell sicherstellen, dass immer der richtige Zweig mit dem richtigen Zweig zusammengeführt wird, da es sonst zu einem Sprung in der Pipeline kommt.
2. Man kann direkt zu jeder Verzweigung schieben, wenn man Zugang dazu hat. Dies würde zu inkonsistenten Codes in den Phasen führen.
3. Bei verzweigungsbasierten Einsätzen kann es immer wieder zu neuen Konflikten bei der Zusammenführung kommen. Es wäre die Aufgabe der Person, die den Zweig zusammenführt, dafür zu sorgen, dass es keine Konflikte gibt.
4. Für jemanden, der sich nicht gut mit Versionskontrollsystemen auskennt, wird es nicht ganz einfach sein. Bei Pipelines kann sogar der Produktmanager einfach reinkommen, auf eine Schaltfläche klicken und es sollte auf magische Weise funktionieren, aber hier muss man wissen, wie das Versionskontrollsystem funktioniert.
5. Je mehr Stufen, desto mehr Verzweigungen. Bald könnte es ein verworrenes Durcheinander werden, wenn es nicht sorgfältig gepflegt wird.

Wie Docker hilft

Da wir bereits darüber gesprochen haben, wie Docker immer sicherstellt, dass derselbe Code durch verschiedene Phasen gepusht wird, können wir wahrscheinlich etwas tun, um beides miteinander zu verschmelzen, um die Flexibilität von serverlosen Anwendungen und das gleiche Maß an Vertrauen zu erlangen, während sie durch verschiedene Phasen bereitgestellt werden.

Die Idee dahinter ist, dass wir mit Docker in der Lage sein sollten, den Code einmal zu bündeln und denselben Code durch verschiedene Phasen zu bewegen. Hierfür werden wir Folgendes tun:

1. Verwenden Sie ein Basis-Image von Docker, auf dem Serverless installiert ist.
2. Kopieren Sie den Code, der in einem Docker-Image bereitgestellt werden soll, und speichern Sie ihn.
3. Verwenden Sie dasselbe Bild für die Bereitstellung auf verschiedenen Stufen.

Einrichten: Serverless mit Docker

Basisbild

Wir werden das obige Basis-Image verwenden, um unser Lambda einzusetzen. Um dieses Basis-Image in einer Ihrer Dockerdateien zu verwenden, können Sie Folgendes tun:

• Fügen Sie die obige Dockerdatei zu einem Github-Repository hinzu
• Weiter zu https://hub.docker.com
• Erstellen Sie ein neues Repository:
• Fügen Sie die relevanten Details ein und halten Sie sie der Einfachheit halber öffentlich.
• Wählen Sie das Repository, in das Sie Ihr Basis-Image übertragen haben.
• Klicken Sie auf erstellen und bauen

Dadurch wird Ihr Basis-Image erstellt und auf Docker Hub gehostet, so dass Sie es für jede Ihrer Anwendungen verwenden können.

Unter Verwendung Ihres Benutzernamens und des Repository-Namens sollten Sie in der Lage sein, dies in jede Ihrer Dockerdateien zu übernehmen.

Dockerfile für Ihr Lambda

Dockerfile ist alles, was Sie brauchen, um Ihre Anwendung zu bündeln. Damit sollte Ihre Codebasis kopiert und alle Abhängigkeiten installiert werden. Sobald das Image erstellt ist, können Sie es in ein beliebiges Docker-Image-Repository wie AWS Elastic Container Service, Docker Hub oder GCP Container Registry stellen, je nachdem, in welcher Cloud-Infrastruktur Sie sich befinden.

Förderung von Bildern auf verschiedenen Ebenen

Um es durch die verschiedenen Stufen zu befördern, muss es in einer Umgebung eingesetzt werden, ohne den Code zu ändern oder zu berühren. Dazu müssen wir ihm einige Umgebungsvariablen übergeben:

Der AWS_SECRET_ACCESS_KEY und die AWS_ACCESS_KEY_ID werden verwendet, um dem Docker-Container Zugriffsrechte zu erteilen, damit er bereitgestellt werden kann. Die STAGE-Variable hilft der serverlosen Konfiguration, die Funktion entsprechend zu benennen. Wenn Sie also mehrere Stages bereitstellen, können Sie sie auf der Seite mit der Auflistung der Cloud-Funktionen anhand des Namens unterscheiden.

Wie Sie die Datei serverless.yml konfigurieren sollten, erfahren Sie unter hier.

Um die Anwendung bereitzustellen, müssen Sie jetzt nur noch Folgendes tun:

Sobald Sie die Variablen durch die entsprechenden Werte ersetzt haben, sollte Ihre Anwendung bereitgestellt werden. Für die Bereitstellung bei anderen Cloud-Anbietern wie GCP oder Azure benötigen Sie wahrscheinlich anbieterspezifische Umgebungsvariablen, um die IAM-Rollenautorisierung einzurichten.

Aufrechterhaltung der Integrität des Rohrs

Nun stellt sich die Frage, wenn man direkt auf einer beliebigen Stufe bereitstellen kann, wie können wir dann sicherstellen, dass sie in genau der gleichen Reihenfolge wie im ursprünglichen Entwurf propagiert werden? Um dies zu gewährleisten, müssen Sie einen Pipeline-Fluss durch Jenkins oder eine andere CI/CD-Plattform entwerfen, um die Verbreitung des Images einzuschränken. Dies zu bestätigen ist eine andere Geschichte, über die wir in einem anderen Blog bald sprechen werden.

Schlussfolgerung

Auch wenn dies alles faszinierend erscheint, sollte man seine Bereitstellung/Codebasis nicht übertechnisieren. Wenn Ihr derzeitiges Setup in einem kleinen Team gut funktioniert, besteht vielleicht keine Notwendigkeit, eine komplexe Devops-Pipeline einzurichten, die an sich schon etwas Lernaufwand erfordert. Jedes Team hat seine eigenen Bedürfnisse und Anforderungen, und man sollte diese Technologien nicht einfach nur einsetzen, um das coole Kind im Block zu sein.

Die oben beschriebene Architektur und Einrichtung wirkt für uns Wunder, weil sie uns dabei hilft:

1. Überwachen Sie die gesamte Pipeline auf höchster Ebene, indem Sie sich einfach in unser Jenkins Dashboard einloggen.
2. Da wir ein schlankes Team sind, war es für uns eine einmalige Sache, die uns geholfen hat, die Kontrolle darüber zu behalten, was in welche Phase geht, und es richtig zu überprüfen und zu fördern.
3. Da es sich um ein völlig losgelöstes und asynchrones Team handelt, kann sogar ein Produktmanager bzw. ein Nicht-Techniker in unserem Team mit nur einem Mausklick Dinge in die Produktion überführen, ohne dass jemand anderes eingreifen muss.