🥇Docker — kas see on mänguasi või mitte? Või ikkagi jah?

Tere kõigile!

Tahaks ma kohe teemast alustada, kuid oleks parem rääkida natuke oma ajaloost:

Sissejuhatus

Ma olen arendaja, kellel on kogemusi frontend ühe lehe rakenduste, scala/java ja nodejs arendamisel serveris.

Pikka aega (kindlasti paar-kolm aastat) hoidsin ma arvamust, et docker on taevane kingitus ja tõeliselt äge tööriist ning iga arendaja peaks oskama sellega töötada. Seega on igal arendajal ka docker oma kohalikul masinal olemas. Mis seal salata, kui vaadata töökuulutusi, mis on postitatud näiteks hh. Igas teises on mainitud dockerit ja kui sul on sellest teadlikkus — on see sinu konkurentsieelis 😉

Oma teekonna jooksul olen kohtunud paljude inimestega, kelle suhtumine dockerisse ja selle ökosüsteemi on olnud erinev. Ühed ütlesid, et see on mugav asi, mis tagab platvormide ühilduvuse. Teised ei saanud aru, miks nad peaksid konteinerites käivitama ja mis kasu sellest on, kolmandatele ei olnud see üldse oluline ja nad ei muretsenud (lihtsalt kirjutasid koodi ja läksid koju — kadedan neid, muide 🙂)

Kasutamise põhjused

Miks ma dockerit kasutasin? Ilmselt järgmiste põhjuste tõttu:

andmebaasi käivitamiseks, 99% rakendustest kasutavad neid
nginx'i käivitamiseks frontend'i jagamiseks ja backend'i proxy'ks
rakendust saab pakendada docker'i pildiks, seega töötab mu rakendus igal pool, kus on docker, ja jaotamise probleem on kohe lahendatud
teenuste avastamine pakub kohe, saab teha mikroteenuseid, iga konteiner (ühendatud ühisse võrku) saab hõlpsasti teisele ligi minna alias'e kaudu, see on väga mugav
äge on luua konteiner ja selles "mängida".

Mis mulle on alati DOHINUD dockeris:

kui mu rakendus töötab, on serveris ikka docker vajalik. Ja miks mul seda tarvis on, kui mu rakendused töötavad jre või nodejs peal ja keskkond nende jaoks on serveris juba olemas?
kui ma tahan käivitada oma (privaatset) kohalikult kokku pandud pilti eemaldatud serveris, siis vajab ma oma docker'i registrit, kuskil peab registry töötama ja veel peab seadistama https, sest docker cli töötab ainult https. Oh, jumal… on muidugi võimalusi, kuidas pilt kohaliku peale salvestada ja docker save scp kaudu lihtsalt pildi edasi saata... Aga see on nii palju liikumist. Ja lisaks tundub see "karkassiga" lahendusena, kuni oma registri olemasolu.
version: '1' services: simplesample-sonar: image: sonarqube:lts ports: - 9001:9000 - 9092:9092 network_mode: bridgeSee on vajalik ainult konteinerite käivitamiseks. Ja kõik. Rohkem ta ei suuda. Docker-compose omab palju oma failide versioone, oma süntaksit. Kui deklareeriv ta ka pole, ei taha ma nende dokumentatsiooni lugeda. See ei ole mulle kuskil mujal vajalik.
meeskonnas töötades kirjutavad enamus inimesi Dockerfile'i väga valesti, ei mõista, kuidas see vahemälu töötab, lisavad pildile kõike, mis vajalik ja mittevajalik, pärivad pildilt, mida ei ole dockerhub'is või privaatsetes registrites, loovad mingisuguseid version: '1' services: simplesample-sonar: image: sonarqube:lts ports: - 9001:9000 - 9092:9092 network_mode: bridge andmebaasifaile ja ei püsita midagi. Samal ajal ütlevad arendajad uhkelt, et docker on lahe, neil töötab kõik kohapeal ja HR kirjutab oma kuulutustes: "Kasutame dockerit ja me vajame kandidaati, kellel on selline töökogemus"
mõtted dolooride tõstmisest dockerisse pidevalt kummitavad: postgresql, kafka, redis. Kahju, et mitte kõik ei tööta konteinerites, mitte kõiki on lihtne konfigureerida ja käivitada. Toetavad seda kolmandate osapoolte arendajad, mitte tootjad ise. Ja muide, tekib kohe küsimus, miks tootjad ei pea vajalikuks oma tooteid dockeris hooldada, võib-olla nad teavad midagi?
tekib pidevalt küsimus konteineri andmete püsivuse kohta. Ja siis mõtled, kas peaks lihtsalt hostikausta mountima või loodud docker volume'i või tegema data containeri, mis nüüd deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume andmed luuakse lihtsalt kuhugi /usr/* ja sama lugu uid ja gid-ga nagu esimesel juhul. Kui käivitad kolmanda osapoole komponendi, siis on vaja dokumentatsiooni lugeda ja otsida vastust küsimusele: "Millistesse konteineri kaustadesse komponent faile kirjutab?"

Mulle on alati häirinud, et tuleb dockeriga liiga kaua vaeva näha alguses: mõtlesin, kuidas käivitada konteinerit, millistest piltidest alustada, tegin Makefile'e, mis sisaldas aliaseid pikkadele docker käskudele. Ei suutnud docker-compose'i taluda, sest ei soovinud õppida veel ühte docker ökosüsteemi tööriista. Ja docker-compose up mind häiris see, eriti kui seal olid veel build struktuurid, mitte juba kokku pandud pildid. Kõike, mida ma tegelikult tahtsin, oli lihtsalt toote tõhus ja kiire valmistamine. Kuid ma ei suutnud kuidagi dockerit õigesti kasutada.

Tutvumine Ansible'iga

Hiljuti (kolm kuud tagasi) töötasin DevOps meeskonnas, kelle iga liige suhtus dockerisse negatiivselt. Põhjustel:

docker haldab iptables (kuigi seda saab välja lülitada daemon.json'is)
docker on katsetamiseks ja tootmises me seda ei jooksuta
kui docker daemon kukub, siis kukuvad ka kõik infrastruktuuri konteinerid
dockerit pole vajagi
miks docker, kui on olemas Ansible ja virtuaalmasinad

Samas kohas kohtusin veel ühe tööriistaga — Ansible. Kunagi olin kuulnud sellest, kuid ei olnud proovinud oma mänguplaanide kirjutamist. Nüüd olen hakkanud oma ülesandeid kirjutama ja minu nägemus on täielikult muutunud! Sest ma taipasin, et Ansible'il on moodulid nende samade docker konteinerite käivitamiseks, piltide kogumiseks, võrkudeks jne., ja konteinerid saab käivitada mitte ainult kohapeal, vaid ka eemalserverites! Minu rõõm ei olnud piiritletud — leidsin NORMAALSE tööriista ja viskasin oma Makefile ja docker-compose failid minema, need on asendatud yaml ülesannetega. Kood vähenes konstruktsioonide kasutamise tõttu, nagu loop, jne. Mida rohkem te Ansible'i tunnete, seda rohkem nüansse saate öelda "kavalate" lahenduste kohta. Ja lihtne lahendus — loomulik jaotus pre/roles/post vahel — ei tekita nüansse., jne.

Docker välistingimustes komponentide nagu andmebaasi käivitamiseks

Hiljuti tutvustasin ssh tunnelitega. Selgus, et on väga lihtne „edastada“ kaugserveri port kohalikku porti. Kaugserver võib olla nii pilvemasin kui ka virtuaalmasin, mis on käivitatud VirtualBoxis. Kui mulle või mu kolleegile on vajalik andmebaas (või mõni muu välistingimustes komponent), saame lihtsalt käivitada serveri, kus see komponent on ja sulgeda, kui serverit enam ei vajata. Portide edastamine annab sama efekti kui andmebaas, mis töötab docker konteineris.

See käsk edastab minu kohaliku porte kaugserverisse, kus on postgresql:

ssh -L 9000:localhost:5432 user@example.com

Kaugserveri kasutamine lahendab meeskonna arendamise probleemi. Sellist serverit saavad kasutada mitmed arendajad korraga, neil ei ole vaja osata postgresql'i seadistada, dockeriga tegeleda ja muude keerukustega. Kaugserveris saab paigaldada sama andmebaasi dockerisse, kui spetsiifilise versiooni paigaldamine on raske. Kõik, mida arendajad vajavad — on anda ssh juurdepääs!

Hiljuti lugesin, et SSH tunnelid on tavalise VPN-i piiratud funktsionaalsus! Võid lihtsalt seadistada OpenVPN või teised VPN-ide rakendused, seadistada infrastruktuuri ja anda selle arendajatele kasutamiseks. See on ju nii lahe!

Hea, AWS, GoogleCloud ja teised pakuvad aastat tasuta kasutamist, seega kasutage neid! Need on odavad, kui neid mitte kasutada. Olen alati mõelnud, milleks mul kaugarvuti nagu gcloud võiks vaja minna, ja mulle tundub, et olen selle leidnud.

Virtuaalmasinana võib kasutada sama Alpine'i, mida aktiivselt kasutatakse docker konteinerites. Või mõnda muud kerget distributsiooni, et masin kiiremini käivituks.

Kokkuvõte: andmebaase ja teisi infrastruktuuri vidinaid saab ja tuleb käitada kaugarvutites või virtualboxis. Mul pole nende vajaduste jaoks dockerit vaja.

Veidi docker piltidest ja jaotamisest.

Olen juba kirjutanud. artiklit millest tahtsin edastada, et docker piltide kasutamine ei anna mingeid garantiisid. Docker pildid on vajalikud ainult docker konteineri loomiseks. Kui te kasutate docker pilti, siis tähendab see, et kasutate docker konteinereid ja te jääte ainult nendega.

Kas olete kuskil näinud, et tarkvara arendajad portivad oma tooteid ainult docker pildis?
Enamiku toodete tulemus on binaarfailid teatud platvormi jaoks, need lihtsalt lisatakse docker pilti, mis pärineb vajalikult platvormilt. Kas te ei ole mõelnud, miks dockerhubis on nii palju sarnaseid pilte? Otsige näiteks nginx, näete 100500 pilti erinevatelt inimestelt. Need inimesed ei ole ise nginx'i arendanud, vaid nad on lihtsalt oma docker pilti lisanud ametliku nginx'i ja kaunistanud oma seadistustega konteinerite mugavaks käivitamiseks.

Tegelikult võib hoida lihtsalt tgz, kui kellelgi on vaja seda dockeris käivitada, siis laske Dockerfile'is lisada tgz, pärineda vajalikust keskkonnast ja luua täiendavaid vidinaid, mis ei muuda tgz ise. See, kes loob docker pilti, teab, mis see tgz on ja mida tal tööks vaja on. Just nii kasutan mina dockerit. siit

Kokkuvõte: mul pole vaja docker registrit, kasutan mõnda S3 või lihtsalt failide salvestust nagu google drive/dropbox.

Docker CI-s.

Kõik firmad, kus olen töötanud, on üksteisega sarnased. Need on tavaliselt toote põhised. Neil on tavaliselt üks rakendus, üks tehnoloogiatehnika (noh, võib-olla paar – kolm programmeerimiskeelt).

Need on ettevõtted, mis kasutavad dockerit oma serverites, kus käivitub CI-protsess. Küsimus on, miks on vaja projekte koguda docker konteineris oma serverites? Miks mitte lihtsalt ette valmistada keskkond kogumiseks, näiteks kirjutada Ansible'i mängu, mis installib vajalikud versioonid nodejs, php, jdk, kopeerib ssh võtmed jne serverisse, milles kogumine toimub?

Praegu mõistan, et see on endale jalgu tulistamine, kuna docker ei too oma isoleerimisega mingeid eeliseid. CI probleemid dockeris, millega ma kokku puutusin:

uuesti on vajalik docker pilt kogumiseks. tuleb otsida pilti või kirjutada oma dockerfile.
90% tõenäosus, et tuleb edastada mingeid ssh võtmeid, salajasi andmeid, mida ei taha docker pildis kirjutada.
konteiner luuakse ja sureb, kõik vahemälud kaovad koos sellega. Järgmine kogumine peab kõik projekti sõltuvused uuesti alla laadima, mis on aeglane ja ebatõhus, ning aeg — see on raha.

Arendajad ei kogu projekte docker konteinerites (ma olin kunagi selline fänn, kahju endast minevikus xD). Java-s on võimalus omada mitu versiooni ja muuta neid ühe käsu abil vastavaks, mis on praegu vajalik. Nodejs-is on sama, on nvm.

Kokkuvõte

Arvan, et docker on väga võimas ja paindlik tööriist, kuid see on tema puudus (kõlab kummaliselt, jah). Selle abil on ettevõtetel lihtne "kinni jääda", kasutada seda seal, kus vaja ja kus mitte. Arendajad käivitavad oma konteinerid, oma keskkonna, ja see kõik voolab sujuvalt CI-sse, tootmisse. DevOps'i meeskond kirjutab mingeid jalgrattaid nende konteinerite käivitamiseks.

Kasutage dockerit ainult kõige viimasel sammul oma tööprotsessis, ärge tooge seda projekti algusesse. See ei lahenda teie äriprobleeme. See lihtsalt nihutab probleeme TEISELE tasemele ja pakub enda lahendusi, teete topelt tööd.

Kui on vajalik docker: jõudsin arusaamisele, et docker on väga hea olemasoleva protsessi optimeerimisel, kuid mitte põhifunktsiooni ehitamisel.

Kui te siiski otsustate dockeri kasutada, siis:

olge äärmiselt ettevaatlikud
ärge suruge dockeri kasutamist arendajatele peale
localiseerige selle kasutamine ühes kohas, ärge levitage seda üle kõikide hoidlate Dockefile ja docker-compose

PS:

Hiljuti leidsin packer ja räägivad, et ta töötab Ansible'iga väga hästi ja võimaldab standardiseerida piltide loomise protsessi (sealhulgas docker image'i).
ka dockerist, huvitav artikkel.

Aitäh, et lugesite, soovin teile läbipaistvaid lahendusi teie asjades ja produktiivseid tööpäevi!

Allikas: habr.com