Containerisierungstransformation für Docker-Großprojekte

Virtualisierung und Containerisierung sind zwei unvermeidliche Probleme bei Cloud-basierten Projekten. Da es sich bei der Virtualisierung um einen reinen Plattformvorgang handelt, muss ein auf dem Linux-Betriebssystem ausgeführtes Projekt nicht geändert werden, um die Virtualisierung zu unterstützen. Wenn das Projekt die Containerisierung unterstützen möchte, sind umfangreiche Detailtransformationsarbeiten erforderlich. Auch die Vorteile der Containerisierung gegenüber der Virtualisierung liegen auf der Hand. Sie bietet eine hohe Leistung beim Betrieb auf Bare Metal und kann Container in Sekundenschnelle starten und stoppen, ganz zu schweigen von einer konsistenten Umgebung für Entwicklung, Tests und Bereitstellung (DevOps-Konzept) sowie den im vorherigen Artikel erwähnten Microservice-Funktionen. Sie können auch verschiedene Artikel finden, die Ihnen Kenntnisse zur Containerisierung (Docker) vermitteln, deshalb werden wir hier nicht näher darauf eingehen. Als Nächstes stellen wir basierend auf der tatsächlichen Situation des Projekts die Probleme und Lösungen vor, die bei der Containerisierungstransformation auftreten.

Containerisieren Sie ein großes Projekt mit Hunderttausenden Zeilen C++-Code und Dutzenden von Anwendungen. Wie Sie die Änderungen am Originalcode minimieren oder sogar die Notwendigkeit von Codeänderungen vollständig vermeiden können. So erledigen Sie dies im Stillen, ohne dass die Business-Programmierer es überhaupt bemerken. So minimieren Sie die Größe von Geschäftsbildern. So erstellen Sie schnell ein Unternehmensimage. Dies sind Probleme, die uns schon seit langer Zeit beschäftigen. Wenn bei der Klassifizierung von Containern die Code-Organisation und -Architektur angepasst werden muss, ist das bei Projekten mit Hunderttausenden von Zeilen eine Katastrophe. Wenn sich das Entwicklungsmodell nach der Transformation zu drastisch ändert, stehen Dutzende oder Hunderte von Business-Programmierern zwangsläufig vor einem Prozess des Neulernens und der Anpassung, der unglaublich kostspielig ist. Die Größe des Geschäftsimages wirkt sich direkt auf die Benutzerfreundlichkeit der Aktualisierung des Containers vor Ort aus, insbesondere wenn sich das Projekt im Ausland befindet und die Netzwerkgeschwindigkeit nicht sehr hoch ist. Die automatisierte und schnelle Bilderstellung ist der Schlüssel zur agilen Entwicklung.

1. So fangen Sie an

Das Verschieben eines unter Linux laufenden Projekts in einen Container ist normalerweise das erste Problem, auf das man stößt. Suchen Sie im Internet nach einem Basis-Image mit einem gcc-Compiler und einem Linux-Betriebssystem. Basierend auf diesem Image können Sie zunächst ein Build-Image für die Kompilierung und CI-Prüfung (Codeprüfung, Ausführen von Unit-Tests usw.) erstellen. Verwenden Sie das Build-Image zur Kompilierung und CI-Prüfung, erstellen Sie dann ein lauffähiges Image basierend auf dem Basis-Image und kopieren Sie die kompilierten Bibliotheken und ausführbaren Programme hinein (über Dockerfile). So entsteht ein möglichst einfaches Bild.

Das mit der obigen Methode erstellte Geschäftsimage kann ausgeführt werden, es gibt jedoch zwei Probleme: Die Produktionszeit ist sehr lang (unser Projekt dauert eine Stunde) und die Geschäftsebene des Images ist sehr groß (unser Projekt hat 1 GB). Diese beiden Probleme sind nicht besonders gravierend, können jedoch sehr lästig werden, wenn das Projekt kommerziell genutzt wird.

2. Container-Schichtung

Das Konzept der Container-Schichtung ist das Kernkonzept von Docker, das unterstützt, dass jeder Container von einem anderen Container „erben“ kann. Die Vererbung sollte hier dem gleichen Konzept entsprechen wie die Vererbung in der objektorientierten Programmierung. Zusätzlich zu den Vorteilen der „Vererbungs“-Funktion besteht bei einer Änderung des zugrunde liegenden Images keine Notwendigkeit, das Image der höheren Ebene zu aktualisieren, sodass wesentlich weniger Dinge aktualisiert werden müssen. Es ist wirklich großartig, ich hätte nicht gedacht, dass objektorientierte Vererbung so nützlich ist! Beeinflusst durch diese Funktion haben wir die im Projekt verwendeten Bibliotheken von Drittanbietern in eine separate Ebene aufgeteilt. Auch der Produktionsprozess ändert sich entsprechend, wie in der folgenden Abbildung dargestellt.

Obwohl der Prozess einen weiteren Schritt umfasst, ist die Wirkung sofort spürbar. Die Produktionszeit der Geschäftsschicht wird von 1 Stunde auf 12 Minuten verkürzt und die Größe auf etwa 100 MB reduziert.

3. Klassifizierung von Geschäftscontainern

Gemäß den Best Practices von Docker sollte ein Container nur einen Programmtyp oder eine Programmkategorie ausführen. Nach wie vor ist es definitiv nicht sinnvoll, in einem Container Dutzende Prozesse auszuführen. Klar klassifizierte Behälter erleichtern zudem die Verwaltung und Durchführung verschiedener Vorgänge. Gleichzeitig wird in den Best Practices für Microservices empfohlen, den Projektcode in Microservices aufzuteilen. Der Code jedes Microservices wird von einem anderen Team gepflegt und ist voneinander unabhängig. Auf die Vor- und Nachteile dieses Ansatzes gehen wir vorerst nicht näher ein. Das ursprüngliche Projekt war ein großes Projekt mit Hunderttausenden von Zeilen und Dutzenden von Programmen, Dutzenden von Entwicklern, unzähligen gemeinsamen Modulen und es war üblich, dass jedes Modul auf die anderen verwies. Jedes Programm bestand aus einer unterschiedlichen Anzahl von Modulen. Wenn die Geschäftsklassifizierung von Docker gemäß den oben genannten Vorschlägen durchgeführt wird, wird dies zweifellos große Änderungen am Projekt mit sich bringen und umfangreiche Anpassungen der Organisationsstruktur erfordern, was nahezu eine unmögliche Aufgabe ist. Wie können wir also Container klassifizieren und gleichzeitig das ursprüngliche Entwicklungsmodell unverändert lassen? Manchmal ist es der beste Weg, eine neue Technologie voranzubringen, die Veränderung unmerklich zu machen.

Die Methode ist eigentlich sehr einfach. Im Container befindet sich ein Skript namens docker-entrypoint.sh, das verwaltet, welche Prozesse nach dem Start des Containers gestartet werden sollen. Wir haben oben ein einheitliches Image für das Projekt erstellt. Beim Klassifizieren müssen wir nur verschiedene Docker-Entrypoint.sh ändern, um je nach Containertyp unterschiedliche Prozesstypen zu starten. Es ist notwendig, unterschiedliche Umgebungsvariablen, unterschiedliche Konfigurationsdateien usw. festzulegen. Natürlich, es ist alles ganz einfach!

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an