Egy időben elhatároztam, hogy írok egy cikket a Docker konténer alapú és deb csomagokkal való szállításról, de amikor elkezdtem, valamiért a régi személyi számítógépek és még a számológépek távoli időszakába csöppentem. Végül a száraz Docker és deb összehasonlítások helyett ilyen gondolatokat osztok meg az evolúcióról, amelyeket az Ön elé terjesztek.
Bármely termék, akármilyen legyen is, valamilyen módon el kell jutnia a termelői szerverekhez, be kell állítani és működésbe kell helyezni. Erről fog szólni ez a cikk.
Történelmi kontextusban fogok gondolkodni, «amit látok — arról éneklek», amit láttam, amikor csak elkezdtem kódot írni, és amit most figyelek meg, amit mi magunk jelenleg használunk és miért. A cikk nem igényli a teljeskörű kutatást, néhány dolog kimaradt, ez az én személyes nézőpontom arról, ami volt, és ami most van.
Tehát a régi szép időkben… a legkorábbi szállítási mód, amellyel találkoztam, a kazettás magnók voltak. Nekem volt egy BK-0010.01 számítógépem...
A számológépek kora
Nem, volt egy még korábbi pillanat, volt egy számológép is. és .
Tehát amikor nekem volt , akkor a program átvitelének módja egy sima kockás papírlap volt, amelyen a program volt feljegyezve, amelyet szükség esetén kézzel írtam be a számológépbe. Ha játszani akartál (igen, még ezen a régi számológépen is voltak játékok) — leültél, és beírtad a programot a számológépbe. Természetesen, amikor a számológép ki volt kapcsolva, a program a semmibe veszett. Ezen kívül, a saját kezűleg papírra írt kódokon kívül a programok a «Rádió» és a «Fiatalok Technikája» folyóiratokban jelentek meg, valamint a korabeli könyvekben is kinyomtatták őket.
A következő módosítás a következő számológép volt , már volt valami energiafüggetlen adatmegőrzése. Most már nem kellett kézzel beírni a játékot vagy programot, hanem néhány varázslatos gombnyomással magától betöltődött.
A számológép legnagyobb programjának mérete 105 lépés volt, a MK-52 állandó memória mérete pedig 512 lépés.
Egyébként, ha vannak fanatikusai ezeknek a számológépeknek, akik ezt a cikket olvassák — a cikk írása közben találtam egy számológép emulátort Androidra, valamint programokat hozzá. Íme, vissza a múltba!
Egy kis kitérő az MK-52-ről (a wikipédiából)
Az MK-52 a „Szojuz TM-7” űrhajón repült az űrbe. A célja az volt, hogy a leszállási pályát kiszámítsa, ha a fedélzeti számítógép meghibásodna.
Az MK-52 az „Elektronika-Astro” memória bővítőblokkal 1988 óta a haditengerészet hajóira került, a navigátor számítástechnikai komplexum részeként.
Az első személyi számítógépek
Térjünk vissza az időbe . Nyilvánvaló, hogy a memória mennyisége is megnőtt, és a kód papírról való gépelése már teljesen kivitelezhetetlen volt (bár az elején tényleg így tettem, mert más tároló nem volt). A szoftverek tárolásának és átadásának fő eszköze a magnókazetta lett.
A kazettás tárolás általában egy vagy két bináris fájl formájában valósult meg, minden más belül helyezkedett el. A megbízhatóság nagyon alacsony volt, gyakran 2-3 másolatot kellett tartani a programról. A betöltési idő sem volt kedvező, a lelkesek különböző frekvenciakódolással kísérleteztek, hogy leküzdjék ezeket a hátrányokat. Én akkoriban még nem foglalkoztam professzionális szoftverfejlesztéssel (kivéve néhány egyszerű BASIC programot), így a belső felépítés részleteiről sajnos nem tudok beszélni. Az, hogy a számítógépen alapvetően csak RAM volt, nagymértékben meghatározta az adatok tárolásának egyszerűségét.
Megbízható és nagy információtárolók megjelenése
Később megjelentek a floppy lemezek, egyszerűsödött a másolási folyamat, és növekedett a megbízhatóság.
De a helyzet drámaian változik, amikor elegendő nagy helyi tárolók, HDD formájában megjelennek.
A szállítás típusa alapvetően megváltozik: megjelennek a telepítőprogramok, amelyek kezelik a rendszer konfigurálási folyamatát, valamint a törlés utáni tisztítást, mivel a programok nem csupán az emlékezetbe kerülnek, hanem már a helyi tárolóba másolják őket, ahonnan szükség esetén tudni kell eltávolítani a felesleges fájlokat.
Párhuzamosan növekszik a szállított szoftver bonyolultsága.
A szállítmányban található fájlok száma egytől akár több százra és ezerre nő, verzióütközések lépnek fel a könyvtárak között, és más örömök, amikor különböző programok ugyanazokat az adatokat használják.
Abban az időben még nem volt számomra nyilvánvaló a Linux létezése, MS DOS-ban és később Windowsban éltem, Borland Pascalban és Delphi nyelven írtam, néha C++ felé is nézegettem. A termékek szállítására sokan használták az InstallShield-et. , amely sikeresen megoldotta az összes felmerülő feladatot a szoftverek telepítése és konfigurálása során.
Az internet kora
Fokozatosan a szoftverrendszerek bonyolultsága még inkább növekedett, a monolitikus és asztali alkalmazások átmenetet képeztek a megosztott rendszerek, vékony kliensek és mikroszolgáltatások felé. Most már nem egy programot kell konfigurálni, hanem egy egész halmazt, úgy, hogy azok együttműködjenek.
A koncepció teljesen megváltozott, megérkezett az Internet, elkezdődött a felhőszolgáltatások kora. Ekkor még csak kezdeti szakaszban voltunk, a weboldalak formájában, senki sem álmodozott igazán szolgáltatásokról. De ez egy fordulópont volt az iparban, mind a fejlesztés, mind az alkalmazások szállítása terén.
Számomra ez a pillanat a fejlesztők generációváltását jelezte (vagy csak az én környezetemben történt), és az a benyomás alakult ki, hogy minden régi, jól bevált szállítási módszert egy pillanat alatt elfelejtenek, és minden kezdődik elölről: az egész szállítást a kálváriás szkriptek formájában végezték, és ezt büszkén neveztek "Folyamatos szállításnak". Valójában egyfajta káosz kezdődött, amikor a régit elfelejtették és nem használták, míg az új gyakorlatilag nem létezett.
Emlékszem az időkre, amikor abban a cégben, ahol akkor dolgoztam (nem mondom meg a nevét), az emberek ahelyett, hogy ant segítségével készítették volna el a buildet (a maven akkor még nem volt népszerű vagy egyáltalán nem létezett), egyszerűen jar fájlokat gyártottak az IDE-ben, és gondtalanul elkötelezték őket az SVN-ben. Így a telepítés abból állt, hogy kivették a fájlt az SVN-ből, és SSH-n átkopizták a megfelelő gépre. Ilyen egyszerű és közvetlen volt.
Ebben az időben a PHP alapú egyszerű weboldalak szállítása ugyancsak primitív módon, egyszerű fájlok FTP-n keresztüli másolásával történt a célgépire. Néha még ez sem volt meg - a kódokat élőben módosították a termelő szerveren, és különös elegancia 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 népszerűbbé váltak, különösképpen abban az időben felfedeztem a RedHat Linux 6-ot, körülbelül 2000-ben. Természetesen itt is voltak bizonyos eszközök a szoftverek telepítésére, a Wikipédia szerint az RPM, mint fő csomagkezelő, már 1995-ben megjelent a RedHat Linux 2.0 verziójában. Azóta a rendszer RPM-csomagok formájában érkezik, és sikeresen létezik és fejlődik egészen napjainkig.
A Debian család disztribúciói hasonló utat követtek, és deb-csomagok formájában valósították meg a telepítést, ami szintén megmaradt napjainkig.
A csomagkezelők lehetővé teszik a szoftvertermékek szállítását, konfigurálását a telepítés során, a különböző csomagok közötti függőségek kezelését, a termékek törlését és a felesleges elemek eltávolítását a deinstallálás során. Tehát alapvetően ez minden, amire szükség van, ezért beszélhetünk arról, hogy évtizedek óta szinte változatlanok maradtak.
A felhőtechnológia lehetővé tette a csomagkezelők számára, hogy ne csak fizikai médiáról, hanem felhős tárolókból is telepítsenek, de alapvetően ez nem változtatott sokat.
Érdemes megjegyezni, hogy manapság vannak törekvések a deb csomagok elhagyására és a snap-csomagok használatára, de erről később.
Tehát ez az új felhőfejlesztő generáció, amely nem ismerte a DEB-t és az RPM-t, is fokozatosan nőtt, tapasztalatokat szerzett, a termékek bonyolultabbá váltak, és szükség volt valamilyen ésszerűbb szállítási módszerre, mint az FTP, bash szkriptek és hasonló diákprojektek.
Ebben a pillanatban lép színre a Docker, ami egyfajta virtualizáció, erőforrások elkülönítése és szállítási mód keveréke. Mostanság ez divatos, ifjúsági, de szükség van rá mindenhez? Pánacea ez?
Megfigyeléseim szerint a Dockert gyakran nem ésszerű választásként ajánlják, hanem csak azért, mert a közösségben erről beszélnek, és azok, akik ajánlják, csak ezt ismerik. Másrészt a régi jó csomagolási rendszerekről általában hallgatnak - léteznek és csendben végzik a dolgukat. Ilyen helyzetben alig van más választás - a választás nyilvánvaló: Docker.
Megpróbálom megosztani a tapasztalataimat, hogy nálunk hogyan zajlott a Docker bevezetése, és mi lett az eredmény.
Saját írású szkriptek
Kezdetben bash-scriptek voltak, amelyek jar-archívumokat telepítettek a szükséges gépekre. Ezt a folyamatot a Jenkins irányította. Ez sikeresen működött, mivel maga a jar-archívum már egy olyan csomag, amely tartalmazza az osztályokat, erőforrásokat és még a konfigurációt is. Ha mindent maximálisan összegyűjtünk benne, akkor a script segítségével való kicsomagolása nem a legnehezebb feladat.
De a scripteknek van néhány hátránya:
- A scriptek általában kapkodva készülnek, ezért annyira primitívek, hogy csak egy legjobban sikerült forgatókönyvet tartalmaznak. Ezt elősegíti, hogy a fejlesztő a lehető leggyorsabb szállításra törekszik, míg egy normális script megírása jelentős erőforrás-befektetést igényel.
- A korábbi pont következményeként a scriptek nem tartalmazzák a deinstalálási eljárást.
- Nincs megszabott frissítési eljárás.
- Új termék megjelenésekor új scriptet kell írni.
- Nincs függőségek támogatása.
Természetesen lehet írni egy kifinomult scriptt, de, ahogy fentebb említettem, ez időt igényel, és nem is keveset, míg az idő mindig szűkös.
Ez nyilvánvalóan korlátozza a telepítési módszer alkalmazási területét az egyszerű rendszerekre. Itt az ideje változtatni.
Docker
Valamikor újonnan érkezett középszintű fejlesztők kezdtek hozzánk jönni, tele ötletekkel és a dockerral kapcsolatban álmodozva. Nos, zászlót a kézbe – csináljuk! Két próbálkozásunk volt. Mindkettő sikertelen – mondhatni, nagy ambíciókkal, de valós tapasztalat híján. Muszáj volt siettetni és mindenáron befejezni? Valószínűleg nem – a csapatnak evolúciósan el kell érnie a szükséges szintet, mielőtt képes lesz a megfelelő eszközök használatára. Ráadásul, amikor kész Docker képeket használtunk, gyakran találkoztunk azzal, hogy a hálózat nem működött helyesen (ami valószínűleg a Docker minőségével is összefüggött), vagy nehéz volt mások konténereit bővíteni.
Milyen kellemetlenségekkel szembesültünk?
- Hálózati problémák bridge módban.
- Nem kényelmes a konténeren belüli naplókat nézni (ha azokat nem külön a host gép fájlrendszerébe mentik).
- Időnként furcsa lefagyások az ElasticSearch-ban a konténeren belül, az okát nem sikerült megállapítani, a konténer hivatalos.
- Nem kényelmes a shell használata a konténeren belül – minden nagyon le van korlátozva, nincsenek megszokott eszközök.
- Nagy konténer méret – drága tárolni
- A nagy konténerméret miatt nehezen tarthatók fenn több verzió
- Hosszabb összeállítás, ellentétben más módszerekkel (szkriptek vagy deb-csomagok)
Másrészt, miért rosszabb a Spring-szolgáltatást jar-archívumként telepíteni a deb-en? Valóban szükség van erőforrás-izolációra? Érdemes-e kényelmes operációs rendszerszerszámokat nélkülözni egy erősen korlátozott konténerbe való betevéssel?
A gyakorlat azt mutatja, hogy valóban nem szükséges, a deb-csomag általában elegendő 90%-ban.
Mikor nem működik a régi jó deb, és mikor van valóban szükségünk a Dockerre?
Számunkra ez a Python szolgáltatások telepítését jelentette. Számos könyvtár volt szükséges a gépi tanuláshoz, amelyek nem szerepeltek a standard operációs rendszer telepítésében (és ami ott volt – nem a megfelelő verziók), a beállításokkal kapcsolatos hackek, az ugyanazon host rendszeren futó különböző szolgáltatások igénye, ami a Docker használatát made szükségessé. A Docker-konténer összeállításának munkaigénye alacsonyabb volt, mint az ötlet, hogy mindezt külön deb-csomagokba csomagoljuk a függőségeivel, és valójában senki nem is foglalkozna ezzel józan ésszel.
A második pillanat, ahol a Docker használatát tervezik – szolgáltatások telepítése blue-green deploy séma szerint. De itt fokozatos bonyolultságot szeretnénk elérni: először deb-csomagokat állítanak össze, majd azokból készül el a Docker-konténer.
Snap-csomagok
Térjünk vissza a snap-csomagokhoz. Először az Ubuntu 16.04-ben jelentek meg hivatalosan. A megszokott deb-csomagokkal és rpm-csomagokkal ellentétben a snap magukban hordozzák az összes függőséget. Egyrészt ez segít elkerülni a könyvtárütközéseket, másrészt ez nagyobb eredeti csomagméreteket eredményez. Ezen kívül ez hatással lehet a rendszer biztonságára is: a snap szállítása esetén a csomag létrehozó fejlesztőnek kell nyomon követnie az összes, a belefoglalt könyvtárak változását. Összességében nem egyértelmű, hogy a használatukból származó mindenki elégedett lenne. De mindenesetre ésszerű alternatívát jelentenek, ha a Docker-t csak a csomagolás eszközeként használják, nem pedig virtualizációs eszközként.
Ennek eredményeként most ésszerű kombinációban használunk deb csomagokat és Docker konténereket, amelyeket bizonyos esetekben snap csomagokkal helyettesítünk.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Ön mivel szállít?
Saját írású szkriptek
Kézi másolás FTP-n.
deb csomagok
rpm csomagok
snap csomagok
Docker képek
Virtuális gépek képei
Teljes HDD másolás.
puppet
ansible
Egyéb
109 felhasználó szavazott. 32 felhasználó tartózkodott.
Forrás: habr.com
