Docker
Dockerfiles

Introduktion

Anmärkningar

# This is a comment
INSTRUCTION arguments

# escape=`

HelloWorld Dockerfile

En minimal Dockerfile ser ut så här:

FROM alpine
CMD ["echo", "Hello StackOverflow!"]

Detta kommer att instruera Docker att bygga en bild baserad på Alpine ( FROM ), en minimal distribution för containrar och att köra ett specifikt kommando ( CMD ) när den resulterande bilden körs.

Bygg och kör det:

docker build -t hello .
docker run --rm hello

Detta kommer att matas ut:

Hello StackOverflow!

Kopierar filer

För att kopiera filer från byggkontext i en Docker-bild använder du COPY instruktionen:

COPY localfile.txt containerfile.txt

Om filnamnet innehåller mellanslag använder du den alternativa syntaxen:

COPY ["local file", "container file"]

COPY kommandot stöder jokertecken. Det kan till exempel användas för att kopiera alla bilder till images/ katalogen:

COPY *.jpg images/

Obs! I det här exemplet finns images/ kanske inte. I detta fall skapar Docker det automatiskt.

Att exponera en hamn

För att deklara exponerade portar från en Dockerfile använd EXPOSE instruktionen:

EXPOSE 8080 8082

Inställningen för exponerade portar kan åsidosättas från Docker-kommandoraden, men det är en bra praxis att uttryckligen ställa in dem i Dockerfile eftersom det hjälper till att förstå vad en applikation gör.

Dockerfiles bästa pratices

Gruppens gemensamma verksamhet

Docker bygger bilder som en samling lager. Varje lager kan bara lägga till data, även om dessa data säger att en fil har tagits bort. Varje instruktion skapar ett nytt lager. Till exempel:

RUN apt-get -qq update
RUN apt-get -qq install some-package

Har ett par nackdelar:

• Det skapar två lager och ger en större bild.
• apt-get update använder apt-get update ensam i ett RUN uttalande orsakar cacheproblem och apt-get install kan instruktioner om apt-get install misslyckas . Anta att du senare ändrar apt-get install genom att lägga till extra paket, sedan tolkar dockaren de initiala och modifierade instruktionerna som identiska och återanvänder cachen från tidigare steg. Som ett resultat av apt-get update kommandot inte körs eftersom dess cachad version används under bygget.

Använd istället:

RUN apt-get -qq update && \
    apt-get -qq install some-package

eftersom detta bara ger ett lager.

Nämn underhållaren

Detta är vanligtvis den andra raden i Dockerfile. Den berättar vem som är ansvarig och kommer att kunna hjälpa.

LABEL maintainer John Doe <[email protected]>

Om du hoppar över det kommer det inte att bryta din bild. Men det hjälper inte dina användare heller.

Var kortfattad

Håll din Dockerfile kort. Om en komplex installation är nödvändig, överväg att använda ett dedicerat skript eller ställa in basbilder.

ANVÄNDARINFORMATION

USER daemon

USER instruktionen ställer in användarnamnet eller UID som ska användas när du kör bilden och för RUN , CMD och ENTRYPOINT instruktioner som följer den i Dockerfile .

WORKDIR instruktion

WORKDIR /path/to/workdir

Den WORKDIR instruktionen sätter arbetskatalogen för alla RUN , CMD , ENTRYPOINT , COPY och ADD instruktioner som följer den i Dockerfile. Om WORKDIR inte finns, skapas den även om den inte används i någon efterföljande Dockerfile instruktion.

Det kan användas flera gånger i en Dockerfile . Om en relativ sökväg tillhandahålls kommer den att vara relativt banan för den tidigare WORKDIR instruktionen. Till exempel:

WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd

Utgången från det sista pwd kommandot i detta Dockerfile skulle vara /a/b/c .

WORKDIR instruktionen kan lösa miljövariabler som tidigare ställts in med ENV . Du kan bara använda miljövariabler uttryckligen inställda i Dockerfile . Till exempel:

ENV DIRPATH /path
WORKDIR $DIRPATH/$DIRNAME
RUN pwd

Utgången från det sista pwd kommandot i detta Dockerfile skulle vara /path/$DIRNAME

VOLUME Instruktion

VOLUME ["/data"]

VOLUME instruktionen skapar en monteringspunkt med det angivna namnet och markerar den som att innehålla externt monterade volymer från den ursprungliga värden eller andra containrar. Värdet kan vara en JSON-matris, VOLUME ["/var/log/"] eller en vanlig sträng med flera argument, till exempel VOLUME /var/log eller VOLUME /var/log /var/db . För mer information / exempel och monteringsanvisningar via Docker-klienten, se delningskataloger via volymdokumentation.

docker run initierar den nyskapade volymen med all data som finns på den angivna platsen i basbilden. Tänk till exempel på följande Dockerfile-utdrag:

FROM ubuntu
RUN mkdir /myvol
RUN echo "hello world" > /myvol/greeting
VOLUME /myvol

Denna Dockerfile resulterar i en bild som orsakar docker-körning, för att skapa en ny monteringspunkt vid / myvol och kopiera hälsningsfilen till den nyligen skapade volymen.

Obs: Om några byggsteg ändrar data inom volymen efter att de har deklarerats kommer dessa ändringar att kasseras.

Obs: Listan är tolkad som en JSON-matris, vilket innebär att du måste använda dubbla citat (“) runt ord som inte är enstaka citat (').

KOPI-instruktion

COPY har två former:

COPY <src>... <dest>
COPY ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

COPY instruktionen kopierar nya filer eller kataloger från <src> och lägger till dem i filsystemet för behållaren vid sökvägen <dest> .

Flera <src> -resurser kan anges men de måste vara relativt till källkatalogen som byggs (byggnadens sammanhang).

Varje <src> kan innehålla jokertecken och matchning görs med Go's filepath.Match regler. Till exempel:

COPY hom* /mydir/        # adds all files starting with "hom"
COPY hom?.txt /mydir/    # ? is replaced with any single character, e.g., "home.txt"

<dest> är en absolut sökväg, eller en sökväg relativt WORKDIR , till vilken källan kopieras inuti destinationsbehållaren.

COPY test relativeDir/   # adds "test" to `WORKDIR`/relativeDir/
COPY test /absoluteDir/  # adds "test" to /absoluteDir/

Alla nya filer och kataloger skapas med en UID och GID på 0.

Obs! Om du bygger med stdin ( docker build - < somefile ) finns det inget COPY , så COPY kan inte användas.

COPY följer följande regler:

• <src> -vägen måste ligga inom sammanhanget för build; du kan inte COPY .. / något / något, eftersom det första steget i en dockningsbyggnad är att skicka sammanhangskatalogen (och underkataloger) till dockningsdemon.

• Om <src> är en katalog, kopieras hela innehållet i katalogen, inklusive filsystemmetadata. Obs! Själva katalogen kopieras inte, bara innehållet.

• Om <src> är någon annan typ av fil, kopieras den individuellt tillsammans med dess metadata. I det här fallet, om <dest> slutar med en baksnabbstreck /, kommer det att betraktas som en katalog och innehållet i <src> kommer att skrivas på <dest>/base(<src>) .

• Om flera <src> -resurser anges, antingen direkt eller på grund av användning av ett jokertecken, måste <dest> vara en katalog, och det måste sluta med en snedstreck / .

• Om <dest> inte avslutas med en slippsteg, kommer den att betraktas som en vanlig fil och innehållet i <src> kommer att skrivas vid <dest> .

• Om <dest> inte finns, skapas det tillsammans med alla kataloger som saknas i dess sökväg.

ENV- och ARG-instruktionen

ENV

ENV <key> <value>
ENV <key>=<value> ...

ENV instruktionen ställer in miljövariabeln <key> till värdet. Detta värde kommer att finnas i miljön för alla ”efterkommande” Dockerfile-kommandon och kan också bytas inline i många.

ENV instruktionen har två former. Den första formen, ENV <key> <value> , sätter en enda variabel till ett värde. Hela strängen efter det första utrymmet behandlas som <value> - inklusive tecken som mellanslag och citat.

Den andra formen, ENV <key>=<value> ... , gör det möjligt att ställa in flera variabler samtidigt. Lägg märke till att den andra formen använder likhetstecknet (=) i syntaxen, medan den första formen inte gör det. I likhet med kommandoradsparning kan citat och backstryk användas för att inkludera mellanslag i värden.

Till exempel:

ENV myName="John Doe" myDog=Rex\ The\ Dog \
    myCat=fluffy

och

ENV myName John Doe
ENV myDog Rex The Dog
ENV myCat fluffy

kommer att ge samma nettoresultat i den slutliga behållaren, men den första formen föredras eftersom den producerar ett enda cacheskikt.

ENV ställs in med ENV kommer att kvarstå när en behållare körs från den resulterande bilden. Du kan visa värdena med hjälp av docker inspect och ändra dem med docker run --env <key>=<value> .

ARG

Om du inte vill fortsätta inställningen, använd ARG istället. ARG ställer in miljöer endast under byggandet. Till exempel inställning

ENV DEBIAN_FRONTEND noninteractive

kan förvirra apt-get användare på en Debian-baserad bild när de kommer in i behållaren i ett interaktivt sammanhang via docker exec -it the-container bash .

Använd istället:

ARG DEBIAN_FRONTEND noninteractive

Alternativt kan du också ställa in ett värde för ett enda kommando genom att använda:

RUN <key>=<value> <command>

EXPOSE Instruktion

EXPOSE <port> [<port>...]

EXPOSE instruktionen informerar Docker att behållaren lyssnar på de angivna nätverksportarna under körning. EXPOSE gör INTE behållarens portar tillgängliga för värden. För att göra det måste du använda antingen -p flaggan för att publicera ett antal portar eller -P flaggan för att publicera alla exponerade portar. Dessa flaggor används i docker run [OPTIONS] IMAGE [COMMAND][ARG...] att exponera porten för värden. Du kan exponera ett portnummer och publicera det externt under ett annat nummer.

docker run -p 2500:80 <image name>

Detta kommando skapar en behållare med namnet <bild> och binder behållarens port 80 till värdmaskinens port 2500.

För att ställa in portomdirigering på värdsystemet, se använda -P flaggan. Nätverksfunktionen Docker stöder att skapa nätverk utan att behöva exponera portar i nätverket, för detaljerad information se översikten över denna funktion).

LABEL Instruktion

LABEL <key>=<value> <key>=<value> <key>=<value> ...

LABEL instruktionen lägger till metadata till en bild. En LABEL är ett nyckelvärdespar. Om du vill inkludera mellanslag inom ett LABEL värde använder du citat och backstryk på samma sätt som du skulle göra i kommandorads-parsning. Några användningsexempel:

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \
that label-values can span multiple lines."

En bild kan ha mer än en etikett. För att ange flera etiketter rekommenderar Docker att kombinera etiketter till en enda LABEL instruktion där det är möjligt. Varje LABEL instruktion producerar ett nytt lager som kan resultera i en ineffektiv bild om du använder många etiketter. Detta exempel resulterar i ett enda bildskikt.

LABEL multi.label1="value1" multi.label2="value2" other="value3"

Ovanstående kan också skrivas som:

LABEL multi.label1="value1" \
      multi.label2="value2" \
      other="value3"

Etiketter är tillsatser inklusive LABEL i FROM bilder. Om Docker möter en etikett / nyckel som redan finns, åsidosätter det nya värdet alla tidigare etiketter med identiska nycklar.

För att se en bilds etiketter, använd kommandot docker inspect.

"Labels": {
    "com.example.vendor": "ACME Incorporated"
    "com.example.label-with-value": "foo",
    "version": "1.0",
    "description": "This text illustrates that label-values can span multiple lines.",
    "multi.label1": "value1",
    "multi.label2": "value2",
    "other": "value3"
},

CMD-instruktion

CMD instruktionen har tre former:

CMD ["executable","param1","param2"] (exec form, this is the preferred form)
CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
CMD command param1 param2 (shell form)

Det kan bara finnas en CMD instruktion i en Dockerfile . Om du listar mer än en CMD kommer bara den sista CMD att träda i kraft.

Huvudsyftet med en CMD är att tillhandahålla standardvärden för en utförande behållare. Dessa standardvärden kan inkludera en körbar eller de kan uteslutas den körbara, i vilket fall måste du också ange en ENTRYPOINT instruktion.

Obs: Om CMD används för att tillhandahålla standardargument för ENTRYPOINT instruktionen, ENTRYPOINT både CMD och ENTRYPOINT instruktionerna anges med JSON-matrisformatet.

Obs: Exec-formuläret är analyserad som en JSON-matris, vilket innebär att du måste använda dubbla citat (“) runt ord som inte är enstaka citat (').

Obs: Till skillnad från skalformen påkallar exec-formen inte ett kommandoskal. Detta innebär att normal skalbehandling inte sker. Till exempel kommer CMD [ "echo", "$HOME" ] inte att göra variabel substitution på $HOME . Om du vill bearbeta skal ska du använda antingen skalformen eller köra ett skal direkt, till exempel: CMD [ "sh", "-c", "echo $HOME" ] .

När CMD instruktionen används i skal- eller exek-formatet ställer kommandot in som ska köras när bilden körs.

Om du använder skalformen för CMD kommer kommandot att köras i /bin/sh -c :

FROM ubuntu
CMD echo "This is a test." | wc -

Om du vill köra ditt kommando utan ett skal måste du uttrycka kommandot som en JSON-matris och ge hela sökvägen till den körbara. Denna matrisform är det föredragna formatet för CMD . Eventuella ytterligare parametrar måste uttryckas individuellt som strängar i matrisen:

FROM ubuntu
CMD ["/usr/bin/wc","--help"]

Om du vill att behållaren ska köra samma körbara varje gång, bör du överväga att använda ENTRYPOINT i kombination med CMD . Se ENTRYPOINT .

Om användaren specificerar argument för dockarkörning kommer de att åsidosätta det standard som anges i CMD .

Obs! Förväxla inte RUN med CMD . RUN kör faktiskt ett kommando vid bildbyggnadstid och begår resultatet; CMD kör inte någonting vid byggtid men anger det avsedda kommandot för bilden.

UNDERHÅLL Instruktion

MAINTAINER <name>

MAINTAINER instruktionen låter dig ställa in fältet författare för de genererade bilderna.

ANVÄND INTE HÅLLSINSTRUKTIONENS DIREKTIV

Enligt officiell Docker-dokumentation MAINTAINER instruktionen bort. Istället bör man använda LABEL instruktionen för att definiera författaren till de genererade bilderna. Den LABEL instruktionen är mer flexibel, möjliggör inställning metadata och lätt kan ses med kommandot docker inspect .

LABEL maintainer="[email protected]"

FRÅN instruktion

FROM <image>

Eller

FROM <image>:<tag>

Eller

FROM <image>@<digest>

FROM instruktionen ställer in basbilden för efterföljande instruktioner. Som sådan måste en giltig Dockerfile ha FROM som sin första instruktion. Bilden kan vara valfri bild - det är särskilt lätt att börja med att dra en bild från Public Repositories.

FROM måste vara den första instruktionen utan kommentarer i Dockerfile.

FROM kan visas flera gånger i en enda Dockerfile för att skapa flera bilder. Skriv helt enkelt in den senaste bild-ID-utmatningen av engagemanget före varje nytt FROM kommando.

Värden för tagg eller smälta är valfria. Om du utelämnar någon av dem antar byggaren en senaste som standard. Byggaren returnerar ett fel om det inte kan matcha taggvärdet.

RUN Instruktion

RUN har två former:

RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
RUN ["executable", "param1", "param2"] (exec form)

RUN instruktionen kommer att utföra alla kommandon i ett nytt lager ovanpå den aktuella bilden och utföra resultaten. Den resulterande engagerade bilden kommer att användas för nästa steg i Dockerfile .

Att lägga RUN instruktioner och generera åtaganden överensstämmer med kärnbegreppen i Docker där åtaganden är billiga och containrar kan skapas från valfri punkt i en bilds historia, ungefär som källkontroll.

Exec-formuläret gör det möjligt att undvika mingring av skalsträng och att RUN kommandon med en basbild som inte innehåller det angivna skalet som kan köras.

Standardskal för skalformen kan ändras med kommandot SHELL .

I skalformen kan du använda en \ (backslash) för att fortsätta en enda RUN instruktion till nästa rad. Tänk till exempel på dessa två rader:

RUN /bin/bash -c 'source $HOME/.bashrc ;\
echo $HOME'

Tillsammans motsvarar de denna enda rad:

RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'

Obs! Om du vill använda ett annat skal, annat än '/ bin / sh', använder du exec-formuläret som passerar i önskat skal. Till exempel RUN ["/bin/bash", "-c", "echo hello"]

Obs: Exec-formuläret analyseras som en JSON-matris, vilket innebär att du måste använda dubbla citat ( “ ) runt ord som inte är enstaka citat ( ' ).

Obs: Till skillnad från skalformen påkallar exec-formen inte ett kommandoskal. Detta innebär att normal skalbehandling inte sker. Till exempel kommer RUN [ "echo", "$HOME" ] inte att ersätta variabler med $HOME . Om du vill bearbeta skal, använd antingen skalformen eller kör ett skal direkt, till exempel: RUN [ "sh", "-c", "echo $HOME" ] .

Obs: I JSON-formuläret är det nödvändigt att undvika stänk. Detta är särskilt relevant på Windows där backslash är sökvägsavskiljaren. Följande rad skulle annars behandlas som skalform på grund av att den inte är giltig JSON och misslyckas på ett oväntat sätt: RUN ["c:\windows\system32\tasklist.exe"]

Rätt syntax för detta exempel är: RUN ["c:\\windows\\system32\\tasklist.exe"]

Cachen för RUN instruktioner ogiltigförklaras inte automatiskt under nästa byggnad. Cachen för en instruktion som RUN apt-get dist-upgrade -y kommer att återanvändas under nästa byggnad. Cachen för RUN instruktioner kan ogiltigförklaras med --no-cache-flaggan, till exempel dockningsbyggnad - ingen-cache.

Se guiden Dockerfile för bästa metoder för mer information.

Cachen för RUN instruktioner kan ogiltigförklaras med ADD instruktioner. Se nedan för mer information.

ONBUILD-instruktion

ONBUILD [INSTRUCTION]

ONBUILD instruktionen lägger till bilden en triggerinstruktion som ska utföras vid ett senare tillfälle, när bilden används som bas för en annan build. Trigaren kommer att köras i samband med nedströmsbyggnaden, som om den hade satts in omedelbart efter FROM instruktionen i nedströms Dockerfile.

Alla bygginstruktioner kan registreras som en trigger.

Detta är användbart om du bygger en bild som kommer att användas som bas för att bygga andra bilder, till exempel en applikationsbyggnadsmiljö eller en demon som kan anpassas med användarspecifik konfiguration.

Om din bild till exempel är en återanvändbar Python-applikationsbyggare kommer den att kräva att applikationskällkoden läggs till i en viss katalog, och den kan kräva att ett build-skript kallas efter det. Du kan inte bara ringa ADD and RUN nu, för du har ännu inte tillgång till programkällkoden, och det kommer att vara annorlunda för varje applikationsbyggnad. Du kan helt enkelt förse applikationsutvecklare med en pannplatta Dockerfile för att kopiera och klistra in i sin applikation, men det är ineffektivt, felbenäget och svårt att uppdatera eftersom det blandas med applikationsspecifik kod.

Lösningen är att använda ONBUILD att registrera förhandsinstruktioner för att köra senare, under nästa byggfas.

Så här fungerar det:

När den stöter på en ONBUILD instruktion lägger byggaren till en utlösare till metadata för bilden som byggs. Instruktionen påverkar inte den nuvarande byggnaden.

I slutet av byggandet lagras en lista över alla triggers i bildmanifestet, under nyckeln OnBuild. De kan inspekteras med docker inspect . Senare kan bilden användas som bas för en nybyggnad med hjälp av FROM instruktionen. Som en del av behandlingen av FROM instruktionen letar nedströmsbyggaren efter ONBUILD triggers och kör dem i samma ordning som de registrerades. Om någon av triggers misslyckas, avbryts FROM instruktionen vilket i sin tur får byggnaden att misslyckas. Om alla triggers lyckas slutförs FROM instruktionen och byggandet fortsätter som vanligt.

Triggers rensas från den slutliga bilden efter att de har körts. Med andra ord ärvs de inte av "barnbarn" -byggnader.

Till exempel kan du lägga till något liknande:

[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
[...]

Varning: Kedja ONBUILD instruktioner med ONBUILD ONBUILD är inte tillåtet.

Varning: ONBUILD instruktionerna kanske inte utlöser FROM eller MAINTAINER instruktioner.

STOPSIGNAL Instruktion

STOPSIGNAL signal

STOPSIGNAL instruktionen ställer in systemets anropssignal som skickas till behållaren för att avsluta. Denna signal kan vara ett giltigt osignerat nummer som matchar en position i kärnans syscall-tabell, till exempel 9, eller ett signalnamn i formatet SIGNAME, till exempel SIGKILL.

HEALTHCHECK Instruktion

HEALTHCHECK instruktionen har två former:

HEALTHCHECK [OPTIONS] CMD command (check container health by running a command inside the container)
HEALTHCHECK NONE (disable any healthcheck inherited from the base image)

HEALTHCHECK instruktionen berättar för Docker hur man testar en behållare för att kontrollera att den fortfarande fungerar. Detta kan upptäcka fall som en webbserver som sitter fast i en oändlig slinga och inte kan hantera nya anslutningar, även om serverprocessen fortfarande körs.

När en behållare har en hälsokontroll har den en hälsostatus utöver sin normala status. Denna status börjar initialt. När en hälsokontroll passerar blir den frisk (oavsett tillstånd den tidigare var). Efter ett visst antal på varandra följande misslyckanden blir det ohälsosamt.

Alternativen som kan visas före CMD är:

--interval=DURATION (default: 30s)
--timeout=DURATION (default: 30s)
--retries=N (default: 3)

Hälsokontrollen körs först intervall sekunder efter att behållaren har startats, och sedan igen intervall sekunder efter att varje tidigare kontroll har slutförts.

Om en enstaka körning av kontrollen tar längre tid än timeout sekunder, anses kontrollen ha misslyckats.

Det tar igen försök i följd av fel i hälsokontrollen för att behållaren ska betraktas som ohälsosam.

Det kan bara finnas en HEALTHCHECK instruktion i en Dockerfile . Om du listar mer än en kommer bara den sista HEALTHCHECK att träda i kraft.

Kommandot efter CMD nyckelordet kan vara antingen ett skalkommando (t.ex. HEALTHCHECK CMD /bin/check-running ) eller en exec-array (som med andra Dockerfile-kommandon; se t.ex. ENTRYPOINT för detaljer).

Kommandans utgångsstatus indikerar behållarens hälsostatus. De möjliga värdena är:

• 0: success - behållaren är frisk och redo att användas
• 1: unhealthy - behållaren fungerar inte korrekt
• 2: starting - behållaren är inte klar för användning ännu, men fungerar korrekt

Om sonden returnerar 2 ("start") när behållaren redan har flyttat ut från "start" -tillståndet, behandlas den istället som "ohälsosam".

Kontrollera till exempel vart femte minut eller så att en webbserver kan betjäna webbplatsens startsida inom tre sekunder:

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

För att hjälpa till att felsöka misslyckade sönder lagras all utmatningstext (UTF-8 kodad) som kommandot skriver på stdout eller stderr i hälsostatus och kan fråges med docker inspect . Sådan utgång ska hållas kort (endast de första 4096 byte lagras för närvarande).

När hälsotillståndet för en container ändras health_status en health_status händelse med den nya statusen.

HEALTHCHECK lades till i Docker 1.12.

SHELL Instruktion

SHELL ["executable", "parameters"]

SHELL instruktionen gör det möjligt att SHELL det standardskal som används för kommandot skalform. Standardskalet på Linux är ["/bin/sh", "-c"] , och på Windows är ["cmd", "/S", "/C"] . SHELL instruktionen måste skrivas i JSON-form i en Dockerfile.

SHELL instruktionen är särskilt användbar i Windows där det finns två vanligt förekommande och ganska olika inhemska skal: cmd och powershell, såväl som alternativa skal tillgängliga inklusive sh.

SHELL instruktionen kan visas flera gånger. Varje SHELL instruktion åsidosätter alla tidigare SHELL instruktioner och påverkar alla efterföljande instruktioner. Till exempel:

FROM windowsservercore

# Executed as cmd /S /C echo default
RUN echo default

# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default

# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello

# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S"", "/C"]
RUN echo hello

Följande instruktioner kan påverkas av SHELL instruktionen när skalformen av dem används i en Dockerfile: RUN , CMD och ENTRYPOINT .

Följande exempel är ett vanligt mönster som finns på Windows som kan strömlinjeformas med hjälp av SHELL instruktionen:

...
RUN powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"
...

Kommandot som anropas av docker är:

cmd /S /C powershell -command Execute-MyCmdlet -param1 "c:\foo.txt"

Detta är ineffektivt av två skäl. Först är det en on nödvändig kommandoprocessor cmd.exe (aka shell) som kallas. För det andra kräver varje RUN instruktion i skalformen en extra powershell-kommando som prefixerar kommandot.

För att göra detta mer effektivt kan en av två mekanismer användas. Den ena är att använda JSON-formen för RUN kommandot, till exempel:

...
RUN ["powershell", "-command", "Execute-MyCmdlet", "-param1 \"c:\\foo.txt\""]
...

Även om JSON-formuläret är entydigt och inte använder det un-nödvändiga cmd.exe, kräver det mer verbositet genom dubbelcitationstecken och flykt. Den alternativa mekanismen är att använda SHELL instruktionen och skalformen, vilket gör en mer naturlig syntax för Windows-användare, särskilt när den kombineras med escape-parser-direktivet:

# escape=`

FROM windowsservercore
SHELL ["powershell","-command"]
RUN New-Item -ItemType Directory C:\Example
ADD Execute-MyCmdlet.ps1 c:\example\
RUN c:\example\Execute-MyCmdlet -sample 'hello world'

Resulterar i:

PS E:\docker\build\shell> docker build -t shell .
Sending build context to Docker daemon 3.584 kB
Step 1 : FROM windowsservercore
 ---> 5bc36a335344
Step 2 : SHELL powershell -command
 ---> Running in 87d7a64c9751
 ---> 4327358436c1
Removing intermediate container 87d7a64c9751
Step 3 : RUN New-Item -ItemType Directory C:\Example
 ---> Running in 3e6ba16b8df9


Directory: C:\


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         6/2/2016   2:59 PM                Example


 ---> 1f1dfdcec085
Removing intermediate container 3e6ba16b8df9
Step 4 : ADD Execute-MyCmdlet.ps1 c:\example\
 ---> 6770b4c17f29
Removing intermediate container b139e34291dc
Step 5 : RUN c:\example\Execute-MyCmdlet -sample 'hello world'
 ---> Running in abdcf50dfd1f
Hello from Execute-MyCmdlet.ps1 - passed hello world
 ---> ba0e25255fda
Removing intermediate container abdcf50dfd1f
Successfully built ba0e25255fda
PS E:\docker\build\shell>

SHELL instruktionen kan också användas för att modifiera hur ett skal fungerar. Om du till exempel använder SHELL cmd /S /C /V:ON|OFF på Windows, kan fördröjd miljövariabel expansionssemantik modifieras.

SHELL instruktionen kan också användas på Linux om ett alternativt skal krävs, t.ex. zsh, csh, tcsh och andra.

SHELL funktionen lades till i Docker 1.12.

Installera Debian / Ubuntu-paket

Kör installationen på ett enda körkommando för att slå samman uppdateringen och installera. Om du lägger till fler paket senare kommer detta att köra uppdateringen igen och installera alla paket som behövs. Om uppdateringen körs separat kommer den att lagras i cache och paketinstallationer kan misslyckas. Ställa in frontend till icke-interaktiv och skicka -y för att installera krävs för skriptinstallationer. Rengöring och rensning i slutet av installationen minimerar skiktets storlek.

FROM debian

RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get install -y \
    git \
    openssh-client \
    sudo \
    vim \
    wget \
 && apt-get clean \
 && rm -rf /var/lib/apt/lists/*