A Docker játék vagy nem? Vagy még mindig igaz?

Hello!

Nagyon szeretnék rögtön rátérni a témára, de helyesebb lenne egy kicsit mesélni a történetemről:

Belépés

Programozó vagyok, tapasztalattal rendelkezik frontend egyoldalas alkalmazások, scala/java és nodejs fejlesztésében a szerveren.

Elég sokáig (pár-három évig biztosan) azon a véleményen voltam, hogy a Docker egy mennyei manna, és általában egy nagyon klassz eszköz, és abszolút minden fejlesztőnek tudnia kell használni. Ebből pedig az következik, hogy minden fejlesztőnek telepítenie kell a Dockert a helyi gépére. Mi a véleményem, nézd át az üresedéseket, amik ugyanarra a hh-ra vannak kiírva. Minden másodikban szerepel a docker említése, és ha a birtokában van, ez lesz a versenyelőnyöd 😉

Útközben sok emberrel találkoztam, akik eltérően viszonyultak a Dockerhez és ökoszisztémájához. Egyesek azt mondták, hogy ez egy kényelmes dolog, amely garantálja a platformok közötti funkcionalitást. A másodikok nem értették, hogy miért kell konténerben futni, és milyen haszon lesz belőle, a harmadikat egyáltalán nem érdekelte és nem is zavarta (csak megírták a kódot és hazamentek - irigylem őket, mód :)

A használat okai

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

• adatbázis indul, az alkalmazások 99%-a használja őket
• az nginx elindítása frontend terjesztéshez és proxyzás a háttérrendszerhez
• csomagolhatod az alkalmazást docker image-be, így az alkalmazásom mindenhol fog működni, ahol van docker, a terjesztési probléma azonnal megoldódik
• szolgáltatás felfedezés a dobozból, mikroszolgáltatásokat hozhat létre, minden konténer (közös hálózathoz csatlakozva) könnyen elérheti a másikat álnéven keresztül, nagyon kényelmes
• Jó móka létrehozni egy tárolót és "játszani" benne.

Amit mindig nem szeretek a dockerben:

• Ahhoz, hogy az alkalmazásom működjön, szükségem van a Dockerre a szerveren. Miért van szükségem erre, ha az alkalmazásaim jre-n vagy nodejs-en futnak, és a számukra megfelelő környezet már a szerveren van?
• ha távoli szerveren szeretném futtatni a (privát) helyben összeállított képemet, akkor kell egy saját docker repository, kell, hogy működjön valahol a registry, és be kell állítanom a https-t is, mert a docker cli csak https-en keresztül működik. Ó, a fenébe... persze vannak lehetőségek a kép helyi mentésére is docker save és csak küldje el a képet scp-n keresztül... De ez a sok testmozgás. Ráadásul „mankós” megoldásnak tűnik, amíg meg nem jelenik a saját adattár
• docker-compose. Csak konténerek futtatásához szükséges. Ez minden. Nem tud mást tenni. Docker-compose fájljainak egy csomó verziója van, saját szintaxisa. Bármennyire is deklaratív, nem akarom elolvasni a dokumentációjukat. máshol nem lesz rá szükségem.
• amikor csapatban dolgoznak, a legtöbben nagyon ferdén írnak egy Dockerfile-t, nem értik, hogyan tárolják a gyorsítótárban, mindent hozzáadnak a képhez, amire szükségük van, és amit nem kell, örökölnek olyan képeket, amelyek nem találhatók a Dockerhubban vagy egy privát adattárban, létrehoznak néhányat. docker-compose fájlokat adatbázisokkal, és semmi sem marad fenn. A fejlesztők ugyanakkor büszkén kijelentik, hogy a Docker menő, minden helyileg működik náluk, a HR pedig fontosnak tartja a megüresedést: „Mi Dockert használunk, és ilyen munkatapasztalattal rendelkező jelöltre van szükségünk.”
• Folyamatosan kísértenek a gondolatok, hogy mindent fel kell emelni a Dockerben: postgresql, kafka, redis. Kár, hogy nem minden működik konténerekben, nem mindent könnyű konfigurálni és futtatni. Ezt a külső fejlesztők támogatják, nem maguk a szállítók. És mellesleg azonnal felvetődik a kérdés: a gyártók nem törődnek a termékeik Dockerben való karbantartásával, miért van ez, talán tudnak valamit?
• Mindig felmerül a kérdés a konténeradatok fennmaradásával kapcsolatban. és akkor arra gondolsz, hogy csak csatoljam a gazdagép könyvtárat vagy hozzak létre egy docker kötetet, vagy készítsek egy adattárolót, amely most deprecated? Ha felcsatolok egy könyvtárat, akkor meg kell győződnem arról, hogy a tárolóban lévő felhasználó uid és gid azonosítója megegyezik a tárolót elindító felhasználó azonosítójával, ellenkező esetben a tároló által létrehozott fájlok root jogokkal jönnek létre. Ha használom volume akkor egyesekben egyszerűen létrejönnek az adatok /usr/* és ugyanaz lesz a történet az uid-vel és a gid-vel, mint az első esetben. Ha harmadik féltől származó összetevőt indít el, el kell olvasnia a dokumentációt, és meg kell keresnie a választ a következő kérdésre: „mely konténerkönyvtárakba ír fájlokat az összetevő?”

Mindig nem szerettem, hogy túl sokáig kellett a Dockerrel foglalkoznom a kezdeti szakaszban: Kitaláltam, hogyan indítsam el a konténereket, milyen képeket indítsak el, készítettem Makefile-okat, amelyek a hosszú Docker parancsok álneveit tartalmazták. Utáltam a dokkoló-kompozíciót, mert nem akartam más eszközt megtanulni a dokkoló ökoszisztémában. ÉS docker-compose up Zavart, főleg, ha még ott találkoztak build konstrukciók, nem pedig már összeállított képek. Valójában csak azt akartam, hogy egy terméket hatékonyan és gyorsan készítsek el. De nem tudtam rájönni, hogyan kell használni a dockert.

Bemutatkozik az Ansible

Nemrég (három hónapja) dolgoztam egy DevOps csapattal, amelynek szinte minden tagja negatívan viszonyult a Dockerhez. Okokból:

• a docker szabályozza az iptables-t (bár a daemon.json fájlban letilthatja)
• a docker hibás, és nem fogjuk élesben futtatni
• ha a docker démon összeomlik, akkor minden infrastruktúrával rendelkező konténer ennek megfelelően összeomlik
• nincs szükség dokkolóra
• minek docker, ha van Ansible és virtuális gépek

Ugyanebben a munkában megismerkedtem egy másik eszközzel - az Ansible-vel. Egyszer hallottam róla, de nem próbáltam saját játékkönyveket írni. És most elkezdtem írni a feladataimat és akkor teljesen megváltozott a látásmódom! Mert rájöttem: az Ansible-ben vannak modulok ugyanazon docker konténerek futtatására, image buildek, hálózatok stb., és a konténerek nem csak lokálisan, hanem távoli szervereken is futtathatók! Örömömnek nem volt határa – találtam egy NORMÁL eszközt, és kidobtam a Makefile és Docker-compose fájljaimat, helyükre yaml feladatok kerültek. A kódot olyan konstrukciók használatával csökkentették, mint loop, whenStb

Docker harmadik féltől származó összetevők, például adatbázisok futtatásához

Nemrég ismerkedtem meg az ssh alagutakkal. Kiderült, hogy egy távoli szerver portját nagyon könnyű „továbbítani” egy helyi portra. A távoli szerver lehet egy felhőben lévő gép vagy egy VirtualBoxban futó virtuális gép. Ha a kollégámnak vagy nekem adatbázisra (vagy más harmadik féltől származó komponensre) van szükségünk, egyszerűen elindíthatjuk a szervert ezzel az összetevővel, és kikapcsolhatjuk, ha nincs szükség a szerverre. A porttovábbítás ugyanazt a hatást biztosítja, mint egy docker-tárolóban futó adatbázis.

Ez a parancs továbbítja a helyi portomat egy távoli, postgresql-t futtató szerverre:

ssh -L 9000: localhost: 5432 [e-mail védett]

A távoli szerver használata megoldja a problémát a csapatfejlesztéssel. Egy ilyen szervert több fejlesztő is használhat egyszerre, nem kell tudniuk konfigurálni a postgresql-t, megérteni a Dockert és más bonyodalmakat. Távoli kiszolgálón ugyanazt az adatbázist telepítheti magában a Dockerben is, ha nehéz egy adott verziót telepíteni. A fejlesztőknek csak ssh hozzáférést kell biztosítaniuk!

Nemrég olvastam, hogy az SSH alagutak a normál VPN korlátozott funkciói! Egyszerűen telepítheti az OpenVPN-t vagy más VPN-megvalósításokat, beállíthatja az infrastruktúrát, és használatra átadhatja a fejlesztőknek. Ez olyan király!

Szerencsére az AWS, a GoogleCloud és mások egy év ingyenes használatot biztosítanak Önnek, ezért használja őket! Olcsóak, ha kikapcsolod, amikor nem használod. Mindig azon töprengtem, miért van szükségem egy távoli szerverre, mint a gcloud, és úgy tűnik, megtaláltam őket.

Helyi virtuális gépként ugyanazt az Alpine-t használhatja, amelyet aktívan használnak a docker-tárolókban. Nos, vagy néhány más könnyű eloszlás, hogy a gép gyorsabban elinduljon.

A lényeg: lehet és kell is futtatni adatbázisokat és egyéb infrastrukturális szolgáltatásokat távoli szervereken vagy virtualboxban. Nincs szükségem dokkolóra ezekre a célokra.

Egy kicsit a docker képekről és a terjesztésről

Már írtam статью amelyben azt akartam érzékeltetni, hogy a docker képek használata nem ad garanciát. Docker-képekre csak egy docker-tároló létrehozásához van szükség. Ha docker lemezképre frissít, akkor a Docker-tárolók használatára frissít, és csak azokat fogja használni.

Látott már valahol, ahol a szoftverfejlesztők csak docker image-ben portolják termékeiket?
A legtöbb termék eredménye bináris fájlok egy adott platformhoz; ezeket egyszerűen hozzáadják a docker image-hez, amely a kívánt platformtól öröklődik. Gondolkozott már azon, hogy miért van olyan sok hasonló kép a dockerhubon? Írja be például, hogy nginx, 100500 XNUMX képet fog látni különböző emberektől. Ezek az emberek nem fejlesztették ki magát az nginxet, egyszerűen hozzáadták a hivatalos nginx-et a docker-imázsukhoz, és saját konfigurációikkal fűszerezték a konténerek elindításának kényelmét szolgálva.

Általában egyszerűen tgz-ben tárolhatja, ha valakinek dockerben kell futtatnia, akkor adja hozzá a tgz-t a Dockerfile-hoz, örökölje a kívánt környezetből, és hozzon létre további kontyokat, amelyek nem változtatják meg magát az alkalmazást a tgz-ben. Bárki, aki docker image-t készít, tudni fogja, mi az a tgz, és mire van szüksége a működéséhez. Én így használom a dockert itt

A lényeg: nincs szükségem docker regisztrációra, valami S3-at használok, vagy csak fájltárolót, például google drive/dropbox

Docker a CI-ben

Az összes cég, ahol dolgoztam, hasonló. Általában élelmiszerüzletek. Vagyis van egy alkalmazásuk, egy technológiai veremük (na jó, talán pár-három programozási nyelv).

Ezek a cégek dockert használnak a szervereiken, ahol a CI folyamat fut. Kérdés – miért kell projekteket felépíteni egy docker konténerben a szerverein? Miért nem készítünk elő egy környezetet a buildhez, például írunk egy Ansible playbook-ot, ami telepíti a nodejs, php, jdk szükséges verzióit, másolja az ssh kulcsokat stb. arra a szerverre, amelyen a build megtörténik?

Most már értem, hogy ezzel lábon lövik magam, mert a dokkoló nem hoz hasznot az elszigeteltségével. Problémák, amelyekkel a CI-vel találkoztam a dockerben:

• ismét szüksége van egy docker image-re az építéshez. keresnie kell egy képet, vagy meg kell írnia saját dockerfájlját.
• 90%, hogy továbbítani kell néhány ssh kulcsot, titkos adatot, amit nem akar a docker image-be írni.
• a konténer létrejön és elhal, minden gyorsítótár elveszik vele együtt. a következő build újra letölti az összes projektfüggőséget, ami időigényes és nem hatékony, az idő pedig pénz.

A fejlesztők nem építenek projekteket docker konténerekben (egykor ilyen rajongó voltam, tényleg, régen sajnálom magam xD). A java-ban több verzió is elérhető, és egyetlen paranccsal módosítható a most szükséges verzióra. Ugyanez a nodejs, van nvm.

Teljesítmény

Úgy gondolom, hogy a docker egy nagyon erős és rugalmas eszköz, ez a hátránya (furcsán hangzik, igen). Segítségével a cégek könnyen ráakadhatnak, és ott használhatják, ahol kell és nem kell. A fejlesztők elindítják a konténereiket, néhány környezetüket, majd mindez simán befolyik a CI-be és a termelésbe. A DevOps csapata valamiféle kódot ír ezeknek a tárolóknak a futtatásához.

Csak a dokkolót használja a legutóbbi munkafolyamatának szakaszában, ne húzza bele a projektbe az elején. Nem oldja meg az üzleti problémáit. Ő csak egy MÁSIK szintre helyezi át a problémákat és saját megoldásokat kínál, te kettős munkát fogsz végezni.

Amikor dokkolóra van szükség: Arra a következtetésre jutottam, hogy a docker nagyon jól tud egy adott folyamatot optimalizálni, de az alapvető funkcionalitás kiépítésében nem

Ha továbbra is a docker használata mellett dönt, akkor:

• legyen rendkívül óvatos
• ne kényszerítse a fejlesztőket a docker használatára
• lokalizálja a használatát egy helyen, ne terjessze szét az összes Dockfile és Docker-compose tárolóban

PS:

• Nemrég találkoztam csomagoló és azt mondják, hogy nagyon jól működik az Ansible-vel, és lehetővé teszi a képek (beleértve a dokkolóképet) létrehozásának egységesítését.
• dockerről is, érdekes cikk

Köszönöm, hogy elolvastad, átlátható döntéseket kívánok ügyeidben, eredményes munkanapokat!

Forrás: will.com