Valahogy egy ponton úgy döntöttem, hogy írok egy cikket a szállításról Docker-konténerek és deb-csomagok formájában, de amikor elkezdtem, valamiért az első személyi számítógépek, sőt számológépek távoli idejébe kerültem. Általánosságban elmondható, hogy a docker és a deb száraz összehasonlítása helyett ezeket a gondolatokat kaptuk az evolúció témájában, amelyeket figyelmébe ajánlok.
Bármilyen termékről van szó, valamilyen módon el kell jutnia a termékszerverekhez, be kell állítani és el kell indítani. Ez a cikk erről fog szólni.
Történelmi kontextusban fogok gondolni arra, hogy „amit látok, arról énekelek”, amit akkor láttam, amikor először elkezdtem kódot írni, és mit figyelek meg most, mi magunk mit használunk jelenleg és miért. A cikk nem állítja be magát egy teljes értékű tanulmánynak, néhány pont kimaradt, ez az én személyes véleményem arról, hogy mi volt és mi van.
Szóval, a régi szép időkben... a legkorábbi szállítási mód, amit találtam, magnók kazettás kazettái voltak. Volt egy BK-0010.01 számítógépem...
A számológépek korszaka
Nem, volt egy még korábbi pillanat, volt egy számológép is и .
Szóval amikor volt , akkor a program átvitelének módja egy közönséges papírlap volt egy dobozban, amelyre egy programot írtak, amelyet szükség esetén a manuális futtatáshoz beírtak a számológépbe. Ha játszani akarsz (igen, még ebben az özönvíz előtti számológépben is voltak játékok) - ülj le és írd be a programot a számológépbe. Természetesen, amikor a számológépet kikapcsolták, a program eltűnt a feledés homályába. A műsorok a személyesen papírra kiírt számológép kódokon kívül megjelentek a „Rádió” és a „Technológia fiataloknak” folyóiratban, illetve az akkori könyvekben is megjelentek.
A következő módosítás egy számológép volt , már van némi látszata a nem felejtő adattárolásnak. Most már nem kellett kézzel beírni a játékot vagy programot, hanem néhány varázslatos passz végrehajtása után a gombokkal betöltötte magát.
A számológép legnagyobb programjának mérete 105 lépés, az MK-52 állandó memóriájának mérete pedig 512 lépés volt.
Mellesleg, ha vannak rajongói ezeknek a számológépeknek, akik olvassák ezt a cikket, a cikk írása során találtam egy számológép-emulátort Androidhoz és programokat is. Előre a múltba!
Egy rövid kitérő az MK-52-ről (a Wikipédiából)
Az MK-52 a Szojuz TM-7 űrszondán repült az űrbe. A leszállási pálya kiszámításához kellett volna használni, ha a fedélzeti számítógép meghibásodik.
52 óta az Elektronika-Astro memóriabővítő egységgel ellátott MK-1988-t a haditengerészet hajóihoz szállítják a navigációs számítástechnikai készlet részeként.
Az első személyi számítógépek
Térjünk vissza az időkbe . Jól látható, hogy több memória volt ott, és a kód beírása egy papírlapról már nem volt lehetőség (bár eleinte ezt csináltam, mert egyszerűen nem volt más adathordozó). A magnókhoz készült hangkazetták a szoftverek tárolásának és szállításának fő eszközeivé válnak.
A kazetta tárolása általában egy-két bináris fájl formájában történt, minden más benne volt. A megbízhatóság nagyon alacsony volt, 2-3 példányt kellett megtartanom a programból. A betöltési idők is csalódást okoztak, és a rajongók különböző frekvenciakódolásokkal kísérleteztek, hogy kiküszöböljék ezeket a hiányosságokat. Akkor még nem foglalkoztam professzionális szoftverfejlesztéssel (nem számítva az egyszerű BASIC programokat), így sajnos nem árulom el részletesen, hogy belül hogyan volt elrendezve. Maga az a tény, hogy a számítógépben többnyire csak RAM volt, meghatározta az adattárolási séma egyszerűségét.
Megbízható és nagy adathordozók megjelenése
Később megjelentek a hajlékonylemezek, leegyszerűsödött a másolási folyamat, nőtt a megbízhatóság.
De a helyzet csak akkor változik drámaian, ha kellően nagy helyi tárolók jelennek meg HDD-k formájában.
Alapvetően változik a kézbesítés típusa: megjelennek a telepítő programok, amelyek a rendszer konfigurálásának folyamatát, valamint az eltávolítás utáni tisztítást irányítják, hiszen a programok nem csak a memóriába kerülnek beolvasásra, hanem már a helyi tárhelyre másolódnak, ahonnan szükség esetén képes legyen kitakarítani a felesleges dolgokat.
Ezzel párhuzamosan a szállított szoftverek összetettsége növekszik.
A kézbesítésben lévő fájlok száma néhányról százra és ezerre nő, a könyvtári verziók közötti konfliktusok és egyéb örömök akkor kezdődnek, amikor a különböző programok ugyanazokat az adatokat használják.
Ekkor még nem volt nyitva előttem a Linux létezése, az MS DOS, majd később a Windows világában éltem, és Borland Pascalban és Delphiben írtam, néha a C++ felé néztem. Akkoriban sokan az InstallShieldot használták termékek szállítására. , amely meglehetősen sikeresen megoldotta a szoftver telepítésével és konfigurálásával kapcsolatos összes feladatot.
Internet korszak
Fokozatosan a szoftverrendszerek összetettsége egyre bonyolultabbá válik, a monolit és asztali alkalmazásoktól áttérnek az elosztott rendszerekre, vékony kliensekre és mikroszolgáltatásokra. Most már nem csak egy programot kell konfigurálnia, hanem ezek egy halmazát, és úgy, hogy mindegyik együtt működjön.
Teljesen megváltozott a koncepció, jött az internet, beköszöntött a felhőszolgáltatások korszaka. Eddig még csak a kezdeti szakaszban, weboldalak formájában senki sem álmodott különösebben szolgáltatásokról. de fordulópontot jelentett mind az alkalmazások fejlesztésében, mind szállításában.
Magamnak megjegyeztem, hogy abban a pillanatban a fejlesztők generációiban váltás történt (vagy csak a környezetemben), és az az érzésem, hogy a régi jó szállítási módok egy pillanat alatt feledésbe merültek, és minden elölről indult. kezdete: az összes szállítást térdszkriptekkel kezdték végezni, és büszkén nevezték „folyamatos szállításnak”. Valójában a káosz időszaka kezdődött, amikor a régit elfelejtik, nem használják, az új pedig egyszerűen nem létezik.
Emlékszem azokra az időkre, amikor a cégünkben, ahol akkor dolgoztam (nem nevezem meg), ahelyett, hogy a hangyán keresztül építettek volna (a maven még nem volt népszerű, vagy egyáltalán nem létezett), az emberek egyszerűen begyűjtötték a tégelyeket az IDE-ben, és nyugodtan elkötelezték magukat. az SVN-ben. Ennek megfelelően a telepítés abból állt, hogy lekérték a fájlt az SVN-ről, és SSH-n keresztül másolták a kívánt gépre. Olyan egyszerű és ügyetlen.
Ugyanakkor az egyszerű webhelyek PHP-ben történő szállítása nagyon primitív módon történt, egyszerűen átmásolták a javított fájlt FTP-n keresztül a célgépre. Néha ez nem így történt – a kódot élőben szerkesztették a termékszerveren, és különösen elegáns volt, ha valahol voltak biztonsági mentések.
RPM és DEB csomagok
Másrészt az internet fejlődésével a UNIX-szerű rendszerek egyre nagyobb népszerűségre tettek szert, különösen ekkor fedeztem fel a RedHat Linux 6-ot, körülbelül 2000-ben. Természetesen a szoftverek szállítására is voltak módok, a Wikipédia szerint az RPM mint fő csomagkezelő már 1995-ben, a RedHat Linux 2.0 verziójában megjelent. Azóta és a mai napig a rendszert RPM-csomagok formájában szállítják, és meglehetősen sikeresen létezik és fejlődik.
A Debian család disztribúciói is hasonló utat jártak be, és deb csomagok formájában valósították meg a szállítást, amely a mai napig változatlan.
A csomagkezelők lehetővé teszik a szoftvertermékek szállítását, a telepítési folyamat során történő konfigurálást, a különböző csomagok közötti függőségek kezelését, a termékek eltávolítását és a szükségtelen elemek eltávolítását az eltávolítási folyamat során. Azok. többnyire csak ennyi kell, ezért gyakorlatilag változatlanok voltak több évtizeden át.
A felhőalapú számítástechnika nemcsak fizikai adathordozóról, hanem felhőtárolókból is telepítette a csomagkezelőket, de alapvetően alig változott.
Érdemes megjegyezni, hogy jelenleg van néhány lépés a deb-ről való elmozdulás és a snap csomagokra való átállás felé, de erről később.
Tehát a felhőfejlesztők ezen új generációja, akik nem ismerték sem a DEB-t, sem az RPM-et, szintén lassan fejlődtek, tapasztalatot szereztek, a termékek összetettebbé váltak, és az FTP-nél, a bash scripteknél és a hasonló hallgatói kézművességnél is ésszerűbb szállítási módokra volt szükség.
És itt jön a képbe a Docker, a virtualizáció, az erőforrás-lehatárolás és a szállítási mód egyfajta keveréke. Most divatos és fiatalos, de mindenhez kell? Ez csodaszer?
Megfigyeléseim szerint a Dockert nagyon gyakran nem ésszerű választásként javasolják, hanem egyszerűen azért, mert egyrészt beszélnek róla a közösségben, és akik ezt javasolják, csak tudják. A jó öreg csomagolórendszerekről viszont többnyire hallgatnak - léteznek és csendben, észrevétlenül végzik a dolgukat. Ilyen helyzetben tényleg nincs más választás - a választás nyilvánvaló - Docker.
Megpróbálom megosztani tapasztalataimat arról, hogyan valósítottuk meg a Dockert, és mi történt ennek eredményeként.
Saját írású forgatókönyvek
Kezdetben voltak bash szkriptek, amelyek jar archívumokat telepítettek a szükséges gépekre. Ezt a folyamatot Jenkins irányította. Ez sikeresen működött, mivel maga a jar archívum már egy összeállítás, amely osztályokat, erőforrásokat és még konfigurációt is tartalmaz. Ha mindent maximálisan beleadsz, akkor nem a legnehezebb a szkriptbe bővíteni
A szkripteknek azonban számos hátránya van:
- A szkripteket általában sietve írják, ezért annyira primitívek, hogy csak egy legjobb forgatókönyvet tartalmaznak. Ezt megkönnyíti az a tény, hogy a fejlesztőt érdekli a gyors szállítás, és egy normál szkript megfelelő mennyiségű erőforrás befektetését igényli.
- az előző pontból adódóan a szkriptek nem tartalmaznak eltávolítási eljárásokat
- nincs kialakított frissítési eljárás
- Amikor új termék jelenik meg, új szkriptet kell írnia
- nincs függőségi támogatás
Természetesen lehet kifinomult forgatókönyvet írni, de ahogy fentebb is írtam, ez nem utolsósorban a fejlesztés ideje, és mint tudjuk, mindig kevés az idő.
Mindez nyilvánvalóan csak a legegyszerűbb rendszerekre korlátozza ennek a telepítési módszernek az alkalmazási körét. Eljött az idő, hogy ezen változtassunk.
Dokkmunkás
Valamikor frissen vert közepek kezdtek érkezni hozzánk, nyüzsögtek az ötletektől és áradoztak a dokkolóról. Hát zászló a kézben – tegyük! Két próbálkozás volt. Mindkettő sikertelen volt - mondjuk nagy ambíciók, de valódi tapasztalat hiánya miatt. Szükséges volt erőltetni és bármilyen módon befejezni? Nem valószínű – a csapatnak a szükséges szintre kell fejlődnie, mielőtt használni tudja a megfelelő eszközöket. Emellett a kész Docker-képek használatakor gyakran találkoztunk azzal, hogy a hálózat nem működött megfelelően (ami talán magának a Dockernek a nedvességéből fakadt), vagy nehézkes volt kibővíteni mások konténereit.
Milyen kellemetlenségekkel találkoztunk?
- Hálózati problémák híd módban
- Kényelmetlen a naplók tárolóban való megtekintése (ha nincsenek külön tárolva a gazdagép fájlrendszerében)
- Az ElasticSearch időnként furcsán lefagy a konténer belsejében, az ok nem derült ki, a konténer hivatalos
- Egy tartályban héjat kell használni - minden nagyon le van csupaszítva, nincsenek szokásos eszközök
- Nagy méretű összegyűjtött tartályok – drága a tárolás
- A konténerek nagy mérete miatt nehéz több verziót támogatni
- Hosszabb építési idő, ellentétben más módszerekkel (szkriptek vagy deb csomagok)
Másrészt miért rosszabb egy Spring szolgáltatást jar archívum formájában telepíteni ugyanazon a deb-en keresztül? Valóban szükséges az erőforrások elkülönítése? Megéri-e elveszíteni az operációs rendszer kényelmes eszközeit, ha egy szolgáltatást egy jelentősen csökkentett konténerbe tömnek?
Ahogy a gyakorlat megmutatta, a valóságban erre nincs szükség, az esetek 90%-ában elegendő a deb csomag.
Mikor bukik el a jó öreg deb, és mikor van igazán szükségünk dockerre?
Számunkra ez a szolgáltatások pythonban történő telepítése volt. A gépi tanuláshoz szükséges és az operációs rendszer szabványos disztribúciójában nem szereplő könyvtárak (és ami volt ott a rossz verziók), beállításokkal való feltörések, az ugyanazon a gazdagépen élő szolgáltatások különböző verzióinak igénye vezetett oda, hogy Ez azt jelenti, hogy ennek a nukleáris keveréknek az egyetlen ésszerű módja a dokkoló volt. A dokkolókonténer összeszerelésének munkaintenzitása alacsonyabbnak bizonyult, mint az az ötlet, hogy az egészet különálló deb-csomagokba csomagolják, függőséggel, és erre valójában senki sem vállalkozna.
A második pont, ahol a Docker használatát tervezik, a szolgáltatások telepítése a kék-zöld telepítési séma szerint. De itt szeretnék fokozatosan növelni a komplexitást: először deb csomagokat építenek, majd ezekből építenek egy docker konténert.
Snap csomagok
Térjünk vissza a gyorscsomagokhoz. Először hivatalosan az Ubuntu 16.04-ben jelentek meg. A szokásos deb és rpm csomagokkal ellentétben a snap az összes függőséget hordozza. Ez egyrészt lehetővé teszi a könyvtári konfliktusok elkerülését, másrészt az így létrejövő csomag nagyobb méretű. Ez ráadásul a rendszer biztonságát is érintheti: snap kézbesítés esetén a beépített könyvtárak minden változását a csomagot létrehozó fejlesztőnek kell figyelnie. Általánosságban elmondható, hogy nem minden olyan egyszerű, és az egyetemes boldogság nem származik használatukból. De ennek ellenére ez egy teljesen ésszerű alternatíva, ha ugyanazt a Dockert csak csomagolóeszközként használják, és nem virtualizációra.
Ennek eredményeként most már a deb csomagokat és a docker konténereket is ésszerű kombinációban használjuk, amelyeket esetleg egyes esetekben snap csomagokra cserélünk.
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Mit használsz a szállításhoz?
-
Saját írású forgatókönyvek
-
Kézi másolás FTP-re
-
deb csomagok
-
rpm csomagok
-
csattanós csomagok
-
Docker-képek
-
Virtuális gép képek
-
Klónozza a teljes HDD-t
-
báb
-
ansible
-
Más
109 felhasználó szavazott. 32 felhasználó tartózkodott.
Forrás: will.com