Irgendwann beschloss ich, einen Artikel über die Lieferung in Form von Docker-Containern und Deb-Paketen zu schreiben, aber als ich anfing, wurde ich aus irgendeinem Grund in die fernen Zeiten der ersten Personalcomputer und sogar Taschenrechner zurückversetzt. Im Allgemeinen haben wir anstelle trockener Vergleiche von Docker und Deb diese Gedanken zum Thema Evolution erhalten, die ich Ihnen zur Überlegung vorstelle.
Jedes Produkt, egal um welches es sich handelt, muss irgendwie auf die Produktserver gelangen, konfiguriert und gestartet werden. Darum geht es in diesem Artikel.
Ich werde in einem historischen Kontext denken: „Was ich sehe, ist das, worüber ich singe“, was ich sah, als ich anfing, Code zu schreiben, und was ich jetzt beobachte, was wir selbst im Moment verwenden und warum. Der Artikel erhebt nicht den Anspruch, eine umfassende Studie zu sein, einige Punkte werden übersehen, dies ist meine persönliche Sicht auf das, was war und was jetzt ist.
Also, in den guten alten Zeiten... waren Kassetten von Tonbandgeräten die früheste Liefermethode, die ich fand. Ich hatte einen Computer BK-0010.01...
Die Ära der Taschenrechner
Nein, es gab einen noch früheren Moment, es gab auch einen Taschenrechner и .
Also, als ich es getan hatte , dann war die Art und Weise, das Programm zu übertragen, ein gewöhnliches Blatt Papier in einer Schachtel, auf dem ein Programm geschrieben war, das, falls erforderlich, um es manuell auszuführen, in den Taschenrechner geschrieben wurde. Wenn Sie spielen möchten (ja, sogar dieser vorsintflutliche Rechner hatte Spiele), setzen Sie sich hin und geben Sie das Programm in den Rechner ein. Als der Rechner ausgeschaltet wurde, geriet das Programm natürlich in Vergessenheit. Zusätzlich zu den persönlich auf Papier ausgeschriebenen Rechnercodes wurden die Sendungen in den Zeitschriften „Radio“ und „Technik für die Jugend“ sowie in Büchern der damaligen Zeit veröffentlicht.
Die nächste Modifikation war ein Taschenrechner , es hat bereits den Anschein einer nichtflüchtigen Datenspeicherung. Jetzt musste das Spiel oder Programm nicht mehr manuell eingegeben werden, sondern nach einigen magischen Bewegungen mit den Tasten wurde es von selbst geladen.
Die Größe des größten Programms im Rechner betrug 105 Schritte und die Größe des permanenten Speichers im MK-52 betrug 512 Schritte.
Übrigens, wenn es Fans dieser Taschenrechner gibt, die diesen Artikel lesen, habe ich beim Schreiben des Artikels sowohl einen Taschenrechner-Emulator für Android als auch Programme dafür gefunden. Vorwärts in die Vergangenheit!
Ein kurzer Exkurs über MK-52 (aus Wikipedia)
MK-52 flog mit der Raumsonde Sojus TM-7 ins All. Es sollte zur Berechnung der Landebahn für den Fall verwendet werden, dass der Bordcomputer ausfällt.
Seit 52 wird der MK-1988 mit der Elektronika-Astro-Speichererweiterungseinheit als Teil eines Navigationscomputerbausatzes an Marineschiffe geliefert.
Die ersten Personalcomputer
Gehen wir zurück in die Zeit . Es ist klar, dass dort mehr Speicher vorhanden war und das Eintippen von Code von einem Blatt Papier aus keine Option mehr war (obwohl ich es zunächst genau getan habe, weil es einfach kein anderes Medium gab). Audiokassetten für Tonbandgeräte werden zum wichtigsten Speicher- und Bereitstellungsmittel für Software.
Die Speicherung auf einer Kassette erfolgte normalerweise in Form einer oder zweier Binärdateien, alles andere war darin enthalten. Die Zuverlässigkeit war sehr gering, ich musste 2-3 Kopien des Programms behalten. Auch die Ladezeiten waren enttäuschend und Enthusiasten experimentierten mit verschiedenen Frequenzkodierungen, um diese Mängel zu beheben. Ich selbst war zu diesem Zeitpunkt noch nicht in der professionellen Softwareentwicklung tätig (von einfachen Programmen in BASIC abgesehen), daher werde ich Ihnen leider nicht im Detail erzählen, wie alles im Inneren angeordnet war. Gerade die Tatsache, dass der Computer größtenteils nur über RAM verfügte, bestimmte die Einfachheit des Datenspeicherschemas.
Das Aufkommen zuverlässiger und großer Speichermedien
Später erschienen Disketten, der Kopiervorgang wurde vereinfacht und die Zuverlässigkeit erhöht.
Die Situation ändert sich jedoch erst dramatisch, wenn ausreichend große lokale Speicher in Form von Festplatten verfügbar sind.
Die Art der Bereitstellung ändert sich grundlegend: Es erscheinen Installationsprogramme, die den Prozess der Systemkonfiguration sowie die Bereinigung nach dem Entfernen verwalten, da Programme nicht nur in den Speicher eingelesen, sondern bereits in den lokalen Speicher kopiert werden, von dem aus Sie sie benötigen in der Lage sein, bei Bedarf unnötige Dinge zu beseitigen.
Gleichzeitig steigt die Komplexität der gelieferten Software.
Die Anzahl der Dateien in der Lieferung steigt von wenigen auf Hunderte und Tausende, Konflikte zwischen Bibliotheksversionen und anderen Freuden beginnen, wenn verschiedene Programme dieselben Daten verwenden.
Zu dieser Zeit war mir die Existenz von Linux noch nicht klar; ich lebte in der Welt von MS DOS und später Windows und schrieb in Borland Pascal und Delphi, manchmal mit Blick auf C++. Viele Leute nutzten damals InstallShield, um Produkte auszuliefern. , das alle zugewiesenen Aufgaben der Bereitstellung und Konfiguration der Software recht erfolgreich gelöst hat.
Internet-Ära
Allmählich wird die Komplexität von Softwaresystemen immer komplexer; von den Monolith- und Desktop-Anwendungen erfolgt ein Übergang zu verteilten Systemen, Thin Clients und Microservices. Jetzt müssen Sie nicht nur ein Programm, sondern eine Reihe davon konfigurieren, damit sie alle zusammenarbeiten.
Das Konzept änderte sich völlig, das Internet kam, die Ära der Cloud-Dienste kam. Von Dienstleistungen hat bisher noch niemand besonders geträumt, nur im Anfangsstadium, in Form von Websites. Aber es war ein Wendepunkt sowohl in der Entwicklung als auch in der Bereitstellung von Anwendungen.
Für mich selbst habe ich festgestellt, dass es in diesem Moment einen Generationswechsel bei den Entwicklern gab (oder nur in meiner Umgebung), und ich hatte das Gefühl, dass alle guten alten Bereitstellungsmethoden auf einmal vergessen waren und alles von vorne begann Anfang: Die gesamte Lieferung begann mit Knieskripten und nannte es stolz „Kontinuierliche Lieferung“. Tatsächlich hat eine Zeit des Chaos begonnen, in der das Alte vergessen und nicht genutzt wird und das Neue einfach nicht existiert.
Ich erinnere mich an die Zeiten, als in unserer Firma, in der ich damals gearbeitet habe (ich werde es nicht nennen), anstatt über Ant zu bauen (Maven war noch nicht beliebt oder existierte überhaupt nicht), haben die Leute einfach Gläser in der IDE gesammelt und sich gelassen daran beteiligt es in SVN. Dementsprechend bestand die Bereitstellung darin, die Datei von SVN abzurufen und sie über SSH auf die gewünschte Maschine zu kopieren. Es ist so einfach und umständlich.
Gleichzeitig erfolgte die Auslieferung einfacher Seiten in PHP auf sehr einfache Weise durch einfaches Kopieren der korrigierten Datei per FTP auf den Zielrechner. Manchmal war das nicht der Fall – der Code wurde live auf dem Produktserver bearbeitet, und besonders schick war es, wenn es irgendwo Backups gab.
RPM- und DEB-Pakete
Andererseits erfreuten sich UNIX-ähnliche Systeme mit der Entwicklung des Internets immer größerer Beliebtheit, insbesondere entdeckte ich zu dieser Zeit etwa im Jahr 6 RedHat Linux 2000. Natürlich gab es auch bestimmte Mittel zur Auslieferung von Software; laut Wikipedia erschien RPM als Hauptpaketmanager bereits 1995 in der Version von RedHat Linux 2.0. Und seitdem und bis heute wird das System in Form von RPM-Paketen ausgeliefert und existiert und entwickelt sich recht erfolgreich.
Distributionen der Debian-Familie folgten einem ähnlichen Weg und implementierten die Auslieferung in Form von Deb-Paketen, was bis heute unverändert geblieben ist.
Mit Paketmanagern können Sie die Softwareprodukte selbst bereitstellen, sie während des Installationsprozesses konfigurieren, Abhängigkeiten zwischen verschiedenen Paketen verwalten, Produkte entfernen und unnötige Elemente während des Deinstallationsprozesses bereinigen. Diese. Meistens genügt das, weshalb sie mehrere Jahrzehnte nahezu unverändert überdauerten.
Cloud Computing hat die Installation von Paketmanagern nicht nur von physischen Medien, sondern auch von Cloud-Repositorys hinzugefügt, aber grundsätzlich hat sich wenig geändert.
Es ist erwähnenswert, dass es derzeit einige Schritte in Richtung einer Abkehr von Deb und einem Wechsel zu Snap-Paketen gibt, aber dazu später mehr.
Auch diese neue Generation von Cloud-Entwicklern, die weder DEB noch RPM kannten, wuchs langsam heran, sammelte Erfahrungen, die Produkte wurden komplexer und es waren einige vernünftigere Bereitstellungsmethoden erforderlich als FTP, Bash-Skripte und ähnliche studentische Arbeiten.
Und hier kommt Docker ins Spiel, eine Art Mischung aus Virtualisierung, Ressourcenbegrenzung und Bereitstellungsmethode. Heutzutage ist es modisch und jugendlich, aber wird es für alles benötigt? Ist das ein Allheilmittel?
Nach meinen Beobachtungen wird Docker sehr oft nicht als vernünftige Wahl vorgeschlagen, sondern einfach, weil einerseits in der Community darüber gesprochen wird und diejenigen, die es vorschlagen, es nur kennen. Über die guten alten Verpackungssysteme schweigt man hingegen größtenteils – sie existieren und verrichten still und unbemerkt ihren Dienst. In einer solchen Situation gibt es wirklich keine andere Wahl – die Wahl liegt auf der Hand – Docker.
Ich werde versuchen, meine Erfahrungen darüber zu teilen, wie wir Docker implementiert haben und was dabei passiert ist.
Selbstgeschriebene Skripte
Ursprünglich gab es Bash-Skripte, die JAR-Archive auf den erforderlichen Maschinen bereitstellten. Dieser Prozess wurde von Jenkins verwaltet. Dies hat erfolgreich funktioniert, da das JAR-Archiv selbst bereits eine Assembly ist, die Klassen, Ressourcen und sogar Konfigurationen enthält. Wenn Sie das Maximum herausholen, ist die Erweiterung in ein Skript nicht das Schwierigste, was Sie brauchen
Aber Skripte haben mehrere Nachteile:
- Skripte werden meist in Eile geschrieben und sind daher so primitiv, dass sie nur ein Best-Case-Szenario enthalten. Dies wird durch die Tatsache erleichtert, dass der Entwickler an einer schnellen Bereitstellung interessiert ist und ein normales Skript die Investition einer angemessenen Menge an Ressourcen erfordert
- Aufgrund des vorherigen Punktes enthalten die Skripte keine Deinstallationsprozeduren
- kein etabliertes Upgrade-Verfahren
- Wenn ein neues Produkt erscheint, müssen Sie ein neues Skript schreiben
- keine Abhängigkeitsunterstützung
Natürlich können Sie ein anspruchsvolles Skript schreiben, aber wie ich oben geschrieben habe, ist dies nicht zuletzt Entwicklungszeit, und wie wir wissen, reicht die Zeit immer nicht aus.
All dies schränkt den Anwendungsbereich dieser Bereitstellungsmethode offensichtlich nur auf die einfachsten Systeme ein. Es ist an der Zeit, dies zu ändern.
Docker
Irgendwann kamen frisch geprägte Mitten zu uns, die vor Ideen brodelten und vom Hafenarbeiter schwärmten. Naja, Fahne in der Hand – los geht’s! Es gab zwei Versuche. Beides scheiterte – sagen wir mal aus großen Ambitionen, aber mangelnder wirklicher Erfahrung. War es notwendig, es zu erzwingen und mit allen möglichen Mitteln zu Ende zu bringen? Das ist unwahrscheinlich – das Team muss sich auf das erforderliche Niveau weiterentwickeln, bevor es die entsprechenden Tools nutzen kann. Darüber hinaus sind wir bei der Verwendung vorgefertigter Docker-Images häufig auf die Tatsache gestoßen, dass das Netzwerk nicht richtig funktionierte (was möglicherweise an der Feuchtigkeit des Dockers selbst lag) oder dass es schwierig war, die Container anderer Leute zu erweitern.
Auf welche Unannehmlichkeiten sind wir gestoßen?
- Netzwerkprobleme im Bridge-Modus
- Es ist unpraktisch, Protokolle in einem Container anzuzeigen (sofern sie nicht separat im Dateisystem des Host-Computers gespeichert sind).
- ElasticSearch friert gelegentlich seltsamerweise im Container ein, der Grund wurde nicht ermittelt, der Container ist offiziell
- Es ist notwendig, eine Hülle in einem Behälter zu verwenden – alles ist sehr reduziert, es gibt keine üblichen Werkzeuge
- Große Sammelbehälter – teuer in der Lagerung
- Aufgrund der großen Containergröße ist es schwierig, mehrere Versionen zu unterstützen
- Längere Erstellungszeit im Gegensatz zu anderen Methoden (Skripte oder Deb-Pakete)
Warum ist es andererseits schlechter, einen Spring-Dienst in Form eines JAR-Archivs über dasselbe Deb bereitzustellen? Ist Ressourcenisolation wirklich notwendig? Lohnt es sich, praktische Betriebssystem-Tools zu verlieren, indem man einen Dienst in einen stark reduzierten Container stopft?
Wie die Praxis gezeigt hat, ist dies in der Realität nicht notwendig, in 90 % der Fälle reicht das Deb-Paket aus.
Wann scheitert das gute alte Deb und wann brauchen wir Docker wirklich?
Für uns bedeutete dies die Bereitstellung von Diensten in Python. Viele Bibliotheken, die für maschinelles Lernen benötigt wurden und nicht in der Standardverteilung des Betriebssystems enthalten waren (und es gab auch falsche Versionen), führten zu Hacks mit Einstellungen und der Notwendigkeit unterschiedlicher Versionen für verschiedene Dienste, die auf demselben Hostsystem ausgeführt wurden Dies bedeutet, dass der einzig vernünftige Weg, dieses Atomgemisch zu transportieren, der Hafen war. Es stellte sich heraus, dass die Arbeitsintensität beim Zusammenbau eines Docker-Containers geringer war als bei der Idee, alles in separate Deb-Pakete mit Abhängigkeiten zu packen, und tatsächlich würde niemand, der bei klarem Verstand ist, dies tun.
Der zweite Punkt, an dem wir Docker verwenden möchten, ist die Bereitstellung von Diensten mithilfe des Blau-Grün-Bereitstellungsschemas. Aber hier möchte ich die Komplexität schrittweise steigern: Zuerst werden Deb-Pakete erstellt und dann ein Docker-Container daraus erstellt.
Snap-Pakete
Kehren wir zu den Snap-Paketen zurück. Sie erschienen erstmals offiziell in Ubuntu 16.04. Im Gegensatz zu den üblichen Deb-Paketen und RPM-Paketen trägt Snap alle Abhängigkeiten. Dadurch lassen sich einerseits Bibliothekskonflikte vermeiden, andererseits ist das resultierende Paket größer. Darüber hinaus kann dies auch Auswirkungen auf die Sicherheit des Systems haben: Bei der Snap-Auslieferung müssen alle Änderungen an den enthaltenen Bibliotheken vom Entwickler überwacht werden, der das Paket erstellt. Im Allgemeinen ist nicht alles so einfach und das universelle Glück entsteht nicht durch deren Verwendung. Dennoch ist dies eine durchaus sinnvolle Alternative, wenn derselbe Docker nur als Paketierungstool und nicht zur Virtualisierung verwendet wird.
Daher verwenden wir jetzt sowohl Deb-Pakete als auch Docker-Container in einer sinnvollen Kombination, die wir vielleicht in einigen Fällen durch Snap-Pakete ersetzen werden.
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Was verwenden Sie für die Lieferung?
-
Selbstgeschriebene Skripte
-
Manuell auf FTP kopieren
-
Deb-Pakete
-
rpm-Pakete
-
Snap-Pakete
-
Docker-Bilder
-
Abbilder virtueller Maschinen
-
Klonen Sie die gesamte Festplatte
-
Marionette
-
ansible
-
Andere
109 Benutzer haben abgestimmt. 32 Benutzer enthielten sich der Stimme.
Source: habr.com