Get best of the week

So werden Sie in sechs Monaten oder noch schneller DevOps-Ingenieur. Teil 5. Bereitstellung

So werden Sie in sechs Monaten oder noch schneller DevOps-Ingenieur. Teil 1. Einführung
So werden Sie in sechs Monaten oder noch schneller DevOps-Ingenieur. Teil 2. Konfiguration
So werden Sie in sechs Monaten oder noch schneller DevOps-Ingenieur. Teil 3. Versionen
So werden Sie in sechs Monaten oder noch schneller DevOps-Ingenieur. Teil 4. Software-Verpackung



Aktualisieren Sie den Speicher


Das Bild oben zeigt, wie eine typische Codebereitstellung aussehen sollte. Ich möchte Sie daran erinnern, wo wir uns jetzt gemäß der Roadmap befinden:



Wenn Sie einen Monat mit dem Studium der einzelnen Abschnitte verbracht haben, sind Sie jetzt bei 4 Monaten. Zu diesem Zeitpunkt sollten Sie bereits wissen, wie Sie die Infrastruktur bereitstellen, die mit Ihrer Software funktioniert, wie Sie Softwareversionen ordnungsgemäß verwalten und für die zukünftige Bereitstellung verpacken. In diesem Artikel wird erläutert, wie Sie Ihren Code ordnungsgemäß bereitstellen können!

Code-Bereitstellung


Haben Sie bemerkt, dass ich "wie" und nicht "wie einfach" gesagt habe? Es ist nicht nur das. Leider ist die korrekte Bereitstellung von Code aus der Entwicklungsumgebung in der Produktumgebung immer noch ein schmerzhafter Prozess, der mit Fehlern und Abstürzen behaftet ist. Dafür gibt es viele Gründe, aber meiner Meinung nach sind es hauptsächlich die Unterschiede zwischen der Umgebung, in der der Code erstellt wird, und der Umgebung, in der er ausgeführt wird.

Das Minimieren dieser Unterschiede ist das Beste, was Sie nicht nur während des Bereitstellungsprozesses, sondern auch während der Ausführung nach der Bereitstellung tun können. Wie können wir also die Unterschiede zwischen unseren Prod- und Nicht-Prod-Umgebungen reduzieren und / oder beseitigen?

Und es funktioniert bei meinem Auto!


Wenn Ihre Entwicklungsinfrastruktur so aussieht:



Und die Produktinfrastruktur sieht so aus:



Betrachten Sie Ihr Problem. Wenn Sie die Infrastruktur als Code verwenden und die Dinge nicht manuell konfigurieren, können Sie sie zu 90% lösen. Wenn nicht, verzweifeln Sie nicht - Sie sind nicht allein. Markieren Sie den Nachmittag, bestimmen Sie, welche Lücken Sie haben (Training, Kultur, Menschen, Prozesse usw.) und füllen Sie sie methodisch nacheinander aus.

Das Fazit ist, dass es Ihnen nicht gelingen wird, einen modernen Technologie-Stack zu verwalten, wenn Sie die Dinge noch manuell konfigurieren. Dies ist ein Axiom. Als erstes müssen Sie sicherstellen, dass alles, was mit prod zu tun hat, das versionierte Artefakt ist, das von Ihrem Bereitstellungsserver bereitgestellt wird.

Unter der Annahme, dass dies alles getan wurde, werde ich mir erlauben, zu behaupten, dass der beste Weg zum Bereitstellen von Code darin besteht, ihn überhaupt nicht bereitzustellen.

Moderner Bereitstellungsansatz


Es ist richtig, dass die Bereitstellung von Code auf Computern ein Echo der neunziger Jahre ist. Das größte Problem bei der Bereitstellung von Code auf einer Reihe von Produktionsmaschinen besteht darin, dass sich Ihre Produktserver (auf denen der Code ausgeführt wird) per Definition von Ihren Entwicklungsservern (auf denen dieser Code geschrieben ist) unterscheiden. Es ist nicht verwunderlich, dass es unmittelbar nach dem Einsatz viele Probleme gibt, die noch nie bemerkt wurden, denn jetzt haben sich die Bedingungen geändert!

Vor der Bereitstellung müssen Sie sicherstellen, dass Ihr Bereitstellungsartefakt die gesamte Laufzeit und nicht Teil des Codes ist. Mit anderen Worten, stellen Sie Ihren Code einmal in der Entwicklungsumgebung bereit, klonen Sie den gesamten Computer, auf dem Ihr Code ausgeführt wird, und kopieren Sie ihn dann, wo immer er sein sollte.



Dies wird als "unveränderliche Bereitstellung" bezeichnet und ist eine sehr leistungsstarke Vorlage, die Ihnen nach der Bereitstellung viele Stunden Kopfschmerzen erspart. Wenn Sie Container ausführen, gilt natürlich dieselbe Idee: Sie stellen überall denselben Container bereit. Man kann sagen: „Hör auf! Mein Produkt unterscheidet sich von dev! "Und das ist richtig, denn die Datenbankbenutzernamen / -kennwörter, Verbindungszeichenfolgen und S3-Dumpster-Speicherorte sind alle verschiedene Dinge! Ja, das sind sehr unterschiedliche Dinge.

Der Weg, um dieses Problem zu lösen, besteht darin, das Prinzip der 12-Faktor-App- Konfiguration zu verwenden. Eine Anwendung von zwölf Faktoren speichert die Konfiguration in env-Variablen oder env-Umgebungsvariablen. Umgebungsvariablen können problemlos zwischen Bereitstellungen geändert werden, ohne den Code zu ändern. Im Gegensatz zu Konfigurationsdateien ist die Wahrscheinlichkeit geringer, dass sie versehentlich in einem Code-Repository gespeichert werden. Im Gegensatz zu benutzerdefinierten Konfigurationsdateien oder anderen Konfigurationsmechanismen wie Java-Systemeigenschaften handelt es sich um einen sprach- und betriebssystemunabhängigen Standard. Daher muss Ihre gesamte Konfiguration ausgelagert und als Umgebungsvariablen auf Ihren Computer übertragen werden.

Wenn Sie sich beispielsweise in AWS befinden, verwenden Sie SSM als externes Repository für Parameter - es lässt sich perfekt in CloudFormation integrieren. Es ist auch sehr einfach, Umgebungsvariablen direkt über AWS ssm cli-Befehle festzulegen. Natürlich haben andere Cloud-Anbieter ähnliche Mechanismen.

Widerstehen Sie auch dem Drang, Ihre Produktmaschinen zu „reparieren“, wenn etwas schief geht. Maschinen müssen unveränderlich sein, was bedeutet, dass alle Korrekturen, die Sie vornehmen, von dev stammen müssen. Ihr Ziel sollte es sein, den Zugriff auf Produktmaschinen überhaupt zu verhindern. Weder ssh noch scp noch prod access - niemals für irgendjemanden, nicht für sich selbst oder für unerfahrene Hacker.

Aber was ist, wenn ich Protokolle benötige, um das Problem zu beheben? Sie haben es erraten - Ihre Magazine sollten auch externalisiert und idealerweise an einen anderen Ort gesendet werden, entweder mit dem ElasticSearch / Logstash / Kibana (ELK) -Stack oder mit kommerzieller Software wie SumoLogic oder Datadog.

Was auch immer Sie tun, Ihre Prod-Maschinen sind ein „Arbeitsvieh“, das beim geringsten Anzeichen von Krankheit ersetzt wird. Sie sind keine „Haustiere“, die gepflegt werden müssen, um durch stundenlange Fehlerbehebung geheilt zu werden.

Ich weiß, dass diese Analogie zu oft verwendet wird, und ich höre von Leuten, die sich wirklich für Rinder interessieren, dass dies nicht ganz stimmt, aber das Wesentliche ist dasselbe - reparieren Sie Ihre Produktmaschinen nicht, reparieren Sie einfach Ihre Entwicklung und setzen Sie sie erneut ein .

Code-Bereitstellungsmechanik


Sie wissen also, was zu tun ist, aber Sie wissen nicht, wie. Leider erscheint hier Jenkins. Wenn Sie es nicht wissen, ist Jenkins einer der beliebtesten Open Source Deployment Automation-Server.



Ich sage "leider", weil Jenkins (und sein Vorgänger Hudson) seit fast zehn Jahren bei uns sind, und das fällt auf. Die Einrichtung ist kompliziert und noch schwieriger zu warten. Es kommt mit Millionen von Plugins von zweifelhafter Qualität. Diese Plugins brechen in der Regel zum ungünstigsten Zeitpunkt und lassen alles andere hinter sich. In der Tat sind Jenkins-Workshops wirklich stabil und selten und werden normalerweise nur in den größten Organisationen angeboten.

Warum empfehle ich Ihnen, mit Jenkins zu beginnen? Denn trotz aller Mängel ist es immer noch äußerst beliebt und im IT-Bereich weit verbreitet. Jenkins zu kennen, insbesondere wie die Jenkins- Datei aufgebaut ist, ist ein großer Vorteil für die Berufsaussichten und kann nicht übersehen werden. Stellen Sie beim Erkunden von Jenkins sicher, dass Sie das neue Pipeline BlueOcean-Plugin und nicht die veraltete Jenkins-Job-Pipeline verwenden. Dies ist wichtig, wenn Ihre CI / CD-Pipeline direkt in Ihrem GitHub / GitLab-Repo-Code gespeichert werden soll. Somit ist die Pipeline selbst ein versionierter Code!



Tatsächlich ist es so wichtig, dass es sich lohnt, es noch einmal zu wiederholen: Alles ist Code! Ihre Anwendung, wie sie bereitgestellt wird, wie sie verfolgt wird, wie sie konfiguriert wird usw. sind alle entsprechend versionierten Codefragmente, die in GitHub / GitLab / Anywhere gespeichert sind. Ziel ist es, eine Umgebung ohne Inkonsistenzen für die Hauptentwickler (Softwareentwickler, die Funktionscode schreiben) zu schaffen.

Zum Beispiel sollte ich in der Lage sein:

  • schreibe deinen eigenen kleinen Microservice;
  • Fügen Sie alle Tests hinzu, die ich für notwendig halte.
  • Jenkinsfile hinzufügen
  • Überwachung als Code-Konfiguration hinzufügen;
  • Geben Sie meine Parameter in der Datei env.yaml an.
  • Speichern Sie dies alles in einem Repository.
  • Lassen Sie Jenkins das angegebene Repository automatisch erkennen.
  • Bauen Sie Ihren Microservice auf.
  • Probier es aus;
  • Erweitern (mit der kanarischen oder blaugrünen Methode);
  • Senden Sie anschließend eine Nachricht an Ihre E-Mail!

Dies ist das Ziel, dessen Erreichung die Essenz der Kernaufgabe der DevOps-Ingenieure ist.

Alternativen zu Jenkins


Wie ich bereits sagte, gibt es Jenkins schon seit Ewigkeiten, und heute gibt es meiner Meinung nach andere, die besten, wenn auch weniger populären Alternativen. Eines davon ist AWS CodeDeploy . Es gibt Einschränkungen, aber die Entwickler haben im letzten Jahr erhebliche Verbesserungen vorgenommen. Wenn Sie in AWS arbeiten, sollten Sie CodeDeploy ausprobieren.

Die zweite Alternative ist das kontinuierliche Integrationsmodul GitLab CI. Wenn in Ihrer Organisation GitLab ausgeführt wird, sollten Sie wahrscheinlich damit beginnen, da es ziemlich gut in den Rest von GitLab integriert ist.

Schließlich hat GitHub ein eigenes Tool zum Bereitstellen von Actions- Anwendungen angekündigt , das von der eigenen Automatisierung unterstützt wird.

Tatsächlich denke ich nicht, dass Tools hier so wichtig sind. Es ist wichtig zu wissen, dass alles, einschließlich der Code-Bereitstellungs-Pipelines, versionierte Artefakte sind und nichts zu produzieren ist, es sei denn, es stammt von dev.

Unabhängig davon, ob Sie mit Jenkins beginnen, versuchen Sie, es als Container einzurichten. Es ist nicht sehr schwierig und bietet eine hervorragende Gelegenheit, die Bereitstellung eines Jenkins-Containerservers mit Jenkins erweiterbaren Container-Arbeitsknoten zu erlernen. Tatsächlich können Sie ohne Container-Orchestrierung beginnen, die Gegenstand des nächsten Artikels ist.

Wird sehr bald fortgesetzt ...

Ein bisschen Werbung :)


Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

More articles:


All Articles