Op de een of andere manier besloot ik op een gegeven moment een artikel te schrijven over bezorging in de vorm van Docker-containers en deb-pakketten, maar toen ik begon, werd ik om de een of andere reden teruggevoerd naar de verre tijden van de eerste personal computers en zelfs rekenmachines. Over het algemeen kregen we, in plaats van droge vergelijkingen van docker en deb, deze gedachten over het onderwerp evolutie, die ik ter overweging presenteer.
Elk product, wat het ook is, moet op de een of andere manier bij de productservers komen, moet worden geconfigureerd en gelanceerd. Dat is waar dit artikel over zal gaan.
Ik zal in een historische context denken: ‘wat ik zie is waar ik over zing’, wat ik zag toen ik voor het eerst code begon te schrijven en wat ik nu waarneem, wat we op dit moment zelf gebruiken en waarom. Het artikel pretendeert niet een volwaardige studie te zijn, er worden enkele punten gemist, dit is mijn persoonlijke kijk op wat was en wat nu is.
Dus in de goede oude tijd... was de vroegste leveringsmethode die ik vond cassettebandjes van bandrecorders. Ik had een computer BK-0010.01...
Het tijdperk van rekenmachines
Nee, er was een nog eerder moment, er was ook een rekenmachine и .
Dus toen ik dat had , dan was de manier om het programma over te dragen een gewoon vel papier in een doos waarop een programma was geschreven, dat, indien nodig, om het handmatig uit te voeren, in de rekenmachine werd geschreven. Als je wilt spelen (ja, zelfs deze antediluviaanse rekenmachine had spellen) - ga zitten en voer het programma in de rekenmachine in. Toen de rekenmachine werd uitgeschakeld, verdween het programma uiteraard in de vergetelheid. Naast de rekenmachinecodes die persoonlijk op papier zijn geschreven, werden de programma's gepubliceerd in de tijdschriften "Radio" en "Technology for Youth", en ook in boeken uit die tijd.
De volgende wijziging was een rekenmachine , het heeft al enige schijn van niet-vluchtige gegevensopslag. Nu hoefde het spel of programma niet handmatig te worden ingevoerd, maar na enkele magische passen met de knoppen te hebben uitgevoerd, laadde het zichzelf.
De grootte van het grootste programma in de rekenmachine was 105 stappen en de grootte van het permanente geheugen in MK-52 was 512 stappen.
Trouwens, als er fans zijn van deze rekenmachines die dit artikel lezen, heb ik tijdens het schrijven van het artikel zowel een rekenmachine-emulator voor Android als programma's daarvoor gevonden. Voorwaarts naar het verleden!
Een korte uitweiding over MK-52 (van Wikipedia)
MK-52 vloog de ruimte in met het Sojoez TM-7 ruimtevaartuig. Het moest worden gebruikt om het landingstraject te berekenen voor het geval de boordcomputer uitviel.
Sinds 52 wordt de MK-1988 met de Elektronika-Astro-geheugenuitbreidingseenheid aan marineschepen geleverd als onderdeel van een navigatiecomputerkit.
De eerste personal computers
Laten we teruggaan naar de tijd . Het is duidelijk dat daar meer geheugen was, en code intypen vanaf een vel papier was geen optie meer (al deed ik dat in eerste instantie wel, omdat er simpelweg geen ander medium was). Audiocassettes voor bandrecorders worden het belangrijkste middel voor het opslaan en leveren van software.
Opslag op een cassette vond meestal plaats in de vorm van een of twee binaire bestanden, al het andere zat erin. De betrouwbaarheid was erg laag, ik moest 2-3 exemplaren van het programma bewaren. De laadtijden waren ook teleurstellend en enthousiastelingen experimenteerden met verschillende frequentiecoderingen om deze tekortkomingen te overwinnen. Destijds was ik zelf nog niet bezig met professionele softwareontwikkeling (de eenvoudige programma's in BASIC niet meegerekend), dus ik zal je helaas niet in detail vertellen hoe alles binnenin geregeld was. Juist het feit dat de computer voor het grootste deel alleen RAM had, bepaalde de eenvoud van het gegevensopslagschema.
De opkomst van betrouwbare en grote opslagmedia
Later verschenen er diskettes, werd het kopieerproces vereenvoudigd en nam de betrouwbaarheid toe.
Maar de situatie verandert alleen dramatisch als er voldoende grote lokale opslagruimtes verschijnen in de vorm van HDD's.
Het type levering verandert fundamenteel: er verschijnen installatieprogramma's die het proces van het configureren van het systeem beheren, evenals het opruimen na verwijdering, omdat programma's niet alleen in het geheugen worden gelezen, maar al naar de lokale opslag worden gekopieerd, van waaruit u ze moet verwijderen indien nodig onnodige zaken kunnen opruimen.
Tegelijkertijd neemt de complexiteit van de geleverde software toe.
Het aantal bestanden in de levering neemt toe van enkele tot honderden en duizenden, conflicten tussen bibliotheekversies en andere geneugten beginnen wanneer verschillende programma's dezelfde gegevens gebruiken.
Destijds stond het bestaan van Linux nog niet voor mij open; ik leefde in de wereld van MS DOS en later Windows, en schreef in Borland Pascal en Delphi, soms kijkend naar C++. Veel mensen gebruikten InstallShield toen om producten te leveren. , waarmee alle toegewezen taken van het implementeren en configureren van de software met succes werden opgelost.
Internet-tijdperk
Geleidelijk aan wordt de complexiteit van softwaresystemen nog complexer; van de monoliet- en desktopapplicaties is er een transitie naar gedistribueerde systemen, thin clients en microservices. Nu moet u niet slechts één programma configureren, maar een reeks programma's, zodat ze allemaal samenwerken.
Het concept veranderde volledig, het internet kwam, het tijdperk van clouddiensten brak aan. Tot nu toe heeft niemand, alleen in de beginfase, in de vorm van websites, vooral van diensten gedroomd. maar het was een keerpunt in zowel de ontwikkeling als de levering van applicaties.
Voor mezelf merkte ik op dat er op dat moment een verandering was in de generaties ontwikkelaars (of alleen in mijn omgeving), en dat er een gevoel was dat alle goede oude leveringsmethoden op een gegeven moment waren vergeten en dat alles vanaf het allereerste begin begon. begin: alle leveringen begonnen met kniescripts te gebeuren en noemden het trots "Continu levering". In feite is er een periode van chaos begonnen, waarin het oude vergeten en niet gebruikt wordt, en het nieuwe eenvoudigweg niet bestaat.
Ik herinner me de tijden dat in ons bedrijf waar ik toen werkte (ik zal het niet noemen), in plaats van te bouwen via mier (maven was nog niet populair of bestond helemaal niet), mensen gewoon potten verzamelden in de IO en sereen toegewijd het in SVN. De implementatie bestond daarom uit het ophalen van het bestand bij SVN en het kopiëren ervan via SSH naar de gewenste machine. Het is zo simpel en onhandig.
Tegelijkertijd gebeurde het opleveren van eenvoudige sites in PHP op een zeer primitieve manier door simpelweg het gecorrigeerde bestand via FTP naar de doelmachine te kopiëren. Soms was dit niet het geval: de code werd live op de productserver bewerkt en het was vooral chic als er ergens back-ups waren.
RPM- en DEB-pakketten
Aan de andere kant begonnen UNIX-achtige systemen met de ontwikkeling van internet steeds populairder te worden, vooral in die tijd ontdekte ik RedHat Linux 6, rond 2000. Natuurlijk waren er ook bepaalde middelen om software te leveren; volgens Wikipedia verscheen RPM als belangrijkste pakketbeheerder al in 1995, in de versie van RedHat Linux 2.0. En sindsdien en tot op de dag van vandaag wordt het systeem geleverd in de vorm van RPM-pakketten en is het met succes bestaand en ontwikkeld.
Distributies van de Debian-familie volgden een soortgelijk pad en implementeerden levering in de vorm van deb-pakketten, wat tot op de dag van vandaag onveranderd is gebleven.
Met pakketbeheerders kunt u de softwareproducten zelf leveren, configureren tijdens het installatieproces, afhankelijkheden tussen verschillende pakketten beheren, producten verwijderen en onnodige items opruimen tijdens het deïnstallatieproces. Die. voor het grootste deel is dat alles wat nodig is, en daarom hebben ze tientallen jaren vrijwel onveranderd geduurd.
Cloud computing heeft de installatie van pakketbeheerders toegevoegd, niet alleen vanaf fysieke media, maar ook vanaf cloudopslagplaatsen, maar er is fundamenteel weinig veranderd.
Het is vermeldenswaard dat er momenteel enkele stappen zijn in de richting van het afstappen van deb en het overschakelen naar snap-pakketten, maar daarover later meer.
Dus deze nieuwe generatie cloudontwikkelaars, die noch DEB noch RPM kende, groeide ook langzaam, deed ervaring op, producten werden complexer en er waren redelijker leveringsmethoden nodig dan FTP, bash-scripts en soortgelijke studentenambachten.
En dit is waar Docker in beeld komt, een soort mix van virtualisatie, resource-afbakening en leveringsmethode. Het is nu modieus en jeugdig, maar is het voor alles nodig? Is dit een wondermiddel?
Uit mijn observaties blijkt dat Docker vaak niet als een redelijke keuze wordt voorgesteld, maar eenvoudigweg omdat er enerzijds in de gemeenschap over wordt gesproken, en degenen die het voorstellen alleen maar weten. Aan de andere kant zwijgen ze voor het grootste deel over de goede oude verpakkingssystemen: ze bestaan en doen hun werk stil en onopgemerkt. In zo'n situatie is er eigenlijk geen andere keuze - de keuze ligt voor de hand - Docker.
Ik zal proberen mijn ervaring te delen over hoe we Docker hebben geïmplementeerd en wat er als gevolg daarvan is gebeurd.
Zelfgeschreven scripts
Aanvankelijk waren er bash-scripts die jar-archieven op de vereiste machines implementeerden. Dit proces werd beheerd door Jenkins. Dit werkte met succes, omdat het jar-archief zelf al een assembly is die klassen, bronnen en zelfs configuratie bevat. Als je er alles aan doet, dan is het uitbreiden ervan naar een script niet het moeilijkste wat je nodig hebt
Maar scripts hebben verschillende nadelen:
- scripts worden meestal in haast geschreven en zijn daarom zo primitief dat ze slechts één best-case scenario bevatten. Dit wordt mogelijk gemaakt door het feit dat de ontwikkelaar geïnteresseerd is in een snelle levering, en een normaal script vereist de investering van een behoorlijke hoeveelheid middelen
- Als gevolg van het vorige punt bevatten de scripts geen verwijderingsprocedures
- geen vastgestelde upgradeprocedure
- Wanneer er een nieuw product verschijnt, moet u een nieuw script schrijven
- geen afhankelijkheidsondersteuning
Natuurlijk kun je een geavanceerd script schrijven, maar zoals ik hierboven schreef, dit is ontwikkelingstijd, en niet in de laatste plaats, en, zoals we weten, is er altijd niet genoeg tijd.
Dit alles beperkt uiteraard het toepassingsgebied van deze implementatiemethode tot alleen de eenvoudigste systemen. De tijd is gekomen om hierin verandering te brengen.
havenarbeider
Op een gegeven moment begonnen er vers geslagen middeltjes naar ons toe te komen, bruisend van ideeën en enthousiast over de havenarbeider. Nou, vlag in de hand - laten we het doen! Er waren twee pogingen. Beiden waren niet succesvol - laten we zeggen vanwege grote ambities, maar gebrek aan echte ervaring. Was het nodig om het te forceren en op welke manier dan ook af te maken? Het is onwaarschijnlijk: het team moet naar het vereiste niveau evolueren voordat het de juiste tools kan gebruiken. Bovendien kwamen we bij het gebruik van kant-en-klare Docker-images vaak tegen dat het netwerk niet correct werkte (wat mogelijk te wijten was aan de vochtigheid van de Docker zelf) of dat het moeilijk was om de containers van anderen uit te breiden.
Welke ongemakken zijn wij tegengekomen?
- Netwerkproblemen in bridge-modus
- Het is lastig om logbestanden in een container te bekijken (als ze niet afzonderlijk zijn opgeslagen in het bestandssysteem van de hostmachine)
- ElasticSearch bevriest af en toe vreemd in de container, de reden is niet vastgesteld, de container is officieel
- Het is noodzakelijk om een schaal in een container te gebruiken - alles is erg uitgekleed, er zijn geen gebruikelijke gereedschappen
- Groot formaat ingezamelde containers - duur om op te slaan
- Vanwege het grote formaat van containers is het moeilijk om meerdere versies te ondersteunen
- Langere bouwtijd, in tegenstelling tot andere methoden (scripts of deb-pakketten)
Aan de andere kant: waarom is het erger om een Spring-service in de vorm van een jar-archief via dezelfde deb te implementeren? Is het isoleren van hulpbronnen echt nodig? Is het de moeite waard om handige besturingssysteemtools kwijt te raken door een service in een sterk kleinere container te proppen?
Zoals de praktijk leert is dit in werkelijkheid niet nodig, het deb-pakket is in 90% van de gevallen voldoende.
Wanneer faalt de goede oude deb en wanneer hebben we docker echt nodig?
Voor ons was dit het inzetten van services in Python. Veel bibliotheken die nodig waren voor machinaal leren en niet waren opgenomen in de standaarddistributie van het besturingssysteem (en wat waren er de verkeerde versies), hacks met instellingen, de behoefte aan verschillende versies voor verschillende services die op hetzelfde hostsysteem woonden, leidden tot dit, dat de enige redelijke manier om dit nucleaire mengsel af te leveren de havenarbeider was. De arbeidsintensiteit van het in elkaar zetten van een dockercontainer bleek lager dan het idee om alles in afzonderlijke deb-pakketten met afhankelijkheden te verpakken, en in feite zou niemand bij zijn volle verstand dit ondernemen.
Het tweede punt waarop we Docker willen gebruiken, is het implementeren van services met behulp van het blauwgroene implementatieschema. Maar hier wil ik een geleidelijke toename van de complexiteit bereiken: eerst worden deb-pakketten gebouwd en vervolgens wordt er een docker-container van gebouwd.
Snap-pakketten
Laten we terugkeren naar snap-pakketten. Ze verschenen voor het eerst officieel in Ubuntu 16.04. In tegenstelling tot de gebruikelijke deb-pakketten en rpm-pakketten, draagt snap alle afhankelijkheden. Aan de ene kant kunt u hierdoor bibliotheekconflicten vermijden, aan de andere kant is het resulterende pakket groter van formaat. Bovendien kan dit ook de veiligheid van het systeem beïnvloeden: in het geval van snelle levering moeten alle wijzigingen aan de meegeleverde bibliotheken worden gecontroleerd door de ontwikkelaar die het pakket maakt. Over het algemeen is niet alles zo eenvoudig en komt universeel geluk niet voort uit het gebruik ervan. Maar niettemin is dit een volkomen redelijk alternatief als dezelfde Docker alleen als verpakkingstool wordt gebruikt en niet voor virtualisatie.
Als gevolg hiervan gebruiken we nu zowel deb-pakketten als docker-containers in een redelijke combinatie, die we in sommige gevallen misschien zullen vervangen door snap-pakketten.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Wat gebruiken jullie voor bezorging?
-
Zelfgeschreven scripts
-
Kopieer handmatig naar FTP
-
deb-pakketten
-
rpm-pakketten
-
snap-pakketten
-
Docker-images
-
Virtuele machine-images
-
Kloon de volledige harde schijf
-
marionet
-
Ansible
-
Ander
109 gebruikers hebben gestemd. 32 gebruikers onthielden zich van stemming.
Bron: www.habr.com