🥇Docker — är det en leksak eller inte? Eller är det faktiskt så?

Hej alla!

Jag vill verkligen börja med ämnet direkt, men det är bättre att först berätta lite om min historia:

Inledning

Jag är en programmerare med erfarenhet av att utveckla frontend singelsidesapplikationer, Scala/Java och Node.js på servern.

Under en ganska lång tid (definitivt ett par – tre år) har jag hållit med om att Docker är en gudagåva och överhuvudtaget ett fantastiskt verktyg som alla utvecklare bör veta hur man använder. Och därmed följer att varje utvecklare borde ha Docker installerat på sin lokala maskin. Faktum är att titta på annonserna som publiceras på samma hh. I varannan finns det nämnd Docker, och om du behärskar det är det din konkurrensfördel 😉

På min väg har jag stött på många människor, med olika attityder till Docker och hans ekosystem. Vissa sa att det är en bekväm sak som garanterar plattformsoberoende. Andra förstod inte varför de skulle köra i containrar och vilken fördel som kom med det, medan de tredje helt enkelt sket i det och bara skrev kod och gick hem – jag avundas dem förresten 🙂

Användningsanledningar

Varför använde jag Docker? Antagligen av följande skäl:

starta databaser, 99% av applikationerna använder dem
starta Nginx för att distribuera frontend och proxy till backend
jag kan paketera applikationen i en Docker-image, vilket gör att min applikation fungerar överallt där Docker finns, distributionsproblemet är redan löst
service discovery ur lådan, man kan skapa mikrotjänster, varje container (ansluten till det gemensamma nätverket) kan enkelt nå en annan via alias, väldigt praktiskt
det är roligt att skapa en container och "leka" med den.

Vad jag alltid INTE gillade med Docker:

för att få min applikation att fungera krävs själva Docker på servern. Men varför skulle jag behöva det när mina applikationer redan körs på JRE eller Node.js och miljön för dem finns redan på servern?
om jag vill köra min (privata) lokalt byggda image på en fjärrserver, behöver jag ett eget Docker-repo, jag måste ha en registry som körs någonstans och dessutom behöver jag konfigurera https, eftersom Docker CLI endast fungerar över https. Åh, fan… det finns ju alternativ, självklart, för att spara imagen lokalt och docker save och helt enkelt kopiera imagen via SCP… Men det är så många rörelser. Och det ser dessutom ut som en "hackig" lösning, tills man får sin egen repository.
docker-compose. Den behövs bara för att köra containrar. Och det är allt. Mer än så kan den inte. Docker-compose har massor av versioner av sina filer, sin egen syntax. Hur deklarativ den än är, vill jag inte läsa deras dokumentation. Jag kommer inte att behöva den någon annanstans.
när man arbetar i team skriver i de flesta fall folk Dockerfile på ett klumpigt sätt, förstår inte hur caching fungerar, lägger till allt som behövs och inte behövs i bilden, ärver från bilder som inte finns på dockerhub eller i det privata arkivet, skapar något docker-compose filer med databaser och inget delas. Samtidigt påstår utvecklarna stolt att docker är fantastiskt, att allt fungerar lokalt och HR skriver viktigt i sina annonser: "Vi använder docker och vi behöver en kandidat med sådan erfarenhet"
förföljer alltid tankar om att köra allt i docker: postgresql, kafka, redis. Tyvärr fungerar inte allt i containrar, inte allt är lätt att konfigurera och starta. Det stöds av tredjepartsutvecklare, inte av leverantörerna själva. Och förresten, uppstår genast frågan, om leverantörerna inte bryr sig om att stödja sina produkter i docker, varför gör de inte det, kanske vet de något?
uppstår alltid en fråga om persistens av containerdata. Och här tänker man, ska jag bara montera en värddirektory eller skapa ett docker-volume eller göra en data-container som nu deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volym data helt enkelt kommer att skapas i något /usr/* och den kommer att ha samma historia med uid och gid som i första fallet. Om du kör en tredjepartskomponent måste du läsa dokumentationen och leta efter svaret på frågan: "i vilka kataloger skriver komponenten filer i containern?"

Jag har alltid ogillat att man måste slösa så mycket tid på docker. i början: jag kom på hur man kör containrar, från vilka bilder man ska starta, gjorde Makefile som innehöll aliaser till långa docker-kommandon. Jag kunde inte stå ut med docker-compose, för jag ville inte lära mig ett ytterligare verktyg inom docker-ekosystemet. Och docker-compose up det oroade mig, särskilt om det också dök upp build konstruktioner istället för redan byggda bilder. Det som jag verkligen ville - var att göra produkten effektivt och snabbt. Men jag kunde inte få ordning på användningen av docker.

Bekantskap med Ansible

Nyligen (för tre månader sedan) arbetade jag med ett DevOps-team, nästan varje medlem av teamet hade en negativ inställning till docker. Av skäl:

docker påverkar iptables (även om man kan stänga av det i daemon.json)
Docker är nödvändig, men vi kommer inte att köra det i produktion.
Om Docker-daemonen kraschar, så kraschar självklart alla containrar med infrastrukturen.
Det finns ingen nödvändighet för Docker.
Varför använda Docker när det finns Ansible och virtuella maskiner?

På samma jobb stötte jag på ett annat verktyg – Ansible. Jag hade hört talas om det tidigare, men jag hade inte provat att skriva mina egna playbooks. Nu har jag börjat skriva mina uppgifter och min syn på verktyget har ändrats radikalt! För jag insåg att Ansible har moduler för att köra samma Docker-containrar, bygga bilder, nätverk med mera, och dessutom kan containrar startas inte bara lokalt utan även på fjärrservrar! Min glädje var gränslös – jag hade hittat ett RIKTIGT verktyg och kastade bort mina Makefile- och docker-compose-filer, de ersattes av yaml-uppgifter. Koden minskades tack vare användningen av konstruktioner som loop, when, etc.

Docker för att köra tredjepartskomponenter som databaser.

Nyligen lärde jag mig om SSH-tunnlar. Det visade sig vara mycket enkelt att "vidarebefordra" en port från en fjärrserver till en lokal port. Fjärrservern kan vara en maskin i molnet eller en virtuell maskin som körs i VirtualBox. Om jag eller min kollega behöver en databas (eller någon annan tredjepartskomponent), kan vi enkelt starta servern med den komponenten och stänga av den när servern inte längre behövs. Portvidarebefordran ger samma effekt som en databas som körs i en Docker-container.

Detta kommando vidarebefordrar min lokala port till en fjärrserver med PostgreSQL:

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

Att använda en fjärrserver löser problemet med utveckling i team. Flera utvecklare kan använda samma server, de behöver inte kunna konfigurera PostgreSQL, förstå sig på Docker och andra krångligheter. På fjärrservern kan man installera samma databas i Docker om det är svårt att installera en specifik version. Det enda som utvecklarna behöver är SSH-åtkomst!

Jag läste nyligen att SSH-tunnlar har begränsad funktionalitet jämfört med en vanlig VPN! Man kan enkelt ställa in OpenVPN eller andra VPN-implementeringar, konfigurera infrastrukturen och ge den till utvecklarna. Det är ju så fantastiskt!

Lyckligtvis erbjuder AWS, GoogleCloud och andra ett år av gratis användning, så använd dem! De är billiga om du stänger av dem när de inte används. Jag har alltid undrat i vilka syften jag skulle behöva en fjärrserver som gcloud, verkar som om jag har hittat det.

Som virtuell maskin på lokal körning kan man använda samma Alpine som aktivt används i dockercontainrar. Eller andra lättviktsdistributioner för att få maskinen att starta snabbare.

Slutsats: det går bra att köra databaser och andra infrastrukturella komponenter på fjärrservrar eller i virtualbox. Jag behöver inte docker för dessa ändamål.

Lite om dockerbilder och distribution

Jag har redan skrivit artikeln där jag ville förmedla att användningen av dockerbilder inte ger några garantier. Dockerbilder behövs bara för att skapa dockercontainrar. Om du förlitar dig på dockerbilder, betyder det att du förlitar dig på användning av dockercontainrar och du kommer bara att jobba med dem.

Har du sett någonstans där mjukvaruutvecklare portat sina produkter endast i dockerbilder?
Resultatet för de flesta produkter är binära filer för en specifik plattform, som bara läggs till i dockerbilden som härstammar från den plattform som behövs. Har du någonsin undrat varför det finns så många liknande bilder på dockerhub? Sök till exempel på nginx, du kommer att se 100500 bilder från olika personer. Dessa personer har inte utvecklat nginx själva, de har bara lagt till officiell nginx i sin dockerbild och anpassat den med sina egna konfigurationer för att göra starten av containrar mer bekväm.

I allmänhet kan man lagra dem i tgz, om någon behöver köra detta i docker, så kan de lägga till tgz i Dockerfile, härstamma från den nödvändiga miljön och skapa ytterligare funktioner som inte ändrar själva applikationen i tgz. Den som skapar dockerbilden kommer att veta vad detta tgz är och vad som behövs för att det ska fungera. Så här använder jag docker. ). Ett typiskt exempel på användning:

Slutsats: jag behöver ingen docker registry, jag använder någon S3 eller bara en fillagringstjänst som google drive/dropbox.

Docker i CI

Alla företag jag har arbetat på liknar varandra. De är oftast produktföretag. Det vill säga att de har en applikation, en teknikstack (kanske en eller två programmeringsspråk).

Dessa företag använder Docker på sina servrar där CI-processen körs. Frågan är — varför behöva bygga projekt i en Docker-container på sina servrar? Varför inte bara förbereda en miljö för bygget, till exempel skriva en Ansible-playbook som installerar de versioner av Node.js, PHP, JDK som behövs och kopierar SSH-nycklar osv. till servern där bygget ska ske?

Nu förstår jag att detta är att skjuta sig själv i foten, eftersom Docker inte ger något värde med sin isolation. Problema med CI i Docker som jag har stött på:

återigen behövs en Docker-avbildning för bygget. Man måste leta rätt på en avbildning eller skriva sin egen Dockerfile.
90 % av tiden måste man vidarebefordra någon slags SSH-nycklar, hemliga data som man inte vill skriva i Docker-avbildningen.
Containern skapas och dör, alla cachar går förlorade tillsammans med den. Nästa byggprocess kommer att ladda ner alla projektberoenden igen, och det tar lång tid och är ineffektivt, och tid är pengar.

Utvecklare bygger inte projekt i Docker-containrar (jag var en gång en sådan fanatiker, synd om mitt tidigare jag xD). I Java finns möjligheten att ha flera versioner och byta med ett kommando till den som behövs just nu. I Node.js är det samma, där finns NVM.

Utdata

Jag anser att Docker är ett mycket kraftfullt och flexibelt verktyg, och det är just detta som är en nackdel (låter konstigt, eller hur?). Med det blir företag lätt ”beroende” av det, de använder det där det behövs och inte behövs. Utvecklare startar sina containrar, en egen miljö, och sedan övergår allt mjukt till CI och produktion. DevOps-teamet skriver något slags cykel för att köra dessa containrar.

Använd Docker endast i det absolut senaste steget i din arbetsprocess, dra inte in det i projektet i början. Det kommer inte att lösa dina affärsproblem. Det kommer endast att skjuta problemen till en ANNAN nivå och erbjuda sina lösningar, och du kommer att göra dubbelt arbete.

När Docker är behövligt: jag har kommit fram till att Docker är väldigt bra för att optimera den etablerade processen men inte för att bygga grundläggande funktionalitet.

Om du ändå har beslutat att använda Docker, så:

var extremt försiktig
tvinga inte användningen av Docker på utvecklarna
lokalisera användningen till en specifik plats, sprid inte ut Dockerfile och docker-compose över alla repositorier.

PS:

Jag stötte nyligen på packer och de säger att han fungerar mycket bra med Ansible och gör det möjligt att standardisera processen för att bygga bilder (inklusive docker image)
också om docker, intressant artikel

Tack för att du läste, jag önskar dig transparenta lösningar i dina affärer och produktiva arbetsdagar!

Källa: habr.com