Je Docker igrača ali ne? Ali pa še vedno drži?

Pozdravljeni vsi!

Resnično želim preiti naravnost na temo, vendar bi bilo pravilneje povedati nekaj o svoji zgodbi:

Začetek

Sem programer z izkušnjami pri razvoju frontend enostranskih aplikacij, scala/java in nodejs na strežniku.

Kar dolgo časa (zagotovo nekaj ali tri leta) sem bil mnenja, da je Docker mana z neba in na splošno zelo kul orodje in bi ga moral znati uporabljati popolnoma vsak razvijalec. In iz tega sledi, da bi moral imeti vsak razvijalec nameščen Docker na svojem lokalnem računalniku. Kaj pa moje mnenje, preglejte prosta delovna mesta, ki so objavljena na istem hh. Vsak drugi vsebuje omembo dockerja in če ga imate, bo to vaša konkurenčna prednost 😉

Na svoji poti sem srečal veliko ljudi z različnimi odnosi do Dockerja in njegovega ekosistema. Nekateri so rekli, da je to priročna stvar, ki zagotavlja funkcionalnost med platformami. Drugim ni bilo jasno, zakaj bi morali teči v zabojnikih in kakšen dobiček bo s tem, tretjim je bilo vseeno in se niso obremenjevali (samo napisali so kodo in odšli domov - zavidam jim, mimogrede pot :)

Razlogi za uporabo

Zakaj sem uporabil docker? Verjetno zaradi naslednjih razlogov:

• zagon baze podatkov, jih uporablja 99 % aplikacij
• zagon nginx za frontend distribucijo in proxy za backend
• aplikacijo lahko zapakiraš v sliko dockerja, na ta način bo moja aplikacija delovala povsod, kjer obstaja docker, problem distribucije je takoj rešen
• odkrivanje storitev takoj, lahko ustvarite mikrostoritve, vsak vsebnik (povezan v skupno omrežje) zlahka doseže drugega prek vzdevka, zelo priročno
• Zabavno je ustvariti posodo in se "igrati" v njej.

Kaj mi pri dockerju vedno NI VŠEČ:

• Da bi moja aplikacija delovala, potrebujem sam Docker na strežniku. Zakaj to potrebujem, če se moje aplikacije izvajajo na jre ali nodejs in je okolje zanje že na strežniku?
• če želim zagnati svojo (zasebno) lokalno zgrajeno sliko na oddaljenem strežniku, potem potrebujem svoj repozitorij dockerjev, potrebujem, da nekje deluje register, in prav tako moram konfigurirati https, ker docker cli deluje samo prek https. Oh prekleto ... seveda obstajajo možnosti za lokalno shranjevanje slike prek docker save in samo pošlji sliko prek scp ... Ampak to je veliko gibov telesa. In poleg tega je videti kot "bergla" rešitev, dokler se ne pojavi vaš lastni repozitorij
• docker-compose. Potreben je samo za zagon kontejnerjev. To je vse. Ne more narediti nič drugega. Docker-compose ima kup različic svojih datotek, lastno sintakso. Ne glede na to, kako deklarativno je, nočem brati njihove dokumentacije. Nikjer drugje ga ne bom potreboval.
• ko delajo v timu, večina ljudi piše Dockerfile zelo ukrivljeno, ne razumejo, kako je predpomnjena, sliki dodajo vse, kar potrebujejo in ne potrebujejo, podedujejo slike, ki niso v Dockerhubu ali zasebnem repozitoriju, ustvarijo nekaj docker-compose datoteke z bazami podatkov in nič ne ostane. Ob tem razvijalci ponosno izjavljajo, da je Docker kul, vse jim deluje lokalno, HR pa v prosto delovno mesto pomembno zapiše: »Uporabljamo Docker in potrebujemo kandidata s takimi delovnimi izkušnjami.«
• Nenehno me preganjajo misli o dvigovanju vsega v Dockerju: postgresql, kafka, redis. Škoda, da ne deluje vse v kontejnerjih, ni vse enostavno konfigurirati in zagnati. To podpirajo razvijalci tretjih oseb in ne prodajalci sami. In mimogrede, takoj se pojavi vprašanje: prodajalci ne skrbijo za vzdrževanje svojih izdelkov v Dockerju, zakaj je tako, morda kaj vedo?
• Vedno se pojavi vprašanje o obstojnosti podatkov vsebnika. in potem pomislite, ali naj samo priklopim gostiteljski imenik ali ustvarim nosilec dockerja ali naredim podatkovni vsebnik, ki je zdaj deprecated? Če priklopim imenik, se moram prepričati, da se uid in gid uporabnika v vsebniku ujemata z ID-jem uporabnika, ki je zagnal vsebnik, sicer bodo datoteke, ki jih je ustvaril vsebnik, ustvarjene s korenskimi pravicami. Če uporabljam volume potem bodo podatki preprosto ustvarjeni v nekaterih /usr/* in z uid in gid bo ista zgodba kot v prvem primeru. Če zaženete komponento tretje osebe, morate prebrati dokumentacijo in poiskati odgovor na vprašanje: "v katere imenike vsebnikov komponenta piše datoteke?"

Vedno mi ni bilo všeč dejstvo, da sem se moral predolgo ukvarjati z Dockerjem v začetni fazi: Ugotovil sem, kako zagnati vsebnike, iz katerih slik zagnati, naredil Makefile, ki so vsebovali vzdevke za dolge ukaze Docker. Sovražil sem docker-compose, ker se nisem želel naučiti drugega orodja v docker ekosistemu. IN docker-compose up Motilo me je, sploh če sta se tam še srečala build konstrukcije, ne pa že sestavljene slike. Vse, kar sem si zares želel, je bilo narediti izdelek učinkovito in hitro. Vendar nisem mogel ugotoviti, kako uporabljati docker.

Predstavljamo Ansible

Pred kratkim (pred tremi meseci) sem delal z ekipo DevOps, katere skoraj vsi člani so imeli negativen odnos do Dockerja. Iz razlogov:

• docker pravila iptables (čeprav ga lahko onemogočite v daemon.json)
• docker je hrošč in ga ne bomo izvajali v produkciji
• če se docker daemon zruši, se ustrezno zrušijo vsi vsebniki z infrastrukturo
• ni potrebe po dockerju
• zakaj docker, če obstaja Ansible in virtualni stroji

Na istem delovnem mestu sem se seznanil še z enim orodjem - Ansible. Enkrat sem slišal za to, vendar nisem poskušal napisati lastnih iger. In zdaj sem začela pisati svoje naloge in takrat se je moja vizija popolnoma spremenila! Ker sem spoznal: Ansible ima module za izvajanje istih vsebnikov dockerjev, gradenj slik, omrežij itd., vsebnike pa je mogoče izvajati ne le lokalno, ampak tudi na oddaljenih strežnikih! Moje veselje ni poznalo meja - našel sem NORMALNO orodje in vrgel stran svoj Makefile in docker-compose datoteke, nadomestile so jih naloge yaml. Koda je bila zmanjšana z uporabo konstruktov, kot je loop, when, Itd

Docker za izvajanje komponent tretjih oseb, kot so baze podatkov

Pred kratkim sem se seznanil s tuneli ssh. Izkazalo se je, da je vrata oddaljenega strežnika zelo enostavno »posredovati« lokalnim vratom. Oddaljeni strežnik je lahko stroj v oblaku ali virtualni stroj, ki se izvaja v VirtualBoxu. Če moj kolega ali jaz potrebujemo bazo podatkov (ali kakšno drugo komponento tretje osebe), lahko preprosto zaženemo strežnik s to komponento in jo izklopimo, ko strežnika ne potrebujemo. Posredovanje vrat daje enak učinek kot baza podatkov, ki se izvaja v vsebniku docker.

Ta ukaz posreduje moja lokalna vrata oddaljenemu strežniku, v katerem se izvaja postgresql:

ssh -L 9000:lokalni gostitelj:5432 [e-pošta zaščitena]

Uporaba oddaljenega strežnika rešuje problem razvoja ekipe. Tak strežnik lahko uporablja več razvijalcev hkrati, ni jim treba znati konfigurirati postgresql, razumeti Dockerja in drugih zapletenosti. Na oddaljenem strežniku lahko isto bazo podatkov namestite v sam Docker, če je težko namestiti določeno različico. Vse, kar razvijalci potrebujejo, je zagotoviti dostop ssh!

Nedavno sem prebral, da so tuneli SSH omejena funkcionalnost običajnega VPN-ja! Lahko preprosto namestite OpenVPN ali druge izvedbe VPN, nastavite infrastrukturo in jo daste razvijalcem v uporabo. To je tako kul!

Na srečo vam AWS, GoogleCloud in drugi podarjajo eno leto brezplačne uporabe, zato jih uporabite! So poceni, če jih izklopite, ko niso v uporabi. Vedno sem se spraševal, zakaj bi potreboval oddaljeni strežnik, kot je gcloud, zdi se, da sem jih našel.

Kot lokalni virtualni stroj lahko uporabite isti Alpine, ki se aktivno uporablja v docker kontejnerjih. No, ali kakšne druge lahke distribucije za hitrejši zagon stroja.

Zaključek: baze podatkov in druge infrastrukturne dobrote lahko in morate izvajati na oddaljenih strežnikih ali v virtualboxu. Za te namene ne potrebujem dockerja.

Nekaj ​​o docker slikah in distribuciji

Sem že pisala статью v katerem sem želel sporočiti, da uporaba slik dockerja ne zagotavlja nobenega jamstva. Docker slike so potrebne samo za ustvarjanje docker vsebnika. Če nadgrajujete na sliko dockerja, potem nadgrajujete na uporabo vsebnikov dockerjev in boste uporabljali samo njih.

Ali ste kje videli, da razvijalci programske opreme prenesejo svoje izdelke samo v sliko dockerja?
Rezultat večine izdelkov so binarne datoteke za določeno platformo; preprosto se dodajo v sliko dockerja, ki je podedovana od želene platforme. Ste se kdaj vprašali, zakaj je na dockerhub toliko podobnih slik? Vnesite na primer nginx in videli boste 100500 slik različnih ljudi. Ti ljudje niso razvili samega nginxa, preprosto so dodali uradni nginx v svojo sliko dockerja in jo začinili s svojimi konfiguracijami za udobje zagona vsebnikov.

Na splošno ga lahko preprosto shraniš v tgz, če ga mora kdo pognati v dockerju, potem naj doda tgz v Dockerfile, podeduje iz želenega okolja in ustvari dodatne štručke, ki ne spremenijo same aplikacije v tgz. Vsak, ki bo ustvaril sliko dockerja, bo vedel, kaj je tgz in kaj potrebuje za delo. Tako uporabljam docker tukaj

Bistvo: ne potrebujem docker registra, uporabil bom nekakšen S3 ali samo shrambo datotek, kot je google drive/dropbox

Docker v CI

Vsa podjetja, v katerih sem delal, so si podobna. Običajno so špecerija. To pomeni, da imajo eno aplikacijo, en tehnološki sklad (no, morda nekaj ali tri programske jezike).

Ta podjetja uporabljajo docker na svojih strežnikih, kjer teče proces CI. Vprašanje: Zakaj morate graditi projekte v docker vsebniku na svojih strežnikih? Zakaj ne bi samo pripravili okolja za gradnjo, na primer napisali Ansible playbook, ki bo namestil potrebne različice nodejs, php, jdk, kopiral ključe ssh itd. na strežnik, v katerem bo potekala gradnja?

Sedaj razumem, da se to strelja v nogo, ker docker s svojo izolacijo ne prinaša nobenega dobička. Težave, na katere sem naletel s CI v dockerju:

• spet potrebujete docker sliko za gradnjo. poiskati morate sliko ali napisati svojo lastno datoteko docker.
• 90 %, da morate posredovati nekaj ssh ključev, skrivnih podatkov, ki jih ne želite zapisati v sliko dockerja.
• vsebnik je ustvarjen in umre, vsi predpomnilniki so izgubljeni skupaj z njim. naslednja zgradba bo ponovno prenesla vse odvisnosti projekta, kar je zamudno in neučinkovito, čas pa je denar.

Razvijalci ne gradijo projektov v docker kontejnerjih (nekoč sem bil tak oboževalec, res, žal mi je v preteklosti xD). V Javi je mogoče imeti več različic in jih z enim ukazom spremeniti v tisto, ki jo potrebujete zdaj. Enako je v nodejs, tam je nvm.

Izhod

Verjamem, da je docker zelo zmogljivo in prilagodljivo orodje, to je njegova pomanjkljivost (zveni čudno, ja). Z njegovo pomočjo se podjetja zlahka navežejo nanj in ga uporabljajo tam, kjer je treba in nepotrebno. Razvijalci zaženejo svoje vsebnike, nekatera svoja okolja, nato pa se vse gladko prelije v CI in produkcijo. Ekipa DevOps piše nekakšno kodo za zagon teh vsebnikov.

Docker uporabljajte samo na najnovejši korak v vašem delovnem procesu, ga ne vlecite v projekt na začetku. To ne bo rešilo vaših poslovnih težav. On bo samo premaknil težave na DRUGO raven in ponudil svoje rešitve, vi boste opravili dvojno delo.

Ko je potreben docker: Prišel sem do zaključka, da je docker zelo dober pri optimizaciji danega procesa, ne pa tudi pri izgradnji osnovne funkcionalnosti

Če se še vedno odločite za uporabo dockerja, potem:

• bodite zelo previdni
• ne silite razvijalcev v uporabo dockerja
• lokalizirajte njegovo uporabo na enem mestu, ne širite ga po vseh repozitorijih Dockefile in docker-compose

PS:

• Pred kratkim sem naletel pakirnica in pravijo, da zelo dobro deluje z Ansibleom in vam omogoča poenotenje postopka gradnje slik (vključno s sliko dockerja)
• tudi o dockerju, zanimiv članek

Hvala za branje, želim vam pregledne odločitve v vaših zadevah in produktivne delovne dni!

Vir: www.habr.com