Ist Docker ein Spielzeug oder nicht? Oder stimmt es immer noch?

Hallo an alle!

Ich möchte eigentlich gleich zum Thema kommen, richtiger wäre es aber, ein wenig über meine Geschichte zu erzählen:

Eintrag

Ich bin ein Programmierer mit Erfahrung in der Entwicklung von Frontend-Single-Page-Anwendungen, Scala/Java und NodeJS auf dem Server.

Lange Zeit (auf jeden Fall ein paar bis drei Jahre) war ich der Meinung, dass Docker ein Wunder vom Himmel und generell ein sehr cooles Tool ist und dass absolut jeder Entwickler in der Lage sein sollte, es zu nutzen. Und daraus folgt, dass jeder Entwickler Docker auf seinem lokalen Rechner installiert haben sollte. Was ist meine Meinung? Schauen Sie sich die Stellenangebote an, die auf derselben Seite ausgeschrieben sind. Jede Sekunde enthält eine Erwähnung von Docker, und wenn Sie es besitzen, ist dies Ihr Wettbewerbsvorteil 😉

Auf meinem Weg traf ich viele Menschen mit unterschiedlichen Einstellungen gegenüber Docker und seinem Ökosystem. Einige sagten, dass dies eine praktische Sache sei, die plattformübergreifende Funktionalität garantiere. Die zweiten verstanden nicht, warum sie in Containern laufen sollten und welchen Gewinn sie daraus ziehen würden, die dritten kümmerten sich überhaupt nicht darum und kümmerten sich nicht darum (sie schrieben einfach den Code und gingen nach Hause – ich beneide sie übrigens Weg :)

Gründe für die Verwendung

Warum habe ich Docker verwendet? Wahrscheinlich aus folgenden Gründen:

• Datenbankstart, 99 % der Anwendungen nutzen sie
• Starten von Nginx für die Frontend-Verteilung und Proxy für das Backend
• Sie können die Anwendung in ein Docker-Image packen. Auf diese Weise funktioniert meine Anwendung überall dort, wo Docker vorhanden ist. Das Verteilungsproblem ist sofort gelöst
• Mit der sofort einsatzbereiten Serviceerkennung können Sie Microservices erstellen. Jeder Container (verbunden mit einem gemeinsamen Netzwerk) kann problemlos über einen Alias ​​​​einen anderen erreichen, was sehr praktisch ist
• Es macht Spaß, einen Container zu erstellen und darin zu „spielen“.

Was mir an Docker immer NICHT gefällt:

• Damit meine Anwendung funktioniert, benötige ich Docker selbst auf dem Server. Warum brauche ich das, wenn meine Anwendungen auf JRE oder NodeJS laufen und die Umgebung dafür bereits auf dem Server ist?
• Wenn ich mein (privates) lokal erstelltes Image auf einem Remote-Server ausführen möchte, benötige ich mein eigenes Docker-Repository, die Registrierung muss irgendwo funktionieren und ich muss auch https konfigurieren, da Docker CLI nur über https funktioniert. Oh verdammt... es gibt natürlich Möglichkeiten, das Bild lokal zu speichern über docker save und senden Sie das Bild einfach über scp ... Aber das sind viele Körperbewegungen. Und außerdem sieht es wie eine „Krückenlösung“ aus, bis Ihr eigenes Repository erscheint
• docker-compose. Es wird nur zum Ausführen von Containern benötigt. Und alle. Er kann nichts anderes tun. Docker-compose hat eine Reihe von Versionen seiner Dateien und eine eigene Syntax. Egal wie deklarativ es ist, ich möchte ihre Dokumentation nicht lesen. Ich werde es nirgendwo anders brauchen.
• Bei der Arbeit im Team schreiben die meisten Leute eine Docker-Datei sehr schief, verstehen nicht, wie sie zwischengespeichert wird, fügen dem Image alles hinzu, was sie brauchen und was nicht, erben von Images, die sich nicht in Dockerhub oder einem privaten Repository befinden, und erstellen welche docker-compose Dateien mit Datenbanken und nichts bleibt bestehen. Gleichzeitig erklären die Entwickler stolz, dass Docker cool ist, bei ihnen funktioniert alles lokal, und die Personalabteilung schreibt in der Stellenausschreibung wichtig: „Wir verwenden Docker und brauchen einen Kandidaten mit solcher Berufserfahrung.“
• Ich werde ständig von dem Gedanken heimgesucht, alles in Docker zu erhöhen: Postgresql, Kafka, Redis. Schade, dass nicht alles in Containern funktioniert, nicht alles einfach zu konfigurieren und auszuführen ist. Dies wird von Drittentwicklern und nicht von den Anbietern selbst unterstützt. Und nebenbei stellt sich sofort die Frage: Anbieter kümmern sich nicht um die Wartung ihrer Produkte in Docker, warum ist das so, vielleicht wissen sie etwas?
• Es stellt sich immer die Frage nach der Persistenz von Containerdaten. Und dann denken Sie, soll ich einfach das Host-Verzeichnis mounten oder ein Docker-Volume erstellen oder einen Datencontainer erstellen, der jetzt verfügbar ist? deprecated? Wenn ich ein Verzeichnis mounte, muss ich sicherstellen, dass die UID und GID des Benutzers im Container mit der ID des Benutzers übereinstimmen, der den Container gestartet hat, andernfalls werden die vom Container erstellten Dateien mit Root-Rechten erstellt. Wenn ich es benutze volume dann werden die Daten einfach in einigen erstellt /usr/* und es wird die gleiche Geschichte mit uid und gid geben wie im ersten Fall. Wenn Sie eine Komponente eines Drittanbieters starten, müssen Sie die Dokumentation lesen und nach der Antwort auf die Frage suchen: „In welche Containerverzeichnisse schreibt die Komponente Dateien?“

Es hat mir immer nicht gefallen, dass ich zu lange an Docker herumbasteln musste im Anfangsstadium: Ich habe herausgefunden, wie man Container startet, von welchen Images man startet, und Makefiles erstellt, die Aliase für lange Docker-Befehle enthalten. Ich hasste Docker-Compose, weil ich kein anderes Tool im Docker-Ökosystem lernen wollte. UND docker-compose up Es störte mich, besonders wenn sie sich dort noch trafen build Konstruktionen statt bereits zusammengesetzter Bilder. Alles, was ich wirklich wollte, war, ein Produkt effizient und schnell herzustellen. Aber ich konnte nicht herausfinden, wie man Docker benutzt.

Wir stellen Ansible vor

Kürzlich (vor drei Monaten) habe ich mit einem DevOps-Team zusammengearbeitet, in dem fast jedes Mitglied eine negative Einstellung gegenüber Docker hatte. Auf Grund:

• Docker-Regeln für iptables (obwohl Sie es in daemon.json deaktivieren können)
• Docker ist fehlerhaft und wir werden es nicht in der Produktion ausführen
• Wenn der Docker-Daemon abstürzt, stürzen alle Container mit Infrastruktur entsprechend ab
• Docker ist nicht erforderlich
• Warum Docker, wenn es Ansible und virtuelle Maschinen gibt?

Im selben Job lernte ich ein weiteres Tool kennen – Ansible. Ich habe einmal davon gehört, aber ich habe nicht versucht, meine eigenen Spielbücher zu schreiben. Und jetzt habe ich angefangen, meine Aufgaben zu schreiben, und dann hat sich meine Vision völlig verändert! Denn mir wurde klar: Ansible verfügt über Module zum Ausführen derselben Docker-Container, Image-Builds, Netzwerke usw., und Container können nicht nur lokal, sondern auch auf Remote-Servern ausgeführt werden! Meine Freude kannte keine Grenzen – ich fand ein NORMALES Tool und warf meine Makefile- und Docker-Compose-Dateien weg, sie wurden durch Yaml-Aufgaben ersetzt. Der Code wurde durch die Verwendung von Konstrukten wie reduziert loop, when, usw.

Docker zum Ausführen von Drittanbieterkomponenten wie Datenbanken

Ich habe kürzlich SSH-Tunnel kennengelernt. Es stellte sich heraus, dass es sehr einfach ist, den Port eines Remote-Servers an einen lokalen Port „weiterzuleiten“. Der Remote-Server kann entweder eine Maschine in der Cloud oder eine virtuelle Maschine sein, die in VirtualBox ausgeführt wird. Wenn mein Kollege oder ich eine Datenbank (oder eine andere Komponente eines Drittanbieters) benötigen, können wir den Server einfach mit dieser Komponente starten und ihn ausschalten, wenn der Server nicht benötigt wird. Die Portweiterleitung hat den gleichen Effekt wie eine Datenbank, die in einem Docker-Container ausgeführt wird.

Dieser Befehl leitet meinen lokalen Port an einen Remote-Server weiter, auf dem postgresql ausgeführt wird:

ssh -L 9000:localhost:5432 [E-Mail geschützt]

Die Verwendung eines Remote-Servers löst das Problem der Teamentwicklung. Ein solcher Server kann von mehreren Entwicklern gleichzeitig verwendet werden; sie müssen nicht in der Lage sein, Postgresql zu konfigurieren, Docker und andere Feinheiten zu verstehen. Auf einem Remote-Server können Sie dieselbe Datenbank in Docker selbst installieren, wenn die Installation einer bestimmten Version schwierig ist. Alles, was Entwickler brauchen, ist SSH-Zugriff bereitzustellen!

Ich habe kürzlich gelesen, dass SSH-Tunnel eine eingeschränkte Funktionalität eines normalen VPN sind! Sie können einfach OpenVPN oder andere VPN-Implementierungen installieren, die Infrastruktur einrichten und sie den Entwicklern zur Nutzung übergeben. Das ist so cool!

Glücklicherweise gewähren Ihnen AWS, GoogleCloud und andere ein Jahr lang kostenlose Nutzung, also nutzen Sie sie! Sie sind günstig, wenn Sie sie bei Nichtgebrauch ausschalten. Ich habe mich immer gefragt, warum ich einen Remote-Server wie gcloud brauche, es scheint, dass ich sie gefunden habe.

Als lokale virtuelle Maschine können Sie dasselbe Alpine verwenden, das aktiv in Docker-Containern verwendet wird. Nun, oder einige andere leichtgewichtige Distributionen, um den Rechner schneller booten zu lassen.

Fazit: Sie können und sollten Datenbanken und andere Infrastruktur-Extras auf Remote-Servern oder in Virtualbox ausführen. Für diese Zwecke benötige ich kein Docker.

Ein wenig über Docker-Images und deren Verteilung

Ich habe schon geschrieben Artikel in dem ich zum Ausdruck bringen wollte, dass die Verwendung von Docker-Images keine Garantie bietet. Docker-Images werden nur zum Erstellen eines Docker-Containers benötigt. Wenn Sie ein Upgrade auf ein Docker-Image durchführen, führen Sie ein Upgrade zur Verwendung von Docker-Containern durch und verwenden nur diese.

Haben Sie irgendwo gesehen, wo Softwareentwickler ihre Produkte nur in einem Docker-Image portieren?
Das Ergebnis der meisten Produkte sind Binärdateien für eine bestimmte Plattform; sie werden einfach dem Docker-Image hinzugefügt, das von der gewünschten Plattform geerbt wird. Haben Sie sich jemals gefragt, warum es auf Dockerhub so viele ähnliche Bilder gibt? Geben Sie beispielsweise nginx ein, Sie sehen 100500 Bilder von verschiedenen Personen. Diese Leute haben Nginx nicht selbst entwickelt, sondern einfach offizielles Nginx zu ihrem Docker-Image hinzugefügt und es mit ihren eigenen Konfigurationen gewürzt, um das Starten von Containern zu erleichtern.

Im Allgemeinen können Sie es einfach in tgz speichern. Wenn jemand es in Docker ausführen muss, lassen Sie ihn tgz zur Docker-Datei hinzufügen, von der gewünschten Umgebung erben und zusätzliche Brötchen erstellen, die die Anwendung selbst in tgz nicht ändern. Jeder, der ein Docker-Image erstellt, weiß, was TGZ ist und was es zum Arbeiten benötigt. So verwende ich Docker hier

Fazit: Ich benötige keine Docker-Registrierung, ich verwende eine Art S3 oder einfach einen Dateispeicher wie Google Drive/Dropbox

Docker in CI

Alle Unternehmen, für die ich gearbeitet habe, sind ähnlich. Sie sind normalerweise Lebensmittelgeschäfte. Das heißt, sie haben eine Anwendung, einen Technologie-Stack (naja, vielleicht ein paar oder drei Programmiersprachen).

Diese Unternehmen verwenden Docker auf ihren Servern, auf denen der CI-Prozess ausgeführt wird. Frage: Warum müssen Sie Projekte in einem Docker-Container auf Ihren Servern erstellen? Warum bereiten Sie nicht einfach eine Umgebung für den Build vor, schreiben Sie beispielsweise ein Ansible-Playbook, das die erforderlichen Versionen von NodeJS, PHP, JDK installiert, SSH-Schlüssel usw. auf den Server kopiert, auf dem der Build stattfinden soll?

Jetzt verstehe ich, dass ich mir damit selbst ins Bein schieße, denn Docker bringt mit seiner Isolation keinen Gewinn. Probleme, die ich mit CI in Docker hatte:

• Auch hier benötigen Sie ein Docker-Image zum Erstellen. Sie müssen nach einem Bild suchen oder Ihre eigene Docker-Datei schreiben.
• Zu 90 % müssen Sie einige SSH-Schlüssel weiterleiten, geheime Daten, die Sie nicht in das Docker-Image schreiben möchten.
• Der Container wird erstellt und stirbt, alle Caches gehen mit ihm verloren. Beim nächsten Build werden alle Projektabhängigkeiten erneut heruntergeladen, was zeitaufwändig und ineffektiv ist und Zeit ist Geld.

Entwickler erstellen keine Projekte in Docker-Containern (ich war einmal so ein Fan, wirklich, früher tat ich mir selbst leid xD). In Java ist es möglich, mehrere Versionen zu haben und diese mit einem Befehl in die Version zu ändern, die Sie jetzt benötigen. Das Gleiche gilt für NodeJS, dort gibt es NVM.

Abschluss

Ich glaube, dass Docker ein sehr leistungsfähiges und flexibles Tool ist, das ist sein Nachteil (klingt seltsam, ja). Mit seiner Hilfe können sich Unternehmen leicht darauf einlassen und es dort einsetzen, wo es benötigt wird und wo nicht. Entwickler starten ihre Container und einige ihrer Umgebungen, dann fließt alles reibungslos in CI und Produktion ein. Das DevOps-Team schreibt eine Art Code, um diese Container auszuführen.

Verwenden Sie Docker nur auf der neuesten Ziehen Sie es nicht zu Beginn in das Projekt, sondern ziehen Sie es in eine bestimmte Phase Ihres Workflows. Es wird Ihre geschäftlichen Probleme nicht lösen. Er wird die Probleme nur auf eine ANDERE Ebene verschieben und seine eigenen Lösungen anbieten, Sie werden doppelte Arbeit leisten.

Wenn Docker benötigt wird: Ich bin zu dem Schluss gekommen, dass Docker sehr gut darin ist, einen bestimmten Prozess zu optimieren, aber nicht darin, grundlegende Funktionen aufzubauen

Wenn Sie sich dennoch für die Verwendung von Docker entscheiden, dann:

• Seien Sie äußerst vorsichtig
• Zwingen Sie Entwickler nicht zur Verwendung von Docker
• Lokalisieren Sie die Verwendung an einem Ort und verteilen Sie sie nicht auf alle Dockefile- und Docker-Compose-Repositorys

PS:

• Ich bin kürzlich darauf gestoßen Packer und sie sagen, dass es sehr gut mit Ansible funktioniert und Ihnen ermöglicht, den Prozess der Imageerstellung (einschließlich Docker-Image) zu vereinheitlichen.
• auch über Docker, interessanter Artikel

Vielen Dank fürs Lesen, ich wünsche Ihnen transparente Entscheidungen in Ihren Angelegenheiten und produktive Arbeitstage!

Source: habr.com