A është Docker një lojë apo jo? Apo ndoshta po?

Përshëndetje të gjithëve!

Të jesh e sinqertë, kam shumë dëshirë të filloj menjëherë me temën, por më mirë do të ishte të flas pak rreth historisë sime:

Hyrje

Jam programues me përvojë në zhvillimin e aplikacioneve frontend dhe serverëve me scala/java dhe nodejs.

Për një kohë të gjatë (sigurisht disa — tre vjet), kam konsideruar se docker është një dhuratë nga qielli dhe vërtet një mjet shumë i mirë që çdo zhvillues duhet ta dijë si ta përdorë. Nga kjo del se çdo zhvillues duhet të ketë docker në makinën e tij lokale. Çfarë mund të them për mendimin tim, thjesht përshkoni ofertat që shfaqen në sajtin e punës hh. Në çdo të dyta ka një përmendje për docker dhe nëse e zotëroni atë — do të jetë një përparësi konkurruese për ju 😉

Në rrugën time kam takuar shumë njerëz, me qëndrime të ndryshme ndaj docker-it dhe ekosistemës së tij. Disa thonin se është një gjë e dobishme që garanton ndër-platforminë. Të tjerë s’kuptonin përse duhet të nisin në kontejnerë dhe cila është përfitimi nga kjo, të tretët gati s'ua ndjente dhe ata s'kishin asnjë shqetësim (thjesht shkruanin kodin dhe iknin në shtëpi — madje, u haja zili atyre 🙂)

Arsyet për përdorim

Pse e përdora docker? Ndoshta për këto arsyet:

• startup i bazës së të dhënave, 99% e aplikacioneve i përdorin ato
• startimi i nginx për shpërndarjen e frontend-it dhe proksimin në backend
• mund të paketoj aplikacionin në një imazh docker, kështu që aplikacioni im do të funksionojë kudo që ka docker, problemi i shpërndarjes është zgjidhur menjëherë
• zb发现服务, mund të krijoni mikroshërbime, çdo kontejner (i lidhur me një rrjet të përgjithshëm) lehtë mund të arrijë te tjetri me alias, shumë e përshtatshme
• është interesante të krijosh një kontejner dhe të "luash" në të.

Çfarë nuk më ka pëlqyer ndonjëherë në docker:

• për të siguruar që aplikacioni im të funksionojë, nevojitet docker-i në server. Përse më duhet kjo, nëse aplikacionet e mia punojnë në jre ose nodejs dhe mjedisi për to tashmë është në server?
• nëse dua të nis imazhin tim (privat) të ndërtuar lokal në një server të largët, atëherë kam nevojë për një depo të vetën docker, duhet që diku të funksionojë registry dhe gjithashtu duhet të konfiguroj https, sepse docker cli punon vetëm përmes https. Oh, ndonjëherë… sigurisht, ka mundësi për ta ruajtur imazhin lokal përmes docker save dhe përmes scp thjesht dërgo imazhin… Por kjo është kaq shumë lëvizje. Dhe gjithashtu duket si një zgjidhje "këmbëngulëse", derisa të krijohet depoja e vet.
• docker-compose. Ai nevojitet vetëm për të ngritur kontejnerët. Dhe mjaft. Nuk mund të bëjë asgjë tjetër. Docker-compose ka shumë versione të skedave të tij, me sintaksën e tij. Sa deklarativ të jetë, nuk dua të lexoj dokumentacionin e tyre. Nuk më nevojitet askund tjetër.
• kur punon në ekip, në shumicën e rasteve, njerëzit shkruajnë Dockerfile shumë keq, nuk e kuptojnë si kjo ruhet në cache, shtojnë në imazh gjithçka që nevojitet dhe që nuk nevojitet, trashëgojnë nga imazhe që nuk ekzistojnë në dockerhub ose në një depo private, krijojnë disa docker-compose skeda me bazat e të dhënave dhe nuk bëjnë asgjë për t’i ruajtur ato. Ndërkohë, zhvilluesit shpallin me krenari se docker është i shkëlqyer, gjithçka funksionon lokal dhe HR-ja me rëndësi e shkruan në njoftimet e punës: ‘Ne përdorim docker dhe na nevojitet një kandidat me përvojë të tillë’
• ngacmojnë vazhdimisht mendimet për ngritjen në docker të gjithçkaje: postgresql, kafka, redis. Për fat të keq, nuk funksionon gjithçka në kontejnerë, nuk është e lehtë të konfigurohet dhe të startohet. Kjo mbështetet nga zhvillues të jashtëm, jo nga vetë ofruesit. Dhe, për të thënë të drejtën, lind menjëherë pyetja, pse ofruesit nuk pëndohen për mbështetje të produkteve të tyre në docker, ndoshta ata dinë diçka?
• gjithmonë lind pyetja rreth qëndrueshmërisë së të dhënave të kontejnerit. dhe këtu mendon, a duhet thjesht të montoj një direktori hosti ose të krijoj një docker volume ose të bëj një data container që tani joveprues? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume atëherë të dhënat thjesht do të krijohen në ndonjë /usr/* dhe do të kem të njëjtin problem me uid dhe gid si në rastin e parë. Nëse po e drejton një komponent të jashtëm, atëherë duhet të lexosh dokumentacionin dhe të kërkosh përgjigje për pyetjen: "në cilat drejtoritë e kontejnerit shkruan skedarët komponenti?"

Më ka shqetësuar gjithmonë se duhet të merrem shumë gjatë me docker-in në fazën fillestare: po mendonim si të drejtonim kontejnerët, nga cilat imazhe të niseshim, bëja Makefile që përmbanin alias për komandat e gjata docker. Nën e urreja docker-compose, sepse nuk doja të mësoja një mjet tjetër të ekosistemit docker. Dhe docker-compose up më shqetësonte, sidomos, nëse aty kishim ndërto konstruksione, e jo imazhe të ndërtuara tashmë. E gjithë ajo që dëshiroja vërtet — ishte thjesht të bëja produktin në mënyrë efektive dhe të shpejtë. Por nuk mund të rregulloja dot përdorimin e docker-it.

Njoftim me Ansible

Para disa muajve, kam punuar me ekipin e DevOps, ku shumica e anëtarëve kishin një qëndrim negativ ndaj docker-it. Arsyet ishin:

• docker menaxhon iptables (edhe pse mund të fiket në daemon.json)
• docker është i ngadalshëm dhe nuk do ta përdorim në prodhim
• nëse docker daemon bie, atëherë bien të gjithë kontejnerët me infrastrukturën
• nuk ka nevojë për docker
• përse docker, nëse kemi Ansible dhe makinat virtuale

Në të njëjtin vend pune, u njoh me një mjet tjetër — Ansible. Dikur kam dëgjuar për të, por nuk kisha provuar të shkruaja playbook-e të mia. Tani kam filluar të shkruaj detyrat e mia dhe këtu vizioni im u ndryshua përfundimisht! Sepse kuptova: Ansible ka module për ekzekutimin e të njëjtave kontejnerë docker, ndërtimin e imazheve, rrjeteve etj., dhe gjithashtu kontejnerët mund të ekzekutohen jo vetëm lokal, por edhe në serverë të largët! Gëzimi im ishte i pafund — unë gjeta një mjet TË MIRË dhe hodha përjashta skedat e mia Makefile dhe docker-compose, ato u zëvendësuan me detyra yaml. Kodi u zvogëlua për shkak të përdorimit të strukturave si loop, when, etj.

Docker për ekzekutimin e komponenteve të jashtme si baza e të dhënave

Kohët e fundit, kam mësuar për tunelimin ssh. M'u duk shumë e thjeshtë të "kaloj" portin e një serveri të largët në portin lokal. Serveri i largët mund të jetë një makinë në re ose një makinë virtuale që ekzekutohet në VirtualBox. Nëse unë ose ndonjë koleg im kemi nevojë për një bazë të dhënash (ose ndonjë komponent tjetër të jashtëm), mund ta ekzekutojmë thjesht serverin me atë komponent dhe ta fikim kur ai nuk është më i nevojshëm. Kalimi i porteve jep të njëjtin efekt si një bazë e dhënash e ekzekutuar në një konteiner docker.

Kjo komandë kalon portin tim lokal në serverin e largët me postgresql:

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

Përdorimi i një serveri të largët zgjidh problemin e zhvillimit në ekip. Ky server mund të përdoret nga disa zhvillues njëkohësisht, ata nuk kanë nevojë të dinë mënyrën se si të konfigurojnë postgresql, nuk duhet të merren me docker dhe sfida të tjera. Në serverin e largët, mund të instaloni të njëjtën bazë të dhënash në docker, nëse të vendosni versionin specifik është e ndërlikuar. E gjitha që do të nevojitet për zhvilluesit është të sigurohen për akses ssh!

Së fundi, lexova se tunelat SSH janë një funksionalitet i kufizuar i një VPN të zakonshme! Thjesht mund të konfiguroni OpenVPN ose implementime të tjera të VPN, të vendosni infrastrukturën dhe t'ia jepni zhvilluesve. A nuk është kaq e mrekullueshme?

Fatmirësisht, AWS, GoogleCloud dhe të tjerë ofrojnë një vit përdorimi falas, kështu që përfitoni prej tyre! Janë të lirë, nëse i fikni kur nuk përdoren. Gjithmonë më ka shërbyer mendimi se për çfarë do të më nevojitet një server i largët si gcloud, duket se e kam gjetur.

Si një makinë virtuale në lokal, mund të përdorni po atë Alpine që përdoret aktivisht në kontejnerët docker. Ose ndonjë shpërndarje tjetër të lehtë për të ngarkuar më shpejt makinën.

Përfundimi: është e nevojshme dhe e dobishme të filloni DB-në dhe funksionalitete të tjera infrastrukturore në servera të largët ose në VirtualBox. Nuk kam nevojë për docker për këto qëllime.

Pak për imazhet docker dhe shpërndarjen

Unë tashmë kam shkruar artikullin në të cilën doja të theksoja se përdorimi i imazheve të docker nuk ofron asnjë garanci. Imazhet docker nevojiten vetëm për të krijuar kontejnerë docker. Nëse ju është dashur të arrini në imazhin docker, do të thotë se jeni duke punuar me kontejnerët docker dhe do të jeni vetëm me ata.

A keni parë ndonjëherë që zhvilluesit e softuerit të portojnë produktet e tyre vetëm në imazhe docker?
Rezultati i shumicës së produkteve janë skedarë binarë për një platformë të caktuar, pikërisht ata thjesht shtohen në imazhin docker i cili trashëgon nga platforma e nevojshme. A e keni menduar ndonjëherë pse në dockerhub ka kaq shumë imazhe të ngjashme? Shkruani për shembull nginx, do të shihni 100500 imazhe nga njerëz të ndryshëm. Këta njerëz nuk e kanë zhvilluar vetë nginx, ata thjesht e kanë shtuar nginx-in zyrtar në imazhin e tyre docker dhe e kanë zbukuruar me konfigurimet e tyre për lehtësinë e ekzekutimit të kontejnerëve.

Në thelb, mund të ruani thjesht në tgz. Nëse dikush ka nevojë ta aktivizojë këtë në docker, le të shtojnë tgz në Dockerfile, të trashëgojnë nga mjedisi përkatës dhe të krijojnë mundësi shtesë që nuk ndryshojnë aplikacionin në tgz. Ajo që do të krijojë imazhin docker do të dijë se çfarë është ky tgz dhe çfarë i nevojitet për funksionim. Kështu e përdor unë docker. këtu

Përfundimi: nuk më nevojitet një regjistrik docker, do të përdor ndonjë S3 ose thjesht një ruajtje skedesh si google drive/dropbox.

Docker në CI

Të gjitha kompanitë ku kam punuar janë të ngjashme me njëra-tjetrën. Ato zakonisht janë produktive. Domethënë, ato kanë një aplikacion të vetëm, një stek teknologjik (ndoshta dy-tri gjuhë programimi).

Këto kompani përdorin docker në serverët e tyre ku aktivizohet procesi CI. Pyetja është: përse është e nevojshme të ndërtohen projektet në një container docker në serverët e tyre? Pse thjesht të mos përgatitet mjedisi për ndërtim, për shembull të shkruhet një playbook Ansible që do të instalohet versionet e nevojshme të nodejs, php, jdk, të kopjojë çelësa ssh, etj. në serverin ku do të ndodhë ndërtimi?

Tani tani më kuptoj se është si të qëllosh në këmbë vetë, sepse docker nuk sjell asnjë përfitim me izolimin e tij. Problemet me CI në docker me të cilat kam hasur:

• sërish është e nevojshme një imazh docker për ndërtimin. Duhet të kërkohet imazhi apo të shkruhet dockerfile i imi.
• 90% se duhet të kaloj disa çelësa ssh, të dhëna sekrete që nuk dëshiroj t'i shkruaj në imazhin docker.
• kontejneri krijohet dhe vdes, humbasin të gjitha cache-t së bashku me të. Ndërtime të tjera do të duan të shkarkojnë të gjitha varësitë e projektit, dhe kjo është e gjatë dhe jo e efektshme, sepse koha është para.

Zhvilluesit nuk ndajnë projekte në konteinerë docker (disa kohë më parë isha një fans i tillë, e pikëlloj veten në të kaluarën xD). Në java ka mundësinë për të pasur disa versione dhe për të kaluar me një komandë në atë që nevojitet tani. Në nodejs është po ashtu, ekziston nvm.

Përfundim

Unë mendoj se docker është një mjet shumë i fuqishëm dhe fleksibël, në këtë gjë qëndron disavantazhi i tij (dingjell, apo jo). Me ndihmën e tij, kompanitë lehtësisht "nisen" me të, e përdorin atje ku është e nevojshme dhe ku nuk është. Zhvilluesit fillojnë të aktivizojnë kontejnerët e tyre, një ambient të caktuar, pastaj gjithçka kalon në CI, prodhim. Ekipi DevOps shkruan disa rrotë për të aktivizuar këta kontejnerë.

Përdorni docker vetëm në fazën më të fundit të procesit tuaj të punës, mos e futur në projekt në fillim. Ai nuk do të zgjidhë problemet tuaja të biznesit. Ai vetëm do të zhvendosë problemet në NJË NIVEL TË DYTË dhe do të ofrojë opsione të tjera për zgjidhje, do të bëni punë dyfish.

Kur docker është i nevojshëm: arrita në përfundimin se docker është shumë i mirë në optimizimin e procesit në vend, por jo në ndërtimin e funksionalitetit bazë.

Nëse vendosët të përdorni docker, atëherë:

• jeni jashtëzakonisht të kujdesshëm
• mos e impononi përdorimin e dockerit mbi zhvilluesit
• lokalizoni përdorimin e tij në një vend, mos e shpërndani në të gjitha repozitorët Dockefile dhe docker-compose.

PS:

• Kohët e fundit kam hasur në packer dhe thotë që punon shumë mirë me Ansible dhe lejon unifikimin e procesit të ndërtimit të imazheve (përfshirë imazhet docker)
• po ashtu për docker, një artikull interesant

Faleminderit që e lexuat deri në fund, ju dëshiroj zgjidhje të qarta në punët tuaja dhe ditë produktive në punë!

Burimi: habr.com