Docker is 'n speelding of nie? Of is dit steeds?

Hallo almal!

Ek wil regtig reguit by die onderwerp uitkom, maar dit sal meer korrek wees om 'n bietjie oor my storie te vertel:

Entry

Ek is 'n programmeerder met ondervinding in die ontwikkeling van frontend enkelbladsy toepassings, scala/java en nodejs op die bediener.

Ek was vir 'n lang tyd (beslis 'n paar of drie jaar) van mening dat Docker manna uit die hemel is en oor die algemeen 'n baie gawe hulpmiddel en absoluut elke ontwikkelaar behoort dit te kan gebruik. En hieruit volg dat elke ontwikkelaar Docker op hul plaaslike masjien moet hê. Wat van my opinie, kyk deur die vakatures wat op dieselfde hh geplaas word. Elke tweede een bevat 'n melding van docker, en as jy dit besit, sal dit jou mededingende voordeel wees 😉

Op my pad het ek baie mense ontmoet, met hul verskillende houdings teenoor Docker en sy ekosisteem. Sommige het gesê dat dit 'n gerieflike ding is wat funksionaliteit oor die platform waarborg. Die tweedes het nie verstaan ​​hoekom hulle in houers moet hardloop en watter wins daaruit sou kom nie, die derdes het glad nie omgegee nie en het nie gepla nie (hulle het net die kode geskryf en huis toe gegaan - ek beny hulle, deur die manier :)

Redes vir gebruik

Hoekom het ek docker gebruik? Waarskynlik om die volgende redes:

• databasis bekendstelling, 99% van toepassings gebruik dit
• loods nginx vir frontend verspreiding en proxying na backend
• jy kan die toepassing in 'n docker-beeld verpak, op hierdie manier sal my toepassing werk waar docker ook al bestaan, die verspreidingsprobleem word onmiddellik opgelos
• diens ontdekking uit die boks, jy kan mikrodienste skep, elke houer (gekoppel aan 'n gemeenskaplike netwerk) kan 'n ander maklik bereik via 'n alias, baie gerieflik
• Dit is lekker om 'n houer te skep en daarin te "speel".

Wat ek altyd NIE van Docker hou nie:

• Om my toepassing te laat werk, het ek Docker self op die bediener nodig. Hoekom het ek dit nodig as my toepassings op jre of nodejs loop en die omgewing daarvoor reeds op die bediener is?
• as ek my (privaat) plaaslik geboude beeld op 'n afgeleë bediener wil laat loop, dan het ek my eie docker repository nodig, ek het die register nodig om iewers te werk en ek moet ook https konfigureer, want docker cli werk net oor https. Ag damn... daar is natuurlik opsies om die beeld plaaslik te stoor via docker save en stuur net die beeld via scp ... Maar dit is baie liggaamsbewegings. En buitendien, dit lyk soos 'n "kruk" oplossing totdat jou eie bewaarplek verskyn
• docker-compose. Dit is net nodig om houers te laat loop. Dis al. Hy kan niks anders doen nie. Docker-compose het 'n klomp weergawes van sy lêers, sy eie sintaksis. Maak nie saak hoe verklarend dit is nie, ek wil nie hul dokumentasie lees nie. Ek sal dit nêrens anders nodig hê nie.
• wanneer hulle in 'n span werk, skryf die meeste mense 'n Docker-lêer baie skeef, verstaan ​​nie hoe dit gekas is nie, voeg alles by wat hulle nodig het en nie nodig het by die prent nie, erf van prente wat nie in Dockerhub of 'n private bewaarplek is nie, skep 'n paar docker-compose lêers met databasisse en niks bly nie. Terselfdertyd verklaar die ontwikkelaars met trots dat Docker cool is, alles werk plaaslik vir hulle, en HR skryf belangrik in die vakature: "Ons gebruik Docker en ons benodig 'n kandidaat met sulke werkservaring."
• Ek word voortdurend spook deur gedagtes oor die verhoging van alles in Docker: postgresql, kafka, redis. Dit is jammer dat alles nie in houers werk nie, nie alles is maklik om te konfigureer en te laat loop nie. Dit word ondersteun deur derdeparty-ontwikkelaars, en nie deur die verskaffers self nie. En terloops, die vraag ontstaan ​​dadelik: verkopers is nie bekommerd oor die instandhouding van hul produkte in Docker nie, hoekom is dit, miskien weet hulle iets?
• Die vraag ontstaan ​​altyd oor die volharding van houerdata. en dan dink jy, moet ek net die gasheergids monteer of 'n docker-volume skep of 'n datahouer maak wat nou is deprecated? As ek 'n gids monteer, moet ek seker maak dat die uid en gid van die gebruiker in die houer ooreenstem met die id van die gebruiker wat die houer geloods het, anders sal die lêers wat deur die houer geskep is met wortelregte geskep word. As ek gebruik volume dan sal die data eenvoudig in sommige geskep word /usr/* en daar sal dieselfde storie wees met uid en gid as in die eerste geval. As u 'n derdeparty-komponent begin, moet u die dokumentasie lees en die antwoord op die vraag soek: "in watter houergidse skryf die komponent lêers?"

Ek het altyd nie gehou van die feit dat ek te lank met Docker moes peuter nie in die aanvanklike stadium: Ek het uitgevind hoe om houers te begin, van watter beelde om te begin, het Makefiles gemaak wat aliasse vir lang Docker-opdragte bevat. Ek het docker-compose gehaat omdat ek nie 'n ander instrument in die docker-ekosisteem wou leer nie. EN docker-compose up Dit het my gepla, veral as hulle nog daar ontmoet het build konstruksies, eerder as reeds saamgestelde beelde. Al wat ek eintlik wou hê, was om net 'n produk doeltreffend en vinnig te maak. Maar ek kon nie uitvind hoe om docker te gebruik nie.

Ons stel Ansible bekend

Ek het onlangs (drie maande gelede) saam met 'n DevOps-span gewerk, waarvan byna elke lid 'n negatiewe houding teenoor Docker gehad het. Om redes:

• docker reëls iptables (alhoewel jy dit kan deaktiveer in daemon.json)
• docker is karretjie en ons sal dit nie in produksie laat loop nie
• as docker daemon ineenstort, dan stort alle houers met infrastruktuur dienooreenkomstig neer
• nie nodig vir docker nie
• Hoekom docker as daar Ansible en virtuele masjiene is

By dieselfde werk het ek kennis gemaak met 'n ander hulpmiddel - Ansible. Ek het eenkeer daarvan gehoor, maar het nie probeer om my eie speelboeke te skryf nie. En nou het ek my take begin skryf en toe verander my visie heeltemal! Want ek het besef: Ansible het modules om dieselfde docker-houers, beeldbou, netwerke, ens. te laat loop, en houers kan nie net plaaslik nie, maar ook op afgeleë bedieners bestuur word! My vreugde het geen perke geken nie - ek het 'n NORMALE instrument gevind en my Makefile en docker-compose-lêers weggegooi, hulle is vervang met yaml-take. Die kode is verminder deur gebruik te maak van konstrukte soos loop, when, Ens.

Docker vir die bestuur van derdeparty-komponente soos databasisse

Ek het onlangs kennis gemaak met ssh tonnels. Dit het geblyk dat dit baie maklik is om die poort van 'n afgeleë bediener te "aanstuur" na 'n plaaslike poort. Die afgeleë bediener kan óf 'n masjien in die wolk wees óf 'n virtuele masjien wat in VirtualBox loop. As ek of my kollega 'n databasis benodig (of 'n ander derdeparty-komponent), kan ons eenvoudig die bediener met hierdie komponent begin en dit afskakel wanneer die bediener nie nodig is nie. Port forwarding gee dieselfde effek as 'n databasis wat in 'n docker-houer loop.

Hierdie opdrag stuur my plaaslike poort aan na 'n afgeleë bediener met postgresql:

ssh -L 9000: plaaslike gasheer: 5432 [e-pos beskerm]

Die gebruik van 'n afgeleë bediener los die probleem met spanontwikkeling op. So 'n bediener kan deur verskeie ontwikkelaars gelyktydig gebruik word; hulle hoef nie postgresql te kan konfigureer, Docker en ander ingewikkeldhede te verstaan ​​nie. Op 'n afgeleë bediener kan u dieselfde databasis in Docker self installeer, as dit moeilik is om 'n spesifieke weergawe te installeer. Al wat ontwikkelaars nodig het, is om ssh-toegang te verskaf!

Ek het onlangs gelees dat SSH-tonnels 'n beperkte funksionaliteit van 'n gewone VPN is! U kan eenvoudig OpenVPN of ander VPN-implementerings installeer, die infrastruktuur opstel en dit aan ontwikkelaars gee vir gebruik. Dit is so cool!

Gelukkig gee AWS, GoogleCloud en ander jou 'n jaar gratis gebruik, so gebruik hulle! Hulle is goedkoop as jy dit afskakel wanneer dit nie gebruik word nie. Ek het altyd gewonder hoekom ek 'n afgeleë bediener soos gcloud sou benodig, dit blyk dat ek dit gevind het.

As 'n plaaslike virtuele masjien kan jy dieselfde Alpine gebruik, wat aktief in docker-houers gebruik word. Wel, of 'n ander liggewig verspreidings om die masjien vinniger te laat begin.

Bottom line: jy kan en moet databasisse en ander infrastruktuur-goedjies op afgeleë bedieners of in virtualbox laat loop. Ek het nie docker vir hierdie doeleindes nodig nie.

'n Bietjie oor docker-beelde en verspreiding

Ek het reeds geskryf 'n artikel waarin ek wou oordra dat die gebruik van docker-beelde geen waarborg bied nie. Docker-beelde is slegs nodig om 'n docker-houer te skep. As jy opgradeer na 'n docker-beeld, dan gradeer jy op om docker-houers te gebruik en jy sal dit net gebruik.

Het jy enige plek gesien waar sagteware-ontwikkelaars hul produkte slegs in 'n docker-beeld oordra?
Die resultaat van die meeste produkte is binêre lêers vir 'n spesifieke platform; hulle word eenvoudig by die docker-beeld gevoeg, wat van die verlangde platform geërf word. Het jy al ooit gewonder hoekom daar soveel soortgelyke beelde op dockerhub is? Voer byvoorbeeld nginx in, jy sal 100500 XNUMX beelde van verskillende mense sien. Hierdie mense het nie nginx self ontwikkel nie, hulle het eenvoudig amptelike nginx by hul docker-beeld gevoeg en dit met hul eie konfigurasies gekruid vir die gerief om houers te begin.

Oor die algemeen kan jy dit eenvoudig in tgz stoor, as iemand dit in docker moet laat loop, laat hulle dan tgz by die Dockerfile voeg, erf van die verlangde omgewing en skep bykomende broodjies wat nie die toepassing self in tgz verander nie. Enigeen wat 'n docker-beeld sal skep, sal weet wat tgz is en wat hy nodig het om te werk. Dit is hoe ek docker gebruik hier

Bottom line: Ek het nie docker-register nodig nie, ek sal 'n soort S3 gebruik of net lêerberging soos Google Drive/dropbox

Docker in CI

Al die maatskappye waarvoor ek gewerk het, is soortgelyk. Hulle is gewoonlik kruideniersware. Dit wil sê, hulle het een toepassing, een tegnologiestapel (wel, miskien 'n paar of drie programmeertale).

Hierdie maatskappye gebruik docker op hul bedieners waar die CI-proses loop. Vraag - hoekom moet jy projekte in 'n dokhouer op jou bedieners bou? Hoekom nie net 'n omgewing vir die bou voorberei nie, byvoorbeeld 'n Ansible-speelboek skryf wat die nodige weergawes van nodejs, php, jdk, kopieer ssh-sleutels, ens. sal installeer na die bediener waarin die bou sal plaasvind?

Nou verstaan ​​ek dit skiet myself in die voet, want docker bring geen wins met sy isolasie nie. Probleme wat ek met CI in docker teëgekom het:

• weereens het jy 'n docker-beeld nodig om te bou. jy moet 'n prent soek of jou eie dockerfile skryf.
• 90% wat jy nodig het om 'n paar ssh-sleutels aan te stuur, geheime data wat jy nie na die docker-beeld wil skryf nie.
• die houer word geskep en sterf, alle caches gaan daarmee saam verlore. die volgende bou sal al die projekafhanklikhede weer aflaai, wat tydrowend en oneffektief is, en tyd is geld.

Ontwikkelaars bou nie projekte in docker-houers nie (ek was eens so 'n fan, regtig, ek voel jammer vir myself in die verlede xD). In java is dit moontlik om verskeie weergawes te hê en dit met een opdrag te verander na die een wat jy nou nodig het. Dit is dieselfde in nodejs, daar is nvm.

Output

Ek glo dat docker 'n baie kragtige en buigsame instrument is, dit is die nadeel daarvan (klink vreemd, ja). Met sy hulp kan maatskappye maklik daaraan vashaak en dit gebruik waar nodig en nie nodig nie. Ontwikkelaars begin hul houers, sommige van hul omgewings, dan vloei dit alles glad na CI en produksie. Die DevOps-span skryf 'n soort kode om hierdie houers uit te voer.

Gebruik slegs docker aan die mees onlangse stadium in jou werkvloei, moenie dit aan die begin by die projek insleep nie. Dit sal nie jou besigheidsprobleme oplos nie. Hy sal net die probleme na 'n ANDER vlak skuif en sy eie oplossings bied, jy sal dubbel werk doen.

Wanneer docker nodig is: Ek het tot die gevolgtrekking gekom dat docker baie goed is om 'n gegewe proses te optimaliseer, maar nie om basiese funksionaliteit te bou nie

As jy steeds besluit om docker te gebruik, dan:

• wees uiters versigtig
• moenie ontwikkelaars dwing om docker te gebruik nie
• lokaliseer die gebruik daarvan op een plek, moenie dit oor alle Dockefile- en docker-compose-bewaarplekke versprei nie

PS:

• Ek het onlangs afgekom verpakker en hulle sê dit werk baie goed met Ansible en laat jou toe om die proses van die bou van beelde te verenig (insluitend docker-beeld)
• ook oor docker, interessante artikel

Dankie dat jy gelees het, ek wens jou deursigtige besluite toe in jou sake en produktiewe werksdae!

Bron: will.com