Är Docker en leksak eller inte? Eller är det fortfarande sant?

Hej alla!

Jag vill verkligen gå direkt till ämnet, men det vore mer korrekt att berätta lite om min historia:

Entry

Jag är en programmerare med erfarenhet av att utveckla frontend single page applikationer, scala/java och nodejs på servern.

Under ganska lång tid (definitivt ett par eller tre år) var jag av åsikten att Docker är manna från himlen och i allmänhet ett väldigt coolt verktyg och absolut alla utvecklare borde kunna använda det. Och av detta följer att varje utvecklare bör ha Docker installerat på sin lokala maskin. Vad sägs om min åsikt, titta igenom de lediga jobb som läggs ut på samma hh. Varannan en innehåller ett omnämnande av docker, och om du äger den kommer detta att vara din konkurrensfördel 😉

På min väg träffade jag många människor, med deras olika attityder till Docker och dess ekosystem. Vissa sa att detta är en bekväm sak som garanterar plattformsoberoende funktionalitet. De andra förstod inte varför de skulle köra i containrar och vilken vinst som skulle komma från det, den tredje brydde sig inte alls och brydde sig inte (de skrev bara koden och gick hem - jag avundas dem, av sätt :)

Anledningar till användning

Varför använde jag docker? Förmodligen av följande skäl:

• databaslansering använder 99 % av applikationerna dem
• lanserar nginx för frontend-distribution och proxy till backend
• du kan paketera applikationen i en docker-bild, på så sätt kommer min applikation att fungera varhelst docker finns, distributionsproblemet löses omedelbart
• tjänstupptäckt direkt, du kan skapa mikrotjänster, varje behållare (ansluten till ett gemensamt nätverk) kan enkelt nå en annan via ett alias, mycket bekvämt
• Det är roligt att skapa en behållare och "leka" i den.

Vad jag alltid INTE gillar med docker:

• För att min applikation ska fungera behöver jag Docker själv på servern. Varför behöver jag detta om mina applikationer körs på jre eller nodejs och miljön för dem redan finns på servern?
• om jag vill köra min (privata) lokalt byggda bild på en fjärrserver så behöver jag ett eget docker-repository, jag behöver registret att fungera någonstans och jag måste även konfigurera https, eftersom docker cli bara fungerar över https. Herregud... det finns såklart alternativ att spara bilden lokalt via docker save och skicka bara bilden via scp... Men det är många kroppsrörelser. Och dessutom ser det ut som en "krycka"-lösning tills ditt eget förråd dyker upp
• docker-compose. Det behövs bara för att köra containrar. Det är allt. Han kan inte göra något annat. Docker-compose har ett gäng versioner av sina filer, sin egen syntax. Hur deklarativt det än är så vill jag inte läsa deras dokumentation. Jag kommer inte behöva det någon annanstans.
• när de arbetar i ett team skriver de flesta en Dockerfil väldigt snett, förstår inte hur den cachelagras, lägger till allt de behöver och inte behöver till bilden, ärver från bilder som inte finns i Dockerhub eller ett privat arkiv, skapar några docker-compose filer med databaser och ingenting kvarstår. Samtidigt deklarerar utvecklarna stolt att Docker är coolt, allt fungerar lokalt för dem, och HR skriver viktigt i den lediga tjänsten: "Vi använder Docker och vi behöver en kandidat med sådan arbetserfarenhet."
• Jag hemsöks ständigt av tankar om att ta upp allt i Docker: postgresql, kafka, redis. Det är synd att allt inte fungerar i containrar, allt är inte lätt att konfigurera och köra. Detta stöds av tredjepartsutvecklare och inte av leverantörerna själva. Och förresten, frågan uppstår omedelbart: leverantörer oroar sig inte för att behålla sina produkter i Docker, varför är det så, de kanske vet något?
• Frågan uppstår alltid om behållardatas beständighet. och då tänker du, ska jag bara montera värdkatalogen eller skapa en dockningsvolym eller göra en databehållare som nu är deprecated? Om jag monterar en katalog måste jag se till att användarens uid och gid i behållaren matchar id:t för användaren som startade behållaren, annars skapas filerna som skapas av behållaren med roträttigheter. Om jag använder volume då kommer data helt enkelt att skapas i vissa /usr/* och det blir samma historia med uid och gid som i det första fallet. Om du startar en tredjepartskomponent måste du läsa dokumentationen och leta efter svaret på frågan: "i vilka behållarkataloger skriver komponenten filer?"

Jag har alltid inte gillat det faktum att jag var tvungen att mixtra med Docker för länge i det inledande skedet: Jag kom på hur man startar behållare, vilka bilder man ska starta från, gjorde Makefiler som innehöll alias till långa Docker-kommandon. Jag hatade docker-compose eftersom jag inte ville lära mig ett annat verktyg i docker-ekosystemet. OCH docker-compose up Det störde mig, speciellt om de fortfarande träffades där build konstruktioner, snarare än redan sammansatta bilder. Allt jag egentligen ville var att bara göra en produkt effektivt och snabbt. Men jag kunde inte ta reda på hur man använder docker.

Vi presenterar Ansible

Nyligen (för tre månader sedan) arbetade jag med ett DevOps-team, där nästan alla medlemmar hade en negativ inställning till Docker. För anledningar:

• docker regler iptables (även om du kan inaktivera det i daemon.json)
• docker är buggig och vi kommer inte att köra den i produktion
• om docker-demonen kraschar, kraschar alla behållare med infrastruktur i enlighet med detta
• inget behov av hamnarbetare
• varför docker om det finns Ansible och virtuella maskiner

På samma jobb blev jag bekant med ett annat verktyg - Ansible. Jag hörde talas om det en gång, men jag försökte inte skriva mina egna lekböcker. Och nu började jag skriva mina uppgifter och då förändrades min vision helt! För jag insåg: Ansible har moduler för att köra samma docker-containrar, bildbyggen, nätverk, etc., och containrar kan köras inte bara lokalt utan även på fjärrservrar! Min glädje visste inga gränser - jag hittade ett NORMALT verktyg och kastade mina Makefile- och docker-compose-filer, de ersattes med yaml-uppgifter. Koden reducerades genom att använda konstruktioner som loop, whenEtc.

Docker för att köra tredjepartskomponenter som databaser

Jag blev nyligen bekant med ssh-tunnlar. Det visade sig att det är väldigt enkelt att "vidarebefordra" porten på en fjärrserver till en lokal port. Fjärrservern kan antingen vara en maskin i molnet eller en virtuell maskin som körs i VirtualBox. Om min kollega eller jag behöver en databas (eller någon annan tredjepartskomponent) kan vi helt enkelt starta servern med denna komponent och stänga av den när servern inte behövs. Port forwarding ger samma effekt som en databas som körs i en docker-container.

Detta kommando vidarebefordrar min lokala port till en fjärrserver som kör postgresql:

ssh -L 9000:localhost:5432 [e-postskyddad]

Att använda en fjärrserver löser problemet med teamutveckling. En sådan server kan användas av flera utvecklare samtidigt, de behöver inte kunna konfigurera postgresql, förstå Docker och andra krångligheter. På en fjärrserver kan du installera samma databas i själva Docker, om det är svårt att installera en specifik version. Allt utvecklare behöver är att ge ssh-åtkomst!

Jag läste nyligen att SSH-tunnlar är en begränsad funktionalitet hos en vanlig VPN! Du kan helt enkelt installera OpenVPN eller andra VPN-implementationer, ställa in infrastrukturen och ge den till utvecklare för användning. Det här är så coolt!

Lyckligtvis ger AWS, GoogleCloud och andra dig ett års 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 varför jag skulle behöva en fjärrserver som gcloud, det verkar som att jag hittade dem.

Som en lokal virtuell maskin kan du använda samma Alpine, som aktivt används i dockningscontainrar. Tja, eller några andra lätta distributioner för att få maskinen att starta snabbare.

Summa summarum: du kan och bör köra databaser och andra infrastrukturgodsaker på fjärrservrar eller i virtualbox. Jag behöver inte docker för dessa ändamål.

Lite om docker-bilder och distribution

Jag har redan skrivit Artikel där jag ville förmedla att användning av docker-bilder inte ger någon garanti. Docker-bilder behövs bara för att skapa en docker-container. Om du uppgraderar till en docker-bild uppgraderar du till att använda docker-containrar och du kommer bara att använda dem.

Har du sett någonstans där mjukvaruutvecklare endast porterar sina produkter i en dockningsbild?
Resultatet av de flesta produkter är binära filer för en specifik plattform, de läggs helt enkelt till i docker-bilden, som ärvs från den önskade plattformen. Har du någonsin undrat varför det finns så många liknande bilder på dockerhub? Skriv in nginx till exempel, du kommer att se 100500 XNUMX bilder från olika personer. Dessa människor utvecklade inte själva nginx, de lade helt enkelt till officiell nginx till sin docker-bild och kryddade den med sina egna konfigurationer för att underlätta lanseringen av containrar.

I allmänhet kan du helt enkelt lagra den i tgz, om någon behöver köra den i docker, låt dem sedan lägga till tgz i Dockerfilen, ärva från den önskade miljön och skapa ytterligare bullar som inte ändrar själva applikationen i tgz. Alla som kommer att skapa en docker-bild vet vad tgz är och vad han behöver för att fungera. Så här använder jag docker här

Sammanfattning: Jag behöver inte docker-registret, jag kommer att använda någon form av S3 eller bara fillagring som google drive/dropbox

Hamnarbetare i CI

Alla företag jag har arbetat för är liknande. De är vanligtvis livsmedelsbutiker. Det vill säga, de har en applikation, en teknikstack (nåja, kanske ett par eller tre programmeringsspråk).

Dessa företag använder docker på sina servrar där CI-processen körs. Fråga - varför behöver du bygga projekt i en dockningscontainer på dina servrar? Varför inte bara förbereda en miljö för bygget, till exempel, skriva en Ansible-spelbok som kommer att installera nödvändiga versioner av nodejs, php, jdk, kopiera ssh-nycklar, etc. till servern där bygget kommer att ske?

Nu förstår jag att detta skjuter mig själv i foten, eftersom docker inte ger någon vinst med sin isolering. Problem jag stötte på med CI i docker:

• återigen behöver du en docker-bild för att bygga. du måste leta efter en bild eller skriva din egen dockerfil.
• 90% som du behöver för att vidarebefordra några ssh-nycklar, hemliga data som du inte vill skriva till docker-bilden.
• behållaren skapas och dör, alla cacher går förlorade tillsammans med den. nästa build kommer att ladda ner alla projektberoenden igen, vilket är tidskrävande och ineffektivt, och tid är pengar.

Utvecklare bygger inte projekt i hamnarcontainrar (jag var en gång ett sådant fan, verkligen, jag tycker synd om mig själv tidigare xD). I java är det möjligt att ha flera versioner och ändra dem med ett kommando till det du behöver nu. Det är samma sak i nodejs, det finns nvm.

Utgång

Jag tror att docker är ett mycket kraftfullt och flexibelt verktyg, detta är dess nackdel (låter konstigt, ja). Med dess hjälp kan företag lätt haka på den och använda den där det behövs och inte behövs. Utvecklare lanserar sina containrar, några av deras miljöer, sedan flyter det hela smidigt in i CI och produktion. DevOps-teamet skriver någon typ av kod för att köra dessa behållare.

Använd endast docker på den senaste steg i ditt arbetsflöde, dra det inte in i projektet i början. Det kommer inte att lösa dina affärsproblem. Han kommer bara att flytta problemen till EN ANNAN nivå och erbjuda sina egna lösningar, du kommer att göra dubbelarbete.

När docker behövs: Jag kom fram till att docker är väldigt bra på att optimera en given process, men inte på att bygga grundläggande funktionalitet

Om du fortfarande bestämmer dig för att använda docker, då:

• var extremt försiktig
• tvinga inte utvecklare att använda docker
• lokalisera dess användning på ett ställe, sprid det inte över alla Dockefile- och docker-compose-förråd

PS:

• Jag kom nyligen över packare och de säger att det fungerar väldigt bra med Ansible och låter dig förena processen att bygga bilder (inklusive docker-bild)
• också om hamnarbetare, intressant artikel

Tack för att du läser, jag önskar dig öppna beslut i dina angelägenheter och produktiva arbetsdagar!

Källa: will.com