Dockerfile Bästa praxis: Bygga smidigare, snabbare och säkrare Docker-avbildningar

Docker har blivit ett oumbärligt verktyg inom modern mjukvaruutveckling, vilket gör det möjligt för team att bygga, leverera och köra applikationer med oöverträffad konsekvens och enkelhet. Kärnan i denna containeriseringsmagi ligger Dockerfile, ett enkelt men kraftfullt skript som fungerar som ritning för att skapa dina Docker-avbildningar.

Att skapa en effektiv Dockerfile-byggprocess är mer än bara en teknisk övning; det är en väg till snabbare utvecklingscykler, mindre och säkrare applikationsutrymmen och mer tillförlitliga distributioner. Oavsett om du är nybörjare på Docker eller vill förfina dina kunskaper, kommer den här guiden att guida dig genom grunderna i att skriva praktiska, effektiva och säkra Dockerfiles.

Förstå Docker-ekosystemet: En snabb uppfriskning

Innan vi dyker in i Dockerfiles, låt oss kortfattat beröra viktiga Docker-koncept:

• Avbildningar: En avbildning är ett lätt, fristående, körbart paket som innehåller allt som behövs för att köra programvara, inklusive kod, en runtime, bibliotek, miljövariabler och konfigurationsfiler. Avbildningar är oföränderliga mallar.
• Behållare: En container är en körbar instans av en avbildning. Du kan skapa, starta, stoppa, flytta eller ta bort containrar. De tillhandahåller isolerade miljöer för dina applikationer.
• Dockerfile: Detta är vårt fokus. En Dockerfile är ett textdokument som innehåller en sekvens av kommandon som Docker använder för att automatiskt sätta ihop en avbildning.
• Docker Hub/Register: Dessa är databaser för att lagra och dela Docker-avbildningar, liknande GitHub för kod.

En välskriven Dockerfile syftar till att producera en avbildning som är så smidig, snabb att bygga och säker som möjligt.

Förklaring av Docker-byggflaggor

• -t myapp:1.0 : Den här flaggan taggar din avbildning med ett namn (myapp) och en version (1.0). Taggning hjälper till med versionskontroll och gör det enklare att referera till specifika avbildningsversioner senare, särskilt vid distribution eller push-överföring till ett register.

• . (punkt) : Detta hänvisar till byggkontexten, katalogen där Docker ska leta efter Dockerfilen och andra filer som behövs under byggprocessen (t.ex. filer som ska KOPIERAS till avbildningen).
  Docker komprimerar och skickar innehållet i den här katalogen till Docker-daemonen. Det är viktigt att notera att endast filer inuti byggkontexten kan nås under byggprocessen.

Viktiga Dockerfile-instruktioner: Byggstenarna

Låt oss utforska de vanligaste instruktionerna och hur man använder dem effektivt.

1. FRÅN: Varje Dockerfile måste börja med en FROM-instruktion. Den anger den basavbildning som din avbildning ska byggas på.
   • Syfte: Att välja en startpunkt, ofta ett operativsystem (som Ubuntu:22.04) eller en förkonfigurerad applikationskörning (som node:18-alpine).
   • Exempel : FRÅN python:3.9-slim
   • Bästa praxis: Välj den minimala basavbildningen som uppfyller din applikations behov. Alpine-versioner är små men använder musl libc, vilket kan ha kompatibilitetsproblem för vissa C-beroende paket. Slim-versioner är en bra kompromiss och erbjuder en avskalad version av en standarddistribution (som Debian) med glibc.
2. ARBETSDIR: Den här inställningen ställer in warbetskatalogen för alla efterföljande RUN-, CMD-, ENTRYPOINT-, COPY- och ADD-instruktioner.
   • Syfte: Att definiera den aktuella katalogkontexten i avbildningen för efterföljande filåtgärder och kommandokörningar. Om katalogen inte finns skapar Docker den.
   • Exempel: ARBETSDIR /usr/src/app
   • Bästa praxis: Använd absoluta sökvägar för WORKDIR. Att byta kataloger med WORKDIR flera gånger är generellt sett smidigare än att kedja cd-kommandon inom RUN-instruktioner.
3. KOPIERA: Kopierar filer eller kataloger från din byggkontext till avbildningens filsystem.
   • Syfte: Lägg till din programkod, konfigurationsfiler och andra nödvändiga resurser i avbildningen.
   • Exempel:

Dockerfile

ARBETSDIR /usr/src/app
KOPIERA paket.json ./
KOPIERA src/ ./src/

• Bästa praxis: För enkel filkopiering, föredra COPY framför ADD. COPY är mer transparent. ADD har extra funktioner som URL-nedladdning och tar-extraktion, vilket kan vara mindre förutsägbart. För tydlighetens skull och säkerhet är det ofta bättre att använda RUN med curl, wget och tar om du behöver ladda ner och extrahera.

4. SIKT: Kör kommandon i ett nytt lager ovanpå den aktuella bilden och sparar resultaten. Detta används för att installera programvara, skapa kataloger, kompilera kod etc.
   • Syfte: Att modifiera avbildningens filsystem genom att installera paket, köra byggskript eller konfigurera konfigurationer.
   • Exempel:

Dockerfile

KÖR apt-get update && apt-get install -y –no-install-recommends \
nginx \
curl \
&& rm -rf /var/lib/apt/lists/*

• Bästa praxis: Kedja relaterade kommandon med && och rensa temporära filer eller pakethanterarcacher (som rm -rf /var/lib/apt/lists/* för Debian/Ubuntu eller yum clean all för CentOS/RHEL) i samma RUN-instruktion. Detta minimerar antalet lager och minskar bildstorleken, eftersom varje RUN-instruktion skapar ett nytt lager.

5. ENV: Ställer in miljövariabler som är tillgängliga under byggprocessen (efter att de har definierats) och när containrar körs från avbildningen.
   • Syfte: Att tillhandahålla konfigurationsvärden, sökvägar eller inställningar som behövs av ditt program eller dina byggskript.
   • Exempel:

Dockerfile

-miljö NODE_ENV=produktionsmiljö
APP_PORT=3000

• Bästa praxis: Använd ENV för icke-känsliga konfigurationsdata. Runtime-injektionsmetoder bör användas istället för att baka in dem i avbildningen med ENV för hemligheter.

6. ARG: Definierar en variabel vid byggtid som användare kan skicka med hjälp av flaggan– build-arg under Docker-bygget.
   • Syfte: Att tillåta parametrisering av byggprocessen utan att modifiera Dockerfilen.
   • Exempel: Dockerfile

Dockerfile

ARG APP_VERSION=1.0.0
ENV APP_VERSION_ENV=${APP_VERSION}
RUN echo “Bygg version ${APP_VERSION_ENV}”

• Bygg med: våldsamt slag docker build– build-arg APP_VERSION=1.2.3 -t myapp.
• Obs: ARG-variabler är inte tillgängliga i den körande behållaren om de inte uttryckligen är angivna som en ENV-variabel, som visas ovan.

7. ÖVERSIKT: Informerar Docker om att containern lyssnar på de angivna nätverksportarna vid körning.
   • Syfte: Detta dokument fungerar främst som dokumentation för avbildningsbyggaren och användaren. Det publicerar inte porteringen.

Exempel:

Dockerfile

EXPOSE 8080

• Obs: För att göra porten tillgänglig från värden använder du flaggan -p eller -P med docker run (t.ex. docker run -p 8080:8080 myimage).

8. CMD och INGÅNGSPUNKT: Definiera vilket kommando som körs när en container startas.
   • CMD ["executable", "param1", "param2"] : Tillhandahåller standardvärden för en exekverande container. Dessa standardvärden kan enkelt åsidosättas genom att lägga till ett kommando i docker run. Om du har flera CMD:er träder endast den sista i kraft.
   • ENTRYPOINT ["executable", "param1", "param2"] : Konfigurerar en container att köras som en körbar fil. Argument som skickas till docker run läggs till i ENTRYPOINT-kommandot.
   • Exempel (typiskt mönster):

Dockerfile

ENTRYPOINT [“python”, “app.py”] # Huvudkommando
CMD [“–help”] # Standardargument om inget anges vid dockerkörning

• Bästa praxis: Använd CMD om du vill ha ett enkelt åsidosättbart standardkommando. Använd ENTRYPOINT för att skapa en avbildning som beter sig som en specifik körbar fil, ofta med hjälp av CMD för att ange standardargument. För webbapplikationer är CMD ["npm", "start"] eller CMD ["python", "manage.py", "runserver"] standard.

Viktiga bästa praxis för optimerade Dockerfiles

Att skriva en fungerande Dockerfile är bara början. Att optimera den ger betydande fördelar.

• Utnyttja byggcachen effektivt: Docker bygger bilder i lager och försöker återanvända lager från tidigare versioner om möjligt (cachning). För att maximera cacheträffar:
  • Ordna instruktionerna från att ändras minst ofta till att ändras mest ofta. Installera till exempel beroenden (som ändras mer sällan) innan du kopierar källkoden för din applikation (som ändras ofta).

Dockerfile

# Bra cachningsexempel för en Node.js-app
FRÅN node:18-alpine
WORKDIR /app
COPY package.json package-lock.json ./ # Beroenden ändras mer sällan
RUN npm ci –omit=dev # Detta lager cachas om paketfiler inte ändras
COPY . . # Källkoden ändras ofta, så det är den sista
CMD:n [“node”, “server.js”]

• Håll dina bilder små: Mindre bilder är snabbare att dra, trycka och driftsätta, och har en minskad attackyta.
  • Använd minimala basavbildningar: Alpine-, slim- eller distroless-varianter är betydligt mindre än fullständiga OS-avbildningar.
  • Rensa upp i samma RUN-lager: Ta bort onödiga cacheminnor eller temporära filer med samma RUN-instruktion efter att du har installerat paket. Till exempel:
    • Debian/Ubuntu: apt-get clean && rm -rf /var/lib/apt/lists/*
    • CentOS/RHEL: yum clean all eller dnf clean all
    • Alpint: rm -rf /var/cache/apk/*
• Omfamna flerstegsbyggen: Detta är ett av de mest effektiva sätten att minska bildstorleken, särskilt för kompilerade språk eller applikationer med byggsteg (som JavaScript-gränssnitt).
  • Koncept: Använd ett steg (ett FROM-block) med alla dina byggverktyg och utvecklingsberoenden för att kompilera/bygga din applikation. Starta sedan ett nytt steg från en minimal runtime-basavbildning och använd COPY– from= endast kopiera de nödvändiga kompilerade artefakterna till detta slutliga, rena skede.
  • Exempel (förenklad Go-applikation): Dockerfile

Dockerfile

# Steg 1: Bygg
FRÅN golang:1.20 SOM builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# Steg 2: Körtid
FRÅN debian:bullseye-slim
WORKDIR /app
COPY –from=builder /app/myapp .
CMD [“./myapp”]

• Byggarstadiet har Go SDK, men den slutliga avbildningen innehåller bara den kompilerade binärfilen och det minimala Alpine OS.
• Prioritera säkerhet:
  • Kör som en icke-root-användare: Som standard körs containrar som root. Detta är en säkerhetsrisk. Skapa en dedikerad, oprivilegierad användare och grupp i din Dockerfile och använd USER-instruktionen för att växla till den. Dockerfile

Dockerfile

KÖR addgroup -S appgroup && adduser -S appuser -G appgroup
# … KOPIERA filer och hämta dem till appuser:appgroup …
ANVÄNDARE appuser

• Installera endast nödvändiga paket: Varje paket är en potentiell sårbarhet. Undvik att installera felsökningsverktyg eller utvecklingsverktyg i produktionsavbildningar (använd flerstegsversioner för detta).
• Hårdkoda inte hemligheter: Undvik att lägga lösenord, API-nycklar eller andra hemligheter i din Dockerfile (t.ex. i ENV-variabler). Använd runtime-injektionsmetoder som Docker-hemligheter, Kubernetes-hemligheter eller miljövariabler som tillhandahålls säkert vid körning.
• Använd .dockerignore effektivt: Skapa en .dockerignore-fil i roten av din byggkontext (på samma nivå som din Dockerfile). Lista filer och kataloger som ska undantas från att skickas till Docker-daemonen (t.ex. .git, node_modules om installerade i avbildningen, lokala IDE-konfigurationer, *.log).
• Fördelar: Snabba upp Docker -byggprocessen genom att minska byggkontextens storlek och förhindra att känsliga eller onödiga filer inkluderas i din avbildning.

Utöver grunderna: Ytterligare förbättringar

När du är bekväm med ovanstående, överväg dessa för ännu bättre Dockerfiles:

• BuildKit: Dockers nyare byggmotor, ofta aktiverad som standard. Den erbjuder bättre prestanda (parallella byggen), förbättrad cachning och avancerade funktioner som bygghemligheter (RUN– mount=type=secret,…) och cachemonteringar (RUN– mount=type=cache,…) för pakethanterare. Se till att den är aktiv eller aktivera den med DOCKER_BUILDKIT=1.
• Linting av Dockerfiles: Använd verktyg som Hadolint (hadolint Dockerfile) för att statiskt analysera din Dockerfile efter fel, stilöverträdelser och efterlevnad av bästa praxis innan du bygger.

Vanliga felsökningstips

• ”Filen hittades inte” under KOPIERA eller LÄGG TILL : Dubbelkolla källsökvägen (den är relativ till byggkontextens rot) och se till att filen inte utesluts av .dockerignore.
• Långsamma byggen: Granska instruktionernas ordning för cacheoptimering. Kombinera RUN-kommandon där det är möjligt. Se till att din .dockerignore är heltäckande.
• Stora bilder: Använd flerstegsbyggen! Rensa upp i RUN-lager. Välj minimala basbilder.

Dockerfiles i ditt DevOps-arbetsflöde

En Dockerfile är en viktig del av "Infrastruktur som kod"

• Versionskontroll: Spara alltid din Dockerfile i ditt Git-arkiv tillsammans med din applikationskod.
• CI/CD-integration: Automatisera din Docker-bygg- och imagepush-process inom dina pipelines för kontinuerlig integration/kontinuerlig leverans (t.ex. GitHub Actions, Jenkins, GitLab CI). Detta säkerställer konsekventa och repeterbara byggen och distributioner.

Slutsats: Att bygga en grund för framgång

Att skapa effektiva Dockerfiles är en investering som ger betydande fördelar vad gäller utvecklingshastighet, driftsäkerhet och applikationssäkerhet. Genom att behärska grundläggande instruktioner, implementera bästa praxis som flerstegsbyggen och noggrann hantering av bildlager, samt prioritera säkerhet, kan du producera Docker-avbildningar som är smidiga, effektiva och robusta.

Den här guiden ger en solid grund. Fortsätt utforska, experimentera och förfina dina Dockerfiler medan du fortsätter din Docker-resa.

Redo att förbättra dina Docker- och DevOps-metoder?

På Seahawk Media specialiserar vi oss på att hjälpa företag att utnyttja den fulla potentialen av containerisering, molnteknik och effektiviserade CI/CD-pipelines. Vårt expertteam finns här för att hjälpa dig om du vill optimera dina applikationsdistributioner, förbättra säkerheten eller accelerera din utvecklingslivscykel.