Op een bepaald moment besloot ik een artikel te schrijven over de distributie in de vorm van Docker-containers en deb-pakketten, maar toen ik begon, werd ik op de een of andere manier meegesleept naar de verre tijden van de eerste persoonlijke computers en zelfs rekenmachines. Kortom, in plaats van droge vergelijkingen van Docker en deb, zijn dit mijn overpeinzingen over evolutie, die ik aan uw oordeel presenteer.
Elk product, wat het ook is, moet op de een of andere manier de productservers bereiken, moet worden ingesteld en opgestart. Hierover zal dit artikel gaan.
Ik zal nadenken in historische context, "wat ik zie - waarover ik zing", wat ik zag toen ik net begon met coderen en wat ik nu observeer, wat we momenteel gebruiken en waarom. Het artikel pretendeert geen volledig onderzoek te zijn, sommige punten zijn achterwege gelaten, dit is mijn persoonlijke kijk op wat er was en wat er nu is.
Dus, in de goede oude tijd... de vroegste manier van distributie die ik me herinner, was via cassettebandjes van magnetofonen. Ik had een BK-0010.01 computer...
Het tijdperk van rekenmachines
Nee, er was een nog eerdere tijd, er was nog een rekenmachine. en .
Zo, toen ik had , was de manier om een programma over te dragen een gewoon vierkant vel papier, waarop het programma was geschreven, dat, indien nodig, handmatig in de rekenmachine werd ingevoerd. Wil je spelen (ja, zelfs op deze verouderde rekenmachine waren er spellen) ā dan ga je zitten en schrijf je het programma in de rekenmachine. Uiteraard raakte het programma verloren bij het uitschakelen van de rekenmachine. Naast handgeschreven codes op papier, werden programma's gepubliceerd in de tijdschriften "Radio" en "Techniek van de Jeugd", en ook gedrukt in boeken van die tijd.
De volgende aanpassing was de rekenmachine , die al een soort energievrije datak opslag had. Nu hoefde je het spel of programma niet meer handmatig in te voeren, maar na het maken van enkele magische knoppen, werd het zelf geladen.
De grootste programmaomvang in de rekenmachine was 105 stappen, terwijl de grootte van het permanente geheugen in MK-52 ā 512 stappen was.
Overigens, als er fans van deze rekenmachines zijn die dit artikel lezen ā tijdens het schrijven van het artikel vond ik zowel een emulator van de rekenmachine voor Android als programma's daarvoor. Vooruit, naar het verleden!
Een korte zijstap over MK-52 (uit Wikipedia)
MK-52 vloog de ruimte in met het schip 'Soyuz TM-7'. Het was bedoeld voor het berekenen van de landingsbaan in het geval het boordcomputer zou falen.
MK-52 met geheugenuitbreidingsblok 'Elektronika-Astro' werd vanaf 1988 op schepen van de marine geleverd als onderdeel van het navigator computerpakket.
De eerste persoonlijke computers
Laten we terugkeren naar de dagen . Het is duidelijk dat er meer geheugen beschikbaar was, en het handmatig invoeren van de code van papier was echt geen optie meer (hoewel ik het in het begin deed omdat er geen andere opslag was). Het belangrijkste middel voor het opslaan en leveren van software werd audiocassettes voor bandrecorders.
Opslag op een cassette was meestal in de vorm van een of twee binaire bestanden, alles andere zat daarbinnen. De betrouwbaarheid was erg laag, we moesten 2-3 kopieƫn van het programma hebben. De laadtijd was ook niet om over naar huis te schrijven, en enthousiastelingen experimenteerden met verschillende frequentiecoderingen om deze tekortkomingen te verhelpen. Ik zelf was toen nog niet professioneel bezig met softwareontwikkeling (behalve met eenvoudige programma's in BASIC), dus ik kan helaas niet veel vertellen over hoe alles binnenin werkte. Het feit dat er op de computer alleen RAM was, bepaalde grotendeels de eenvoud van het datasysteem.
De opkomst van betrouwbare en grote opslagmedia
Later kwamen de diskettes op, het kopieerproces vereenvoudigde en de betrouwbaarheid groeide.
Maar de situatie veranderde radicaal pas toen er voldoende grote lokale opslagmiddelen in de vorm van HDD's verschenen.
Het type levering verandert principieel: er komen installatieprogramma's die het configuratieproces beheren, evenals het schoonmaken na verwijdering, omdat programma's niet alleen naar het geheugen worden gelezen, maar al in de lokale opslag worden gekopieerd, waarvan onnodige data indien nodig moet kunnen worden verwijderd.
Tegelijkertijd neemt de complexiteit van de geleverde software toe.
Het aantal bestanden in de levering stijgt van enkele tot honderden en duizenden, en er ontstaan versieconflicten tussen bibliotheken en andere problemen wanneer verschillende programma's dezelfde gegevens gebruiken.
In die tijd was het bestaan van Linux voor mij nog niet bekend; ik leefde in de wereld van MS DOS en later Windows, en programmeerde in Borland Pascal en Delphi, af en toe kijkend naar C++. Voor de levering van producten gebruikten velen in die tijd InstallShield , dat met succes alle opgestelde taken voor het implementeren en configureren van software oploste.
Het tijdperk van het internet
Geleidelijk aan wordt de complexiteit van softwaresystemen nog ingewikkelder; de overgang van monoliet en desktopapplicaties naar gedistribueerde systemen, dunne clients en microservices vindt plaats. Nu moet je niet slechts Ć©Ć©n programma configureren, maar een hele reeks, op zo'n manier dat ze allemaal goed samenwerken.
Het concept veranderde volledig; het internet kwam, en het tijdperk van de cloudservices begon. Het was nog maar in de beginfase, in de vorm van websites, en niemand droomde echt van serivces, maar dit was een keerpunt in de industrie, zowel in de ontwikkeling als in de levering van applicaties.
Voor mezelf merkte ik op dat op dit moment een generatiewissel van ontwikkelaars plaatsvond (of was het alleen in mijn omgeving?), en er was een gevoel dat alle oude, vertrouwde leveringsmethoden plotseling waren vergeten en alles weer vanaf het begin begon: alle leveringen gebeurden met handgeschreven scripts en dit werd trots 'Continuous delivery' genoemd. In feite begon een periode van chaos, waarbij het oude vergeten was en niet meer werd gebruikt, terwijl het nieuwe simpelweg ontbrak.
Ik herinner me de tijd toen in het bedrijf waar ik toen werkte (ik zal de naam niet noemen) in plaats van een build te maken via ant (maven was toen nog niet populair of bestond Ć¼berhaupt niet), mensen eenvoudigweg jar bestanden in de IDE maakten en ze zonder problemen in SVN committen. Uiteraard bestond de uitrol uit het ophalen van het bestand uit SVN en het kopiĆ«ren ervan via SSH naar de juiste machine. Zo eenvoudig en grof.
In diezelfde tijd werd de levering van eenvoudige websites op PHP op een heel primitieve manier gedaan door een aangepast bestand simpelweg via FTP naar de doelmachine te kopiĆ«ren. Soms was er zelfs niet zo'n mogelijkheid ā de code werd live op de productieserver aangepast, en het was bijzonder chic als er ergens backups waren.
RPM- en DEB-pakketten
Aan de andere kant, met de ontwikkeling van het internet zijn UNIX-achtige systemen steeds populairder geworden. Zo ontdekte ik rond het jaar 2000 RedHat Linux 6 voor mezelf. Uiteraard waren er ook daar bepaalde middelen voor het leveren van software. Volgens Wikipedia ontstond RPM als de belangrijkste pakketbeheerder al in 1995, met de release van RedHat Linux 2.0. En sindsdien wordt het systeem geleverd in de vorm van RPM-pakketten en bestaat het succesvol voort en ontwikkelt het zich verder.
De distributies van de Debian-familie zijn een vergelijkbaar pad ingeslagen en hebben de levering in de vorm van deb-pakketten geĆÆmplementeerd, wat tot op de dag van vandaag onveranderd is gebleven.
Pakketbeheersystemen maken het mogelijk om de softwareproducten zelf te leveren, ze tijdens de installatie te configureren, afhankelijkheden tussen verschillende pakketten te beheren, producten te verwijderen en ongewenste bestanden tijdens de de-installatie schoon te maken. Dit is in grote lijnen alles wat nodig is; daarom hebben ze gedurende enkele decennia vrijwel zonder veranderingen standgehouden.
Cloud computing heeft het pakketbeheer verrijkt met de mogelijkheid om niet alleen van fysieke media te installeren, maar ook uit cloud-repositories. Maar principeel is er weinig veranderd.
Het is opmerkelijk dat er op dit moment enkele bewegingen zijn richting een afgang van deb en een overstap naar snap-pakketten, maar daar later meer over.
Dus, deze nieuwe generatie cloudontwikkelaars, die noch DEB, noch RPM kende, groeide ook langzaam, deed ervaring op, en de producten werden complexer. Er waren betere manieren van levering nodig dan FTP, bash-scripts en soortgelijke studentenhacks.
En hier komt Docker in beeld, een soort mix van virtualisatie, resource-isolatie en leveranciersmethoden. Dit is nu trendy en modern, maar is het echt nodig voor alles? Is het een panacee?
Uit mijn observaties blijkt dat Docker vaak niet als een verstandige keuze wordt aangeboden, maar gewoon omdat hierover in de gemeenschap wordt gesproken. En degenen die het voorstellen, kennen meestal alleen dat product. Aan de andere kant, over de oude vertrouwde verpakkingssystemen wordt vrijwel niet gesproken ā ze zijn er en ze doen hun werk stilletjes en onopvallend. In zo'n situatie is er niet veel keuze ā de keuze is duidelijk ā Docker.
Ik zal proberen mijn ervaring te delen over hoe wij Docker hebben geĆÆmplementeerd en wat uiteindelijk het resultaat was.
Eigen scripts
Aanvankelijk waren er bash-scripts die jar-archieven op de juiste machines uitrolden. Dit proces werd beheerd door Jenkins. Dit werkte goed, aangezien het jar-archief op zichzelf al een bundel is die klassen, bronnen en zelfs configuratie bevat. Als je alles maximaal erin stopt, is het uitpakken met een script niet het moeilijkste dat je hoeft te doen.
Maar scripts hebben verschillende nadelen:
- scripts worden meestal haastig geschreven en zijn daardoor zo primitief dat ze maar Ć©Ć©n succesvolle scenario bevatten. Dit komt doordat de ontwikkelaar geĆÆnteresseerd is in een snelle oplevering, terwijl een normaal script een aanzienlijke hoeveelheid middelen vereist.
- als gevolg van het vorige punt bevatten scripts geen de-installatieprocedures.
- er is geen vastgestelde upgradeprocedure.
- bij de lancering van een nieuw product moet er een nieuw script geschreven worden.
- er is geen ondersteuning voor afhankelijkheden.
Natuurlijk kun je een geavanceerd script schrijven, maar zoals ik al eerder zei, dat kost ontwikkeltijd, en tijd is, zoals bekend, altijd schaars.
Dit beperkt duidelijk het toepassingsgebied van deze uitrolmethode tot de eenvoudigste systemen. Het is tijd om dit te veranderen.
Docker
Op een gegeven moment begonnen nieuwe mid-level ontwikkelaars met veel ideeĆ«n en dromen over Docker bij ons te komen. Nou, de vlag kan hijsen ā laten we het doen! Er waren twee pogingen. Beide waren niet succesvol ā laten we zeggen, vanwege hoge ambities, maar te weinig praktische ervaring. Moest het geforceerd worden en met alle middelen worden afgemaakt? Waarschijnlijk niet ā het team moet evolutionair op het juiste niveau komen voordat ze de juiste tools kunnen gebruiken. Bovendien kwamen we bij het gebruik van kant-en-klare Docker-afbeeldingen vaak tegen dat het netwerk daar niet goed werkte (wat mogelijk ook te maken had met de onvolwassenheid van Docker zelf) of dat het moeilijk was om de containers van anderen uit te breiden.
Met welke ongemakken hebben we te maken gehad?
- Netwerkproblemen in bridge-modus.
- Het is moeilijk om logs in de container te bekijken (tenzij ze apart in het bestandssysteem van de hostmachine worden opgeslagen).
- Af en toe een vreemde vastloper van ElasticSearch binnen de container, de oorzaak is nooit vastgesteld, het is een officiƫle container.
- Het is onhandig om de shell binnen de container te gebruiken ā alles is sterk beperkt, er zijn geen vertrouwde tools beschikbaar.
- Grote grootte van verzamelde containers zorgt voor hoge opslagkosten
- Door de grote grootte van containers is het moeilijk om meerdere versies te onderhouden
- Lange opbouwtijd, in tegenstelling tot andere methoden (scripts of deb-pakketten)
Aan de andere kant, waarom kan een Spring-service in de vorm van een jar-archief niet gewoon als een deb worden gedeployed? Is resource-isolatie echt nodig? Moeten we handige hulpprogramma's van het besturingssysteem opgeven door de service in een sterk vereenvoudigde container te stoppen?
Uit ervaring blijkt dat dit in de praktijk niet nodig is; een deb-pakket volstaat in 90% van de gevallen.
Wanneer werkt het oude vertrouwde deb-pakket niet en wanneer hebben we echt Docker nodig?
Voor ons was dit het uitrollen van services in Python. Veel bibliotheken die nodig zijn voor machine learning en die ontbreken in de standaard levering van het besturingssysteem (en de versies die er waren, waren niet de juiste), hacks met configuraties, de noodzaak voor verschillende versies voor verschillende services die op hetzelfde host-systeem draaien, leidde ertoe dat de enige redelijke manier om deze complexe mix aan te bieden Docker bleek te zijn. De arbeidsintensiviteit van het bouwen van een Docker-container bleek minder te zijn dan het idee om dit alles in aparte deb-pakketten met afhankelijkheden te verpakken; eerlijk gezegd zou niemand in zijn gezonde verstand dat op zich nemen.
Een tweede punt waar Docker wordt overwogen, is voor het uitrollen van services volgens het blue-green deployment schema. Maar hier wil men de complexiteit geleidelijk verhogen: eerst worden deb-pakketten gebouwd, en daarna wordt daaruit de Docker-container samengesteld.
Snap-pakketten
Laten we terugkeren naar snap-pakketten. Ze verschenen voor het eerst officieel in Ubuntu 16.04. In tegenstelling tot de gebruikelijke deb- en rpm-pakketten bevatten snap-pakketten alle afhankelijkheden. Enerzijds voorkomt dit conflicten met bibliotheken, anderzijds resulteert dit in aanzienlijk grotere pakketgroottes. Bovendien kan dit invloed hebben op de veiligheid van het systeem: bij de levering van snap moet de ontwikkelaar die het pakket maakt, zelf toezicht houden op alle wijzigingen in de ingesloten bibliotheken. Kortom, het is niet zo eenvoudig en het algemene geluk van hun gebruik is niet gegarandeerd. Maar toch is het een heel redelijke alternatieve oplossing, als Docker alleen wordt gebruikt als verpakkingsmiddel en niet voor virtualisatie.
Uiteindelijk maken we nu in een redelijke combinatie gebruik van zowel deb-pakketten als Docker-containers, die we in bepaalde gevallen misschien zullen vervangen door snap-pakketten.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquĆŖte. , alstublieft.
Wat gebruikt u voor levering?
Eigen scripts
Handmatig kopiƫren naar FTP
deb-pakketten
rpm-pakketten
snap-pakketten
Docker-images
Virtuele machine-images
We klonen de hele HDD
puppet
ansible
Anders
109 gebruikers stemden. 32 gebruikers onthielden zich.
Bron: habr.com
