🥇Kas Docker on mänguasi või mitte? Või siiski on?

Tere kõigile!

Tahan kohe teemaga alustada, aga parem on rääkida veidi oma lugu:

Sissejuhatus

Olen arendaja, kellel on kogemusi frontend ühekordsete rakenduste, Scala/Java ja Node.js serveriarendusega.

Pikka aega (ilmselt juba paar-kolm aastat) arvasin, et Docker on tõeline kingitus ja väga äge tööriist, millega iga arendaja peaks oskama töötada. Seega järeldub, et igaühel peaks olema Docker oma kohalikus arvutis. Mida enam rääkida minu arvamusest, vaadake lihtsalt tööpakkumisi, mis on üles pandud samaaegselt (hh). Igas teises on mainitud Dockerit ja kui te oskate seda kasutada — see annab teile konkurentsieelise 😉

Olen kohtunud paljude inimestega, kelle suhtumine Dockerisse ja selle ökosüsteemi on erinev. Ühed ütlevad, et see on mugav asi, mis tagab ristplatvormi. Teised ei mõista, miks peaks nad konteinerites töötama ja milline on sellest kasu, kolmandatele on see täielikult ükskõik ja nad ei muretse (lihtsalt kirjutavad koodi ja lähevad koju — kardan neid isegi 🙂)

Kasutamise põhjused

Miks ma dockerit kasutasin? Ilmselt järgmistel põhjustel:

andmebaasi käivitamiseks, 99% rakendustest kasutavad neid
nginx'i käivitamine frontendi jagamiseks ja backend'i proksimiseks
rakenduse saab pakkida docker'i pildiks, nii et minu rakendus töötab igal pool, kus on docker, ja levitamise probleem on kohe lahendatud
teenuse leidmine on sisseehitatud, saab teha mikroteenuseid, iga konteiner (ühendatud ühise võrku) saab teise juurde ligi alias'ega, väga mugav
äge on konteiner luua ja sellega 'mängida'.

Mida ma dockeris alati EI meeldinud:

et minu rakenduse töötamiseks on serveris vaja dockerit. Aga miks mulle see vajalik on, kui mu rakendused töötavad jre või nodejs peal ja need keskkonnad on serveris juba olemas?
kui ma tahan käivitada oma (privaatset) kohapeal koostatud pilti kaugarvutis, siis mul on vaja oma docker'i registrit, registry peab kuskil töötama ja veel tuleb seada https, sest docker cli töötab ainult https-i peal. Oh jama… muidugi on variandid, kuidas pilti kohalikult salvestada läbi docker save ja lihtsalt visata pilt scp kaudu… Aga see on nii palju liigutusi. Ja see näeb ka «kõrgelt» lahendusena välja, kuni oma hoidla olemas on.
docker-composeSee on vajalik ainult konteinerite käivitamiseks. Ja kõik. Rohkem ta midagi ei oska. Docker-compose omab palju versioone oma faile, oma süntaksit. Ükskõik kui deklareeriv ta olema on, ei taha ma nende dokumentatsiooni lugeda. See ei tule mulle enam kuskil kasuks.
meeskonnas töötades kirjutavad enamik inimesi Dockerfile väga kehvasti, ei mõista, kuidas see vahemälus töötab, lisavad piltidesse kõik, mis on vajalik ja mis mitte, pärivad piltidelt, mida pole dockerhubis või privaatsetes hoidlates, loovad mingisuguseid docker-compose failidega andmebaase ja ei midagi ei persisteeri. Samal ajal tugevate väljatöötajate nõudmised, et docker on äge, neil kõik töötab lokaalselt, ja HR märkis olulistes kuulutustes: «Kasutame dockerit ja vajame kandidaati, kellel on selline töökogemus.»
siiski kummitavad mõtted dockerisse kõiki asju ja kõike tõsta: postgresql, kafka, redis. Kahju, et kõik ei tööta konteinerites, mitte kõik pole lihtsad konfigureerida ja käivitada. Seda toetavad kolmandad osalised, mitte tootjad ise. Ja muide, tekib kohe küsimus, kui tootjad ei muretse oma toodete toetamise pärast dockeris, siis miks need seda ei tee? Kas nad teavad midagi, mida meie ei tea?
kordub küsimus konteineri andmete püsivusest. Ja siin mõtled, kas mountida hosti kataloog või luua docker volume või teha data container, mis nüüd deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume siis jäävad andmed lihtsalt mõnesse /usr/* ja uid ja gid on sama lugu nagu esimeses olukorras. Kui käivitad kolmanda osapoole komponendi, siis pead süvenema dokumentatsiooni ja otsima vastust küsimusele: "millistes konteineri kataloogides komponent faile kirjutab?"

Mulle pole kunagi meeldinud, et dockeriga tuleb liiga kaua tegeleda alguses: ma mõtlesin, kuidas konteinerid käivitada, millistelt piltidelt käivitada, tegin Makefile, mis sisaldas lühendiid pikaid docker käske. Ma ei suutnud kannatada docker-compose, kuna ma ei tahtnud õppida veel ühte tööriista docker ökosüsteemis. Ja docker-compose up mõi mind, eriti kui seal olid veel build konstruktsioonid, mitte juba kokku pandud pildid. Kõik, mida ma tegelikult tahtsin, oli lihtsalt toote efektiivne ja kiire loomine. Kuid ma ei suutnud kuidagi dockerit lahti seletada.

Tutvumine Ansible'iga

Hiljuti (kolme kuu eest) töötasin DevOps meeskonnas, mille iga liige suhtus dockerisse negatiivselt. Põhjused:

docker haldab iptables'i (kuigi seda saab daemon.json-is välja lülitada)
docker on ebastabiilne ja me ei hakka seda tootmises käivitama
kui docker daemon kukub, siis langevad kõik konteinerid koos infrastruktuuriga
dockerit pole vaja
miks docker, kui on Ansible ja virtuaalsed masinad

Samas töös kohtusin ma veel ühe tööriistaga — Ansible'iga. Olen sellest varem kuulnud, kuid ei olnud proovinud kirjutada oma mängukavasid. Nüüd olen hakanud kirjutama oma ülesandeid ja minu nägemus on muutunud! Sest ma sain aru: Ansible'il on moodulid, mis võimaldavad käivitada samu docker konteinerite, piltide, võrkude jne. Samuti saab konteinerid käivitada mitte ainult kohapeal, vaid ka eemal olevatel serveritel! Minu elevus oli piiritu — ma leidsin NORMAALSE tööriista ja viskasin oma Makefile'i ja docker-compose failid ära, need asendati yaml ülesannetega. Kood on vähenenud konstruktsioonide kasutamise tõttu, nagu loop, when, jne.

Docker kolmandate osade komponentide, nagu andmebaasi, käivitamiseks

Hiljuti tutvusin ssh tunnelitega. Selgus, et on väga lihtne 'edastada' kaugserveri port kohalikule port. Kaugserver võib olla nagu pilvemasin, nii ka virtuaalmasin, mis töötab VirtualBoxis. Kui mulle või minu kolleegile on vajalik andmebaas (või mõni muu kolmas komponent), saame lihtsalt käivitada serveri selle komponendiga ja sulgeda, kui server ei ole vajalik. Portide edastamine annab sama efekti nagu andmebaas, mis töötab docker konteineris.

See käsk suunab minu kohaliku pordi kaugserverisse, kus on postgresql:

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

Kaugserveri kasutamine lahendab arendamise meeskonnas probleemi. Sellist serverit saavad korraga kasutada mitu arendajat, nad ei pea oskama postgresql'i seadistada, Dockerist ja muudest keerukustest aru saama. Kaugserverisse saab paigaldada sama andmebaasi, kui spetsiifilist versiooni on raske seadistada. Kõik, mida arendajad vajavad, on ssh juurdepääs!

Hiljuti lugesin, et SSH tunnelid on tavalise VPN-i piiratud funktsionaalsus! Võib lihtsalt seadistada OpenVPN-i või teisi VPN-i realiseerimisi, seadistada infrastruktuuri ja anda arendajatele kasutamiseks. See on tõesti lahe!

Õnneks pakuvad AWS, GoogleCloud ja teised aasta tasuta kasutamist, kasutage neid! Need on odavad, kui neid mittetöötamise ajal kinni keerata. Olen alati mõelnud, mis eesmärkidel võiksin vajada kaugserverit nagu gcloud, tundub, et olen selle leidnud.

Virtuaalse masina jaoks kohaliku keskkonna täitmiseks võib kasutada sama Alpine'i, mida aktiivselt kasutatakse dockerite konteinerites. Või mõne teise kerge distributsiooni, et masin kiiremini üles laadida.

Kokkuvõte: andmebaaside ja muude infrastruktuuri komponentide käitamine on võimalik ja vajalik eemalserverites või virtualboxis. Dockerit ei ole mulle nende eesmärkide saavutamiseks vaja.

Veidi dockerite piltide ja jaotamisest

Olen juba kirjutanud artiklile selles, et dockerite piltide kasutamine ei anna mingit garantiid. Dockerite pildid on vajalikud ainult dockerite konteinerite loomiseks. Kui sa kasutad dockerit, tähendab see, et oled seotud dockerite konteinerite ja ainult nendega.

Kas olete kunagi näinud, et tarkvaraarendajad portiksid oma tooteid ainult dockerite pildis?
Enamiku toodete tulemus on binaarfailid konkreetse platvormi jaoks, need lisatakse lihtsalt docker-pildile, mis pärib vajaliku platvormi. Kas olete kunagi mõelnud, miks on dockerhubis nii palju sarnaseid pilte? Otsige näiteks nginx, näete 100500 pilti erinevatelt inimestelt. Need inimesed ei ole nginx'i ise loonud, nad on lihtsalt oma docker-pildile lisanud ametliku nginx'i ja kaunistanud seda oma konfigureerimistega konteinerite käivitamise mugavuseks.

Üldiselt saab salvestada lihtsalt tgz formaadis, kui keegi soovib seda dockeris käivitada, siis võib Dockerfile'i lisada tgz, pärida vajalikust keskkonnast ja luua lisafunktsioone, mis ei muuda rakendust tgz-s. See, kes loob docker-pilti, teab, mis tgz on ja mida tal tööks vaja on. Just nii kasutan mina dockeri. siin

Kokkuvõte: mul ei ole vaja docker registry't, kasutaks mõnd S3 või lihtsalt failide hoiustamise teenust nagu google drive/dropbox.

Docker CI-s

Kõik ettevõtted, kus ma olen töötanud, on omavahel sarnased. Need on enamasti tooteettevõtted. See tähendab, et neil on mingi üks rakendus, üks tehnoloogiate kogum (võib-olla paar-kolm programmeerimiskeelt).

Need hosting that puts developers first? Docker can solve many issues; here’s how it works. Why build projects in Docker containers on your servers? Why not just prepare the environment for building, like writing an Ansible playbook that installs the necessary versions of Node.js, PHP, JDK, copies SSH keys, etc., to the server where the build will occur?

I've come to realize this is self-sabotage because Docker brings no benefits through its isolation. The CI problems I've encountered with Docker include:

You still need a Docker image for the build. You have to find an image or write your own Dockerfile.
There’s a 90% chance you need to pass some SSH keys or secret data that you don’t want to write in the Docker image.
The container creates and dies, losing all caches along with it. The next build will have to download all project dependencies again, which is time-consuming and inefficient, and time is money.

Developers don't build projects in Docker containers (I used to be a fan, but I pity my past self xD). In Java, you can have multiple versions and switch with one command to the one you need now. The same applies to Node.js; there's nvm.

Kokkuvõte

Ma arvan, et Docker on väga võimas ja paindlik tööriist, mis on samas tema miinus (kõlab kummaliselt, jah). Selle abil on ettevõtetel lihtne "kinni jääda", kasutades seda seal, kus vaja ja kus ei ole. Arendajad käivitavad oma konteinerid, mingit oma keskkonda, seejärel voolab kõik sujuvalt CI-sse ja tootmisse. DevOps meeskond kirjutab mingeid rattaid, et käivitada neid konteinerid.

Kasutage Dockerit ainult viimasel etapil teie töös, ärge tooge seda projekti alguses. See ei lahenda teie äri probleeme. See lihtsalt tõukab probleemid teisele tasemele ja pakub oma lahendusi, teete topelt tööd.

Kui Docker on vajalik: jõudsin arusaamale, et Docker on väga hea töötava protsessi optimeerimises, kuid mitte põhifunktsionaalsuse loomises.

Kui te siiski otsustate Dockerit kasutada, siis:

olge äärmiselt ettevaatlikud
ärge suruge Dockerit arendajatele peale
lokaliseerige selle kasutamine ühte kohta, ärge levitage seda kõikidesse repodesse, Dockefile ja docker-compose

PS:

Hiljuti sattusin kokku packer ja räägib, et see töötab Ansible'iga väga hästi ja võimaldab ühtlustada piltide loomise protsessi (sealhulgas docker image'i)
ka dockerist, huvitav artikkel

Aitäh, et lugesite, soovin teile selgeid lahendusi teie tegemistes ja produktiivseid tööpäevi!

Allikas: habr.com