Kas Docker on mänguasi või mitte? Või on see ikka tõsi?

Tere kõigile!

Tahaks väga kohe teema juurde jõuda, aga õigem oleks natuke oma loost rääkida:

Kanne

Olen programmeerija, kellel on kogemusi üheleheliste esiotsa rakenduste, scala/java ja nodejs serveris arendamisel.

Päris pikka aega (paar-kolm aastat kindlasti) olin seda meelt, et Docker on taevamanna ja üldiselt väga lahe tööriist ja sellega peaks hakkama saama absoluutselt iga arendaja. Sellest järeldub, et igal arendajal peaks olema Docker oma kohalikku masinasse installitud. Aga minu arvamus, vaadake läbi need vabad töökohad, mis on postitatud samale hh-le. Iga teine ​​sisaldab dokkeri mainimist ja kui see teile kuulub, on see teie konkurentsieelis 😉

Oma teel kohtasin paljusid inimesi, kellel oli erinev suhtumine Dockeri ja selle ökosüsteemi. Mõned ütlesid, et see on mugav asi, mis tagab platvormidevahelise funktsionaalsuse. Teised ei saanud aru, miks nad peaksid konteinerites jooksma ja mis kasu sellest tuleb, kolmandad ei hoolinud üldse ja ei viitsinud (kirjutasid lihtsalt koodi ja läksid koju – kadestan neid, tee :)

Kasutamise põhjused

Miks ma dokkerit kasutasin? Tõenäoliselt järgmistel põhjustel:

• andmebaasi käivitamine, kasutab neid 99% rakendustest
• nginxi käivitamine kasutajaliidese levitamiseks ja puhverserveri kasutamine taustaprogrammi jaoks
• saate rakenduse pakendada dockeri kujutisesse, nii töötab minu rakendus kõikjal, kus docker on olemas, levitamisprobleem lahendatakse kohe
• teenuste avastamine karbist välja võttes saate luua mikroteenuseid, iga konteiner (ühendatud ühisesse võrku) pääseb hõlpsasti teise juurde aliase kaudu, väga mugav
• Konteiner on lõbus luua ja selles "mängida".

Mis mulle dokkeri juures alati EI meeldi:

• Minu rakenduse töötamiseks vajan serveris Dockerit ennast. Miks mul seda vaja on, kui mu rakendused töötavad jre-s või nodejs-is ja nende jaoks mõeldud keskkond on juba serveris?
• kui ma tahan oma (privaatset) lokaalselt ehitatud pilti kaugserveris käivitada, siis mul on vaja oma dockeri repositooriumit, mul on vaja, et register töötaks kuskil ja pean ka https seadistama, sest docker cli töötab ainult üle https. Oh kurat... muidugi on võimalusi pildi kohalikuks salvestamiseks docker save ja lihtsalt saada pilt scp kaudu... Aga see on palju kehaliigutusi. Ja pealegi tundub see "kargu" lahendusena, kuni ilmub teie enda hoidla
• docker-compose. Seda on vaja ainult konteinerite käitamiseks. See on kõik. Ta ei saa midagi muud teha. Docker-compose on hunnik oma failide versioone, oma süntaks. Ükskõik kui deklaratiivne see ka poleks, ma ei taha nende dokumentatsiooni lugeda. Mul pole seda kuskil mujal vaja.
• meeskonnas töötades kirjutab enamik inimesi Dockerfile'i väga viltu, ei saa aru, kuidas see vahemällu salvestatakse, lisab pildile kõik vajaliku ja mittevajaliku, pärib piltidelt, mida ei ole Dockerhubis ega privaatses hoidlas, loob mõne docker-compose failid andmebaasidega ja midagi ei püsi. Samal ajal kinnitavad arendajad uhkusega, et Docker on lahe, kõik töötab nende jaoks kohapeal ja HR kirjutab vakantsusse: "Kasutame Dockerit ja vajame sellise töökogemusega kandidaati."
• Mind kummitavad pidevalt mõtted Dockeris kõike tõsta: postgresql, kafka, redis. Kahju, et kõik konteinerites ei tööta, kõike pole lihtne konfigureerida ja käivitada. Seda toetavad kolmanda osapoole arendajad, mitte müüjad ise. Ja muide, tekib kohe küsimus: müüjad ei muretse oma toodete Dockeris hooldamise pärast, miks see nii on, võib-olla nad teavad midagi?
• Alati tekib küsimus konteineriandmete püsivuse kohta. ja siis mõtled, kas ma peaksin lihtsalt ühendama hosti kataloogi või looma dokiköite või tegema andmekonteineri, mis on nüüd deprecated? Kui ühendan kataloogi, siis pean veenduma, et konteineris oleva kasutaja uid ja gid ühtivad konteineri käivitanud kasutaja ID-ga, vastasel juhul luuakse konteineri loodud failid juurõigustega. Kui ma kasutan volume siis mõnes luuakse andmed lihtsalt /usr/* ja uid ja gid saab olema sama lugu nagu esimesel juhul. Kui käivitate kolmanda osapoole komponendi, peate lugema dokumentatsiooni ja otsima vastust küsimusele: "millistesse konteinerikataloogidesse komponent faile kirjutab?"

Mulle pole alati meeldinud, et pidin Dockeriga liiga kaua nokitsema algstaadiumis: Mõtlesin välja, kuidas konteinereid käivitada, millistest piltidest käivitada, tegin Makefile, mis sisaldas pikkade Dockeri käskude varjunimesid. Ma vihkasin dokkide koostamist, sest ma ei tahtnud õppida dokkide ökosüsteemis teist tööriista. JA docker-compose up Mind häiris see, eriti kui nad seal ikka kohtusid build konstruktsioonid, mitte juba kokkupandud kujutised. Kõik, mida ma tõesti tahtsin, oli lihtsalt toode tõhusalt ja kiiresti valmistada. Kuid ma ei saanud aru, kuidas dokkerit kasutada.

Tutvustame Ansible'i

Hiljuti (kolm kuud tagasi) töötasin DevOpsi meeskonnaga, mille peaaegu kõik liikmed suhtusid Dockeri negatiivselt. Põhjustel:

• docker reeglid iptables (kuigi saate selle keelata saidil daemon.json)
• docker on lollakas ja me ei kasuta seda tootmises
• kui dokkedeemon jookseb kokku, jooksevad kõik infrastruktuuriga konteinerid kokku vastavalt
• dokkerit pole vaja
• milleks docker, kui on olemas Ansible ja virtuaalmasinad

Samal töökohal tutvusin veel ühe tööriistaga - Ansible. Ma kuulsin sellest kunagi, kuid ma ei püüdnud oma mänguraamatuid kirjutada. Ja nüüd hakkasin oma ülesandeid kirjutama ja siis muutus mu nägemus täielikult! Sest sain aru: Ansiblel on moodulid samade dokkekonteinerite, pildiehituste, võrkude jms käitamiseks ning konteinereid saab käivitada mitte ainult lokaalselt, vaid ka kaugserverites! Minu rõõmul polnud piire – leidsin NORMAALSE tööriista ja viskasin ära oma Makefile'i ja dockeri koostamise failid, need asendati yamli ülesannetega. Koodi vähendati, kasutades selliseid konstruktsioone nagu loop, whenJne

Docker kolmandate osapoolte komponentide, näiteks andmebaaside käitamiseks

Hiljuti sain tuttavaks ssh tunnelitega. Selgus, et kaugserveri porti on väga lihtne “edasida” kohalikku porti. Kaugserver võib olla kas pilves olev masin või VirtualBoxis töötav virtuaalmasin. Kui mu kolleeg või mina vajame andmebaasi (või mõnda muud kolmanda osapoole komponenti), saame serveri selle komponendiga lihtsalt käivitada ja selle välja lülitada, kui serverit pole vaja. Pordi edastamine annab sama efekti kui dokkimiskonteineris töötav andmebaas.

See käsk edastab mu kohaliku pordi kaugserverisse, kus töötab postgresql:

ssh -L 9000:localhost:5432 kasutaja@näide.com

Kaugserveri kasutamine lahendab meeskonna arendamise probleemi. Sellist serverit saavad korraga kasutada mitu arendajat, nad ei pea oskama postgresqli konfigureerida, Dockerist ja muudest keerukustest aru saama. Kaugserveris saate sama andmebaasi installida ka Dockerisse, kui konkreetse versiooni installimine on keeruline. Kõik, mida arendajad vajavad, on ssh-juurdepääs!

Hiljuti lugesin, et SSH tunnelid on tavalise VPN-i piiratud funktsionaalsusega! Saate lihtsalt seadistada OpenVPN või muud VPN-i rakendused, seadistage infrastruktuur ja tehke see arendajatele kättesaadavaks. See on nii lahe!

Õnneks pakuvad AWS, GoogleCloud ja teised teile aasta aega tasuta kasutamist, seega kasutage neid! Need on odavad, kui lülitate need välja, kui neid ei kasutata. Olen alati mõelnud, miks mul on vaja kaugserverit nagu gcloud, tundub, et leidsin need.

Kohaliku virtuaalmasinana saate kasutada sedasama Alpine'i, mida kasutatakse aktiivselt dokkimiskonteinerites. Noh, või mõni muu kerge jaotus, et masin kiiremini käivitada.

Alumine rida: saate ja peaksite kaugserverites või virtualboxis andmebaase ja muid infrastruktuuri hüvesid käivitama. Ma ei vaja nendel eesmärkidel dokkerit.

Veidi dockeri piltidest ja levitamisest

Ma juba kirjutasin artiklit millega tahtsin öelda, et dockeri piltide kasutamine ei anna mingit garantiid. Dockeri pilte on vaja ainult dokkimiskonteineri loomiseks. Kui täiendate dokkeri kujutist, siis täiendate dokkeri konteinereid ja kasutate ainult neid.

Kas olete näinud kuskil, kus tarkvaraarendajad portivad oma tooteid ainult dokkimispildina?
Enamiku toodete tulemuseks on binaarfailid konkreetse platvormi jaoks, need lisatakse lihtsalt dockeri kujutisele, mis päritakse soovitud platvormilt. Kas olete kunagi mõelnud, miks on dockerhubis nii palju sarnaseid pilte? Sisestage näiteks nginx, näete 100500 XNUMX pilti erinevatelt inimestelt. Need inimesed ei arendanud nginxi ise, nad lihtsalt lisasid ametliku nginxi oma dokipildile ja maitsestasid seda konteinerite käivitamise mugavuse huvides oma konfiguratsioonidega.

Üldiselt saab selle lihtsalt tgz-s salvestada, kui kellelgi on vaja seda dockeris käivitada, siis las ta lisab tgz Dockerfile'i, pärib soovitud keskkonnast ja loob täiendavaid hunnikuid, mis ei muuda rakendust ennast tgz-is. Igaüks, kes loob dockeri kujutise, teab, mis on tgz ja mida ta tööks vajab. Nii kasutan ma dokkerit siin

Alumine rida: ma ei vaja dockeri registrit, ma kasutan mingit S3 või lihtsalt failisalvestust, näiteks google drive/dropbox

Docker CI-s

Kõik ettevõtted, kus olen töötanud, on sarnased. Tavaliselt on need toidupoed. See tähendab, et neil on üks rakendus, üks tehnoloogiapakk (noh, võib-olla paar või kolm programmeerimiskeelt).

Need ettevõtted kasutavad dokkerit oma serverites, kus CI-protsess töötab. Küsimus: Miks peate oma serverites projekte ehitama dokkeri konteineris? Miks mitte lihtsalt ehitada keskkond ette, näiteks kirjutada Ansible playbook, mis installib serverisse, kus ehitamine toimub, vajalikud nodejs, php, jdk versioonid, kopeerib ssh võtmed jne?

Nüüd saan aru, et see tulistab endale jalga, sest docker ei too oma isolatsiooniga tulu. Probleemid, millega puutusin kokku CI-ga dockeris:

• jällegi on ehitamiseks vaja dockeri kujutist. peate otsima pildi või kirjutama oma dockeri faili.
• 90%, et peate edastama mõned ssh-võtmed, salajased andmed, mida te ei soovi dockeri kujutisele kirjutada.
• konteiner luuakse ja sureb, koos sellega kaovad kõik vahemälud. järgmises järgus laaditakse kõik projektisõltuvused uuesti alla, mis on aeganõudev ja ebaefektiivne ning aeg on raha.

Arendajad ei ehita projekte dokkide konteineritesse (ma olin kunagi selline fänn, tõesti, mul on minevikus kahju xD). Javas on võimalik omada mitut versiooni ja muuta need ühe käsuga praeguseks vajalikuks. Nodejs on samamoodi, seal on nvm.

Väljund

Usun, et docker on väga võimas ja paindlik tööriist, see on selle puudus (kõlab kummaliselt, jah). Selle abiga saavad ettevõtted selle kergesti konksu külge ja kasutavad seda seal, kus vaja ja mitte. Arendajad käivitavad oma konteinerid, mõned keskkonnad, seejärel liigub see kõik sujuvalt CI-sse ja tootmisse. DevOpsi meeskond kirjutab nende konteinerite käitamiseks mingit koodi.

Kasutage dokkerit ainult sees kõige hiljutisem töövoo etapis, ärge lohistage seda projekti alguses. See ei lahenda teie äriprobleeme. Ta viib probleemid vaid TEISELE tasemele ja pakub omapoolseid lahendusi, sina teed topelttööd.

Kui dokkerit on vaja: Jõudsin järeldusele, et docker oskab väga hästi antud protsessi optimeerida, aga mitte põhifunktsionaalsust üles ehitada

Kui otsustate ikkagi dokkerit kasutada, tehke järgmist.

• ole äärmiselt ettevaatlik
• ärge sundige arendajaid dokkerit kasutama
• lokaliseerige selle kasutamine ühes kohas, ärge levitage seda kõigis Dockfile'i ja dockeri koostamise hoidlates

PS:

• Sattusin hiljuti kokku pakendaja ja nad ütlevad, et see töötab Ansiblega väga hästi ja võimaldab teil piltide (sealhulgas dokkimispildi) loomise protsessi ühtlustada.
• ka dokkerist, huvitav artikkel

Täname lugemise eest, soovin teile läbipaistvaid otsuseid oma asjades ja tulemuslikke tööpäevi!

Allikas: www.habr.com