Ich habe in verschiedenen Unternehmen gearbeitet, die Microservices einsetzen. Und sie ließen sie in Docker-Containern laufen. Jetzt arbeite ich mit einem Projekt, das zwar ein Monolith ist, aber dennoch bequemer in einem Container ausgeführt werden kann.
Einerseits ist Docker ein sehr vielseitiges Werkzeug, mit dem sich eine Vielzahl von Aufgaben einfach und effektiv lösen lassen. Es ist verständlich und es scheint, dass alles elementar ist. Wenn Sie jedoch nicht Ihre Zeit und Ressourcen aufwenden, um die ordnungsgemäße Verwendung zu „pumpen“, werden Sie wahrscheinlich einfache Dinge überkomplizieren. Und natürlich gehen Sie davon aus, dass Sie Recht haben, und Docker ist ein mittelmäßiger, sperriger Müll, der nicht zur Lösung Ihrer einzigartigen Aufgabe geeignet ist.
Normalerweise sieht in einem Standardunternehmen die Bearbeitung einer Aufgabe folgendermaßen aus:
- Git Push wird mit unserem Commit durchgeführt
- Ein System wird ausgelöst, sei es Jenkins, TeamCity usw.
- Pipeline / Job wird gestartet, in dem Bibliotheken von Drittanbietern heruntergeladen, das Projekt kompiliert und Tests ausgeführt werden
- Ein Docker-Image mit dem zusammengestellten Projekt (ADD ..) wird erstellt und in die Remote-Docker-Registrierung verschoben
- Irgendwie wird auf dem Remote-Server das Docker-Pull ausgeführt (Koch, Marionette, manuell über Docker-Compose) und der Container gestartet.
Intuitiv hatte ich immer das Gefühl, dass alles irgendwie zu kompliziert war. Dieser Prozess heißt stolz CI / CD, und ich habe solche klugen Leute satt, die keinen Zweifel daran haben, dass dies der einfachste Weg ist.
Für den Endbenutzer sieht es so aus: Durch Drücken auf das Git-Repository wird das, was sich im Commit befand, irgendwo entfaltet.
Was ich an diesem Ansatz NICHT mag.
- Die einzige Möglichkeit, das System auf einem Remote-Server bereitzustellen, besteht darin, alle fünf Schritte auszuführen.
- In Schritt 3 benötigen Sie möglicherweise Zugriffsschlüssel für private Bibliotheken. Der Vorgang kann lang sein, wenn das Zwischenspeichern zuvor heruntergeladener Bibliotheken nicht konfiguriert ist.
- Sie müssen die Docker-Datei vorbereiten, das Image festlegen (FROM ...), festlegen, wie das Image markiert werden soll, und Zugriff auf das Repository benötigen, in das das Image übertragen wird.
- Benötigen Sie ein eigenes Repository, konfigurieren Sie https. Schließlich funktioniert der Docker-Client nur mit https.
Der vierte Absatz wird natürlich einmal gemacht und sollte vielleicht nicht hinzugefügt werden.
Aber wie oft wird das Wort Docker bereits in der Veröffentlichungsphase erwähnt?
Denken Sie darüber nach: Warum ziehen wir all diesen Docker vorzeitig? Weil angenommen wird, dass der Behälter bequem ist und „Nun, alles war in Ordnung, es funktioniert. Was fängst du dann an? “.
Für solche Leute kann ich also sagen - Docker-Container sind kein Allheilmittel und nicht die einzige Umgebung, in der Ihre Anwendung ausgeführt werden kann. Projekt geschrieben in Python, PHP, JS, Swift, Scala / Java usw. kann ausgeführt werden auf:
- entfernte virtuelle Maschine
- auf einem lokalen Host ohne Virtualisierungs- und Docker-Container.
Auf einmal :)
Stellen wir uns vor, wir erstellen einen Dienst, der auf nodeJS ausgeführt wird.
Das Ergebnis dieses Projekts (oder wie ich das 'Artefakt' nenne) ist eine Reihe von js-Dateien (der Dienst selbst) + node_modules (Bibliotheken von Drittanbietern, die im Dienst verwendet werden).
Angenommen, wir haben sichergestellt, dass der Dienst funktioniert, und möchten ihn remote ausführen, damit unsere Tester ihn auf Funktionalität testen können.
Wie gefällt Ihnen diese Idee:
- Wir machen .tar.gz mit unserem Projekt und laden es in ... Remote-Repository von Artefakten hoch! (Solche Repositorys werden auch als "binäres Repository" bezeichnet.)
- Wir geben die URL an, über die sie unseren Service herunterladen und mit dem Testen beginnen können.
Außerdem können Tester den Dienst entweder lokal zu Hause starten, wenn sie über alles verfügen, oder eine Docker-Datei erstellen, in der ein Artefakt heruntergeladen wird, und einfach den Container starten. Na ja, oder was anderes.
Ich sage sofort, wenn Sie nicht möchten, dass Tester Docker-Container starten und im Allgemeinen "es ist nicht ihre Aufgabe", dann starten Sie ein Tool, das Bilder sammelt, sobald neue Artefakte im binären Repository erscheinen (verwenden Sie den Web-Hook, jagen Sie regelmäßig über die Krone).
Aus binären Repositorys gibt es nun:
Nexus ist einfach zu bedienen, es gibt eine Reihe verschiedener Repositorys, die Sie erstellen können (npm, maven, raw, docker), also benutze ich es.
Dies ist eine verdammt einfache Idee. Warum habe ich nirgendwo darüber gelesen? Im Internet können Sie keine Artikel zählen, "wie bei Git Push irgendwo, wo ein Container in einer Art Kubernet bereitgestellt wird". Von solch komplexen Algorithmen stehen die Haare zu Berge.
Der Zweck dieses Artikels ist beispielsweise, dass es nicht erforderlich ist, das Projekt in einem Prozess zusammenzustellen und dem Docker-Image hinzuzufügen.
Teilen und herrschen!
Erstellen Sie das Projekt und veröffentlichen Sie Artefakte an einem herunterladbaren Ort. (Die Docker-Registrierung ist nicht der einzige Ort, an dem Sie Ihr Projekt speichern und universelle Pfade für die Bereitstellung von Artefakten an Server auswählen können.)
Stellen Sie mit einem separaten Tool Artefakte an den Server bereit, auf dem Ihr Projekt ausgeführt werden soll.
Alles ist sehr einfach. Geben Sie anderen die Wahl: Verwenden Sie Docker, führen Sie Kubernetes aus oder verwenden Sie ein anderes Tool, um Artefakte auszuführen. Sie müssen den Einsatz von Technologie nicht auferlegen, obwohl sie Ihnen sehr bequem und modisch erscheint.
Viel Glück beim Start Ihrer Projekte!