A është Docker një lodër apo jo? Apo në të vërtetë po?

Përshëndetje të gjithëve!

Më shumë do të doja të filloja menjëherë me temën, por është më e përshtatshme të flas pak për historinë time:

Hyrje

Jam programues me përvojë në zhvillimin e aplikacioneve njëfaqëshe frontend, scala/java dhe nodejs në server.

Për një kohë të gjatë (me siguri dy – tre vjet), kam mbajtur mendimin se docker është një bekim nga qielli dhe në të vërtetë një mjet shumë të shkëlqyer dhe çdo zhvillues duhet të dijë ta përdorë. Dhe këtu del se çdo zhvillues duhet të ketë docker në makinën e tij lokal. Po ç'të them për mendimin tim, shfletoni listat e vendeve të punës në hh. Në çdo të dytë përmendet docker dhe nëse e zotëroni atë, do të jetë një avantaj më shumë për ju 😉

Në rrugën time kam takuar shumë njerëz me qasje të ndryshme ndaj docker dhe ekosistemit të tij. Disa thonin se është një gjë e dobishme që garanton ndërlidhshmërinë nëpër platforma. Të tjerët nuk kuptonin pse duhet të drejtoheshin në konteinerë dhe çfarë fitimi sjell kjo, disa të tjerë nuk u interesonin fare (thjesht shkruanin kodin dhe iknin në shtëpi — i admiroj, përsa i përket atyre 🙂)

Arsyet e përdorimit

Pse përdora docker? Ndoshta për këto arsye:

• ekzekutimi i bazës së të dhënave, 99% e aplikacioneve i përdorin ato
• ekzekutimi i nginx për shpërndarjen e frontend dhe për proxy në backend
• mund të paketosh aplikacionin në një imazh docker, kështu që aplikacioni im do të funksionojë kudo ku ka docker, problemi i shpërndarjes zgjidhet menjëherë
• zbulimi i shërbimit nga kutia, mund të krijosh mikroshërbime, çdo konteiner (i lidhur në një rrjet të përbashkët) lehtësisht mund të arrijë tjetrin përmes aliasit, shumë e përshtatshme
• është argëtuese të krijosh një konteiner dhe të "luash" në të.

Çfarë nuk më ka pëlqyer kurrë te docker:

• për të cilin aplikacioni im të funksionojë, kërkohet docker vetë në server. Po pse ma duhet kjo, nëse aplikacionet e mia funksionojnë në jre ose në nodejs dhe mjedisi për to tashmë është në server?
• nëse dëshiroj të ekzekutoj imazhin tim (privat) të ndërtuar lokal në një server të distancuar, atij i nevojitet një depo docker e vetme, duhet që diku të funksiononte registry dhe gjithashtu duhet të konfiguroj https, sepse docker cli funksionon vetëm përmes https. Oh, sikur… ka mundësi, sigurisht, ta ruaj imazhin lokal përmes docker save dhe përmes scp thjesht të dërgoj imazhin… Por kjo do të thotë kaq shumë lëvizje. Dhe gjithashtu duket si një zgjidhje "patchy", derisa të shfaqet depoja ime.
• docker-composeAi është i nevojshëm vetëm për të nisur kontejnerët. Dhe kaq. Nudi askënd tjetër. Docker-compose Këto kanë shumë versione të skedarëve të tyre, sintaksën e tyre. Sa do që të jetë deklarative, nuk dua të lexoj dokumentacionin e tyre. Nuk do më nevojitet asgjë diku tjetër.
• Kur punojnë në ekip, shumica e njerëzve i shkruajnë Dockerfile shumë keq, nuk kuptojnë si e menaxhohet cache, shtojnë në imazh gjithçka që nevojitet dhe që nuk nevojitet, trashëgojnë nga imazhe që nuk janë në dockerhub ose në një depo private, krijojnë disa docker-compose skedarë me baza të dhënash dhe nuk ruajnë asgjë. Ndërkohë, zhvilluesit e shpallin me krenari se docker është i shkëlqyer, gjithçka funksionon lokal dhe HR-ja shkruan në vendet e punës: «Ne përdorim docker dhe na nevojitet një kandidat me këtë përvojë pune»
• përherë e ndjekin mendimet për ngritjen e çdo gjëje në docker: postgresql, kafka, redis. Sa keq që gjithçka nuk funksionon në kontejnerë, dhe jo gjithçka është lehtë për t'u konfiguruar dhe nisur. Kjo mbështetet nga zhvillues jashtë, dhe jo nga vetë ofruesit. Dhe, për më tepër, shfaqet një pyetje e menjëhershme, pse ofruesit nuk shqetësohen për mbështetje të produkteve të tyre në docker, ndoshta dinë diçka?
• përherë lind pyetja për qëndrueshmërinë e të dhënave të kontejnerëve. Dhe këtu mendon, a duhet ta lidhi thjesht një direktori hosti apo të krijoj një docker volume ose të bëj një data container i cili tani deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume do të krijojë të dhënat thjesht në ndonjë /usr/* dhe do të ketë të njëjtën histori me uid dhe gid si në rastin e parë. Nëse nis një komponent të tretë, duhet të lexosh dokumentacionin dhe të kërkosh përgjigje për pyetjen: «Në cilat direktori të kontejnerit komponenti shkruan skedarë?»

Më ka shqetësuar gjithmonë se duhet të merrem shumë gjatë me docker-in në fazën fillestare: unë po mendoja se si të nisa kontejnerët, nga cilat imazhe të nisja, bëja Makefile, të cilat përmbanin aliazhe për komandat e gjata të docker. Nuk e kam duruar docker-compose, sepse nuk kisha dëshirë të mësoja një tjetër mjet të ekosistemit docker. Dhe docker-compose up më ka shqetësuar, sidomos, nëse aty kishin build strukturat e tjera, e jo imazhe të mbledhura përpara. Çfarëdo që doja, ishte të bëja produktin efikasisht dhe shpejt. Por nuk mund të përmirësoja përdorimin e docker-it.

Njohja me Ansible

Kohët e fundit (tre muaj më parë), kam punuar me një ekip DevOps, pothuajse çdo anëtar i të cilit kishte një qëndrim negativ ndaj docker. Për arsyet:

• docker menaxhon iptables (edhe pse mund ta çaktivizosh në daemon.json)
• Docker është i domosdoshëm dhe nuk do ta nisim në prodhim
• Nëse docker daemon bie, atëherë gjithashtu bien të gjithë kontejnerët me infrastrukturën
• Nuk ka nevojë për docker
• Pse docker kur ka Ansible dhe makina virtuale?

Në atë punë unë u takova me një mjet tjetër - Ansible. Disa herë kam dëgjuar për të, por nuk kisha provuar të shkruaja playbooks të mia. Tani kam filluar të shkruaj detyrat e mia dhe këtu vizioni im u ndryshua plotësisht! Sepse unë e kuptova: Ansible ka module për të ekzekutuar të njëjtit kontejnerë docker, ndërtimin e imazheve, rrjete etj., dhe gjithashtu mund të ekzekutoni kontejnerët jo vetëm lokal, por edhe në servera të largët! Gëzimi im ishte i pakufizuar - unë gjeta një mjet të PËRSHTATSHËM dhe hodha jashtë Makefile dhe docker-compose skedarët e mi, të cilat u zëvendësuan me detyrat yaml. Kodi u reduktua për shkak të përdorimit të ndërtimeve të tipit loop, when, etj.

Docker për të ekzekutuar komponentë të jashtëm si databaza

Kohët e fundit kam njohur tunelimin ssh. Doli se është shumë e thjeshtë "të shfrytëzohet" porta e serverit të largët në portin lokal. Serveri i largët mund të jetë një makinë në cloud, si dhe një makinë virtuale e lancuar në VirtualBox. Nëse unë ose ndonjë koleg im na nevojitet një databazë (apo ndonjë komponent tjetër të jashtëm), mund të ekzekutojmë thjesht serverin me këtë komponent dhe ta fikim kur nuk na nevojitet. Shfrytëzimi i porteve jep efektin e një databaze të lansuar në kontejnerin docker.

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

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

Përdorimi i serverit të largët zgjidh problemin e zhvillimit në grup. Një server i tillë mund të përdoret nga disa zhvillues, ata nuk kanë nevojë të dinë të konfigurojnë postgresql, të kuptojnë docker dhe kompleksitete të tjera. Në serverin e largët mund të instalohet e njëjta databazë në docker, nëse vendosja e versionit specifik është e vështirë. Gjithçka që do të nevojitet për zhvilluesit është të ofrohet qasje ssh!

Kohët e fundit lexova se tunelimi SSH është funksionim i kufizuar i një VPN normale! Mund të konfiguroni thjesht OpenVPN ose realizime të tjera të VPN, të konfiguroni infrastrukturën dhe t'ia jepni zhvilluesve. Kjo është aq e shkëlqyer!

Fatke, AWS, GoogleCloud, dhe të tjerë ofrojnë një vit përdorimi falas, prandaj shfrytëzojini! Janë shumë të lira, nëse i fikni kur nuk përdoren. Unë gjithmonë kam menduar për çfarë do të më duhet një server i largët si gcloud, duket se e kam gjetur.

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

Përfundim: është e mundur dhe e nevojshme të nisin databaza dhe përfitime të tjera infrastrukturore në servera të largët ose në virtualbox. Më nevojitet docker për këto qëllime.

Pak rreth imazheve docker dhe shpërndarjeve

Të kam shkruar më parë artikull në të cilin doja të përcillja se përdorimi i imazheve docker nuk jep asnjë garanci. Imazhet docker janë të nevojshme vetëm për të krijuar një kontejner docker. Nëse e mbani atë si imazh docker, atëherë po e mbani atë në përdorim kontejneresh docker dhe do të jeni vetëm me ta.

A keni parë ndonjëherë që zhvilluesit e softuerit të portojnë produktet e tyre vetëm si imazhe docker?
Rezultati i shumicës së produkteve është skedarë binarë për një platformë të caktuar, e cila thjesht shtohet në imazhin docker që trashëgon nga platforma e nevojshme. Çfarë keni menduar, pse ka kaq shumë imazhe të ngjashme në dockerhub? Shkruani për shembull nginx, do të shihni 100500 imazhe nga njerëz të ndryshëm. Këta njerëz nuk e zhvilluan vetë nginx, ata thjesht e shtuan nginx zyrtar në imazhin e tyre docker dhe e pasuruan me konfigurimet e tyre për lehtësimin e nisjes së kontejnerëve.

Në përgjithësi, mund ta ruani thjesht në tgz, nëse dikujt i nevojitet ta nisë këtë në docker, le të shtojë tgz në Dockerfile, të trashëgojë nga ambienti i nevojshëm dhe të krijojë përfitime të tjera që nuk ndryshojnë aplikacionin në tgz. Ai që do të krijojë imazhin docker do të dijë se çfarë është ky tgz dhe çfarë i nevojitet për të punuar. Kështu e përdor docker unë. këtu

Përfundim: nuk më nevojitet docker registry, do të përdor ndonjë S3 ose thjesht një ruajtje skedari 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. Do të thotë se kanë një aplikacion, një grup teknologjish (ndoshta dy - tre gjuhë programimi).

Këto kompani përdorin docker në serverët e tyre ku iniciohet procesi CI. Pyetja është — pse është e nevojshme të ndërtohen projektet në një konteiner docker në serverët e tyre? Pse të mos përgatitet një mjedis për ndërtim, për shembull të shkruhet një playbook Ansible që do të instalonte versionet e nevojshme të nodejs, php, jdk, të kopjonte çelësat ssh dhe të tjera në serverin ku do të bëhej ndërtimi?

Tani kuptoj se kjo është si të të godasësh veten në këmbë, sepse docker nuk sjell asnjë përfitim me izolimin e tij. Problemet me CI në docker me të cilat jam përballur:

• përsëri nevojitet një imazh docker për ndërtimin. duhet të kërkosh një imazh ose të shkruash dockerfile-në tënde.
• 90% është e nevojshme që të kalosh ndonjë çelës ssh, të dhëna sekrete, që nuk dëshiron t'i shkruash në imazhin docker.
• konteineri krijohet dhe vdes, humbasin të gjitha cache-t me të. Ndërtimi tjetër do të shkarkojë përsëri të gjitha varësitë e projektit, dhe kjo është e gjatë dhe jo efikase, ndërsa koha është para.

Zhvilluesit nuk ndërtojnë projekte në konteinerë docker (dikur isha një fanatik i tillë, më vjen keq për veten time në të kaluarën xD). Në java ka mundësi për të pasur disa versione dhe për të ndërruar me një komandë në atë që nevojitet tani. Në nodejs është po e njëjta gjë, ekziston nvm.

Përfundimi

Mendoj se docker është një mjet shumë i fuqishëm dhe fleksibël, dhe këtu qëndron disfata e tij (tingëllon çuditshëm, apo jo). Me të, kompanitë lehtë "varin" veten duke e përdorur aty ku duhet dhe nuk duhet. Zhvilluesit nisnin konteinerët e tyre, një mjedis të tyre, pastaj gjithçka kalon ngadalë në CI, prodhim. Ekipa DevOps shkruan disa mekanizma për të nisur këta konteinerë.

Përdorni docker vetëm në fazën më të fundit në procesin tuaj të punës, mos e sillni atë në projekt në fillim. Nuk do të zgjidhë problemet tuaja të biznesit. Ai vetëm do të zhvendosë problemet në NJË NIVEL TË DYTË dhe do të ofrojë opsionet e tij për zgjidhje, ju do të bëni punë të dyfishta.

Kur është e nevojshme docker: arrita në përfundimin se docker është shumë i mirë në optimizimin e procesit të vendosur, por jo në ndërtimin e funksionalitetit themelor.

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

• jini jashtëzakonisht të kujdesshëm
• mos i impononi përdorimin e docker zhvilluesve
• lokalizoni përdorimin e tij në një vend, mos e shpërndani në të gjitha repozitorët Dockefile dhe docker-compose

PS:

• Sapo kam hasur në packer dhe thonë se 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 interesante

Faleminderit që e lexuat, ju uroj zgjidhje transparente në punët tuaja dhe dite produktive në punë!

Burimi: habr.com