Er Docker et legetøj eller ej? Eller er det stadig sandt?

Hej alle!

Jeg vil rigtig gerne komme direkte til emnet, men det ville være mere korrekt at fortælle lidt om min historie:

Indrejse

Jeg er programmør med erfaring i at udvikle frontend single page applikationer, scala/java og nodejs på serveren.

I ret lang tid (helt sikkert et par eller tre år) var jeg af den opfattelse, at Docker er manna fra himlen og generelt et meget fedt værktøj, og absolut enhver udvikler burde kunne bruge det. Og heraf følger, at enhver udvikler bør have Docker installeret på deres lokale maskine. Hvad med min mening, se de ledige stillinger igennem, der er slået op på samme hh. Hver anden indeholder en omtale af docker, og hvis du ejer den, vil dette være din konkurrencefordel 😉

På min vej mødte jeg mange mennesker med deres forskellige holdninger til Docker og dets økosystem. Nogle sagde, at dette er en praktisk ting, der garanterer funktionalitet på tværs af platforme. De anden forstod ikke hvorfor de skulle køre i containere og hvilken overskud der ville komme af det, den tredje var overhovedet ligeglad og gad ikke (de skrev bare koden og gik hjem - jeg misunder dem, af måde :)

Grunde til brug

Hvorfor brugte jeg docker? Sandsynligvis af følgende årsager:

• databaselancering, 99% af applikationerne bruger dem
• lancering af nginx til frontend-distribution og proxy til backend
• du kan pakke applikationen i et docker-billede, på denne måde vil min applikation fungere overalt, hvor der findes docker, distributionsproblemet er løst med det samme
• service opdagelse ud af boksen, du kan oprette mikrotjenester, hver container (forbundet til et fælles netværk) kan nemt nå en anden via et alias, meget praktisk
• Det er sjovt at skabe en container og "lege" i den.

Hvad jeg altid IKKE kan lide ved docker:

• For at min applikation kan fungere, har jeg brug for selve Docker på serveren. Hvorfor har jeg brug for dette, hvis mine applikationer kører på jre eller nodejs, og miljøet for dem allerede er på serveren?
• hvis jeg vil køre mit (private) lokalt byggede billede på en ekstern server, så har jeg brug for mit eget docker repository, jeg skal bruge registreringsdatabasen til at virke et eller andet sted, og jeg skal også konfigurere https, fordi docker cli kun virker over https. Åh for fanden... der er selvfølgelig muligheder for at gemme billedet lokalt via docker save og send bare billedet via scp... Men det er mange kropsbevægelser. Og desuden ligner det en "krykke"-løsning, indtil dit eget depot dukker op
• docker-compose. Det er kun nødvendigt for at køre containere. Det er alt. Han kan ikke andet. Docker-compose har en masse versioner af sine filer, sin egen syntaks. Uanset hvor deklarativt det er, vil jeg ikke læse deres dokumentation. Jeg får ikke brug for det andre steder.
• når de arbejder i et team, skriver de fleste en Dockerfil meget skævt, forstår ikke, hvordan den cachelagres, tilføjer alt, hvad de har brug for og ikke har brug for til billedet, arver fra billeder, der ikke er i Dockerhub eller et privat depot, opret nogle docker-compose filer med databaser og intet fortsætter. Samtidig erklærer udviklerne stolt, at Docker er sejt, alt fungerer lokalt for dem, og HR skriver vigtigt i den ledige stilling: "Vi bruger Docker, og vi har brug for en kandidat med en sådan arbejdserfaring."
• Jeg er konstant hjemsøgt af tanker om at hæve alt i Docker: postgresql, kafka, redis. Det er ærgerligt, at ikke alt fungerer i containere, ikke alt er nemt at konfigurere og køre. Dette understøttes af tredjepartsudviklere og ikke af leverandørerne selv. Og i øvrigt melder spørgsmålet sig straks: Leverandører bekymrer sig ikke om at vedligeholde deres produkter i Docker, hvorfor er det, måske ved de noget?
• Spørgsmålet opstår altid om beholderdatas persistens. og så tænker du, skal jeg bare montere værtsmappen eller oprette en docker-volumen eller lave en databeholder, som er nu deprecated? Hvis jeg monterer en mappe, så skal jeg sikre mig, at uid og gid for brugeren i containeren matcher id'et for den bruger, der lancerede containeren, ellers vil filerne oprettet af containeren blive oprettet med root-rettigheder. Hvis jeg bruger volume så bliver dataene simpelthen oprettet i nogle /usr/* og der vil være den samme historie med uid og gid som i det første tilfælde. Hvis du starter en tredjepartskomponent, skal du læse dokumentationen og lede efter svaret på spørgsmålet: "i hvilke containermapper skriver komponenten filer?"

Jeg kunne altid ikke lide det faktum, at jeg skulle pille ved Docker for længe i den indledende fase: Jeg fandt ud af, hvordan man starter containere, hvilke billeder der skal startes fra, lavede Make-filer, der indeholdt aliaser til lange Docker-kommandoer. Jeg hadede docker-compose, fordi jeg ikke ønskede at lære et andet værktøj i docker-økosystemet. OG docker-compose up Det generede mig, især hvis de stadig mødtes der build konstruktioner, frem for allerede samlede billeder. Alt, hvad jeg egentlig ønskede, var bare at lave et produkt effektivt og hurtigt. Men jeg kunne ikke finde ud af at bruge docker.

Introduktion til Ansible

For nylig (for tre måneder siden) arbejdede jeg med et DevOps-team, hvor næsten alle medlemmer havde en negativ holdning til Docker. Af grunde:

• docker regler iptables (selvom du kan deaktivere det i daemon.json)
• docker er buggy, og vi kører den ikke i produktion
• hvis docker-dæmonen går ned, så crasher alle containere med infrastruktur tilsvarende
• intet behov for docker
• hvorfor docker, hvis der er Ansible og virtuelle maskiner

På samme job stiftede jeg bekendtskab med et andet værktøj - Ansible. Jeg hørte om det en gang, men jeg prøvede ikke at skrive mine egne spillebøger. Og nu begyndte jeg at skrive mine opgaver og så ændrede min vision sig fuldstændig! Fordi jeg indså: Ansible har moduler til at køre de samme docker-containere, image builds, netværk osv., og containere kan køres ikke kun lokalt, men også på fjernservere! Min glæde kendte ingen grænser - jeg fandt et NORMALt værktøj og smed mine Makefile- og docker-compose-filer, de blev erstattet med yaml-opgaver. Koden blev reduceret ved at bruge konstruktioner som loop, whenOsv

Docker til at køre tredjepartskomponenter såsom databaser

Jeg har for nylig stiftet bekendtskab med ssh-tunneler. Det viste sig, at det er meget nemt at "viderestille" porten på en ekstern server til en lokal port. Fjernserveren kan enten være en maskine i skyen eller en virtuel maskine, der kører i VirtualBox. Hvis min kollega eller jeg har brug for en database (eller en anden tredjepartskomponent), kan vi blot starte serveren med denne komponent og slukke den, når serveren ikke er nødvendig. Port forwarding giver samme effekt som en database, der kører i en docker-container.

Denne kommando videresender min lokale port til en ekstern server, der kører postgresql:

ssh -L 9000:localhost:5432 [e-mail beskyttet]

Brug af en ekstern server løser problemet med teamudvikling. En sådan server kan bruges af flere udviklere på én gang; de behøver ikke at kunne konfigurere postgresql, forstå Docker og andre forviklinger. På en ekstern server kan du installere den samme database i selve Docker, hvis det er svært at installere en bestemt version. Alt, hvad udviklere behøver, er at give ssh-adgang!

Jeg læste for nylig, at SSH-tunneler er en begrænset funktionalitet af en almindelig VPN! Du kan blot installere OpenVPN eller andre VPN-implementeringer, opsætte infrastrukturen og give den til udviklere til brug. Det er så sejt!

Heldigvis giver AWS, GoogleCloud og andre dig et års gratis brug, så brug dem! De er billige, hvis du slukker dem, når de ikke er i brug. Jeg har altid undret mig over, hvorfor jeg skulle bruge en fjernserver som gcloud, det ser ud til, at jeg fandt dem.

Som en lokal virtuel maskine kan du bruge den samme Alpine, som bruges aktivt i docker-containere. Nå, eller nogle andre letvægtsfordelinger for at få maskinen til at starte hurtigere.

Nederste linje: du kan og bør køre databaser og andre infrastrukturgoder på fjernservere eller i virtualbox. Jeg har ikke brug for docker til disse formål.

Lidt om docker-billeder og distribution

Jeg har allerede skrevet en artikel hvor jeg ønskede at formidle, at brug af docker-billeder ikke giver nogen garanti. Docker-billeder er kun nødvendige for at oprette en docker-container. Hvis du opgraderer til et docker-billede, så opgraderer du til at bruge docker-containere, og du vil kun bruge dem.

Har du set nogen steder, hvor softwareudviklere kun porterer deres produkter i et docker-billede?
Resultatet af de fleste produkter er binære filer til en bestemt platform; de føjes blot til docker-billedet, som er nedarvet fra den ønskede platform. Har du nogensinde undret dig over, hvorfor der er så mange lignende billeder på dockerhub? Indtast nginx for eksempel, du vil se 100500 billeder fra forskellige mennesker. Disse mennesker udviklede ikke nginx selv, de tilføjede simpelthen officiel nginx til deres docker-image og krydrede det med deres egne konfigurationer for at gøre det nemmere at starte containere.

Generelt kan du simpelthen gemme det i tgz, hvis nogen har brug for at køre det i docker, så lad dem tilføje tgz til Dockerfilen, arve fra det ønskede miljø og oprette yderligere buns, der ikke ændrer selve applikationen i tgz. Enhver, der vil oprette et docker-billede, vil vide, hvad tgz er, og hvad han skal bruge for at arbejde. Sådan bruger jeg docker her

Nederste linje: Jeg har ikke brug for docker-registrering, jeg vil bruge en slags S3 eller bare fillagring som google drive/dropbox

Docker i CI

Alle de virksomheder, jeg har arbejdet for, ligner hinanden. De er normalt dagligvarer. Det vil sige, at de har én applikation, én teknologistak (nå, måske et par eller tre programmeringssprog).

Disse virksomheder bruger docker på deres servere, hvor CI-processen kører. Spørgsmål: Hvorfor skal du bygge projekter i en docker-container på dine servere? Hvorfor ikke bare forberede et miljø til bygningen, for eksempel skrive en Ansible playbook, der vil installere de nødvendige versioner af nodejs, php, jdk, kopiere ssh-nøgler osv. til den server, hvor bygningen skal foregå?

Nu forstår jeg, at det her skyder mig selv i foden, for docker bringer ikke noget overskud med sin isolation. Problemer jeg stødte på med CI i docker:

• igen skal du have et docker-image for at bygge. du skal lede efter et billede eller skrive din egen dockerfil.
• 90%, at du skal videresende nogle ssh-nøgler, hemmelige data, som du ikke ønsker at skrive til docker-billedet.
• beholderen oprettes og dør, alle caches går tabt sammen med den. den næste build vil gendownloade alle projektafhængigheder, hvilket er tidskrævende og ineffektivt, og tid er penge.

Udviklere bygger ikke projekter i docker-containere (jeg var engang sådan en fan, virkelig, jeg har ondt af mig selv tidligere xD). I java er det muligt at have flere versioner og ændre dem med en kommando til den du har brug for nu. Det er det samme i nodejs, der er nvm.

Output

Jeg mener, at docker er et meget kraftfuldt og fleksibelt værktøj, dette er dens ulempe (lyder mærkeligt, ja). Med dens hjælp kan virksomheder nemt blive hooked på det og bruge det, hvor det er nødvendigt og ikke nødvendigt. Udviklere lancerer deres containere, nogle af deres miljøer, så flyder det hele jævnt ind i CI og produktion. DevOps-teamet skriver en form for kode til at køre disse containere.

Brug kun docker til den seneste trin i din arbejdsgang, lad være med at trække det ind i projektet i begyndelsen. Det løser ikke dine forretningsproblemer. Han vil kun flytte problemerne til ET ANDET niveau og tilbyde sine egne løsninger, du vil gøre dobbeltarbejde.

Når der er brug for docker: Jeg kom til den konklusion, at docker er meget god til at optimere en given proces, men ikke til at bygge grundlæggende funktionalitet

Hvis du stadig beslutter dig for at bruge docker, så:

• vær yderst forsigtig
• tving ikke udviklere til at bruge docker
• lokaliser dets brug ét sted, spred det ikke på tværs af alle Dockefile- og docker-compose-depoter

PS:

• Jeg stødte for nylig på packer og de siger, at det fungerer meget godt med Ansible og giver dig mulighed for at forene processen med at bygge billeder (inklusive docker-billede)
• også om havnearbejder, interessant artikel

Tak fordi du læste, jeg ønsker dig gennemsigtige beslutninger i dine anliggender og produktive arbejdsdage!

Kilde: www.habr.com