Eines Tages beschloss ich, einen Artikel über die Lieferung von Docker- und Deb-Paketen in Form von Containern zu schreiben, aber als ich anfing, litt ich aus irgendeinem Grund in den fernen Tagen der ersten PCs und sogar Taschenrechner. Im Allgemeinen sind dies anstelle trockener Vergleiche von Docker und Deb die Gedanken zur Evolution, die ich Ihrem Hof vorstelle.
Jedes Produkt, was auch immer es ist, muss irgendwie auf die Produktserver gelangen, muss konfiguriert und gestartet werden. In diesem Artikel geht es darum.
Ich werde im historischen Kontext reflektieren: "Was ich sehe - dass ich singe", was ich gesehen habe, als ich angefangen habe, Code zu schreiben und was ich jetzt beobachte, was wir selbst im Moment verwenden und warum. Der Artikel gibt nicht vor, eine vollwertige Studie zu sein, einige Punkte fehlen, dies ist meine persönliche Ansicht darüber, was war und was jetzt ist.
Also, in den guten alten Zeiten ... war die früheste Versandmethode, die ich fand, mit Bandkassetten. Ich hatte einen Computer BK-0010.01 ...
Das Zeitalter der Taschenrechner
Nein, es gab einen noch früheren Punkt, es gab auch einen
MK-61- und einen
MK-52- Rechner.
Als ich
MK-61 hatte , bestand die Möglichkeit, das Programm zu übertragen, darin, ein normales Stück Papier in einer Box zu verwenden, auf der das Programm aufgezeichnet wurde, und das bei Bedarf manuell in den Taschenrechner geschrieben wurde. Wenn Sie spielen möchten (ja, es gab sogar Spiele auf diesem Antidiluvian-Rechner), setzen Sie sich 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 geschriebenen Taschenrechnercodes wurden die Programme in den Magazinen Radio und Technik der Jugend sowie in Büchern dieser Zeit veröffentlicht.
Die nächste Modifikation war der
MK-52- Rechner, er schien bereits eine Art nichtflüchtiger Datenspeicher zu sein. Jetzt musste das Spiel oder Programm nicht mehr manuell eingegeben werden, aber nachdem einige magische Durchgänge mit Tasten ausgeführt wurden, wurde es selbst geladen.
Das Volumen des größten Programms im Taschenrechner 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 - beim Schreiben des Artikels habe ich sowohl einen Taschenrechner-Emulator für Android als auch ein Programm dafür gefunden. Vorwärts in die Vergangenheit!
Ein kleiner Exkurs über MK-52 (aus Wikipedia)
MK-52 flog mit dem Raumschiff Sojus TM-7 ins All. Es sollte verwendet werden, um die Landebahn zu berechnen, falls der Bordcomputer ausfällt.
MK-52 mit der Speichererweiterungseinheit "Electronics-Astro" seit 1988 wurde im Rahmen eines Navigationscomputer-Kits an die Schiffe der Marine geliefert.
Die ersten PCs
Kehren wir zu den Zeiten von
BK-0010 zurück . Es ist klar, dass dort mehr Speicher vorhanden war und es keine Option mehr war, Code von einem Blatt Papier zu steuern (obwohl ich dies zuerst getan habe, weil es einfach kein anderes Medium gab). Die Hauptmittel zur Speicherung und Lieferung von Software sind Audiokassetten für Tonbandgeräte.
Die Speicherung auf einer Kassette erfolgte normalerweise in Form von ein oder zwei Binärdateien, alles andere war darin enthalten. Die Zuverlässigkeit war sehr gering, ich musste 2-3 Kopien des Programms behalten. Auch die Ladezeit war nicht glücklich, Enthusiasten experimentierten mit unterschiedlicher Frequenzcodierung, um diese Mängel zu beheben. Zu diesem Zeitpunkt war ich selbst noch nicht mit der professionellen Softwareentwicklung beschäftigt (abgesehen von einfachen Basisprogrammen), daher werde ich Ihnen leider nicht im Detail sagen, wie alles im Inneren angeordnet war. Die Tatsache, dass zum größten Teil nur RAM auf dem Computer vorhanden war, bestimmte die Einfachheit des Datenspeicherschemas.
Die Entstehung zuverlässiger und großer Speichermedien
Später erscheinen Disketten, der Kopiervorgang wird vereinfacht und die Zuverlässigkeit steigt.
Die Situation ändert sich jedoch nur dann dramatisch, wenn ausreichend große lokale Speicher in Form einer Festplatte angezeigt werden.
Die Art der Übermittlung ändert sich grundlegend: Es werden Installationsprogramme angezeigt, die den Systemkonfigurationsprozess sowie die Bereinigung nach dem Löschen steuern, da die Programme nicht nur in den Speicher eingelesen, sondern bereits in den lokalen Speicher kopiert werden, den Sie löschen müssen, falls erforderlich.
Gleichzeitig steigt die Komplexität der mitgelieferten Software.
Die Anzahl der Dateien in der Lieferung steigt von Einheiten auf Hunderte und Tausende, Konflikte zwischen Bibliotheksversionen und andere Freuden beginnen, wenn verschiedene Programme dieselben Daten verwenden.
In jenen Tagen war die Existenz von Linux für mich noch nicht offen, ich lebte in der Welt von MS DOS und später von Windows und schrieb in Borland Pascal und Delphi, manchmal mit Blick auf C ++. Um Produkte in jenen Tagen zu liefern, verwendeten viele InstallShield
ru.wikipedia.org/wiki/InstallShield , das alle Aufgaben der Bereitstellung und Konfiguration von Software recht erfolgreich löste.
Zeitalter des Internets
Allmählich wird die Komplexität von Softwaresystemen noch komplizierter. Von Monolith- und Desktop-Anwendungen geht ein Übergang zu verteilten Systemen, Thin Clients und Microservices über. Jetzt müssen Sie nicht nur ein Programm konfigurieren, sondern auch deren Set, damit sie alle zusammen Freunde sind.
Das Konzept hat sich komplett geändert, das Internet ist gekommen, die Ära der Cloud-Dienste ist gekommen. Bisher wird es nur in der Anfangsphase in Form von Websites interpretiert, von denen niemand besonders geträumt hat. Dies war jedoch ein Wendepunkt in der Branche sowohl für die Entwicklung als auch für die tatsächliche Bereitstellung von Anwendungen.
Für mich selbst stellte ich fest, dass es in diesem Moment einen Wechsel in den Generationen von Entwicklern gab (oder nur in meiner Umgebung), und ich hatte das Gefühl, dass alle guten alten Liefermethoden in einem Moment vergessen wurden und alles von Anfang an begann: Sie begannen, die gesamte Lieferung zu machen mit kniehohen Skripten und nannte es stolz "Continuous Delivery". Tatsächlich begann eine Zeit des Chaos, in der das Alte vergessen und nicht benutzt wird, aber es gibt einfach kein Neues.
Ich erinnere mich an die Zeiten, als in unserer Firma, in der ich damals gearbeitet habe (ich rufe nicht an), anstatt durch Ameisen zu bauen (Maven war noch nicht oder gar nicht beliebt), die Leute einfach Glas in IDE gesammelt und sich verpflichtet haben ihn in svn. Dementsprechend bestand die Bereitstellung darin, die Datei von SVN abzurufen und über SSH auf den gewünschten Computer zu kopieren. So einfach und ungeschickt.
Gleichzeitig wurde die Bereitstellung einfacher Sites für PHP durch einfaches Kopieren der korrigierten Datei über FTP auf den Zielcomputer recht primitiv gestaltet. Manchmal gab es so etwas nicht - der Code wurde live auf dem Produktserver bearbeitet, und es war besonders schick, wenn irgendwo Backups vorhanden waren.
RPM- und DEB-Pakete
Andererseits wurden mit der Entwicklung des Internets UNIX-ähnliche Systeme immer beliebter, insbesondere zu dieser Zeit entdeckte ich RedHat Linux 6 um das Jahr 2000. Natürlich gab es dort bestimmte Tools für die Softwarebereitstellung, laut Wikipedia erschien RPM als Hauptpaketmanager bereits 1995 in der Version von RedHat Linux 2.0. Und von damals bis heute wurde das System in Form von RPM-Paketen geliefert und existiert und entwickelt sich recht erfolgreich.
Die Distributionen der Debian-Familie gingen einen ähnlichen Weg und implementierten die Lieferung in Form von Deb-Paketen, die ebenfalls bis heute unverändert sind.
Mit Paketmanagern können Sie die Softwareprodukte selbst bereitstellen, während des Installationsprozesses konfigurieren, Abhängigkeiten zwischen verschiedenen Paketen verwalten, Produkte entfernen und den Überschuss während der Deinstallation bereinigen. Das heißt, Zum größten Teil ist dies alles, was benötigt wird, weshalb sie mehrere Jahrzehnte ohne oder mit nur geringen Veränderungen dauerten.
Clouds, die der Installation des Paketmanagers hinzugefügt wurden, stammen nicht nur von physischen Medien, sondern auch von Cloud-Repositorys, aber im Grunde hat sich wenig geändert.
Es ist erwähnenswert, dass es derzeit einige Probleme gibt, Deb zu vermeiden und auf Snap-Pakete umzusteigen, aber dazu später mehr.
Diese neue Generation von Cloud-Entwicklern, die weder DEB noch RPM kannten, wuchs ebenfalls langsam, sammelte Erfahrungen, Produkte wurden komplizierter und es wurden einige vernünftigere Bereitstellungsmethoden benötigt als FTP, Bash-Skripte und ähnliche Handarbeiten für Studenten.
Und hier betritt Docker die Szene, eine Art Mischung aus Virtualisierung, Ressourcenzuweisung und Bereitstellungsmethoden. Es ist jetzt in Mode, Jugend, aber wird es für alles benötigt? Ist es ein Allheilmittel?
Nach meinen Beobachtungen wird Docker sehr oft nicht als vernünftige Wahl angeboten, sondern einfach, weil es einerseits in der Community diskutiert wird und diejenigen, die es anbieten, es nur wissen. Andererseits schweigen sie größtenteils über die guten alten Verpackungssysteme - sie sind und sind, sie erledigen ihre Arbeit leise und unmerklich. In einer solchen Situation gibt es 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 als Ergebnis passiert ist.
Selbstgeschriebene Skripte
Anfangs gab es Bash-Skripte, die JAR-Archive auf den erforderlichen Computern bereitstellten. Verwaltete diesen Prozess von Jenkins. Dies hat erfolgreich funktioniert, da das JAR-Archiv selbst bereits eine Assembly ist, die Klassen, Ressourcen und sogar Konfiguration enthält. Wenn Sie alles maximal einsetzen und es dann mit einem Skript erweitern, ist dies nicht die schwierigste Sache, die Sie benötigen
Skripte haben jedoch mehrere Nachteile:
- Skripte werden normalerweise in Eile geschrieben und sind daher so primitiv, dass sie nur eines der erfolgreichsten Skripte enthalten. Dies wird durch die Tatsache erleichtert, dass der Entwickler an einer schnellen Bereitstellung interessiert ist und ein normales Skript eine angemessene Menge an Ressourcen erfordert.
- Infolge des vorherigen Absatzes enthalten die Skripte nicht die Deinstallationsprozedur
- Kein etabliertes Upgrade-Verfahren
- Wenn ein neues Produkt angezeigt wird, müssen Sie ein neues Skript schreiben
- Keine Abhängigkeitsunterstützung
Natürlich können Sie ein ausgefallenes Skript schreiben, aber wie ich oben geschrieben habe, ist dies Entwicklungszeit und nicht die kleinste, aber wie Sie wissen, gibt es immer nicht genug Zeit.
Dies alles beschränkt den Umfang dieser Bereitstellungsmethode offensichtlich auf die einfachsten Systeme. Es ist an der Zeit, dies zu ändern.
Docker
Irgendwann kamen frisch gebackene Mitten zu uns, brodelten vor Ideen und schwärmten von einem Hafenarbeiter. Nun, die Flagge in der Hand - mach es! Es gab zwei Versuche. Beides erfolglos - sagen wir mal, wegen der großen Ambitionen, aber des Mangels an wirklicher Erfahrung. War es notwendig, auf irgendeine Weise zu zwingen und zu beenden? Es ist unwahrscheinlich, dass das Team evolutionär auf das gewünschte Niveau wachsen muss, bevor es die entsprechenden Tools verwenden kann. Darüber hinaus stießen wir bei vorgefertigten Bildern des Dockers häufig auf die Tatsache, dass das Netzwerk dort nicht ordnungsgemäß funktionierte (was möglicherweise auch mit der Feuchtigkeit des Dockers selbst zusammenhängt) oder dass es schwierig war, die Container anderer Personen zu erweitern.
Welche Unannehmlichkeiten sind uns begegnet?
- Netzwerkprobleme im Bridge-Modus
- Es ist unpraktisch, sich die Protokolle im Container anzusehen (wenn sie nicht separat zum Dateisystem des Hostcomputers übertragen werden).
- In regelmäßigen Abständen hängt ElasticSearch im Container, der Grund wurde nicht ermittelt, der Container ist offiziell
- Es ist umständlich, die Schale im Behälter zu verwenden - alles ist stark beschnitten, es gibt keine bekannten Werkzeuge
- Große Behälter zum Sammeln - teuer in der Lagerung
- Aufgrund der Größe der Container ist es schwierig, mehrere Versionen zu unterstützen
- Längerer Build im Gegensatz zu anderen Methoden (Skripte oder Deb-Pakete)
Ist es andererseits schlimmer, einen Spring-Service in Form eines JAR-Archivs über dieselbe Deb bereitzustellen? Wird eine Ressourcenisolierung wirklich benötigt? Lohnt es sich, praktische Tools des Betriebssystems zu verlieren und den Dienst in einen stark beschnittenen Container zu stopfen?
Wie die Praxis gezeigt hat, ist dies in der Realität nicht erforderlich. In 90% der Fälle reicht ein Deb-Paket aus.
Wann scheitert eine gute alte Debatte noch und wann brauchten wir wirklich einen Docker?
Für uns war dies eine Bereitstellung von Diensten in Python. Viele Bibliotheken, die für maschinelles Lernen benötigt werden und in der Standardauslieferung des Betriebssystems nicht verfügbar sind (und welche der falschen Versionen vorhanden waren), Hacks mit Einstellungen, die Notwendigkeit unterschiedlicher Versionen für unterschiedliche Dienste, die auf demselben Hostsystem ausgeführt werden, führten dazu dass der einzig vernünftige Weg, dieses Kerngemisch zu liefern, Docker war. Die Komplexität beim Zusammenstellen des Docker-Containers erwies sich als geringer als die Idee, alles in separate Deb-Pakete mit Abhängigkeiten zu packen, und niemand, der bei klarem Verstand ist, hätte es angenommen.
Der zweite Punkt, an dem Sie Docker verwenden möchten, ist die Bereitstellung von Diensten mithilfe des blau-grünen Bereitstellungsschemas. Aber hier möchte ich die Komplexität schrittweise erhöhen: Zuerst werden Deb-Pakete gesammelt und dann ein Docker-Container daraus zusammengestellt.
Snap-Pakete
Zurück zu den Snap-Paketen. Sie erschienen erstmals offiziell in Ubuntu 16.04. Im Gegensatz zu den üblichen Deb-Paketen und RPM-Paketen enthält Snap alle Abhängigkeiten. Dies vermeidet einerseits den Konflikt von Bibliotheken, andererseits bedeutet es bedeutendere Größen des resultierenden Pakets. Darüber hinaus kann dies die Sicherheit des Systems beeinträchtigen: Im Falle eines Snaps sollten alle Änderungen an den enthaltenen Bibliotheken vom Entwickler überwacht werden, der das Paket erstellt. Im Allgemeinen ist nicht alles so einfach und das allgemeine Glück ihrer Verwendung kommt nicht. Dies ist jedoch eine durchaus vernünftige Alternative, wenn derselbe Docker nur als Mittel zum Verpacken und nicht als Virtualisierung verwendet wird.
Infolgedessen verwenden wir jetzt sowohl Deb-Pakete als auch Docker-Container in einer vernünftigen Kombination, die wir möglicherweise in einigen Fällen durch Snap-Pakete ersetzen werden.