Wir beginnen unseren Blog mit Veröffentlichungen, die auf den neuesten Reden unseres technischen Direktors basieren (Dmitri Stolyarov). Sie alle fanden im Jahr 2016 auf verschiedenen Fachveranstaltungen statt und widmeten sich dem Thema DevOps und Docker. Ein Video vom Docker-Moskau-Treffen im Badoo-Büro haben wir bereits auf der Seite. Neue Beiträge werden von Artikeln begleitet, die den Kern der Berichte vermitteln. Also…
31. Mai auf der Konferenz Im Rahmen des Festivals „Russian Internet Technologies“ (RIT++ 2016) wurde der Abschnitt „Continuous Deployment and Deployment“ mit dem Bericht „Best Practices of Continuous Delivery with Docker“ eröffnet. Es fasste und systematisierte die Best Practices für den Aufbau eines Continuous Delivery (CD)-Prozesses mit Docker und anderen Open-Source-Produkten zusammen. Mit diesen Lösungen arbeiten wir in der Produktion und können dabei auf praktische Erfahrungen zurückgreifen.
Wenn Sie die Möglichkeit haben, eine Stunde zu verbringen , empfehlen wir, es vollständig anzusehen. Ansonsten finden Sie unten die Hauptzusammenfassung in Textform.
Kontinuierliche Lieferung mit Docker
Unter Kontinuierliche Liefer Wir verstehen die Kette von Ereignissen, durch die der Anwendungscode aus dem Git-Repository zunächst in die Produktion gelangt und dann im Archiv landet. Sie sieht so aus: Git → Build → Test → Release → Operate.
Der größte Teil des Berichts ist der Build-Phase (Anwendungsmontage) gewidmet, und die Themen Release und Betrieb werden kurz angesprochen. Wir werden über Probleme und Muster sprechen, mit denen Sie sie lösen können. Die spezifischen Implementierungen dieser Muster können unterschiedlich sein.
Warum wird Docker hier überhaupt benötigt? Nicht umsonst haben wir uns entschieden, im Zusammenhang mit diesem Open-Source-Tool über Continuous-Delivery-Praktiken zu sprechen. Obwohl der gesamte Bericht seiner Verwendung gewidmet ist, werden viele Gründe deutlich, wenn man das Hauptmuster der Einführung von Anwendungscode betrachtet.
Haupt-Rollout-Muster
Wenn wir also neue Versionen der Anwendung einführen, stehen wir mit Sicherheit vor der Herausforderung Ausfallzeitproblem, generiert beim Wechsel des Produktionsservers. Der Datenverkehr von der alten Version der Anwendung zur neuen kann nicht sofort wechseln: Zuerst müssen wir sicherstellen, dass die neue Version nicht nur erfolgreich heruntergeladen, sondern auch „aufgewärmt“ (d. h. vollständig bereit für die Bearbeitung von Anfragen) ist.
Daher werden für einige Zeit beide Versionen der Anwendung (alt und neu) gleichzeitig funktionieren. Was automatisch dazu führt Konflikt mit gemeinsam genutzten Ressourcen: Netzwerk, Dateisystem, IPC usw. Mit Docker lässt sich dieses Problem leicht lösen, indem verschiedene Versionen der Anwendung in separaten Containern ausgeführt werden, wobei die Ressourcenisolation innerhalb desselben Hosts (Server/virtuelle Maschine) gewährleistet ist. Natürlich kommt man mit einigen Tricks ganz ohne Isolierung aus, aber wenn es ein fertiges und praktisches Werkzeug gibt, dann gibt es den gegenteiligen Grund – es nicht zu vernachlässigen.
Die Containerisierung bietet bei der Bereitstellung viele weitere Vorteile. Jede Anwendung hängt davon ab spezifische Version (oder Versionsbereich) Dolmetscher, Verfügbarkeit von Modulen/Erweiterungen etc. sowie deren Versionen. Und das gilt nicht nur für die unmittelbare ausführbare Umgebung, sondern für die gesamte Umgebung, einschließlich Systemsoftware und deren Version (bis zur verwendeten Linux-Distribution). Da Container nicht nur Anwendungscode, sondern auch vorinstallierte System- und Anwendungssoftware in den erforderlichen Versionen enthalten, können Sie Probleme mit Abhängigkeiten vergessen.
Lassen Sie uns verallgemeinern Haupt-Rollout-Muster neue Versionen unter Berücksichtigung folgender Faktoren:
- Im ersten Container läuft zunächst die alte Version der Anwendung.
- Anschließend wird die neue Version in einem zweiten Container ausgerollt und „aufgewärmt“. Es ist bemerkenswert, dass diese neue Version selbst möglicherweise nicht nur aktualisierten Anwendungscode, sondern auch alle seine Abhängigkeiten sowie Systemkomponenten (z. B. eine neue Version von OpenSSL oder die gesamte Distribution) enthält.
- Wenn die neue Version vollständig bereit ist, Anfragen zu bedienen, wechselt der Datenverkehr vom ersten Container zum zweiten.
- Die alte Version kann nun gestoppt werden.
Dieser Ansatz, verschiedene Versionen der Anwendung in separaten Containern bereitzustellen, bietet einen weiteren Komfort: schneller Rollback auf die alte Version (schließlich reicht es, den Verkehr auf den gewünschten Container umzustellen).
Die abschließende erste Empfehlung klingt nach etwas, woran selbst der Kapitän nichts auszusetzen hatte: „[bei der Organisation von Continuous Delivery mit Docker] Verwenden Sie Docker [und verstehen, was es gibt]" Denken Sie daran, dass dies kein Allheilmittel ist, das jedes Problem löst, sondern ein Werkzeug, das eine wunderbare Grundlage bietet.
Reproduzierbarkeit
Unter „Reproduzierbarkeit“ verstehen wir eine allgemeine Reihe von Problemen, die beim Betrieb von Anwendungen auftreten. Wir sprechen über solche Fälle:
- Von der Qualitätsabteilung für die Inszenierung überprüfte Skripte müssen in der Produktion genau reproduziert werden.
- Anwendungen werden auf Servern veröffentlicht, die Pakete von verschiedenen Repository-Spiegeln empfangen können (im Laufe der Zeit werden sie aktualisiert und mit ihnen die Versionen der installierten Anwendungen).
- „Vor Ort funktioniert bei mir alles!“ (...und Entwickler haben keinen Zutritt zur Produktion.)
- Sie müssen etwas in der alten (archivierten) Version überprüfen.
- ...
Ihr allgemeiner Kern besteht darin, dass die vollständige Einhaltung der verwendeten Umgebungen (sowie die Abwesenheit des menschlichen Faktors) erforderlich ist. Wie können wir die Reproduzierbarkeit gewährleisten? Erstellen Sie Docker-Images basierend auf Code von Git, und verwenden Sie sie dann für jede Aufgabe: auf Teststandorten, in der Produktion, auf lokalen Computern von Programmierern ... Gleichzeitig ist es wichtig, die durchgeführten Aktionen zu minimieren nach Zusammensetzen des Bildes: Je einfacher es ist, desto unwahrscheinlicher sind Fehler.
Infrastruktur ist Code
Wenn die Infrastrukturanforderungen (Verfügbarkeit der Serversoftware, deren Version usw.) nicht formalisiert und „programmiert“ sind, kann die Einführung eines Anwendungsupdates katastrophale Folgen haben. Wenn Sie beispielsweise im Staging bereits auf PHP 7.0 umgestiegen sind und den Code entsprechend umgeschrieben haben, wird sein Erscheinen in der Produktion mit etwas altem PHP (5.5) sicherlich jemanden überraschen. Sie dürfen eine große Änderung in der Interpreterversion nicht vergessen, aber „der Teufel steckt im Detail“: Die Überraschung kann in einer geringfügigen Aktualisierung einer Abhängigkeit liegen.
Ein Ansatz zur Lösung dieses Problems ist bekannt als IaC (Infrastruktur als Code, „Infrastruktur als Code“) und beinhaltet das Speichern von Infrastrukturanforderungen zusammen mit dem Anwendungscode. Damit können Entwickler und DevOps-Spezialisten mit demselben Git-Anwendungs-Repository arbeiten, jedoch an unterschiedlichen Teilen davon. Aus diesem Code wird in Git ein Docker-Image erstellt, in dem die Anwendung unter Berücksichtigung aller Besonderheiten der Infrastruktur bereitgestellt wird. Einfach ausgedrückt: Die Skripte (Regeln) zum Zusammenstellen von Bildern sollten sich im selben Repository wie der Quellcode befinden und zusammengeführt werden.
Bei einer mehrschichtigen Anwendungsarchitektur – es gibt zum Beispiel nginx, das vor einer Anwendung steht, die bereits innerhalb eines Docker-Containers läuft – müssen für jede Schicht Docker-Images aus Code in Git erstellt werden. Dann enthält das erste Image eine Anwendung mit einem Interpreter und anderen „engen“ Abhängigkeiten, und das zweite Image enthält den Upstream-Nginx.
Docker-Images, Kommunikation mit Git
Wir unterteilen alle von Git gesammelten Docker-Images in zwei Kategorien: temporär und freigegeben. Temporäre Bilder sind mit dem Namen des Zweigs in Git gekennzeichnet, können beim nächsten Commit überschrieben werden und werden nur für die Vorschau (nicht für die Produktion) ausgerollt. Dies ist ihr Hauptunterschied zu Release-Versionen: Sie wissen nie, welcher spezifische Commit darin enthalten ist.
Es ist sinnvoll, in temporären Bildern zu sammeln: den Master-Branch (Sie können ihn automatisch auf eine separate Site ausrollen, um ständig die aktuelle Master-Version zu sehen), Branches mit Releases, Branches mit bestimmten Innovationen.
Nachdem die Vorschau temporärer Bilder die Notwendigkeit einer Übersetzung in die Produktion erfordert, setzen die Entwickler ein bestimmtes Tag. Automatisch nach Tag gesammelt Bild freigeben (sein Tag entspricht dem Tag von Git) und wird im Staging ausgerollt. Bei erfolgreicher Verifizierung durch die Qualitätsabteilung geht es in die Produktion.
dapp
Alles Beschriebene (Rollout, Image-Assemblierung, anschließende Wartung) kann mithilfe von Bash-Skripten und anderen „improvisierten“ Tools selbstständig umgesetzt werden. Aber wenn man das macht, dann führt die Umsetzung irgendwann zu großer Komplexität und schlechter Kontrollierbarkeit. Als wir dies erkannten, entwickelten wir unser eigenes spezielles Workflow-Dienstprogramm für die Erstellung von CI/CD – dapp.
Der Quellcode ist in Ruby geschrieben, Open Source und wird auf veröffentlicht . Leider ist die Dokumentation derzeit der schwächste Punkt des Tools, aber wir arbeiten daran. Und wir werden mehr als einmal über den Dapp schreiben und reden, weil... Wir können es kaum erwarten, seine Fähigkeiten mit der gesamten interessierten Community zu teilen, aber in der Zwischenzeit senden Sie Ihre Probleme und Pull-Requests und/oder verfolgen Sie die Entwicklung des Projekts auf GitHub.
Aktualisiert am 13. August 2019: derzeit ein Projekt dapp umbenannt in Der Code wurde in Go komplett neu geschrieben und die Dokumentation wurde erheblich verbessert.
Kubernetes
Ein weiteres fertiges Open-Source-Tool, das im professionellen Umfeld bereits große Anerkennung gefunden hat, ist Kubernetes, ein Docker-Verwaltungscluster. Das Thema seiner Verwendung beim Betrieb von auf Docker basierenden Projekten geht über den Rahmen des Berichts hinaus, daher beschränkt sich die Präsentation auf einen Überblick über einige interessante Funktionen.
Für den Rollout bietet Kubernetes:
- Bereitschaftsprüfung – Überprüfung der Bereitschaft einer neuen Version der Anwendung (um den Datenverkehr dorthin umzuleiten);
- Rolling Update – sequentielles Image-Update in einem Cluster von Containern (Herunterfahren, Update, Vorbereitung für den Start, Verkehrsumschaltung);
- synchrones Update – Aktualisieren eines Images in einem Cluster mit einem anderen Ansatz: zuerst auf der Hälfte der Container, dann auf dem Rest;
- Canary-Releases – Starten eines neuen Images auf einer begrenzten (kleinen) Anzahl von Containern, um Anomalien zu überwachen.
Da es sich bei Continuous Delivery nicht nur um die Veröffentlichung einer neuen Version handelt, bietet Kubernetes eine Reihe von Möglichkeiten für die anschließende Wartung der Infrastruktur: integrierte Überwachung und Protokollierung für alle Container, automatische Skalierung usw. All dies funktioniert bereits und wartet nur auf die ordnungsgemäße Wartung Umsetzung in Ihren Prozessen.
Abschließende Empfehlungen
- Verwenden Sie Docker.
- Erstellen Sie Docker-Images von Anwendungen für alle Ihre Anforderungen.
- Folgen Sie dem Grundsatz „Infrastruktur ist Code“.
- Verknüpfen Sie Git mit Docker.
- Regulieren Sie die Reihenfolge des Rollouts.
- Verwenden Sie eine vorgefertigte Plattform (Kubernetes oder eine andere).
Videos und Folien
Video vom Auftritt (ca. eine Stunde) (Der Bericht selbst beginnt ab der 5. Minute – folgen Sie dem Link, um ab diesem Moment abzuspielen).
Präsentation des Berichts:
PS
Weitere Berichte zum Thema auf unserem Blog:
- «» (Dmitry Stolyarov; 27. Mai 2019 auf der DevOpsConf);
- «» (Dmitry Stolyarov; 8. November 2018 auf HighLoad++);
- «» (Dmitry Stolyarov; 7. November 2017 auf HighLoad++);
- «» (Dmitry Stolyarov; 6. Juni 2017 bei RootConf).
Source: habr.com