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 jener Zeit war mir die Existenz noch nicht offenbart worden. LinuxIch lebte in der Welt von MS-DOS und spĂ€ter, WindowsEr programmierte in Borland Pascal und Delphi und experimentierte gelegentlich auch mit C++. Damals nutzten viele InstallShield fĂŒr die Produktverbreitung. , 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 gewannen mit der Entwicklung des Internets UNIX-Ă€hnliche Systeme zunehmend an PopularitĂ€t; insbesondere zu dieser Zeit entdeckte ich RedHat. Linux 6, um das Jahr 2000. NatĂŒrlich gab es auch dort bestimmte Möglichkeiten, Software zu verteilen. Laut Wikipedia tauchte RPM als wichtigster Paketmanager bereits 1995 in der RedHat-Version auf. Linux 2.0. Seitdem wird das System als RPM-Paket ausgeliefert und erfreut sich weiterhin groĂer Beliebtheit.
Verteilung der Familie Debian Sie gingen einen Ă€hnlichen Weg und fĂŒhrten die Zustellung in Form von Deb-Paketen ein, 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
Kommen wir zurĂŒck zu Snap-Paketen. Sie tauchten erstmals offiziell auf im Jahr 1990. Ubuntu 16.04. April. Im Gegensatz zu herkömmlichen DEB- und RPM-Paketen enthalten Snaps alle AbhĂ€ngigkeiten. Dadurch werden zwar Bibliothekskonflikte vermieden, das resultierende Paket ist jedoch gröĂer. AuĂerdem kann dies die Systemsicherheit beeintrĂ€chtigen: Beim Deployment von Snaps muss der Entwickler, der das Paket erstellt hat, alle Ănderungen an den enthaltenen Bibliotheken selbst verwalten. Insgesamt ist die Vorgehensweise nicht ganz unkompliziert, und die Verwendung von Snaps ist nicht immer optimal. Sie stellt jedoch eine durchaus sinnvolle Alternative dar, wenn beispielsweise Docker ausschlieĂlich 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
