Onko Docker lelu vai ei? Vai onko se edelleen totta?

Hei kaikille!

Haluan todella päästä suoraan aiheeseen, mutta olisi oikeampaa kertoa hieman tarinastani:

Merkintä

Olen ohjelmoija, jolla on kokemusta yksisivuisten frontend-sovellusten, scala/javan ja nodejien kehittämisestä palvelimella.

Olin melko pitkään (varmasti pari-kolme vuotta) sitä mieltä, että Docker on taivaan manna ja yleisesti ottaen erittäin siisti työkalu ja ehdottomasti jokaisen kehittäjän pitäisi pystyä käyttämään sitä. Ja tästä seuraa, että jokaisella kehittäjällä pitäisi olla Docker asennettuna paikalliselle koneelleen. Entä minun mielipiteeni, katso läpi avoimet työpaikat, jotka on julkaistu samassa hh: ssä. Joka toinen sisältää maininnan dockerista, ja jos omistat sen, tämä on kilpailuetusi 😉

Matkallani tapasin monia ihmisiä, joilla oli erilaisia ​​asenteita Dockeria ja sen ekosysteemiä kohtaan. Jotkut sanoivat, että tämä on kätevä asia, joka takaa eri alustojen toimivuuden. Toiset eivät ymmärtäneet, miksi heidän pitäisi ajaa konteissa ja mitä hyötyä siitä tulisi, kolmas ei välittänyt ollenkaan eivätkä vaivautunut (he vain kirjoitti koodin ja lähti kotiin - kadehdin heitä, tapa :)

Syitä käyttöön

Miksi käytin dockeria? Luultavasti seuraavista syistä:

• tietokannan käynnistäminen, 99 % sovelluksista käyttää niitä
• nginx:n käynnistäminen käyttöliittymän jakeluun ja välityspalvelinta taustajärjestelmään
• voit pakata sovelluksen docker-kuvaan, näin sovellukseni toimii missä tahansa dockeri on olemassa, jakeluongelma ratkeaa välittömästi
• Palvelun löytäminen heti valmiina, voit luoda mikropalveluita, jokainen kontti (yhteiseen verkkoon yhdistetty) pääsee helposti toiseen aliaksen kautta, erittäin kätevä
• On hauskaa luoda kontti ja "leikkiä" siinä.

Mistä en aina pidä dockerissa:

• Jotta sovellukseni toimisi, tarvitsen itse Dockerin palvelimelle. Miksi tarvitsen tätä, jos sovellukseni toimivat jre- tai nodejs-alustalla ja niiden ympäristö on jo palvelimella?
• jos haluan ajaa (yksityistä) paikallisesti rakennettua kuvani etäpalvelimella, tarvitsen oman telakointivaraston, tarvitsen rekisterin toimivan jossain ja minun on myös määritettävä https, koska docker cli toimii vain https:n yli. Voi hitto... on tietysti vaihtoehtoja tallentaa kuva paikallisesti kautta docker save ja lähetä kuva scp:n kautta... Mutta se on paljon kehon liikkeitä. Ja lisäksi se näyttää "sauva" ratkaisulta, kunnes oma arkistosi ilmestyy
• docker-compose. Sitä tarvitaan vain konttien käyttämiseen. Siinä kaikki. Hän ei voi tehdä muuta. Docker-compose on joukko versioita tiedostoistaan, oma syntaksi. Huolimatta siitä, kuinka julki se on, en halua lukea heidän asiakirjojaan. En tarvitse sitä missään muualla.
• työskennellessään ryhmässä useimmat ihmiset kirjoittavat Docker-tiedoston hyvin vinosti, eivät ymmärrä kuinka se tallennetaan välimuistiin, lisäävät kuvaan kaiken tarvitsemansa ja tarpeettomat, perivät kuvista, jotka eivät ole Dockerhubissa tai yksityisessä arkistossa, luovat joitain docker-compose tiedostot tietokannoilla ja mitään ei tapahdu. Samalla kehittäjät vakuuttavat ylpeänä, että Docker on siisti, kaikki toimii heidän kohdallaan paikallisesti, ja HR kirjoittaa avoimeen paikkaan: "Käytämme Dockeria ja tarvitsemme ehdokkaan, jolla on tällainen työkokemus."
• Minua ahdistaa jatkuvasti ajatukset kaiken nostamisesta Dockerissa: postgresql, kafka, redis. Harmi, että kaikki ei toimi konteissa, kaikkea ei ole helppo määrittää ja suorittaa. Tätä tukevat kolmannen osapuolen kehittäjät, eivät itse toimittajat. Ja muuten, heti herää kysymys: myyjät eivät välitä tuotteidensa ylläpidosta Dockerissa, miksi näin, ehkä he tietävät jotain?
• Aina herää kysymys konttitietojen pysyvyydestä. ja sitten mietit, pitäisikö minun vain liittää isäntähakemisto vai luoda telakointiasema tai tehdä tietosäiliö, joka on nyt deprecated? Jos liitän hakemiston, minun on varmistettava, että säilön käyttäjän uid ja gid vastaavat säilön käynnistäneen käyttäjän tunnusta, muuten säilön luomat tiedostot luodaan pääkäyttäjän oikeuksin. Jos käytän volume silloin tiedot yksinkertaisesti luodaan joissakin /usr/* ja uid:n ja gid:n kanssa tulee olemaan sama tarina kuin ensimmäisessä tapauksessa. Jos käynnistät kolmannen osapuolen komponentin, sinun on luettava dokumentaatio ja etsittävä vastaus kysymykseen: "Mihin säilöhakemistoihin komponentti kirjoittaa tiedostoja?"

En aina pitänyt siitä, että minun piti puuhailla Dockerin kanssa liian kauan alkuvaiheessa: Selvitin kuinka käynnistää kontit, mistä kuvista käynnistän, tein Makefilejä, jotka sisälsivät aliaksia pitkille Docker-komentoille. Vihasin docker-säveltämistä, koska en halunnut oppia toista työkalua telakointiekosysteemissä. JA docker-compose up Se häiritsi minua, varsinkin jos he tapasivat vielä siellä build rakenteita jo koottujen kuvien sijaan. Halusin vain tehdä tuotteen tehokkaasti ja nopeasti. Mutta en ymmärtänyt, miten dockeria käytetään.

Esittelyssä Ansible

Äskettäin (kolme kuukautta sitten) työskentelin DevOps-tiimin kanssa, jonka melkein jokaisella jäsenellä oli negatiivinen asenne Dockeria kohtaan. Syistä:

• Docker hallitsee iptablesia (vaikka voit poistaa sen käytöstä tiedostossa daemon.json)
• docker on buginen, emmekä käytä sitä tuotannossa
• jos telakka-daemon kaatuu, kaikki säiliöt, joissa on infrastruktuuri, kaatuvat vastaavasti
• ei tarvita telakkaa
• miksi Docker, jos on Ansible ja virtuaalikoneita

Samassa työssä tutustuin toiseen työkaluun - Ansible. Kuulin siitä kerran, mutta en yrittänyt kirjoittaa omia leikkikirjojani. Ja nyt aloin kirjoittaa tehtäviäni ja sitten visioni muuttui täysin! Koska tajusin: Ansiblessa on moduuleja samojen telakointikonttien, kuvakoonnusten, verkkojen jne. ajamiseen, ja kontteja voidaan ajaa paitsi paikallisesti myös etäpalvelimilla! Iloni ei tuntenut rajoja - löysin NORMAALItyökalun ja heitin pois Makefile- ja Docker-Compose-tiedostot, ne korvattiin yaml-tehtävillä. Koodia pienennettiin käyttämällä rakenteita, kuten loop, when, Jne

Docker kolmannen osapuolen komponenttien, kuten tietokantojen, käyttämiseen

Tutustuin äskettäin ssh-tunneleihin. Kävi ilmi, että etäpalvelimen portin "välittäminen" paikalliseen porttiin on erittäin helppoa. Etäpalvelin voi olla joko pilvessä oleva kone tai VirtualBoxissa toimiva virtuaalikone. Jos kollegani tai minä tarvitsemme tietokannan (tai jonkin muun kolmannen osapuolen komponentin), voimme yksinkertaisesti käynnistää palvelimen tällä komponentilla ja sammuttaa sen, kun palvelinta ei tarvita. Portin edelleenlähetys antaa saman vaikutuksen kuin docker-säiliössä toimiva tietokanta.

Tämä komento välittää paikallisen portin etäpalvelimelle, jossa on postgresql:

ssh -L 9000:localhost:5432 [sähköposti suojattu]

Etäpalvelimen käyttö ratkaisee tiimin kehittämisen ongelman. Tällaista palvelinta voivat käyttää useat kehittäjät kerralla; heidän ei tarvitse pystyä konfiguroimaan postgresql-asetuksia, ymmärtämään Dockeria ja muita monimutkaisuuksia. Etäpalvelimella voit asentaa saman tietokannan itse Dockeriin, jos tietyn version asentaminen on vaikeaa. Ainoa mitä kehittäjät tarvitsevat, on tarjota ssh-käyttöoikeus!

Luin äskettäin, että SSH-tunnelit ovat tavallisen VPN:n rajoitettu toiminto! Voit yksinkertaisesti asentaa OpenVPN:n tai muita VPN-toteutuksia, määrittää infrastruktuurin ja antaa sen kehittäjien käytettäväksi. Tämä on niin siistiä!

Onneksi AWS, GoogleCloud ja muut antavat sinulle vuoden ilmaisen käytön, joten käytä niitä! Ne ovat halpoja, jos ne sammutetaan, kun niitä ei käytetä. Mietin aina, miksi tarvitsen etäpalvelimen, kuten gcloud, näyttää siltä, ​​​​että löysin ne.

Paikallisena virtuaalikoneena voit käyttää samaa Alpinea, jota käytetään aktiivisesti telakointisäiliöissä. No, tai joitain muita kevyitä jakaumia, jotta kone käynnistyy nopeammin.

Bottom line: voit ja pitäisi käyttää tietokantoja ja muita infrastruktuurin herkkuja etäpalvelimissa tai virtualboxissa. En tarvitse telakkaa näihin tarkoituksiin.

Hieman telakointikuvista ja jakelusta

Kirjoitin jo Artikkeli jossa halusin ilmaista, että Docker-kuvien käyttö ei takaa mitään. Docker-kuvia tarvitaan vain Docker-säilön luomiseen. Jos olet päivittämässä Docker-kuvaksi, päivität käyttämään Docker-säilöjä ja käytät vain niitä.

Oletko nähnyt missään, missä ohjelmistokehittäjät siirtävät tuotteensa vain telakointikuvaan?
Useimmat tuotteet ovat binääritiedostoja tietylle alustalle; ne lisätään yksinkertaisesti docker-kuvaan, joka peritään halutulta alustalta. Oletko koskaan miettinyt, miksi dockerhubissa on niin paljon samankaltaisia ​​kuvia? Kirjoita esimerkiksi nginx, näet 100500 XNUMX kuvaa eri ihmisiltä. Nämä ihmiset eivät kehittäneet itse nginxiä, he vain lisäsivät virallisen nginxin telakointikuvaansa ja maustivat sen omilla asetuksillaan konttien käynnistämisen helpottamiseksi.

Yleensä voit yksinkertaisesti tallentaa sen tgz: hen, jos jonkun on suoritettava se Dockerissa, anna heidän lisätä tgz Docker-tiedostoon, periä halutusta ympäristöstä ja luoda lisäpaketteja, jotka eivät muuta itse sovellusta tgz:ssä. Jokainen docker-kuvan luova tietää, mikä tgz on ja mitä hänen tarvitsee toimiakseen. Näin käytän dockeria täällä

Bottom line: En tarvitse Docker-rekisteriä, käytän jonkinlaista S3:a tai vain tiedostojen tallennustilaa, kuten google drive/dropbox

Docker CI:ssä

Kaikki yritykset, joissa olen työskennellyt, ovat samanlaisia. Ne ovat yleensä päivittäistavarakauppoja. Eli heillä on yksi sovellus, yksi teknologiapino (no, ehkä pari tai kolme ohjelmointikieltä).

Nämä yritykset käyttävät dockeria palvelimillaan, joissa CI-prosessi suoritetaan. Kysymys: Miksi sinun on rakennettava projekteja palvelimillasi olevaan telakointisäiliöön? Mikset vain valmistele ympäristöä rakentamiselle, esimerkiksi kirjoita Ansible playbook, joka asentaa tarvittavat versiot nodejs-, php-, jdk-, ssh-avaimet jne. palvelimelle, jossa koonti tapahtuu?

Nyt ymmärrän, että tämä ampuu itseäni jalkaan, koska telakka ei tuota voittoa eristyneisyytensä kanssa. Dockerin CI:n kanssa kohtaamani ongelmat:

• jälleen tarvitset telakointikuvan rakentamiseen. sinun täytyy etsiä kuva tai kirjoittaa oma docker-tiedosto.
• 90%, että sinun on välitettävä edelleen joitain ssh-avaimia, salaisia ​​tietoja, joita et halua kirjoittaa docker-kuvaan.
• kontti luodaan ja kuolee, kaikki välimuistit menetetään sen mukana. seuraava koontiversio lataa kaikki projektin riippuvuudet uudelleen, mikä on aikaa vievää ja tehotonta, ja aika on rahaa.

Kehittäjät eivät rakenna projekteja telakkakonteissa (olin joskus sellainen fani, todella, säälin itseäni menneisyydessä xD). Javassa on mahdollista olla useita versioita ja vaihtaa ne yhdellä komennolla nyt tarvitsemasi. Se on sama nodejsissa, siellä on nvm.

johtopäätös

Uskon, että docker on erittäin tehokas ja joustava työkalu, tämä on sen haittapuoli (kuulostaa oudolta, kyllä). Sen avulla yritykset voivat helposti jäädä siihen koukkuun ja käyttää sitä siellä, missä tarvitaan ja ei. Kehittäjät lanseeraavat konttinsa, osan ympäristöistään, minkä jälkeen kaikki siirtyy sujuvasti CI:hen ja tuotantoon. DevOps-tiimi kirjoittaa jonkinlaista koodia näiden säiliöiden suorittamiseksi.

Käytä telakointiasemaa vain päällä Viimeisin älä vedä sitä projektiin alussa. Se ei ratkaise yrityksesi ongelmia. Hän vain siirtää ongelmat TOiselle tasolle ja tarjoaa omia ratkaisujaan, sinä teet kaksinkertaista työtä.

Kun telakkaa tarvitaan: Tulin siihen tulokseen, että docker on erittäin hyvä optimoimaan annettua prosessia, mutta ei rakentamaan perustoimintoja

Jos päätät silti käyttää dockeria, niin:

• ole erittäin varovainen
• älä pakota kehittäjiä käyttämään Dockeria
• lokalisoi sen käyttö yhteen paikkaan, älä levitä sitä kaikkiin Dockefile- ja Docker-compose-tietovarastoihin

PS:

• Törmäsin äskettäin pakkaaja ja he sanovat, että se toimii erittäin hyvin Ansiblen kanssa ja mahdollistaa kuvien (mukaan lukien telakointikuvan) yhdistämisen.
• myös dockerista, mielenkiintoinen artikkeli

Kiitos kun luit, toivon sinulle läpinäkyviä päätöksiä asioissasi ja tuottavia työpäiviä!

Lähde: will.com