Evolution of Delivery Methods, or Reflections on Docker, deb, jar, and More

At one point, I decided to write an article about delivery in the form of Docker containers and deb packages, but when I started, I somehow drifted back to the distant times of the first personal computers and even calculators. In general, instead of dry comparisons between Docker and deb, I ended up with these reflections on the topic of evolution, which I present for your consideration.

Any product, no matter what it is, must somehow reach the product servers, be configured, and launched. This is what this article will be about.

I will reflect in a historical context, 'what I see, I sing about', what I saw when I first started writing code and what I observe now, what we ourselves are using at the moment and why. The article does not claim to be a comprehensive study; some moments are omitted; this is my personal view of what was and what exists now.

So, in the good old days… the earliest method of delivery I experienced was cassette tapes from tape recorders. I had a BK-0010.01 computer...

The Era of Calculators

No, there was an even earlier moment; there was a calculator. MK-61 och MK-52.

So, when I had MK-61, the method of transferring a program was an ordinary sheet of graph paper, on which the program was recorded, and when it was necessary to launch it, it was manually entered into the calculator. If you wanted to play (yes, yes, even on this ancient calculator there were games) — you would sit down and input the program into the calculator. Naturally, when the calculator was turned off, the program vanished into oblivion. Besides the codes manually written on paper, programs were published in the magazines 'Radio' and 'Youth Technology', and also printed in books of that time.

The next modification was the calculator MK-52, which already had some semblance of non-volatile data storage. Now there was no need to manually input the game or program; after making some magical passes with the buttons, it loaded itself.

The largest program in the calculator was 105 steps, and the size of the permanent memory in the MK-52 was 512 steps.

Förresten, om det finns några fans av dessa kalkylatorer som läser denna artikel — när jag skrev artikeln hittade jag en emulator för kalkylatorn för Android och program för den. Framåt, till det förflutna!

• Emulator MK-61 för Android
• Programkatalog för MK-61

En liten avstickare om MK-52 (från Wikipedia)

MK-52 flög i rymden på rymdskeppet "Soyuz TM-7". Det var tänkt att användas för att beräkna landningsbanan om omborddatorn skulle gå sönder.

MK-52 med minnesexpansionsenheten "Elektronika-Astro" började levereras till flottans fartyg som en del av ett navigationsberäkningssystem från 1988.

De första persondatorerna

Låt oss återvända till tiderna BK-0010. Det är förståeligt att det också blev mer minne, och att skriva in kod från papper var verkligen inte ett alternativ längre (även om jag i början gjorde just det, eftersom det inte fanns någon annan lagringsmetod). Huvudmedlet för lagring och distribution av programvara blev ljudkassetter för kassettbandspelare.

Lagring på kassett var vanligtvis i form av en eller två binära filer, allt annat fanns internt. Tillförlitligheten var mycket låg, man var tvungen att ha 2-3 kopior av programmet. Laddningstiden var inte heller särskilt tillfredsställande; entusiaster experimenterade med olika frekvenskodningar för att bekämpa dessa brister. Jag sysslade själv inte med professionell mjukvaruutveckling vid den tiden (förutom några enkla program i Basic), så jag kan tyvärr inte berätta i detalj hur allt var uppbyggt internt. Den enda faktorn att datorn hade endast RAM minnesmässigt definierade till stor del enkelheten i datalagringsschemat.

Framväxten av pålitliga och stora informationslagringar

Senare kom disketter, vilket förenklade kopieringsprocessen och ökade tillförlitligheten.
Men situationen förändras radikalt först när tillräckligt stora lokala lagringsenheter i form av HDD blir tillgängliga.

Typen av distribution förändras principiellt: installationsprogram dyker upp som hanterar systemkonfigurationsprocessen och städning efter borttagning, eftersom program inte bara läses in i minnet, utan kopieras redan till den lokala lagringsenheten, från vilken man också måste kunna rensa bort det som inte längre behövs.

Samtidigt ökar komplexiteten hos den levererade programvaran.
Antalet filer i leveransen ökar från en till hundratals och tusentals, vilket leder till versionskonflikter av bibliotek och andra glädjeämnen när olika program använder samma data.

På den tiden var jag fortfarande inte medveten om linuxexistensen, jag levde i en värld av MS DOS och senare Windows, och jag programmerade på Borland Pascal och Delphi, ibland tittade jag mot C++. För att leverera produkter använde många InstallShield. ru.wikipedia.org/wiki/InstallShield, som framgångsrikt löste alla uppsatta mål för deployment och konfiguration av mjukvara.

Internetepoken

Allt eftersom kompliciteten i programvarusystemen ökade, övergick man från monolitiska och skrivbordsapplikationer till distribuerade system, tunn klient och mikrotjänster. Nu behövde man konfigurera inte bara ett program utan en uppsättning av dem, och de måste alla fungera bra tillsammans.

Konceptet förändrades helt, Internet kom och en era av molntjänster började. Även om det fortfarande bara var i ett tidigt skede, i form av webbplatser, drömde ingen riktigt om tjänster, men detta var en vändpunkt i industrin både för utveckling och leverans av applikationer.

Jag la märke till att vid denna tidpunkt skedde en generationsväxling bland utvecklarna (eller var det bara i min omgivning), och det kändes som att alla gamla goda sätt att leverera hade glömts bort på en gång och allt började om från början: all leverans började göras med skript skrivna på knäet, och man kallade det stolt "Continuous Delivery". I praktiken började en period av rörig ordning, där det gamla var bortglömt och inte användes, medan det nya helt enkelt inte fanns.

Jag minns tiderna när vi i företaget där jag då arbetade (jag kommer inte nämna namnet) istället för att bygga genom ant (maven var då fortfarande inte populär eller fanns överhuvudtaget), samlade folk bara jar-filen i IDE och tryggt committade den i SVN. Följaktligen bestod leveransen av att hämta filen från SVN och kopiera den via SSH till rätt maskin. Så enkelt och primitivt.

Samtidigt gjorde leveransen av enkla webbplatser på PHPs just det – en mycket primitiv kopiering av den korrigerade filen via FTP till måmaskinen. Ibland fanns det inte ens sådant – koden ändrades direkt på produktionsservern, och det var särskilt lyxigt om det fanns några backupkopior någonstans.

RPM- och DEB-paket

Å andra sidan, med internets utveckling har UNIX-liknande system blivit alltmer populära, särskilt just vid den tiden upptäckte jag RedHat Linux 6, omkring år 2000. Det är självklart att det även där fanns verktyg för mjukvaruleverans, enligt Wikipedia uppträdde RPM som den huvudsakliga paketadministratören redan 1995, i version 2.0 av RedHat Linux. Och sedan dess har systemet levererats i form av RPM-paket och existensen har varit framgångsrik och i utveckling.

Debian-familjens distributioner har gått en liknande väg och implementerat mjukvaruleverans i form av deb-paket, vilket också har förblivit oförändrat fram till idag.

Paketadministratörer gör det möjligt att leverera själva programprodukterna, konfigurera dem under installation, hantera beroenden mellan olika paket, utföra borttagning av produkter och städa upp överflödigt under avinstallation. Det vill säga, i stort sett är det allt som behövs, och därför har de hållit sig i flera decennier nästan oförändrade.

Molnlösningar har lagt till möjlighet till installation inte bara från fysiska lagringsmedia, utan även från molnarkiv, men prinicipiellt har lite förändrats.

Det bör nämnas att det för närvarande finns vissa tendenser mot att överge deb och övergå till snap-paket, men mer om det senare.

Så, detta nya generation av molnutvecklare, som inte kände till vare sig DEB eller RPM, växte också sakta, fick erfarenhet, produkterna blev mer komplexa, och det krävdes mer rationella sätt att leverera, än FTP, bash-skript och liknande studentevenemang.
Och här kommer Docker in i bilden, en slags blandning av virtualisering, resursegregation och leveransmetod. Det är nu modernt, ungdomligt, men behövs det för allt? Är det en universallösning?

Enligt mina observationer erbjuds Docker mycket ofta inte som ett rationellt val, utan helt enkelt för att det pratas om det i gemenskapen, och de som erbjuder det känner endast till det. Å andra sidan är de gamla goda paketeringssystemen mestadels tysta — de finns och gör sitt jobb tyst och osynligt. I en sådan situation finns det inte mycket val — valet är uppenbart — Docker.

Jag försöker dela med mig av erfarenheten av hur vi implementerade Docker, och vad resultatet blev.

Egenutvecklade skript

I början fanns det bash-skript som distribuerade jar-filer till de nödvändiga maskinerna. Jenkins hanterade denna process. Det fungerade framgångsrikt, eftersom jar-filen redan är en samling som innehåller klasser, resurser och till och med konfiguration. Om man packar allt maximalt i den — är det inte det mest komplicerade att distribuera den med skript.

Men skripten har flera nackdelar:

• Skripten skrivs ofta hastigt vilket gör dem så primitiva att de bara innehåller det mest gynnsamma scenariot. Detta främjas av att utvecklaren är intresserad av att leverera snabbt, medan ett ordentligt skript kräver investering av en hel del resurser.
• Som en följd av föregående punkt innehåller skripten ingen avinstallationsprocedur.
• Det finns ingen etablerad uppgraderingsprocedur.
• Vid lanseringen av en ny produkt måste man skriva ett nytt skript.
• Det finns inget stöd för beroenden.

Naturligtvis kan man skriva ett avancerat skript, men som jag nämnde tidigare — det tar tid att utveckla, och tid är alltid en bristvara.

Detta begränsar självklart användningsområdet för denna distributionsmetod till enklaste system. Det är dags att ändra på detta.

Docker

Vid något tillfälle började nyutbildade mellanliggande utvecklare komma till oss, sprudlande av idéer och drömmande om Docker. Jaha, låt oss göra det! Det gjordes två försök. Båda misslyckade — låt oss säga, på grund av stora ambitioner men bristande verklig erfarenhet. Skulle vi tvinga fram och avsluta det med alla medel? Troligtvis inte — teamet måste växa evolutionsmässigt till rätt nivå innan det kan använda rätt verktyg. Dessutom, när vi använde färdiga Docker-bilder, stötte vi ofta på problem med nätverket (vilket kanske också var kopplat till det instabila hos Docker själv) eller hade svårt att utvidga andras containrar.

Vilka besvär stötte vi på?

• Nätverksproblem i bridge-läge.
• Det är obekvämt att se loggar i containern (om de inte är flyttade separat till filsystemet på värdmaskinen).
• Periodisk konstig frysnings av ElasticSearch inuti containern, orsaken kunde vi aldrig fastställa, containern är officiell.
• Det är obekvämt att använda shell i containern — allt är kraftigt begränsat, inga bekanta verktyg finns tillgängliga.
• Stora storlekar på insamlade containrar – dyrt att lagra
• På grund av stora storlekar på containrar är det svårt att stödja flera versioner
• Längre samlingstid, i motsats till andra metoder (skript eller deb-paket)

Å andra sidan, varför skulle en Spring-tjänst i form av en jar-arkiv vara sämre att distribuera via samma deb? Är resursisolering verkligen nödvändig? Ska man avstå från bekväma verktyg i operativsystemet genom att stoppa tjänsten i en kraftigt nedbantad container?

Som erfarenheten visar – i praktiken är det inte nödvändigt, deb-paket räcker i 90% av fallen.

När fungerar den gamla goda deb ändå inte och när behövde vi faktiskt Docker?

För oss handlade det om att distribuera tjänster på python. Många bibliotek som behövs för maskininlärning som saknades i standarddistributionen av operativsystemet (och det som fanns – var inte i rätt version), hack för inställningar, behov av olika versioner för olika tjänster som lever på samma värdsystem ledde till att det enda rimliga sättet att leverera denna kärnblandning blev Docker. Arbetsinsatsen för att bygga Docker-container var lägre än tanken att paketera allt detta i separata deb-paket med beroenden, och ingen vid sunda förnuft skulle ens ta sig an det.

Den andra punkten där Docker planeras att användas – för distribution av tjänster enligt blue-green deploy-schema. Men här vill man få en gradvis ökning av komplexiteten: först samlas deb-paket, och sedan byggs Docker-containern utifrån dem.

Snap-paket

Låt oss återkomma till snap-paketen. De dök upp officiellt i Ubuntu 16.04. Till skillnad från de vanliga deb-paketen och rpm-paketen bär snap på alla beroenden. Å ena sidan undviker detta biblioteks konflikter, å andra sidan ger det mer betydande storlekar på det resulterande paketet. Dessutom kan detta påverka systemets säkerhet: vid leverans av snap måste utvecklaren som skapar paketet hålla koll på alla ändringar i de inkluderade biblioteken. Så det är inte helt entydigt och allmän lycka med deras användning kommer inte automatiskt. Men icke desto mindre är det en fullt rimlig alternativ, om samma Docker används endast som ett medel för paketering, inte virtualisering.

Som sammanfattning används vi nu i en rimlig kombination både deb-paket och Docker-containrar, som vi eventuellt kommer att byta ut mot snap-paket i vissa fall.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Vad använder du för leverans?

• Egenutvecklade skript

• Vi kopierar manuellt via FTP.

• deb-paket

• rpm-paket

• snap-paket

• Docker-bilder

• Virtuella maskinbilder

• Vi klonar hela HDD:n.

• puppet

• ansible

• Annat

109 användare röstade. 32 användare avstod.

Källa: habr.com