ProHoster > Blogs > Administrācija > Vai Docker ir rotaļlieta vai nē? Vai arī tā joprojām ir taisnība?

Vai Docker ir rotaļlieta vai nē? Vai arī tā joprojām ir taisnība?

Sveiki visiem!

Ļoti gribu ķerties pie tēmas, bet pareizāk būtu mazliet pastāstīt par savu stāstu:

Ieraksts

Esmu programmētājs ar pieredzi frontend vienas lapas aplikāciju, scala/java un nodejs izstrādē uz servera.

Diezgan ilgu laiku (pāris vai trÄ«s gadus noteikti) biju uzskats, ka Docker ir debesu manna un vispār ļoti forÅ”s rÄ«ks un pilnÄ«gi katram izstrādātājam bÅ«tu jāprot to izmantot. No tā izriet, ka katram izstrādātājam ir jābÅ«t instalētam Docker savā vietējā datorā. Kas par manu viedokli, paskaties cauri vakances, kas ir izliktas tajā paŔā hh. Katrā otrajā ir pieminēts dokers, un, ja tas jums pieder, tā bÅ«s jÅ«su konkurences priekÅ”rocÄ«ba šŸ˜‰

Pa ceļam es satiku daudzus cilvēkus ar atŔķirÄ«go attieksmi pret Docker un tās ekosistēmu. Daži teica, ka Ŕī ir ērta lieta, kas garantē starpplatformu funkcionalitāti. Otrie nesaprata, kāpēc jāskrien konteineros un kāda peļņa no tā bÅ«s, treÅ”ajiem bija pilnÄ«gi vienalga un netraucēja (vienkārÅ”i uzrakstÄ«ja kodu un devās mājās - apskaužu viņus, pa veids :)

LietoŔanas iemesli

Kāpēc es izmantoju docker? Iespējams, Ŕādu iemeslu dēļ:

  • datu bāzes palaiÅ”ana, 99% lietojumprogrammu tās izmanto
  • nginx palaiÅ”ana priekÅ”gala izplatÄ«Å”anai un starpniekservera izmantoÅ”ana aizmugursistēmai
  • jÅ«s varat iepakot lietojumprogrammu docker attēlā, tādā veidā mana lietojumprogramma darbosies visur, kur pastāv docker, izplatÄ«Å”anas problēma tiek atrisināta nekavējoties
  • pakalpojumu atklāŔana no kastes, jÅ«s varat izveidot mikropakalpojumus, katrs konteiners (pieslēgts kopējam tÄ«klam) var viegli sasniegt citu, izmantojot aizstājvārdu, ļoti ērti
  • Ir jautri izveidot konteineru un "spēlēties" tajā.

Kas man vienmēr NEPATÄŖK Docker:

  • Lai mana lietojumprogramma darbotos, man serverÄ« ir nepiecieÅ”ams pats Docker. Kāpēc man tas ir vajadzÄ«gs, ja manas lietojumprogrammas darbojas uz jre vai nodejs un tām paredzēta vide jau ir serverÄ«?
  • ja gribu palaist savu (privāto) lokāli uzbÅ«vēto attēlu uz attālā servera, tad vajag savu docker repozitoriju, vajag, lai kaut kur strādā reÄ£istrs un arÄ« jākonfigurē https, jo docker cli strādā tikai pār https. Ak, sasodÄ«ts... protams, ir iespējas saglabāt attēlu lokāli caur docker save un vienkārÅ”i nosÅ«tiet attēlu caur scp... Bet tas ir daudz Ä·ermeņa kustÄ«bu. Un turklāt tas izskatās kā ā€œkruÄ·uā€ risinājums, lÄ«dz parādās jÅ«su paÅ”u krātuve
  • docker-compose. Tas ir nepiecieÅ”ams tikai konteineru darbināŔanai. Tas ir viss. ViņŔ neko citu nevar. Docker-compose ir virkne failu versiju, sava sintakse. Lai cik tas bÅ«tu deklaratÄ«vs, es nevēlos lasÄ«t viņu dokumentāciju. Man tas nekur citur nebÅ«s vajadzÄ«gs.
  • strādājot komandā, lielākā daļa cilvēku raksta Dockerfile ļoti greizi, nesaprot, kā tas tiek saglabāts keÅ”atmiņā, pievieno attēlam visu nepiecieÅ”amo un nevajadzÄ«go, manto no attēliem, kas nav Dockerhub vai privātā repozitorijā, izveido dažus docker-compose faili ar datu bāzēm, un nekas nepaliek. Tajā paŔā laikā izstrādātāji ar lepnumu paziņo, ka Docker ir forÅ”s, viņiem viss darbojas lokāli, un HR vakancei Ä«paÅ”i raksta: "Mēs izmantojam Docker, un mums ir nepiecieÅ”ams kandidāts ar Ŕādu darba pieredzi."
  • Mani nepārtraukti vajā domas par visu celÅ”anu Docker: postgresql, kafka, redis. Žēl, ka ne viss darbojas konteineros, ne visu ir viegli konfigurēt un palaist. To atbalsta treÅ”o puÅ”u izstrādātāji, nevis paÅ”i pārdevēji. Un, starp citu, uzreiz rodas jautājums: pārdevēji neuztraucas par savu produktu uzturÄ“Å”anu Docker, kāpēc tas tā ir, varbÅ«t viņi kaut ko zina?
  • Vienmēr rodas jautājums par konteinera datu noturÄ«bu. un tad jÅ«s domājat, vai man vienkārÅ”i jāpievieno resursdatora direktorijs vai jāizveido docker sējums vai jāizveido datu konteiners, kas tagad ir deprecated? Ja es montēju direktoriju, tad man ir jāpārliecinās, vai konteinerā esoŔā lietotāja uid un gid atbilst konteinera palaiÅ”anas lietotāja id, pretējā gadÄ«jumā konteinera izveidotie faili tiks izveidoti ar root tiesÄ«bām. Ja es lietoju volume tad daži vienkārÅ”i tiks izveidoti /usr/* un ar uid un gid bÅ«s tas pats stāsts kā pirmajā gadÄ«jumā. Ja palaižat treŔās puses komponentu, jums ir jāizlasa dokumentācija un jāmeklē atbilde uz jautājumu: "kuros konteinera direktorijos komponents ieraksta failus?"

Man vienmēr nav paticis, ka man bija pārāk ilgi jāmācās ar Docker sākotnējā stadijā: Es izdomāju, kā palaist konteinerus, no kādiem attēliem palaist, izveidoju Makefiles, kas saturēja garās Docker komandas aizstājvārdus. Es ienÄ«du doku komponÄ“Å”anu, jo nevēlējos apgÅ«t citu doku ekosistēmas rÄ«ku. UN docker-compose up Mani tas traucēja, it Ä«paÅ”i, ja viņi tur joprojām satikās build konstrukcijas, nevis jau samontēti attēli. Viss, ko es patieŔām vēlējos, bija vienkārÅ”i izveidot produktu efektÄ«vi un ātri. Bet es nevarēju saprast, kā izmantot docker.

Iepazīstinām ar Ansible

Nesen (pirms trÄ«s mēneÅ”iem) es strādāju ar DevOps komandu, kuras gandrÄ«z katram dalÄ«bniekam bija negatÄ«va attieksme pret Docker. Iemeslu dēļ:

  • docker noteikumi iptables (lai gan to var atspējot daemon.json)
  • docker ir kļūdains, un mēs to nedarbosim ražoÅ”anā
  • ja docker dēmons avarē, tad attiecÄ«gi avarē visi konteineri ar infrastruktÅ«ru
  • nav nepiecieÅ”ams dokeris
  • kāpēc docker, ja ir Ansible un virtuālās maŔīnas

Tajā paŔā darbā es iepazinos ar citu rÄ«ku - Ansible. Reiz par to dzirdēju, bet nemēģināju rakstÄ«t pats savas rokasgrāmatas. Un tagad es sāku rakstÄ«t savus uzdevumus un tad mans redzējums pilnÄ«bā mainÄ«jās! Jo sapratu: Ansible ir moduļi, lai darbinātu vienus un tos paÅ”us docker konteinerus, attēlu bÅ«vējumus, tÄ«klus utt., un konteinerus var palaist ne tikai lokāli, bet arÄ« attālos serveros! Manam priekam nebija robežu ā€“ es atradu NORMĀLU rÄ«ku un izmetu savus Makefile un docker-compose failus, tie tika aizstāti ar yaml uzdevumiem. Kods tika samazināts, izmantojot tādas konstrukcijas kā loop, when, Uc

Docker treÅ”o puÅ”u komponentu, piemēram, datu bāzu, darbināŔanai

Nesen iepazinos ar ssh tuneļiem. IzrādÄ«jās, ka attālā servera portu ir ļoti viegli ā€œpārsÅ«tÄ«tā€ uz vietējo portu. Attālais serveris var bÅ«t vai nu maŔīna mākonÄ«, vai virtuāla maŔīna, kas darbojas programmā VirtualBox. Ja manam kolēģim vai man ir nepiecieÅ”ama datu bāze (vai kāds cits treŔās puses komponents), mēs varam vienkārÅ”i startēt serveri ar Å”o komponentu un izslēgt to, kad serveris nav vajadzÄ«gs. Portu pāradresācija nodroÅ”ina tādu paÅ”u efektu kā datu bāze, kas darbojas docker konteinerā.

Šī komanda pārsūta manu vietējo portu uz attālo serveri, kurā darbojas postgresql:

ssh -L 9000:localhost:5432 [e-pasts aizsargāts]

Attālā servera izmantoÅ”ana atrisina problēmu ar komandas attÄ«stÄ«bu. Šādu serveri var izmantot vairāki izstrādātāji vienlaikus, viņiem nav jāspēj konfigurēt postgresql, saprast Docker un citas sarežģītÄ«bas. Attālā serverÄ« to paÅ”u datu bāzi var instalēt paŔā Docker, ja ir grÅ«ti instalēt konkrētu versiju. Viss, kas izstrādātājiem ir nepiecieÅ”ams, ir nodroÅ”ināt ssh piekļuvi!

Nesen lasÄ«ju, ka SSH tuneļi ir ierobežota parastā VPN funkcionalitāte! Varat vienkārÅ”i instalēt OpenVPN vai citas VPN implementācijas, iestatÄ«t infrastruktÅ«ru un nodot to izstrādātājiem lietoÅ”anai. Tas ir tik forÅ”i!

Par laimi, AWS, GoogleCloud un citi sniedz jums gadu bez maksas, tāpēc izmantojiet tos! Tie ir lēti, ja tos izslēdzat, kad tos neizmantojat. Es vienmēr domāju, kāpēc man ir vajadzÄ«gs attālais serveris, piemēram, gcloud, Ŕķiet, ka es tos atradu.

Kā vietējo virtuālo maŔīnu varat izmantot to paÅ”u Alpine, kas tiek aktÄ«vi izmantota docker konteineros. Nu, vai daži citi vieglie sadalÄ«jumi, lai padarÄ«tu maŔīnu ātrāku palaiÅ”anu.

Secinājums: jūs varat un vajadzētu palaist datu bāzes un citus infrastruktūras labumus attālos serveros vai virtuālajā kastē. Šiem nolūkiem man nav vajadzīgs doks.

Nedaudz par doku attēliem un izplatÄ«Å”anu

Es jau rakstÄ«ju raksts kurā es gribēju pateikt, ka docker attēlu izmantoÅ”ana nesniedz nekādu garantiju. Docker attēli ir nepiecieÅ”ami tikai Docker konteinera izveidei. Ja veicat jaunināŔanu uz Docker attēlu, jÅ«s veicat jaunināŔanu, lai izmantotu Docker konteinerus un izmantosit tikai tos.

Vai esat redzējuÅ”i kaut kur, kur programmatÅ«ras izstrādātāji portē savus produktus tikai docker attēlā?
Lielākā daļa produktu ir bināri faili noteiktai platformai; tie tiek vienkārÅ”i pievienoti docker attēlam, kas tiek mantots no vēlamās platformas. Vai esat kādreiz domājis, kāpēc vietnē dockerhub ir tik daudz lÄ«dzÄ«gu attēlu? Ievadiet, piemēram, nginx, jÅ«s redzēsit 100500 XNUMX attēlus no dažādiem cilvēkiem. Å ie cilvēki neizstrādāja paÅ”u nginx, viņi vienkārÅ”i pievienoja oficiālo nginx savam doka attēlam un papildināja to ar savām konfigurācijām, lai bÅ«tu ērtāk palaist konteinerus.

Vispār var vienkārÅ”i glabāt tgz, ja kādam vajag palaist dockerā, tad lai pievieno tgz Dockerfile, manto no vēlamās vides un izveido papildus bulkas, kas nemaina paÅ”u aplikāciju tgz. Ikviens, kurÅ” izveidos docker attēlu, zinās, kas ir tgz un kas viņam ir nepiecieÅ”ams, lai strādātu. Šādi es izmantoju docker Å”eit

ApakŔējā lÄ«nija: man nav nepiecieÅ”ams docker reÄ£istrs, es izmantoÅ”u kaut kādu S3 vai vienkārÅ”i failu krātuvi, piemēram, Google disku/dropbox

Dokeris CI

Visi uzņēmumi, kuros esmu strādājusi, ir lÄ«dzÄ«gi. Tās parasti ir pārtikas preces. Tas ir, viņiem ir viena lietojumprogramma, viena tehnoloÄ£iju kaudze (labi, varbÅ«t pāris vai trÄ«s programmÄ“Å”anas valodas).

Å ie uzņēmumi savos serveros, kur darbojas CI process, izmanto docker. Jautājums: Kāpēc jums ir jāveido projekti savos serveros docker konteinerā? Kāpēc gan vienkārÅ”i nesagatavot bÅ«vÄ“Å”anai vidi, piemēram, uzrakstÄ«t Ansible playbook, kas serverÄ«, kurā notiks bÅ«vÄ“Å”ana, instalēs nepiecieÅ”amās nodejs, php, jdk versijas, nokopēs ssh atslēgas utt.?

Tagad saprotu, ka tas ir Å”auÅ”ana sev kājā, jo dokeris ar savu izolāciju nekādu peļņu nenes. Problēmas, ar kurām es saskāros ar CI Docker:

  • atkal jums ir nepiecieÅ”ams docker attēls, lai izveidotu. jums ir jāmeklē attēls vai jāuzraksta savs dockerfile.
  • 90%, ka jums ir jāpārsÅ«ta dažas ssh atslēgas, slepenie dati, kurus nevēlaties rakstÄ«t docker attēlam.
  • konteiners tiek izveidots un nomirst, kopā ar to tiek zaudētas visas keÅ”atmiņas. nākamajā bÅ«vniecÄ«bā tiks atkārtoti lejupielādētas visas projekta atkarÄ«bas, kas ir laikietilpÄ«gi un neefektÄ«vi, un laiks ir nauda.

Izstrādātāji nebÅ«vē projektus dokeru konteineros (es kādreiz biju tāds fans, tieŔām, agrāk žēl xD). Java ir iespējams izveidot vairākas versijas un nomainÄ«t tās ar vienu komandu uz vajadzÄ«go tagad. Nodejs ir tas pats, tur ir nvm.

secinājums

Es uzskatu, ka docker ir ļoti spēcÄ«gs un elastÄ«gs rÄ«ks, tas ir tā trÅ«kums (izklausās dÄ«vaini, jā). Ar tās palÄ«dzÄ«bu uzņēmumi var viegli pieÄ·erties tam un izmantot to, kur nepiecieÅ”ams un nav vajadzÄ«gs. Izstrādātāji palaiž savus konteinerus, dažas no savām vidēm, pēc tam tas viss vienmērÄ«gi nonāk CI un ražoÅ”anā. DevOps komanda raksta sava veida kodu, lai palaistu Å”os konteinerus.

Izmantojiet docker tikai ieslēgtu jaunākais posmā savā darbplÅ«smā, neievelciet to projektā sākumā. Tas neatrisinās jÅ«su biznesa problēmas. ViņŔ tikai pārcels problēmas CITĀ lÄ«menÄ« un piedāvās savus risinājumus, tu darÄ«si dubultdarbu.

Kad ir nepiecieÅ”ams doks: Es nonācu pie secinājuma, ka docker ļoti labi spēj optimizēt doto procesu, bet ne izveidot pamata funkcionalitāti

Ja joprojām nolemjat izmantot docker, tad:

  • esiet ārkārtÄ«gi uzmanÄ«gs
  • nepiespiediet izstrādātājus izmantot docker
  • lokalizējiet tā lietoÅ”anu vienuviet, neizplatiet to visās Dockefile un Docker-compose krātuvēs

PS:

Paldies, ka izlasījāt, novēlu pārskatāmus lēmumus jūsu lietās un produktīvas darba dienas!

Avots: www.habr.com

Pievieno komentāru