Docker – er det et legesæt eller ej? Eller måske ja?

Hej alle sammen!

Jeg har meget lyst til straks at springe ind i emnet, men det er bedre at fortælle lidt om min historie først:

Introduktion

Jeg er programmør med erfaring i udvikling af frontend-eensides applikationer, Scala/Java og Node.js på serveren.

I lang tid (i hvert fald et par - tre år), har jeg ment, at Docker er en himmelsk gave og generelt et fantastisk værktøj, som enhver udvikler bør kunne bruge. Heraf følger, at hver udvikler også bør have Docker installeret på sin lokale maskine. Og hvad angår min mening, kan du blot kigge på de jobopslag, der findes på HH. I hver anden er der nævnt Docker, og hvis du kan det, vil det være din konkurrencefordel 😉

På min rejse har jeg mødt mange mennesker med forskellige holdninger til Docker og dens økosystem. Nogle sagde, at det er et praktisk værktøj, der garanterer tværplatformskompatibilitet. Andre forstod ikke, hvorfor de skulle køre i containere, og hvad gevinsten var, og nogle var helt ligeglade og bekymrede sig ikke (de skrev bare kode og gik hjem - jeg misunder dem, for øvrigt 🙂)

Årsager til brug

Hvorfor brugte jeg Docker? Måske af følgende årsager:

• opstart af databaser; 99% af applikationerne bruger dem
• opstart af Nginx til at levere frontend og proxy til backend
• man kan pakke en applikation i et Docker-billede; dermed vil min applikation fungere, hvor som helst der er Docker, distributionsproblemet er løst med det samme
• service discovery lige ud af boksen, man kan lave mikrotjenester; hver container (tilsluttet et fælles netværk) kan nemt nå den anden via alias, meget praktisk
• det er sjovt at oprette en container og "lege" i den.

Hvad jeg altid IKKElige ved Docker:

• For at min applikation skal fungere, kræver jeg, at Docker er installeret på serveren. Og hvorfor skulle jeg have det, når mine applikationer allerede kører på JRE eller Node.js, og der allerede er et miljø til dem på serveren?
• Hvis jeg ønsker at køre mit (private) lokalbyggede billede på en fjernserver, har jeg brug for mit eget Docker-repositorium, og der skal være en registry, der fungerer et eller andet sted, og jeg skal også konfigurere HTTPS, fordi Docker CLI kun fungerer via HTTPS. Åh, pokker… der er selvfølgelig muligheder for at gemme billedet lokalt gennem docker save og så bare overføre billedet via SCP... Men det kræver så mange bevægelser. Og det ser også «halvfærdigt» ud, indtil jeg får mit eget repository.
• docker-composeDen er kun nødvendig for at køre containere. Og det er alt. Der er ikke mere, den kan gøre. Docker-compose har en masse versioner af sine filer, sin egen syntaks. Uanset hvor deklarativ den måtte være, vil jeg ikke læse deres dokumentation. Jeg har ikke brug for den noget andet sted.
• Når man arbejder i et team, skriver de fleste mennesker Dockerfile meget skævt, forstår ikke, hvordan det caches, tilføjer alt, hvad der er nødvendigt og unødvendigt til billedet, arver fra billeder, der ikke er på dockerhub eller i et privat repository, skaber nogle docker-compose filer med databaser og intet bliver persisteret. På samme tid erklærer udviklerne stolt, at docker er fantastisk, og de har alt til at køre lokalt, og HR skriver vigtigt i jobopslaget: "Vi bruger docker, og vi har brug for en kandidat med sådan erfaring".
• jagter konstant tanken om at køre alt og alle i docker: postgresql, kafka, redis. Det er ærgerligt, at ikke alt fungerer i containere, ikke alt er let at konfigurere og starte. Dette støttes af tredjepartsudviklere og ikke af leverandørerne selv. Og forresten opstår straks spørgsmålet, leverandøren bekymrer sig ikke om at vedligeholde sine produkter i docker, hvorfor gør de ikke det, måske ved de noget?
• der opstår altid spørgsmål om vedholdenheden af containerdata. Og her overvejer man, om man bare skal montere en værtens mappe eller oprette en docker volume eller lave en data container, som nu deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume dataene bare bliver oprettet i et eller andet /usr/* og der vil være den samme historie med uid og gid som i første tilfælde. Hvis du starter en tredjepartskomponent, skal du læse dokumentationen nøje og finde svaret på spørgsmålet: "I hvilke mapper skriver komponenten filer i containeren?"

Jeg har altid ikke kunnet lide, at man skal bruge for lang tid på at rode med docker. I den indledende fase: fandt jeg ud af, hvordan man kører containere, fra hvilke billeder man skal starte, lavede Makefile, som indeholdt aliase til lange docker-kommandoer. Jeg kunne ikke lide docker-compose, fordi jeg ikke ville lære endnu et værktøj i docker-økosystemet. Og docker-compose up det irriterede mig, især hvis der også var build konstruktioner, og ikke allerede bygget billeder. Alt, hvad jeg virkelig ønskede, var blot at gøre produktet effektivt og hurtigt. Men jeg kunne simpelthen ikke organisere brugen af docker.

Introduktion til Ansible

For nylig (for tre måneder siden) arbejdede jeg sammen med et DevOps-team, hvor næsten hvert medlem havde en negativ holdning til docker. Af årsager:

• Docker styrer iptables (selvom det kan deaktiveres i daemon.json)
• Docker er temmelig skadelig, og vi vil ikke køre det i produktion
• Hvis Docker-demonen crasher, crasher alle containere med infrastrukturen også
• Der er ikke behov for Docker
• Hvorfor bruge Docker, når der er Ansible og virtuelle maskiner?

På det samme arbejde stødte jeg på et andet værktøj - Ansible. Jeg havde engang hørt om det, men havde ikke prøvet at skrive mine egne playbooks. Men nu begyndte jeg at skrive mine egne opgaver, og mit synspunkt ændrede sig helt! For jeg indså, at Ansible har moduler til at køre de samme Docker-containere, bygge billeder, netværk mv., og containere kan køres ikke kun lokalt, men også på eksterne servere! Min begejstring kendte ingen grænser - jeg havde fundet et GODT værktøj og smidt mine Makefile og Docker Compose-filer væk, de blev erstattet med YAML-opgaver. Koden blev reduceret takket være brugen af konstruktioner som loop, block, osv.

Docker til at køre tredjeparts komponenter som databaser

For nylig blev jeg bekendt med SSH-tunneler. Det viste sig at være meget nemt at 'forwarde' en port fra en ekstern server til en lokal port. Den eksterne server kan være en cloud-maskine eller en virtuel maskine, der kører i VirtualBox. Hvis jeg eller en af mine kolleger har brug for en database (eller en anden tredjeparts komponent), kan vi bare starte serveren med denne komponent og slukke den, når serveren ikke længere er nødvendig. Ports forwarding giver den samme effekt som en database, der kører i en Docker-container.

Denne kommando forwarder min lokale port til den eksterne server med PostgreSQL:

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

Brugen af en ekstern server løser problemet med udvikling i et team. Flere udviklere kan bruge den samme server, de behøver ikke at kunne konfigurere PostgreSQL, forstå Docker og de øvrige finurligheder. På den eksterne server kan man installere den samme database i Docker, hvis det er svært at installere en specifik version. Alt hvad udviklerne vil have brug for er SSH-adgang!

Jeg læste for nylig, at SSH-tunneler er en begrænset funktionalitet sammenlignet med en almindelig VPN! Man kan nemt konfigurere OpenVPN eller andre VPN-løsninger, opsætte infrastrukturen og give den til udviklerne. Det er ret cool!

Heldigvis tilbyder AWS, GoogleCloud og andre et gratis års brug, så udnyt det! De er billige, hvis du slukker for dem, når de ikke er i brug. Jeg har altid spekuleret på, hvornår jeg ville have brug for en fjernserver som gcloud; nu ser det ud til, at jeg har fundet svaret.

Som en virtuel maskine på lokalt niveau kan du bruge den samme Alpine, som aktivt anvendes i Docker-containere. Eller nogle andre lette distributioner for hurtigere opstart af maskinen.

Konklusion: det er muligt og nødvendigt at køre databaser og andre infrastrukturelle komponenter på fjernservere eller i VirtualBox. Jeg har ikke brug for Docker til disse formål.

Lidt om Docker-billeder og distribution.

Jeg har tidligere skrevet artiklen om, at brugen af Docker-billeder ikke giver nogen garantier. Docker-billeder er kun nødvendige for at oprette Docker-containere. Hvis du er bundet til et Docker-billede, betyder det, at du kun kan bruge Docker-containere.

Har du nogensinde set udviklere portere deres produkter kun til Docker-billeder?
Resultatet af de fleste produkter er binære filer til en bestemt platform, som blot tilføjes til et Docker-billede, der arver fra den nødvendige platform. Har du nogensinde undret dig over, hvorfor der er så mange lignende billeder på Docker Hub? Søg for eksempel på nginx, og du vil se 100.500 billeder fra forskellige mennesker. Disse personer har ikke selv udviklet nginx; de har blot tilføjet den officielle nginx til deres Docker-billede og tilføjet deres egne konfigurationer for at lette opstarten af containerne.

Generelt kan man gemme dem som tgz; hvis nogen har brug for at køre dette i Docker, kan de tilføje tgz i Dockerfile, arve fra det nødvendige miljø og skabe yderligere funktioner, der ikke ændrer selve applikationen i tgz. Den, der skaber Docker-billedet, vil vide, hvad denne tgz er, og hvad der er nødvendigt for at få det til at fungere. Det er således, jeg bruger Docker. her

Konklusion: jeg har ikke brug for en Docker registry; jeg vil bruge et hvilket som helst S3 eller blot en filopbevaring som Google Drive/Dropbox.

Docker i CI

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

Disse virksomheder bruger Docker på deres servere, hvor CI-processen kører. Spørgsmålet er — hvorfor skal man samle projekter i Docker-containere på egne servere? Hvorfor ikke bare forberede et miljø til opbygning, for eksempel ved at skrive en Ansible-playbook, der installerer de nødvendige versioner af Node.js, PHP, JDK, kopierer SSH-nøgler osv. til serveren, hvor opbygningen skal finde sted?

Nu forstår jeg, at det er skud i foden, fordi Docker ikke giver nogen gevinst med sin isolation. Problemer med CI i Docker, som jeg har stødt på:

• igen har jeg brug for et Docker-billede til opbygning. Jeg skal finde et billede eller skrive min egen Dockerfile.
• 90% af tiden skal jeg videregive nogle SSH-nøgler, hemmelige oplysninger, som jeg ikke ønsker at skrive i Docker-billedet.
• Containeren oprettes og dør, og alle caches tabes sammen med den. Næste opbygning vil skulle downloade alle projektets afhængigheder igen, hvilket er langsomt og ineffektivt, og tid er penge.

Udviklere samler ikke projekter i Docker-containere (jeg var engang sådan en fanatiker, men det er synd for mit tidligere jeg xD). I Java er der mulighed for at have flere versioner og skifte til den, der er nødvendig med ét kommando. Det samme gælder for Node.js, der findes nvm.

Output

Jeg mener, at Docker er et meget kraftfuldt og fleksibelt værktøj, men det er også dets ulempe (det lyder underligt, ikke?). Gennem det lette virksomheder 'bliver afhængige' af det, bruger det hvor det er nødvendigt og unødvendigt. Udviklere kører deres containere, deres eget miljø, og så flyder alt dette glat ind i CI, produktion. DevOps-teamet skriver nogle cykler for at starte disse containere.

Brug Docker kun på det allerbedste trin i din arbejdsgang, tag ikke det ind i projektet fra starten. Det løser ikke dine forretningsproblemer. Det vil kun flytte problemerne til et ANDET niveau og tilbyde sine egne løsningsmuligheder, og du vil gøre dobbelt arbejde.

Når Docker er nødvendigt: jeg er nået frem til, at Docker er meget godt til optimering af den etablerede proces, men ikke til opbygning af grundlæggende funktionalitet.

Hvis du alligevel har besluttet at bruge Docker, så:

• vær yderst forsigtig
• påtvung ikke brugen af Docker til udviklerne
• lokaliser dets brug ét sted, spred ikke Dockerfile og docker-compose ud over alle repositories.

PS:

• For nylig stødte jeg på packer Og de siger, at det fungerer meget godt med Ansible og gør det muligt at standardisere processen for opbygning af billeder (inklusive docker image)
• Også om docker, interessant artikel

Tak fordi du læste med, jeg ønsker dig klare løsninger i dine forretninger og produktive arbejdsdage!

Kilde: habr.com