A Docker csak egy játék, vagy nem? Vagy mégis?

Mindenkinek szia!

Nagyon szeretném azonnal a témához ugrani, de helyesebb lenne egy kicsit mesélni a történetemről:

Bevezetés

Programozó vagyok, tapasztalattal egyoldalú alkalmazások frontend fejlesztésében, scala/java és nodejs használatában a szerveren.

Elég hosszú ideje (már biztosan pár — három éve) azon a véleményen voltam, hogy a docker mennyei manna, és egyébként is nagyon jó eszköz, és minden programozónak tudnia kellene használni. Ebből következik, hogy minden programozónak dockernek kell lennie a helyi gépén. De ne is beszéljek a véleményemről, nézz meg egy kicsit a hirdetéseket, amiket ugyanott találsz a hh-n. Minden másodikban van egy említés dockerrel kapcsolatban, és ha rendelkezik vele — ez lesz a versenyelőnyöd 😉

Az utam során sok emberrel találkoztam, akik különböző attitűdökkel álltak a dockerhez és annak ökoszisztémájához. Egyesek azt mondták, hogy ez egy kényelmes dolog, amely garantálja a platformfüggetlenséget. Mások nem értették, miért kellene nekik konténerekben futniuk, és mi az előny ebből, harmadikakat pedig egyáltalán nem érdekelt, ők csak írták a kódot és hazamentek — amúgy nekik irigylem ezt 🙂

Használat okai

Miért használtam a dockert? Valószínűleg a következő okok miatt:

• adatbázisok futtatása, a programok 99%-a használja őket
• nginx futtatása a frontend kiszolgálására és a backendre való proxyzáshoz
• az alkalmazásom docker képként való becsomagolása, így az alkalmazásom mindenhol működni fog, ahol docker elérhető, a disztribúciós probléma már azonnal megoldódik
• beépített szolgáltatáskeresés, mikroservices készítése, minden konténer (a közös hálózathoz csatlakozva) könnyen elérheti a másikat aliason, nagyon kényelmes
• Menő konténert létrehozni és „játszani” benne.

Ami mindig NEM tetszett a dockerben:

• Ahhoz, hogy az alkalmazásom működjön, magának a dockernak kell lennie a szerveren. De minek, ha az alkalmazásaim már jre-n vagy nodejs-en futnak, és a környezet már létezik a szerveren?
• Ha szeretném futtatni a saját (privát) helyi gyűjtött képet egy távoli szerveren, akkor szükségem van a saját docker tárolómra, valahol működnie kell a registrynak, és be kell állítani a https-et, mert a docker cli csak https-en működik. Jaj, de… vannak persze lehetőségek, például helyben elmenteni a képet docker save és scp-vel egyszerűen átküldeni a képet… De ez annyi mozgalom. És ez ráadásul „tákolt” megoldásnak tűnik, amíg meg nem jelenik a saját tárolóm.
• docker-composeCsak a konténerek indítására van szükség. És ennyi. Másra nem képes. Docker-compose Sok verziója van a fájljainak, saját szintaxisa. Bárhogy is deklaratív, nem akarom olvasni a dokumentációjukat. Nem lesz rá szükségem máshol.
• Csapatmunkában sokan nagyon hibásan írják a Dockerfile-t, nem értik, hogyan cache-eli, mindent, ami szükséges és szükségtelen beraknak a képekbe, olyan képekből örökölnek, amelyek nincsenek a Docker Hubon vagy egy privát tárolóban, hogy különféle docker-compose fájlokat hoznak létre adatbázisokkal, és semmit sem tartósítanak. Eközben a fejlesztők büszkén állítják, hogy a Docker nagyszerű, minden helyben működik, és az HR fontosnak tartja, hogy a hirdetésekben szerepeljen: „Docker-t használunk, és olyan jelölt kell, akinek van ilyen tapasztalata.”
• állandóan az a gondolat kísért, hogy minden és bármi a Dockerben fusson: PostgreSQL, Kafka, Redis. Kár, hogy nem minden működik konténerekben, nem mindent könnyű konfigurálni és elindítani. Ezt harmadik fél fejlesztők támogatják, nem maguk a gyártók. És egyébként rögtön felmerül a kérdés, hogy ha a gyártók nem aggódnak a termékeik Dockerben való támogatása miatt, talán tudnak valamit?
• mindig felmerül a kérdés a konténer adatok tartósságáról. És itt azon gondolkodom, hogy egyszerűen mount-oljam a gazdadatkönyvtárat vagy hozzak létre egy Docker volume-ot, vagy csináljak egy data container-t, ami most deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume ezért az adatok valahol létrejönnek /usr/* és ugyanaz a történet lesz az uid és gid esetén, mint az első esetben. Ha harmadik fél komponenst indítasz, akkor bele kell olvasnod a dokumentációba és megtalálni a választ a kérdésre: „milyen könyvtárakba írja a komponens a fájlokat a konténerben?”

Mindig is zavart, hogy túl sokáig kell vacakolnom a Dockerrel. a kezdeti szakaszban: kitaláltam, hogyan indítsam a konténereket, milyen képekből indítsak, készítettem Makefile-t, amelyek hosszú Docker parancsok aliasait tartalmazták. Ki nem állhattam a Docker Compose-t, mert nem akartam még egy eszközt tanulni a Docker ökoszisztémában. És docker-compose up különösen zavart, ha még ott is találkoztam build konstrukciókkal, nem pedig már előre elkészített képekkel. Amit tényleg akartam – hogy hatékonyan és gyorsan készítsem el a terméket. De sehogy sem tudtam rendszerezni a Docker használatát.

Ismerkedés az Ansible-lal

Nemrég (három hónappal ezelőtt) dolgoztam egy DevOps csapattal, amelynek szinte minden tagja negatívan viszonyult a Dockerhez. Az okai:

• A Docker irányítja az iptables-t (bár a daemon.json-ban le lehet tiltani)
• A Docker nem stabil, és nem fogjuk éles környezetben futtatni
• Ha a Docker daemon összeomlik, akkor az összes infrastruktúrával rendelkező konténer is összeomlik
• A Docker használata nem szükséges
• Miért a Docker, ha ott van az Ansible és a virtuális gépek?

Ugyanezen a munkahelyen ismerkedtem meg egy másik eszközzel - az Ansible-lal. Valamikor hallottam róla, de nem próbáltam ki a saját playbookjaimat. Most viszont elkezdtem írni a feladataimat, és itt a látásom végleg megváltozott! Mert rájöttem, hogy az Ansible-nek vannak moduljai a Docker konténerek futtatására, a képek összeállítására, a hálózatok kezelésére stb., ráadásul a konténereket nemcsak helyben, hanem távoli szervereken is futtathatjuk! A lelkesedésem határtalan volt - megtaláltam a NORMÁLIS eszközt, és kidobtam a Makefile-jaimat és a docker-compose fájljaimat, helyettük yaml feladatok lettek. A kód csökkent az ilyen szerkezetek használatával loop, when, stb.

A Docker külső komponensek, például adatbázisok futtatására szolgál

Nemrégiben megismertem az SSH alagutakat. Kiderült, hogy nagyon egyszerű "átirányítani" egy távoli szerver portját a helyi portra. A távoli szerver lehet felhőbeli gép, vagy VirtualBox-ban futó virtuális gép. Ha nekem vagy a kollégámnak szüksége van egy adatbázisra (vagy bármely más külső komponensre), egyszerűen elindíthatjuk a szervert ezzel a komponenssel, és leállíthatjuk, amikor nincs rá szükség. A portok átirányítása ugyanolyan hatást gyakorol, mint egy Docker konténerben futó adatbázis.

Ez a parancs irányítja át a helyi portomat egy távoli PostgreSQL szerverre:

ssh -L 9000:localhost:5432 user@example.com

Egy távoli szerver használata megoldja a csapatban végzett fejlesztés problémáját. Ilyen szervert több fejlesztő is használhat egyszerre, nekik nem kell tudniuk beállítani a PostgreSQL-t, érteni a Dockert és egyéb kifinomultságokat. A távoli szerveren ugyanazt az adatbázist telepíthetjük a Dockerbe, ha egy speciális verzió telepítése nehézkes. A fejlesztőknek csak SSH hozzáférést kell biztosítani!

Nemrég olvastam, hogy az SSH alagutak a hagyományos VPN korlátozott funkcionalitása! Egyszerűen beállíthatunk OpenVPN-t vagy más VPN megvalósításokat, beállítjuk az infrastruktúrát, és átadjuk a fejlesztőknek. Ez tényleg nagyon menő!

Szerencsére az AWS, GoogleCloud és hasonlók egy év ingyenes használatot kínálnak, érdemes ezeket kihasználni! Ha nem használjuk őket, nagyon olcsók. Mindig is gondolkodtam, hogy mire lenne szükségem egy távoli szerver típúsú gcloud-ra, úgy tűnik, most megtaláltam őket.

Helyi virtuális gépként ugyanazt az Alpine-t használhatod, amelyet aktívan használnak a docker konténerekben. Vagy választhatsz más könnyített disztribúciókat is, hogy gyorsabban betöltődhessen a gép.

Összegzés: az adatbázisok és egyéb infrastruktúra elemek futtatása távoli szervereken vagy virtualboxban is lehetséges és ajánlott. Nem szükséges docker ezekhez a célokhoz.

Egy kis információ a docker képekről és disztribúciókról.

Már írtam. cikket amelyben szerettem volna kifejezni, hogy a docker képek használata nem nyújt semmilyen garanciát. A docker képek csak arra szolgálnak, hogy létrehozzanak egy docker konténert. Ha egy docker képre támaszkodsz, akkor a docker konténerek használatára is támaszkodsz, és csak azokkal fogsz dolgozni.

Láttál már valahol olyan szoftverfejlesztőket, akik csak docker képbe portolták a termékeiket?
A legtöbb termék eredménye a bináris fájlok egy adott platformhoz. Ezeket egyszerűen hozzáadják a docker képhez, amely a szükséges platformból származik. Elgondolkodtál már azon, miért van annyi hasonló kép a dockerhub-on? Írd be például az nginx-et, és láthatod a rengeteg képet különböző emberektől. Ezek az emberek nem fejlesztették magát az nginx-et, egyszerűen a saját docker képükbe beletették az hivatalos nginx-t, és saját konfigurációikkal tálalták a konténerek indítását.

Összességében tárolhatod egyszerűen tgz formátumban, ha valakinek szüksége van erre dockerben való indításhoz, akkor adja hozzá a tgz-t a Dockerfile-hoz, öröklődjön a szükséges környezettől, és hozzon létre további elemeket, amelyek nem módosítják magát az alkalmazást a tgz-ben. Annak, aki docker képet fog készíteni, tudnia kell, mi az a tgz és mire van szüksége a működéshez. Éppen így használom a dockert. itt

Összegzés: nekem nincs szükségem docker registry-re, inkább valamilyen S3-at vagy egyszerűen fájl tárolót használok, mint a google drive/dropbox.

Docker a CI-ben

Minden cég, ahol dolgoztam, hasonlít egymásra. Jellemzően termékcégek. Vagyis van egy alkalmazásuk, egy technológiai stack-jük (talán néhány programozási nyelv párban - hármasával).

Ezek a cégek docker-t használnak a szervereiken, ahol a CI folyamat zajlik. Kérdés — miért szükséges projekteket docker konténerben építeni a saját szervereinken? Miért ne készítenénk elő egy környezetet az építéshez, például írhatnánk egy Ansible playbookot, amely a szükséges nodejs, php, jdk verziókat telepíti, másolja az ssh kulcsokat stb. arra a szerverre, ahol az építés zajlik?

Most már értem, hogy ez saját lábmetszés, mert a docker nem hoz semmilyen előnyt az izolációjával. CI problémák a dockernél, amelyekkel szembesültem:

• újra szükséges a docker kép az építéshez. Keresni kell a képet vagy írni a saját dockerfile-unkat.
• 90%, hogy valamilyen ssh kulcsot, titkos adatokat kell átadni, amelyeket nem akarok beleírni a docker képbe.
• a konténer létrejön és meghal, minden cache elveszik vele. A következő építés újra le fogja tölteni a projekt összes függőségét, ami lassú és hatástalan, és az idő — pénz.

A fejlesztők nem építenek projekteket docker konténerben (régen én is ilyen rajongó voltam, kár értem a múltban xD). A java lehetőséget ad arra, hogy több verziót tartsunk, és egy parancssal változtassunk arra, amelyik most szükséges. A nodejs hasonló, van nvm.

Következtetés

Úgy gondolom, hogy a docker egy nagyon erőteljes és rugalmas eszköz, és ez a hátránya (furcsán hangzik, igen). A cégek könnyen „rákapnak”, használják, ahol szükséges és ahol nem. A fejlesztők futtatják a saját konténerüket, egyfajta saját környezetet, majd ez az egész simán átmegy a CI-be, a termelésbe. A DevOps csapatok valamilyen kerékpárokat készítenek, hogy elindítsák ezeket a konténereket.

Csak a legutolsó lépcsőfokon használja a dockert a munkafolyamatában, ne cipelje a projektbe az elején. Nem fogja megoldani az üzleti problémáit. Csak áthelyezi a problémákat EGY MÁS szintre, és a saját megoldási javaslatait fogja felkínálni, Ön pedig dupla munkát fog végezni.

Mikor van szükség a dockerre?: arra a megállapításra jutottam, hogy a docker nagyon jó a megvalósított folyamat optimalizálásában, de nem az alapfunkciók felépítésében.

Ha mégis úgy dönt, hogy használja a dockert, akkor:

• legyen nagyon óvatos
• ne kényszerítse a docker használatát a fejlesztőkre
• korlátozza annak használatát egy helyen, ne szórja szét a Dockerfile-t és a docker-compose-t az összes adattárban.

PS:

• Nemrégiben találkoztam a packer-rel. Azt mondják, hogy nagyon jól működik az Ansible-lel, és lehetővé teszi a képmáskák (beleértve a docker image-t is) előállításának folyamatának egységesítését.
• Szintén a dokkról, érdekes cikk.

Köszönöm, hogy elolvastad, kívánok neked átlátható megoldásokat az ügyeidben és produktív munkanapokat!

Forrás: habr.com