Ĉu Docker estas ludilo aŭ ne? Aŭ ĉu ĝi ankoraŭ estas vera?

Saluton ĉiuj!

Mi tre volas rekte aliri la temon, sed estus pli ĝuste rakonti iom pri mia rakonto:

eniro

Mi estas programisto kun sperto pri disvolvado de fasad-unupaĝaj aplikoj, scala/java kaj nodejs sur la servilo.

Dum sufiĉe longa tempo (certe kelkaj aŭ tri jaroj), mi opiniis, ke Docker estas manao el la ĉielo kaj ĝenerale tre bonega ilo kaj absolute ĉiu programisto devus povi uzi ĝin. Kaj el tio sekvas, ke ĉiu programisto devus havi Docker instalitan sur sia loka maŝino. Kio pri mia opinio, trarigardu la vakantaĵojn kiuj estas afiŝitaj sur la sama hh. Ĉiu dua enhavas mencion de docker, kaj se vi posedas ĝin, ĉi tio estos via konkurenciva avantaĝo 😉

Sur mia vojo, mi renkontis multajn homojn, kun iliaj malsamaj sintenoj al Docker kaj ĝia ekosistemo. Iuj diris, ke ĉi tio estas oportuna afero, kiu garantias transplatforman funkcion. La duaj ne komprenis kial ili kuru en ujoj kaj kian profiton venos el tio, la tria tute ne zorgis kaj ne ĝenis (ili nur skribis la kodon kaj iris hejmen - mi envias ilin, pro la maniero :)

Kialoj por uzo

Kial mi uzis docker? Verŝajne pro la sekvaj kialoj:

• lanĉo de datumbazo, 99% de aplikoj uzas ilin
• lanĉante nginx por fasaddistribuo kaj prokurado al backend
• vi povas paki la aplikaĵon en docker-bildo, tiamaniere mia aplikaĵo funkcios kie ajn docker ekzistas, la distribua problemo estas tuj solvita
• servo malkovro el la skatolo, vi povas krei mikroservojn, ĉiu ujo (ligita al komuna reto) povas facile atingi alian per kaŝnomo, tre oportuna
• Estas amuze krei ujon kaj "ludi" en ĝi.

Kion mi ĉiam NE ŝatas pri docker:

• Por ke mia aplikaĵo funkciu, mi bezonas Docker mem sur la servilo. Kial mi bezonas ĉi tion se miaj aplikaĵoj funkcias per jre aŭ nodejs kaj la medio por ili jam estas sur la servilo?
• se mi volas ruli mian (privatan) loke konstruitan bildon sur fora servilo, tiam mi bezonas mian propran docker-deponejon, mi bezonas la registron funkcii ie kaj mi ankaŭ bezonas agordi https, ĉar docker cli funkcias nur per https. Ho diablo... estas ebloj, kompreneble, por konservi la bildon loke per docker save kaj simple sendu la bildon per scp... Sed tio estas multaj korpaj movoj. Kaj krome, ĝi aspektas kiel "lambastona" solvo ĝis via propra deponejo aperos
• docker-compose. Necesas nur por ruli ujojn. Tio estas ĉio. Li ne povas fari ion alian. Docker-compose havas amason da versioj de siaj dosieroj, sian propran sintakson. Kiom ajn deklara ĝi estas, mi ne volas legi ilian dokumentadon. Mi ne bezonos ĝin aliloke.
• laborante en teamo, plej multaj homoj skribas Dockerfile tre malrekte, ne komprenas kiel ĝi estas kaŝmemorigita, aldonas ĉion, kion ili bezonas kaj ne bezonas al la bildo, heredas de bildoj kiuj ne estas en Dockerhub aŭ privata deponejo, kreas iujn. docker-compose dosieroj kun datumbazoj kaj nenio daŭras. Samtempe, la programistoj fiere deklaras, ke Docker estas bonega, ĉio funkcias loke por ili, kaj HR grave skribas en la vakanto: "Ni uzas Docker kaj ni bezonas kandidaton kun tia labora sperto."
• Min konstante plagas pensoj pri altigado de ĉio en Docker: postgresql, kafka, redis. Estas domaĝe, ke ne ĉio funkcias en ujoj, ne ĉio estas facile agordi kaj ruli. Ĉi tio estas subtenata de triaj programistoj, kaj ne de la vendistoj mem. Kaj cetere, la demando tuj ŝprucas: vendistoj ne zorgas pri konservado de siaj produktoj en Docker, kial ĉi tio, eble ili scias ion?
• La demando ĉiam ŝprucas pri la persisto de ujdatumoj. kaj tiam vi pensas, ĉu mi simple muntu la gastigan dosierujon aŭ kreu docker-volumon aŭ faru datumujon kiu nun estas deprecated? Se mi muntas dosierujon, tiam mi devas certigi, ke la uid kaj gid de la uzanto en la ujo kongruas kun la id de la uzanto, kiu lanĉis la ujon, alie la dosieroj kreitaj de la ujo estos kreitaj kun radikrajtoj. Se mi uzas volume tiam la datumoj simple estos kreitaj en iuj /usr/* kaj estos la sama rakonto kun uid kaj gid kiel en la unua kazo. Se vi lanĉas triapartan komponanton, vi devas legi la dokumentaron kaj serĉi la respondon al la demando: "en kiuj ujo-dosierujoj la komponanto skribas dosierojn?"

Mi ĉiam ne ŝatis la fakton, ke mi devis trudi kun Docker tro longe en la komenca etapo: Mi eltrovis kiel lanĉi ujojn, el kiuj bildoj lanĉi, faris Makefiles, kiuj enhavis kaŝnomojn al longaj Docker-komandoj. Mi malamis docker-compose ĉar mi ne volis lerni alian ilon en la docker-ekosistemo. KAJ docker-compose up Ĝi ĝenis min, precipe se ili ankoraŭ renkontiĝis tie build konstruoj, prefere ol jam kunvenitaj bildoj. Ĉio, kion mi vere volis, estis nur fari produkton efike kaj rapide. Sed mi ne povis eltrovi kiel uzi docker.

Prezentante Ansible

Lastatempe (antaŭ tri monatoj), mi laboris kun teamo DevOps, preskaŭ ĉiuj membroj de kiu havis negativan sintenon al Docker. Pro kialoj:

• docker regas iptables (kvankam vi povas malŝalti ĝin en daemon.json)
• docker estas bug kaj ni ne funkcios ĝin en produktado
• se docker-demono kraŝas, tiam ĉiuj ujoj kun infrastrukturo kraŝas laŭe
• ne necesas docker
• Kial docker se ekzistas Ansible kaj virtualaj maŝinoj

En la sama laboro, mi konatiĝis kun alia ilo - Ansible. Mi aŭdis pri ĝi unufoje, sed mi ne provis skribi miajn proprajn ludlibrojn. Kaj nun mi komencis verki miajn taskojn kaj tiam mia vizio tute ŝanĝiĝis! Ĉar mi rimarkis: Ansible havas modulojn por ruli la samajn docker-ujojn, bildkonstruaĵojn, retojn ktp., kaj ujoj povas ruliĝi ne nur loke, sed ankaŭ sur foraj serviloj! Mia ĝojo ne konis limojn - mi trovis NORMALAN ilon kaj forĵetis miajn Makefile kaj docker-compose dosierojn, ili estis anstataŭigitaj per yaml-taskoj. La kodo estis reduktita uzante konstrukciojn kiel loop, when, Ktp

Docker por ruli triapartajn komponantojn kiel datumbazojn

Mi lastatempe konatiĝis kun ssh-tuneloj. Montriĝis, ke estas tre facile "sendi" la havenon de fora servilo al loka haveno. La fora servilo povas esti aŭ maŝino en la nubo aŭ virtuala maŝino funkcianta en VirtualBox. Se mia kolego aŭ mi bezonas datumbazon (aŭ iun alian trian komponanton), ni povas simple komenci la servilon per ĉi tiu komponanto kaj malŝalti ĝin kiam la servilo ne estas bezonata. Havena plusendado donas la saman efikon kiel datumbazo kuranta en docker-ujo.

Ĉi tiu komando plusendas mian lokan havenon al fora servilo, kiu funkcias postgresql:

ssh -L 9000:localhost:5432 [retpoŝte protektita]

Uzado de fora servilo solvas la problemon kun teama disvolviĝo. Tia servilo povas esti uzata de pluraj programistoj samtempe; ili ne bezonas povi agordi postgresql, kompreni Docker kaj aliajn komplikaĵojn. Sur fora servilo, vi povas instali la saman datumbazon en Docker mem, se estas malfacile instali specifan version. Ĉiuj programistoj bezonas estas provizi ssh-aliron!

Mi lastatempe legis, ke SSH-tuneloj estas limigita funkcieco de regula VPN! Vi povas simple instali OpenVPN aŭ aliajn VPN-efektivigojn, agordi la infrastrukturon kaj doni ĝin al programistoj por uzo. Ĉi tio estas tiel mojosa!

Feliĉe, AWS, GoogleCloud kaj aliaj donas al vi jaron da senpaga uzo, do uzu ilin! Ili estas malmultekostaj se vi malŝaltas ilin kiam ne estas uzataj. Mi ĉiam scivolis kial mi bezonus foran servilon kiel gcloud, ŝajnas ke mi trovis ilin.

Kiel loka virtuala maŝino, vi povas uzi la saman Alpan, kiu estas aktive uzata en docker-ujoj. Nu, aŭ iuj aliaj malpezaj distribuoj por plirapidigi la maŝinon.

Fundo: vi povas kaj devas ruli datumbazojn kaj aliajn infrastrukturajn bonaĵojn sur foraj serviloj aŭ en virtualskatolo. Mi ne bezonas docker por ĉi tiuj celoj.

Iom pri docker-bildoj kaj distribuado

Mi jam skribis artikolo en kiu mi volis transdoni, ke uzi docker-bildojn ne donas ajnan garantion. Docker-bildoj necesas nur por krei docker-ujon. Se vi ĝisdatigas al docker-bildo, tiam vi ĝisdatigas por uzi docker-ujojn kaj vi nur uzos ilin.

Ĉu vi vidis ie kie programistoj portas siajn produktojn nur en docker-bildo?
La rezulto de plej multaj produktoj estas binaraj dosieroj por specifa platformo; ili estas simple aldonitaj al la docker-bildo, kiu estas heredita de la dezirata platformo. Ĉu vi iam scivolis kial estas tiom da similaj bildoj sur dockerhub? Enigu nginx ekzemple, vi vidos 100500 bildojn de malsamaj homoj. Ĉi tiuj homoj ne evoluigis nginx mem, ili simple aldonis oficialan nginx al sia docker-bildo kaj spicis ĝin per siaj propraj agordoj por la oportuno lanĉi ujojn.

Ĝenerale, vi povas simple konservi ĝin en tgz, se iu bezonas ruli ĝin en docker, tiam lasu ilin aldoni tgz al la Dockerfile, heredi de la dezirata medio kaj krei pliajn bulkojn kiuj ne ŝanĝas la aplikaĵon mem en tgz. Ĉiu, kiu kreos docker-bildon, scios kio estas tgz kaj kion li bezonas por labori. Jen kiel mi uzas docker tie

Fundo: Mi ne bezonas docker-registron, mi uzos ian S3 aŭ nur dosierstokadon kiel google drive/dropbox

Docker en CI

Ĉiuj kompanioj, por kiuj mi laboris, estas similaj. Ili estas kutime nutraĵvendejo. Tio estas, ili havas unu aplikaĵon, unu teknologian stakon (nu, eble kelkajn aŭ tri programlingvojn).

Ĉi tiuj kompanioj uzas docker sur siaj serviloj, kie funkcias la CI-procezo. Demando: Kial vi bezonas konstrui projektojn en docker-ujo sur viaj serviloj? Kial ne simple prepari medion por la konstruo, ekzemple, verki Ansible-ludlibron, kiu instalos la necesajn versiojn de nodejs, php, jdk, kopiu ssh-ŝlosilojn ktp al la servilo en kiu la konstruo okazos?

Nun mi komprenas, ke ĉi tio pafas min en la piedon, ĉar docker ne alportas profiton per sia izolado. Problemoj, kiujn mi renkontis kun CI en docker:

• denove vi bezonas docker-bildon por konstrui. vi devas serĉi bildon aŭ skribi vian propran dockerfile.
• 90% ke vi devas plusendi kelkajn ssh-ŝlosilojn, sekretajn datumojn, kiujn vi ne volas skribi al la docker-bildo.
• la ujo estas kreita kaj mortas, ĉiuj kaŝmemoroj estas perditaj kune kun ĝi. la sekva konstruo re-elŝutos ĉiujn projektajn dependecojn, kio estas temporaba kaj neefika, kaj tempo estas mono.

Programistoj ne konstruas projektojn en docker-ujoj (mi iam estis tia ŝatanto, vere, mi kompatas min en la pasinteco xD). En java eblas havi plurajn versiojn kaj ŝanĝi ilin per unu komando al tiu, kiun vi bezonas nun. Estas same en nodejs, ekzistas nvm.

konkludo

Mi kredas, ke tiu docker estas tre potenca kaj fleksebla ilo, ĉi tio estas ĝia malavantaĝo (sonas strange, jes). Kun ĝia helpo, kompanioj povas facile alkroĉi ĝin kaj uzi ĝin kie necesas kaj ne necesas. Programistoj lanĉas siajn ujojn, kelkajn el siaj medioj, tiam ĉio glate fluas en CI kaj produktadon. La teamo DevOps skribas ian kodon por ruli ĉi tiujn ujojn.

Uzu docker nur ŝaltita la plej freŝa stadio en via laborfluo, ne trenu ĝin en la projekton komence. Ĝi ne solvos viajn komercajn problemojn. Li nur movos la problemojn al ALIA nivelo kaj proponos siajn proprajn solvojn, vi faros duoblan laboron.

Kiam docker estas necesa: Mi venis al la konkludo, ke docker estas tre bona pri optimumigado de difinita procezo, sed ne pri konstruado de bazaj funkcioj

Se vi ankoraŭ decidas uzi docker, tiam:

• estu ege singarda
• ne devigu programistojn uzi docker
• lokalizu ĝian uzon en unu loko, ne disvastigu ĝin tra ĉiuj Dockefile kaj docker-compose-deponejoj

PS:

• Mi ĵus renkontis pakisto kaj ili diras, ke ĝi funkcias tre bone kun Ansible kaj permesas vin unuigi la procezon de konstruado de bildoj (inkluzive de docker-bildo)
• ankaŭ pri docker, interesa artikolo

Dankon pro legado, mi deziras al vi travideblajn decidojn en viaj aferoj kaj produktivaj labortagoj!

fonto: www.habr.com