🥇Docker: icke-skadliga råd

I kommentaren till min artikel Docker: skadliga råd fanns det många förfrågningar om att förklara vad som är så hemskt med den Dockerfile som beskrivs i den.

Sammanfattning av föregående avsnitt: två utvecklare under en sträng deadline skriver en Dockerfile. Under processen kommer Ops Igor Ivanovich in. Den slutgiltiga Dockerfile är så dålig att Igor Ivanovich nästan får en hjärtattack.

Låt oss nu reda ut vad som är fel med den här Dockerfile.

Så, en vecka har gått.

Utvecklare Petya träffar Ops Igor Ivanovich i matsalen över en kopp kaffe.

P: Igor Ivanovich, är du mycket upptagen? Jag skulle vilja gå igenom var vi gjorde fel.

II: Det är bra, man träffar sällan utvecklare som är intresserade av drift.
Först, låt oss komma överens om några saker:

Docker-ideologi: en container — en process.
Ju mindre containern är, desto bättre.
Ju mer som tas från cachen, desto bättre.

P: Men varför ska det bara vara en process i en container?

II: När Docker startar en container övervakar den tillståndet för processen med pid 1. Om processen dör försöker Docker starta om containern. Anta att du har flera applikationer som körs i containern eller att den huvudsakliga applikationen inte körs med pid 1. Om processen dör får Docker inte veta det.

Om det inte finns några fler frågor, visa din Dockerfile.

Och Petya visade:

FROM ubuntu:latest

# Kopiera källkoden
COPY . /app
WORKDIR /app

# Uppdaterar paketlistan
RUN apt-get update 

# Uppdaterar paketen
RUN apt-get upgrade

# Installerar nödvändiga paket
RUN apt-get -y install libpq-dev imagemagick gsfonts ruby-full ssh supervisor

# Installerar bundler
RUN gem install bundler

# Installerar nodejs som används för att bygga statiken
RUN curl -sL https://deb.nodesource.com/setup_9.x | sudo bash -
RUN apt-get install -y nodejs

# Installerar beroenden
RUN bundle install --without development test --path vendor/bundle

# Rensar cachar
RUN rm -rf /usr/local/bundle/cache/*.gem 
RUN apt-get clean 
RUN rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 
RUN rake assets:precompile
# Kör skriptet vid start av containern som startar allt annat.
CMD ["/app/init.sh"]

II: Åh, låt oss gå igenom det steg för steg. Vi börjar med den första raden:

FROM ubuntu:latest

Du tar taggen latest. Att använda taggen latest kan leda till oförutsägbara konsekvenser. Tänk dig att underhållaren av bilden bygger en ny version av bilden med en annan programvarulista, denna bild får taggen latest. Och din container slutar i bästa fall att byggas, och i värsta fall får du buggar som du inte hade tidigare.

Du tar en bild med ett fullt operativsystem som har en massa onödig programvara, vilket ökar storleken på containern. Ju mer programvara, desto fler säkerhetshål och sårbarheter.

Dessutom, ju större bilden är, desto mer utrymme tar den på värden och i registret (du har ju någonstans att lagra bilderna)?

P: Ja, självklart, vi har ett register, du har ju konfigurerat det.

AI: Så, vad var jag inne på?.. Aha, storlekar… Belastningen på nätverket ökar också. För en enskild bild märks det inte, men när du har kontinuerlig byggnation, tester och distribution, blir det påtagligt. Och om du inte har Gudsläget på AWS, så får du även en astronomisk räkning.

Därför behöver du välja den mest lämpliga bilden, med exakt version och minimi programvara. Till exempel, ta: FROM ruby:2.5.5-stretch

P: Åh, jag förstår. Hur och var kan jag se de befintliga bilderna? Hur vet jag vilken jag behöver?

AI: Vanligtvis hämtas bilder från Docker Hub, blanda inte ihop det med Pornhub :). För en bild finns det vanligtvis flera versioner:
Microsoft har meddelat om utvidgning av funktionaliteten i WSL2.: bilder som är byggda på en minimalistisk Linux-bild, bara 5 MB. Nackdelen är att den är byggd med en egen implementation av libc, standardpaket fungerar inte. Det kan ta tid att hitta och installera det önskade paketet.
Scratch: grundbild som inte används för att bygga andra bilder. Den är utformad för att köra binära, förberedd data. Den är perfekt för att köra binära applikationer som innehåller allt som behövs, som till exempel Go-applikationer.
Baserat på något operativsystem, som Ubuntu eller Debian. Här behöver jag nog inte förklara mer.

AI: Nu behöver vi installera alla tilläggspaket och rensa våra cache. Och vi kan genast ta bort apt-get upgrade. Annars kommer olika versioner av bilderna att skapas vid varje byggnation, trots att basbildens tagg är fastställd. Att uppdatera paketen i bilden är en maintainer-uppgift som innebär att taggen ändras.

P: Ja, jag försökte göra det, och så här blev det:

WORKDIR /app
COPY ./ /app

RUN curl -sL https://deb.nodesource.com/setup_9.x | bash - 
    && apt-get -y install libpq-dev imagemagick gsfonts ruby-full ssh supervisor nodejs 
    && gem install bundler 
    && bundle install --without development test --path vendor/bundle

RUN rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

AI: Inte dåligt, men det finns också saker att förbättra. Titta, det här kommandot:

RUN rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

… tar bort inte data från den slutgiltiga bilden, utan skapar endast ett extra lager utan dessa data. Rätt så:

RUN curl -sL https://deb.nodesource.com/setup_9.x | bash - 
    && apt-get -y install libpq-dev imagemagick gsfonts nodejs 
    && gem install bundler 
    && bundle install --without development test --path vendor/bundle   
    && rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Men det är inte allt. Har du Ruby där? Då behöver du inte kopiera hela projektet i början. Det räcker att kopiera Gemfile och Gemfile.lock.

Med denna metod kommer bundle install inte att köras vid varje ändring av källkoden, utan endast om Gemfile eller Gemfile.lock har ändrats.

Samma metoder fungerar även för andra språk med beroendehanterare, såsom npm, pip, composer och andra som baseras på en fil med en lista över beroenden.

Och slutligen, minns du att jag i början pratade om Docker-ideologin ‘en container – en process’? Det betyder att en övervakare inte behövs. Du bör inte heller installera systemd av samma skäl. I praktiken är Docker själv en övervakare. Och när du försöker köra flera processer i den, är det som att köra flera applikationer i en övervakare.
Vid byggandet kommer du att skapa en enhetlig bild och sedan starta det nödvändiga antalet containrar så att en process körs i varje.

Men mer om det senare.

Q: Det verkar som jag har förstått. Titta, vad vi har:

FROM ruby:2.5.5-stretch

WORKDIR /app
COPY Gemfile* /app

RUN curl -sL https://deb.nodesource.com/setup_9.x | bash - 
    && apt-get -y install libpq-dev imagemagick gsfonts nodejs 
    && gem install bundler 
    && bundle install --without development test --path vendor/bundle   
    && rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 

COPY . /app
RUN rake assets:precompile

CMD ["bundle", "exec", "passenger", "start"]

Men ska vi omdefiniera att starta demoner vid containerstart?

AI: Ja, precis. Förresten kan du använda både CMD och ENTRYPOINT. Att ta reda på skillnaden är din läxa. Det finns bra information om detta på Habré. artikeln.

Så, låt oss gå vidare. Du laddar ner installationsfilen för node, men det finns ingen garanti för att den innehåller det du behöver. Vi måste lägga till validering. Till exempel så här:

KÖR curl -sL https://deb.nodesource.com/setup_9.x > setup_9.x 
    && echo "958c9a95c4974c918dca773edf6d18b1d1a41434  setup_9.x" | sha1sum -c - 
    && bash setup_9.x 
    && rm -rf setup_9.x 
    && apt-get -y install libpq-dev imagemagick gsfonts nodejs 
    && gem install bundler 
    && bundle install --without development test --path vendor/bundle   
    && rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Genom kontrollsumman kan du kontrollera att du har laddat ner rätt fil.

P: Men om filen ändras kommer byggnaden att misslyckas.

AI: Ja, och konstigt nog är det också en fördel. Du kommer att få veta att filen har ändrats och kan kika på vad som har ändrats. Man vet ju aldrig, de kanske har lagt till ett skript som raderar allt det rör vid, eller skapar en bakdörr.

P: Tack. Så den slutgiltiga Dockerfile kommer att se ut så här:

FROM ruby:2.5.5-stretch

WORKDIR /app
COPY Gemfile* /app

RUN curl -sL https://deb.nodesource.com/setup_9.x > setup_9.x 
    && echo "958c9a95c4974c918dca773edf6d18b1d1a41434  setup_9.x" | sha1sum -c - 
    && bash setup_9.x 
    && rm -rf setup_9.x 
    && apt-get -y install libpq-dev imagemagick gsfonts nodejs 
    && gem install bundler 
    && bundle install --without development test --path vendor/bundle   
    && rm -rf /usr/local/bundle/cache/*.gem 
    && apt-get clean  
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* 

COPY . /app
RUN rake assets:precompile

CMD ["bundle", "exec", "passenger", "start"]

P: Igor Ivanovich, tack för hjälpen. Jag måste redan skynda mig, jag behöver göra 10 commits till idag.

Igor Ivanovich, som stoppade den brådskande kollegan med blicken, tar en klunk starkt kaffe. Efter att ha funderat i några sekunder om SLA på 99,9 % och kod utan buggar ställer han en fråga.

AI: Var lagrar ni loggarna?

P: Självklart i production.log. Förresten, hur får vi åtkomst till dem utan ssh?

AI: Om ni lämnar dem i filer har vi redan en lösning för er. Kommandot docker exec tillåter att köra vilket kommando som helst i containern. Till exempel kan ni göra cat för loggarna. Och om ni använder nyckeln -it och startar bash (om det är installerat i containern), får ni interaktiv tillgång till containern.

Men det är inte bra att lagra loggar i filer. Minst sagt leder det till okontrollerad tillväxt av containern, loggarna roteras ju inte. Alla loggar bör skickas till stdout. Där kan de sedan ses med kommandot docker logs.

P: Igor Ivanovich, kanske vi kan flytta loggarna till en monterad katalog på den fysiska noden, som användardata?

AI: Bra att ni inte glömde att flytta data som laddats till nodens disk. Loggar kan också hanteras på det sättet, men glöm inte att ställa in rotation.
Okej, du kan gå nu.

P: Igor Ivanovich, kan du rekommendera något att läsa?

AI: För att börja, läs rekommendationerna från Docker-utvecklarna, knappast någon kan Docker bättre än de.

Och om du vill praktisera, gå på intensivkurs. Teori utan praktik är död.

Källa: habr.com

Docker: inte skadliga råd