Container telepítés

Elszigetelt konténerben dolgozunk.
Telepítse a Dockert a Docker telepítéséhez a OneGet szolgáltató PowerShell modulját használjuk, amely a szolgáltatókkal együttműködve végrehajtja a telepítést, ebben az esetben a MicrosoftDockerProvider . A szolgáltató lehetővé teszi a konténerek funkcióját a gépen. A Dockert is telepíti, amely újraindítást igényel. A Docker szükséges a Windows konténerekkel való együttműködéshez. A Docker Engine és a Docker kliensből áll.
Nyissa meg az emelt PowerShell munkamenetet, és futtassa a következő parancsokat.
Először telepítse a Docker-Microsoft PackageManagement Szolgáltatót a PowerShell Galériából .
 Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
 Ezt követően a PackageManagement PowerShell modul segítségével telepítheti a Docker legújabb verzióját.
 Install-Package -Name docker -ProviderName DockerMsftProvider
 Amikor a PowerShell megkérdezi, hogy megbízik-e a "DockerDefault" csomagforrással, írja be az A billentyűt a telepítés folytatásához. A telepítés befejezése után indítsa újra a számítógépet.
 Restart-Computer -Force
 Windows Server rendszer naprakész-e: sconfig
 A Docker elszigetelt tartályokban dolgozik. A konténer olyan folyamat, amely egy gazdagépen fut. A gazda lehet helyi vagy távoli. Amikor egy operátor végzi a docker run , a futó konténerfolyamat elszigetelten működik, mivel rendelkezik saját fájlrendszerrel, saját hálózatával és saját elkülönített folyamatfával, amely elválik a gazdagéptől.

Ez az oldal részletezi, hogyan használhatja a docker run parancsot a konténer erőforrásainak futásidejű meghatározásához.

Általános forma

Az alapvető docker run parancs ezt a formát veszi át:

 $ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
A docker run parancsnak meg kell adnia egy IMAGE-t, amellyel a tartály származhat. Egy képfejlesztő meghatározhatja az alábbiakhoz kapcsolódó kép alapértelmezéseket:

önálló vagy előtérben futó
a konténer azonosítása
hálózati beállítások
futásidejű korlátok a CPU-n és a memórián
A docker run [OPTIONS] a kezelő hozzáadhatja vagy felülírhatja a fejlesztő által beállított alapértelmezett értékeket. Ráadásul a szolgáltatók felülírhatják majdnem a Docker futtatás által beállított alapértelmezett értékeket. Az operátor képes felülbírálni a kép és a Docker futásidejű alapértelmezéseit, ezért a futásnak több lehetősége van, mint bármely más docker .

Az [OPTIONS] típusainak értelmezésével kapcsolatban lásd: Az opciótípusok .

Megjegyzés : A Docker rendszer konfigurációjától függően előfordulhat, hogy elő kell írnia a docker run parancsot a sudo . Annak elkerülése érdekében, hogy a docker parancs használatával ne használjon sudo t, a rendszergazda létrehozhat egy úgynevezett docker nevű Unix-csoportot, és hozzáadhatja hozzá a felhasználókat. A konfigurációról további információt az operációs rendszer Docker telepítési dokumentációjában talál.

Operatőr kizárólagos opciói

Csak az operátor (az a személy, aki végrehajtja a docker run ) a következő opciókat állíthatja be.

Elválasztva előtérben
Különálló (-d)
Előtér
A konténer azonosítása
Név (-név)
PID egyenértékű
IPC beállítások (-ipc)
Hálózati beállítások
Újraindítási házirendek (-restart)
Tisztítás (-rm)
Az erőforrások futási idejének korlátai
Futásidejű jogosultság és Linux-képességek
Elválasztva előtérben

A Docker konténer indításakor először eldöntheti, hogy a konténert a "háttérben" vagy "alapértelmezett előtér" üzemmódban kívánja-e futtatni a háttérben:

 -d=false: Detached mode: Run container in the background, print new container id
Különálló (-d)

A tároló elindításához különálló módban a -d=true vagy csak -d opciót használjuk. Tervezés szerint a konténerek elválasztott üzemmódban indulnak el, amikor a konténer futtatásához használt gyökérfolyamat elhagyja, hacsak nem adja meg a --rm opciót sem. Ha a --rm használja a --rm , akkor a konténer el lesz távolítva, amikor kilép, vagy amikor a démon kilép, attól függően, hogy melyik történik először.

Ne engedje át a service x start parancsot egy leválasztott tárolóba. Például ez a parancs megpróbálja elindítani a nginx szolgáltatást.

 $ docker run -d -p 80:80 my_image service nginx start
Ezzel sikerül elindítani a nginx szolgáltatást a tartály belsejében. Azonban nem sikerül az elválasztott konténer paradigmája abban az esetben, ha a gyökérfolyamat ( service nginx start ) visszatér, és a leválasztott konténer megáll a tervek szerint. Ennek eredményeként a nginx szolgáltatás nginx de nem használható. Ehelyett egy olyan folyamat elindításához, mint a nginx webszerver, tegye a következőket:

 $ docker run -d -p 80:80 my_image nginx -g 'daemon off;'
A bemenet / kimenet leválasztott tároló használatával hálózati kapcsolatokat vagy megosztott köteteket használhat. Ez azért szükséges, mert a tároló már nem hallgatja a parancssort, ahol a docker run futott.

A leválasztott tárolóba való visszahelyezéshez használja a docker attach parancsot.

Előtér

Előtér módban (az alapértelmezett, amikor a -d nincs megadva) a docker run elindíthatja a folyamatot a tartályban, és csatlakoztathatja a konzolt a folyamat szabványos bemenetéhez, kimenetéhez és standard hibájához. Lehet, hogy úgy tesz, mintha TTY lenne (ez az, amit a legtöbb parancssori végrehajthatónak vár), és továbbadja a jeleket. Mindez konfigurálható:

 -a=[] : Attach to `STDIN`, `STDOUT` and/or `STDERR` -t : Allocate a pseudo-tty --sig-proxy=true: Proxy all received signals to the process (non-TTY mode only) -i : Keep STDIN open even if not attached
Ha nem adja meg a -a akkor a Docker mind az stdout, mind az stderr kapcsolódni fog. Megadhatja, hogy a három szabványos stream ( STDIN , STDOUT , STDERR ) közül STDERR szeretne kapcsolódni, mint például:

 $ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
Interaktív folyamatokhoz (például héjhoz) a -i -t együtt kell használnia annak érdekében, hogy egy tty-t lefoglaljon a konténerfolyamatra. -i -t gyakran írták -it amint látni fogjuk a későbbi példákban. A -t megadása tilos, ha az ügyfél a szabványos bevitelt egy csőből fogadja, mint például:

 $ echo test | docker run -i busybox cat
Megjegyzés : A konténerben PID 1 -ként futó folyamatot a Linux speciálisan kezeli: figyelmen kívül hagy minden jelet az alapértelmezett művelettel. Így a folyamat nem fog megszűnni a SIGINT vagy a SIGTERM kivéve, ha kódolt.

A konténer azonosítása

Név (-név)

A kezelő háromféle módon azonosítani tudja a tartályt:

Azonosító típusa Példaérték
UUID hosszú azonosító „F78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778”
UUID rövid azonosító „F78375b1c487”
Név „Evil_ptolemy”
Az UUID azonosítók a Docker démonból származnak. Ha nem rendel hozzá egy konténernevet a --name opcióval, akkor a démon véletlenszerű karakterláncnevet generál. A name meghatározása hasznos lehet a tartalom értelmezéséhez. Ha megad egy name , akkor használhatja, ha a tárolót a Docker hálózaton belül hivatkozik. Ez a háttér és az előtér Docker konténerek esetében is működik.

Megjegyzés : Az alapértelmezett hídhálózaton tárolt konténereket név szerint kell kommunikálni.

PID egyenértékű

Végül, az automatizáláshoz segítséget kaphat, hogy a Docker írja a tárolóazonosítót egy választott fájlra. Ez hasonlít arra, hogy egyes programok hogyan írhatják fel folyamatazonosítójukat egy fájlra (PID-fájlként látták őket):

 --cidfile="": Write the container ID to the file
Image [: tag]

Noha nem feltétlenül egy tárolóeszköz azonosításának eszköze, akkor megadhatja a kép egy olyan verzióját, amelyhez a konténert futtatni szeretné a image[:tag] hozzáadásával. Például, a docker run ubuntu:14.04 .

Image [@digest]

A v2 vagy újabb képformátumot használó képek tartalommal címezhető azonosítóval rendelkeznek, amelyet emésztésnek neveznek. Mindaddig, amíg a kép előállításához használt bemenet változatlan marad, az emésztési érték előre kiszámítható és referenciálható.

Az alábbi példában egy konténer fut az sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 a sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 digest segítségével:

 $ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
PID beállítások (-pid)

 --pid="" : Set the PID (Process) Namespace mode for the container, 'container:<name|id>': joins another container's PID namespace 'host': use the host's PID namespace inside the container
Alapértelmezés szerint minden tárolónak engedélyezve van a PID névtér.

A PID névtér a folyamatok elválasztását biztosítja. A PID névtér eltávolítja a rendszerfolyamatok nézetét, és lehetővé teszi a folyamatazonosságok újrafelhasználását, beleértve a pid 1-et.

Bizonyos esetekben azt szeretné, hogy a konténer megoszthassa a gazdagép folyamatnevetartományát, alapvetően lehetővé téve a konténeren belüli folyamatok számára a rendszer összes folyamatának megtekintését. Például fel lehet építeni egy tárolót olyan hibakeresési eszközökkel, mint a strace vagy a gdb , de ezeket az eszközöket szeretné használni, amikor a tartályon belüli folyamatok hibakeresését végezte.

Példa: futtassa a htopot egy tárolóban

Hozzon létre ezt a Docker fájlt:

 FROM alpine:latest RUN apk add --update htop && rm -rf /var/cache/apk/* CMD ["htop"]
Építsd a Docker fájlt, és tagoljd be a képet myhtop :

 $ docker build -t myhtop .
Használja a következő parancsot a htop futtatásához egy tárolóban:

 $ docker run -it --rm --pid=host myhtop
Egy másik konténer pid névtartományának összekapcsolása használható a tároló hibakeresésére.

Példa

Indítson el egy redisz szervert futtató konténert:

 $ docker run --name my-redis -d redis
A redis tartály hibaelhárítása egy másik tartály futtatásával, amely strace-t tartalmaz:

 $ docker run -it --pid = container:my-redis my_strace_docker_image bash $ strace -p 1
UTS beállítások (-uts)

 --uts="" : Set the UTS namespace mode for the container, 'host': use the host's UTS namespace inside the container
Az UTS névtér a gazdagép nevének és a tartománynak az adott névtérben futó folyamatok számára látható tartományának beállítása. Alapértelmezés szerint az összes konténer, beleértve a --network=host , rendelkezik saját UTS névtérrel. A host beállítása azt eredményezi, hogy a tároló ugyanazt a UTS névtéret használja, mint a gazda. Ne feledje, hogy - a --hostname érvénytelen a host UTS módban.

Lehet, hogy meg szeretné osztani az UTS névteret a gazda segítségével, ha azt szeretné, hogy a konténer gazdaneve megváltozzon, ahogyan a gazda gazdanevének neve megváltozik. Egy fejlettebb felhasználási eset a fogadó gazdagépének megváltoztatása egy tárolóból.

IPC beállítások (-ipc)

 --ipc="MODE" : Set the IPC mode for the container
A következő értékek fogadhatók el:

Érték Leírás
„” A démon alapértelmezett használata.
"egyik sem" Saját privát IPC névtér, a / dev / shm nélkül.
"magán" Saját IPC névtér.
„Megosztható” Saját magán IPC névtér, azzal a lehetőséggel, hogy megoszthatja azt más tárolókkal.
"Konténer: <_name-or-ID_>" Csatlakozzon egy másik ("megosztható") konténer IPC névteréhez.
"házigazda" Használja a gazda rendszer IPC névterét.
Ha nincs megadva, akkor a démon alapértelmezett változatát használhatja, amely lehet "private" vagy "shareable" , attól függően, hogy a démon verziója és konfigurációja milyen.

Az IPC (POSIX / SysV IPC) névtér a megosztott memória szegmensek, a szemaforák és az üzenetsorok elválasztását biztosítja.

Az osztott memória szegmensek felgyorsítják a folyamatok közötti kommunikációt a memória sebességén, nem pedig csöveken vagy a hálózati veremen keresztül. Az osztott memóriát általában az adatbázisok és az egyéni (jellemzően C / OpenMPI, C ++ / növekvő könyvtárak használatával) nagy teljesítményű alkalmazások használják a tudományos számítástechnikai és pénzügyi szolgáltatási ágazatokban. Ha az ilyen típusú alkalmazások több tárolóba vannak bontva, meg kell osztani a tárolók IPC-mechanizmusait a "shareable" fő" (azaz "adományozó") tároló "shareable" módja és "container:<donor-name-or-ID>" más tartályokhoz.

Hálózati beállítások

 --dns=[] : Set custom dns servers for the container --network="bridge" : Connect a container to a network 'bridge': create a network stack on the default Docker bridge 'none': no networking 'container:<name|id>': reuse another container's network stack 'host': use the Docker host network stack '<network-name>|<network-id>': connect to a user-defined network --network-alias=[] : Add network-scoped alias for the container --add-host="" : Add a line to /etc/hosts (host:IP) --mac-address="" : Sets the container's Ethernet device's MAC address --ip="" : Sets the container's Ethernet device's IPv4 address --ip6="" : Sets the container's Ethernet device's IPv6 address --link-local-ip=[] : Sets one or more container's Ethernet device's link local IPv4/IPv6 addresses
Alapértelmezés szerint minden tároló rendelkezik hálózati kapcsolattal, és minden kimenő kapcsolatot létrehozhat. Az operátor teljesen letilthatja a hálózati kapcsolatot a docker run --network none amely letiltja az összes bejövő és kimenő hálózatot. Ilyen esetekben az I / O fájlokat csak az STDIN és az STDOUT fájlok segítségével végezheti el.

A kikötők közzététele és a többi tárolóhoz való kapcsolódás csak az alapértelmezett (híd) művelettel működik. A kapcsolódási szolgáltatás egy örökölt szolgáltatás. Mindig a Docker hálózati meghajtók használatát kell előnyben részesítened a linkeléssel.

A konténer alapértelmezés szerint ugyanazokat a DNS-kiszolgálókat használja, mint a gazda, de ezt felülírhatja a --dns .

Alapértelmezés szerint a MAC-cím a tárolóhoz rendelt IP-cím használatával generálódik. A konténer MAC-címét kifejezetten megadhatja, ha a MAC-címet a --mac-address címparaméterrel (formátum: 12:34:56:78:9a:bc ) biztosítja. Tudatában annak, hogy a Docker nem ellenőrzi, hogy kézzel megadott MAC-címeket egyedi.

Támogatott hálózatok:

Hálózat Leírás
egyik sem Nincs hálózati kapcsolat a tartályban.
híd (alapértelmezett) Csatlakoztassa a tartályt a hídhoz az veth interfészeken keresztül.
házigazda Használja a gazda hálózati kötegét a tárolóban.
tartály : <név | id> Használja a másik tárolónak a hálózat nevét vagy azonosítóját .
HÁLÓZAT Csatlakoztatja a tartályt egy felhasználó által létrehozott hálózathoz (a docker network create parancs segítségével)
Hálózat: nincs

A hálózatban none olyan konténer, amely nem férhet hozzá külső útvonalakhoz. A tartálynak továbbra is engedélyezett egy loopback interfésze a konténerben, de nincsenek útvonalai a külső forgalom számára.

Hálózat: híd

A konténer bridge beállított hálózat a docker alapértelmezett hálózati beállításait fogja használni. A gazdagépen egy híd van beállítva, amelyet általában docker0 , és pár veth hoz létre a konténer számára. Az veth pár egyik oldala a hídon lévő gazdagépen fog maradni, míg a pár másik oldala a konténer veth belsejébe kerül a loopback interfész mellett. Egy IP-címet fognak kiosztani a konténerek számára a híd hálózatán, és a forgalmat a konténerhez vezető híd irányítja.

A konténerek alapértelmezés szerint kommunikálhatnak az IP-címükön. Név szerinti kommunikációhoz kapcsolódni kell.

Hálózat: fogadó

A konténer fogadó hálózatának megosztása esetén a fogadó hálózati veremét megosztja, és a gazdagép összes interfésze elérhető lesz a tároló számára. A konténer gazdanévje megegyezik a gazdanév gazdagépnevével. Ne feledje, hogy a --mac-address érvénytelen a host netmode-ban. A host hálózati módban a konténer alapértelmezés szerint saját UTS-névteret is tartalmaz. Mint ilyen, a --hostname megengedett a --hostname módban, és csak a konténeren belüli gazdanevet fogja megváltoztatni. Hasonlóan a --hostname , a --add-host , --dns , --dns-search és --dns-option opciókat host hálózati módban lehet használni. Ezek a beállítások frissítik az /etc/hosts vagy a /etc/resolv.conf a tárolóban. A /etc/hosts és /etc/resolv.conf .

Az alapértelmezett bridge összehasonlítva a host mód jelentősen jobb hálózati teljesítményt nyújt, mivel a gazdagép saját hálózatépítő veremét használja, míg a hídnak a dokkoló-démonon keresztül kell haladnia a virtualizáció egy szintjén. Ajánlatos konténereket futtatni ebben a módban, amikor a hálózatépítési teljesítményük kritikus, például egy termelési Load Balancer vagy egy nagy teljesítményű webszerver.

Megjegyzés : --network="host" a konténer teljes hozzáférést biztosít a helyi rendszerszolgáltatásokhoz, például a D-buszhoz, és így bizonytalannak tekinthető.

Hálózat: konténer

A container beállított hálózattal egy konténer megosztja egy másik tároló hálózat veremét. A másik tároló nevét a következőképpen kell megadni: - --network container:<name|id> . Vegye figyelembe, hogy az --add-host --hostname --dns --dns-search --dns-option és a --mac-address érvénytelen a container netmode-ban, és a --publish --publish-all --expose szintén érvénytelen container netmode-ben.

Példa egy Redis konténer futtatására Redis-val, amely a localhost kötődik, majd futtatja a redis-cli parancsot, és csatlakozik a Redis szerverhez a localhost felületen.

 $ docker run -d --name redis example/redis --bind 127.0.0.1 $ # use the redis container's network stack to access localhost $ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
Felhasználó által definiált hálózat

Hálózatot hozhat létre Docker hálózati illesztőprogram vagy külső hálózati illesztőprogram-bővítmény használatával. Több tárolót is csatlakoztathat ugyanazon a hálózaton. Ha egy felhasználó által meghatározott hálózathoz csatlakozik, a konténerek könnyen kommunikálhatnak csak egy másik konténer IP-címét vagy nevét használva.

A többcsatornás kapcsolatot támogató overlay hálózatokhoz vagy egyedi bővítményekhez hasonlóan ugyanazon multi-host hálózathoz csatlakozó, de különböző motorokról indított konténerek is így kommunikálhatnak.

A következő példa létrehoz egy hálózatot a beépített hídhálózat-illesztőprogram használatával és egy tároló futtatásával a létrehozott hálózatban

 $ docker network create -d bridge my-net $ docker run --network=my-net -itd --name=container3 busybox
Az / etc / hosts kezelése

Az Ön konténerének sorai vannak a /etc/hosts amelyek meghatározzák a tároló hostname-jét, valamint a localhost és néhány más közönséget. Az --add-host flag felhasználható további sorok hozzáadására az /etc/hosts .

 $ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts 172.17.0.22 09d03f76bf2c fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback 86.75.30.9 db-static
Ha egy konténer csatlakozik az alapértelmezett hídhálózathoz és más tárolóeszközökkel van linked , akkor a konténer /etc/hosts fájljája a csatolt konténer nevével frissül.

Megjegyzés Mivel a Docker frissíteni tudja a tároló /etc/hosts fájlját, esetleg előfordulhatnak olyan helyzetek, amikor a tartályon belüli folyamatok végül egy üres vagy hiányos /etc/hosts fájlt olvasnak. A legtöbb esetben újra kell próbálnunk újra olvasni a problémát.

Újraindítási házirendek (-restart)

A --restart zászló használata a Docker futtatásakor megadhatja az újraindítási házirendet, hogy miként kell a konténert újraindítani vagy kilépni.

Ha egy újraindítási házirend aktív egy konténeren, akkor az fel lesz docker ps vagy újraindul a docker ps . Hasznos lehet a docker events használata is, hogy az újraindítási házirend érvényes legyen.

A Docker a következő újraindítási házirendeket támogatja:

Irányelv Eredmény
nem Ne indítsa újra automatikusan a tartályt, amikor kilép. Ez az alapértelmezett.
meghibásodás [: max-próbálkozások] Indítsa újra csak akkor, ha a konténer nem nulla kioldási állapotból lép ki. Opcionálisan korlátozhatja az újraindítás számát, újra megkísérli a Docker démon kísérleteket.
mindig Mindig indítsa újra a tartályt a kijárati állapottól függetlenül. Ha mindig megadja, a Docker démon megpróbálja végleg indítani a konténert. A tartály mindig elindul a démon indításakor, függetlenül a tartály aktuális állapotától.
kivéve, ha-megállt Mindig indítsa újra a tartályt a kijárati állapottól függetlenül, de ne indítsa el a démon indításakor, ha a tartályt előzőleg leállította.
Minden egyes újraindítás előtt egyre több késleltetést (duplája az előző késleltetésnek, 100 milliszekundumot meg kell kezdeni), hogy elkerülje a szerver elárasztását. Ez azt jelenti, hogy a démon 100 ms-ra, majd 200 ms-ra, 400-ra, 800-ra, 1600-ra és így tovább vár, amíg a on-failure nem docker stop , vagy ha a docker stop vagy docker rm -f a konténert.

Ha a konténer sikeresen újraindul (a konténer elindul, és legalább 10 másodpercig fut), a késleltetés alapértelmezett értéke 100 ms.

Megadhatja, hogy a Docker mennyi ideig próbálja újraindítani a tartályt, ha a hibaüzenetet használja. Alapértelmezés szerint a Docker örökre megpróbálja újraindítani a tartályt. A konténerhez tartozó (kísérletezett) újraindítások száma a docker inspect révén érhető el. Például az "én-konténer" konténer újraindításához;

 $ docker inspect -f "{{ .RestartCount }}" my-container # 2
Vagy az utolsó alkalommal, amikor a tartály újraindításra került;

 $ docker inspect -f "{{ .State.StartedAt }}" my-container # 2015-03-04T23:47:07.691840179Z
A --restart (újraindítási) házirend - a --rm (tisztítás) zászló kombinálása hibát eredményez. A konténer újraindításakor a csatolt ügyfelek le vannak kapcsolva. Lásd a példákat a --rm (tisztítás) zászló használatáról ezen az oldalon.

Példák

 $ docker run --restart=always redis
Ezzel az újraindítási házirendet mindig a redis konténer futtatja, így ha a konténer kilép, a Docker újraindítja.

 $ docker run --restart=on-failure:10 redis
Ezzel a redis tartály újraindítási házirendet fog végrehajtani a hiba esetén, és a maximális újraindítási szám 10 lehet. Ha a redis tartály több mint 10-szer egymás után nem nulla redis lép ki, a Docker megszakítja a tároló újraindítását. A maximális újraindítási határérték megadása csak a meghibásodási házirendre érvényes.

Kilépési állapot

A kilépési kód a docker run ad tájékoztatást arról, hogy miért nem futott a konténer, vagy miért lépett ki a rendszer. Ha a docker run egy nem nulla kóddal kilép, a kilépési kód követi a chroot szabványt, lásd alább:

125 ha a hiba maga a Docker démon

 $ docker run --foo busybox; echo $? # flag provided but not defined: --foo See 'docker run --help'. 125
126 ha a zárt parancs nem használható

 $ docker run busybox /etc; echo $? # docker: Error response from daemon: Container command '/etc' could not be invoked. 126
127 ha a zárolt parancs nem található

 $ docker run busybox foo; echo $? # docker: Error response from daemon: Container command 'foo' not found or does not exist. 127
Másik utasítás kilépési kódja

 $ docker run busybox /bin/sh -c 'exit 3'; echo $? # 3
Tisztítás (-rm)

Alapértelmezés szerint a konténer fájlrendszere a konténer kilépése után is fennáll. Ez megkönnyíti a hibakeresést (mivel ellenőrizheti az utolsó állapotot), és alapértelmezés szerint megőrzi az összes adatot. De ha rövid távú előtérbeli folyamatokat használ , ezek a konténeres fájlrendszerek valóban felhalmozódnak. Ha azt szeretné, hogy a Docker automatikusan kitisztítsa a tartályt, és távolítsa el a fájlrendszert, amikor a konténer kilép , hozzáadhatja a --rm flag:

 --rm=false: Automatically remove the container when it exits (incompatible with -d)
Megjegyzés : A --rm jelző beállításakor a Docker eltávolítja a tartályhoz tartozó köteteket is, amikor a tartályt eltávolítják. Ez hasonló a futó docker rm -v my-container . Csak a név nélkül megadott kötetek kerülnek eltávolításra. Például a docker run --rm -v /foo -v awesome:/bar busybox top , a /foo kötet eltávolításra kerül, de a /bar nem. A --volumes-from on keresztül --volumes-from kötetek ugyanazzal a logikával törlődnek - ha az eredeti kötetet egy névvel adták meg, akkor nem kerül eltávolításra.

Biztonsági konfiguráció

 --security-opt="label=user:USER" : Set the label user for the container --security-opt="label=role:ROLE" : Set the label role for the container --security-opt="label=type:TYPE" : Set the label type for the container --security-opt="label=level:LEVEL" : Set the label level for the container --security-opt="label=disable" : Turn off label confinement for the container --security-opt="apparmor=PROFILE" : Set the apparmor profile to be applied to the container --security-opt="no-new-privileges:true|false" : Disable/enable container processes from gaining new privileges --security-opt="seccomp=unconfined" : Turn off seccomp confinement for the container --security-opt="seccomp=profile.json": White listed syscalls seccomp Json file to be used as a seccomp filter
Az egyes konténerek alapértelmezett címkézési sémáját felülbírálhatja a --security-opt flag --security-opt . A következő parancs szintjének megadása lehetővé teszi ugyanazt a tartalmat a konténerek között.

 $ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
Megjegyzés : Az MLS címkék automatikus fordítása jelenleg nem támogatott.

A konténer biztonsági címkézésének tiltása és a - --privileged zászlóval történő --privileged a következő paranccsal:

 $ docker run --security-opt label=disable -it fedora bash
Ha egy tartályon belüli folyamatokra szigorúbb biztonsági házirendet szeretne, megadhatja a tároló másik típusát. Futtathat egy olyan tárolót, amely csak az Apache-portokon hallgatható, ha végrehajtja a következő parancsot:

 $ docker run --security-opt label=type:svirt_apache_t -it centos bash
Megjegyzés : Meg kell írni a svirt_apache_t típusú definíciót.

Ha meg szeretné akadályozni, hogy a konténer folyamata további jogosultságokat szerezzen, akkor a következő parancsot hajthatja végre:

 $ docker run --security-opt no-new-privileges -it centos bash
Ez azt jelenti, hogy az olyan parancsok, amelyek kiváltságokat emelnek, mint a su vagy a sudo , már nem működnek. Ez azt is okozza, hogy a seccomp szűrők később kerülnek alkalmazásra, miután a jogosultságok le lettek dobva, ami azt jelentheti, hogy korlátozottabb szűrőkészletet találhat. További részletekért lásd a rendszermag dokumentációját .

Adja meg az init folyamatát

Használhatja a --init jelzőt arra az --init , ha egy init-folyamatot PID 1 -ként kell használni a tartályban. Az init eljárás megadása biztosítja az init rendszer szokásos feladatait, például a zombi folyamatok leküzdését a létrehozott tárolóban.

Az alapértelmezett init eljárás az első docker-init futtatható fájl, amely a Docker démon folyamatának elérési útjában található. Ez a docker-init bináris, amelyet az alapértelmezett telepítés tartalmazza, tini .

Adja meg az egyéni csoportokat

A --cgroup-parent flag használatával átadhatja a megadott csoportot, hogy futtasson egy konténert. Ez lehetővé teszi a csoportok létrehozását és kezelését. Megadhatja az egyéni erőforrásokat ezeknek a csoportoknak, és a konténereket egy közös szülőcsoport alá helyezheti.

Az erőforrások futási idejének korlátai

A kezelő a konténer teljesítményparamétereit is beállíthatja:

választási lehetőség Leírás
-m , --memory="" Memória korlát (formátum: <number>[<unit>] ). A szám pozitív egész szám. Az egység lehet b , k , m vagy g egyike. A minimum 4M.
--memory-swap="" Teljes memória korlát (memória + swap, formátum: <number>[<unit>] ). A szám pozitív egész szám. Az egység lehet b , k , m vagy g egyike.
--memory-reservation="" Memory soft limit (formátum: <number>[<unit>] ). A szám pozitív egész szám. Az egység lehet b , k , m vagy g egyike.
--kernel-memory="" Kernel memória korlát (formátum: <number>[<unit>] ). A szám pozitív egész szám. Az egység lehet b , k , m vagy g egyike. A minimum 4M.
-c , --cpu-shares=0 CPU-részvények (relatív súly)
--cpus=0.000 CPU-k száma. A szám tört szám. 0.000 nem jelent korlátot.
--cpu-period=0 Határozza meg a CPU CFS (Teljesen Fair Scheduler) időtartamát
--cpuset-cpus="" CPU-k, amelyeknél engedélyezni kell a végrehajtást (0-3, 0,1)
--cpuset-mems="" Memóriacsomópontok (MEMs), amelyekben engedélyezik a végrehajtást (0-3, 0,1). Csak a NUMA rendszerekre érvényes.
--cpu-quota=0 Határozza meg a CPU CFS (Teljesen Fair Scheduler) kvótát
--cpu-rt-period=0 Korlátozza a CPU valós idejét. Mikroszekundumban. Szükséges a szülőcsoportok beállítása, és nem lehet nagyobb, mint a szülő. Szintén ellenőrizze az rtprio ulimits-et.
--cpu-rt-runtime=0 Korlátozza a CPU valós idejű futási idejét. Mikroszekundumban. Szükséges a szülőcsoportok beállítása, és nem lehet nagyobb, mint a szülő. Szintén ellenőrizze az rtprio ulimits-et.
--blkio-weight=0 Az IO blokk tömege (relatív súly) 10 és 1000 közötti súlyértéket fogad el.
--blkio-weight-device="" IO blokk súlya (relatív eszköz súlya, formátum: DEVICE_NAME:WEIGHT )
--device-read-bps="" Korlátozza az olvasási sebességet egy eszközről (formátum: <device-path>:<number>[<unit>] ). A szám pozitív egész szám. Az egység lehet az kb , mb vagy gb egyike.
--device-write-bps="" Limit írási sebesség egy eszközre (formátum: <device-path>:<number>[<unit>] ). A szám pozitív egész szám. Az egység lehet az kb , mb vagy gb egyike.
--device-read-iops="" Határérték leolvasási sebesség (IO másodpercenként) egy eszközről (formátum: <device-path>:<number> ). A szám pozitív egész szám.
--device-write-iops="" Limit írási sebesség (IO másodpercenként) egy eszközre (formátum: <device-path>:<number> ). A szám pozitív egész szám.
--oom-kill-disable=false Függetlenül attól, hogy letiltja-e az OOM Killer-t a tároló számára, vagy sem.
--oom-score-adj=0 A konténer OOM preferenciái (-1000 és 1000 között)
--memory-swappiness="" Állítsa be a tároló memória swappiness viselkedését. 0 és 100 közötti egész számot fogad el.
--shm-size="" A /dev/shm mérete. A formátum <number><unit> . number nagyobbnak kell lennie mint 0 . Az egység opcionális, és lehet b (bájt), k (kilobájt), m (megabyte) vagy g (gigabájt). Ha elhagyja az egységet, a rendszer byte-ot használ. Ha teljesen kihagyja a méretet, a rendszer 64m használ.
Felhasználói memória korlátozások

A felhasználói memória használatának négy módja van:

választási lehetőség Eredmény
memória = inf, memória-swap = inf (alapértelmezett) Nincs tárolási korlát a tároló számára. A konténer annyi memóriát használhat, amennyire szüksége van.
memória = L <inf, memória-swap = inf (adjon meg memóriát és állítsa be a memóriacserét -1 ) A konténer nem használhat több memóriát, mint a bájtnyi memóriát, de annyi swapet használhat, amennyire szükséges (ha a gazda támogatja a swap memóriát).
memória = L <inf, memória-swap = 2 * L (a memória cseréje nélkül kell megadni a memóriát) A konténer nem használhat több memóriabájtot, mint a bájt, a swap és a memóriahasználat kétszer annyi.
memória = L <inf, memória-swap = S <inf, L <= S (adjon meg mind memóriát, mind memóriakártyát) A konténer nem használhat több memória-bájtot, a swap és a memóriahasználatot S korlátozza.
Példák:

 $ docker run -it ubuntu:14.04 /bin/bash
Nem állítunk semmit a memóriáról, ez azt jelenti, hogy a tárolóban lévő folyamatok annyi memóriát használhatnak, amennyire szükségük van.

 $ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
Beállítjuk a memória korlátot és a letiltott swap memória korlátot, ez azt jelenti, hogy a tárolóban lévő folyamatok 300M memóriát és annyi swap memóriát használhatnak (ha a gazda támogatja a swap memóriát).

 $ docker run -it -m 300M ubuntu:14.04 /bin/bash
Csak memóriahatárt állítunk be, ez azt jelenti, hogy a tárolóban lévő folyamatok 300M memóriát és 300M-os swap memóriát használnak, alapértelmezés szerint a teljes virtuális memória méretét (-memória-swap) a memória duplájára állítjuk be, ebben az esetben a memória + swap lenne 2 * 300M, így a folyamatok 300M-os swap memóriát is használhatnak.

 $ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
Mind a memóriát, mind a swap memóriát beállítjuk, így a tárolóban lévő folyamatok 300M memóriát és 700M-os swap memóriát használhatnak.

A memóriafoglalás egyfajta memória-puha határ, amely lehetővé teszi a memória nagyobb megosztását. Normális körülmények között a tárolók a memóriában a legtöbb memóriát használhatják, és csak a -m / - --memory opcióval beállított kemény határok korlátozzák. Ha memóriafoglalást állít be, a Docker felismeri a memóriahelyzetet vagy az alacsony memóriát, és kényszeríti a tárolókat, hogy korlátozzák a fogyasztást a foglalási korlátra.

Mindig határozza meg a memória fenntartási értékét a hard limit alatt, ellenkező esetben a kemény határ elsőbbséget élvez. A 0 foglalás ugyanaz, mint a foglalás beállítása. Alapértelmezés szerint (fenntartás nélküli beállítás nélkül) a memóriafoglalás megegyezik a memória korláttal.

A memóriafoglalás soft limit funkció, és nem garantálja, hogy a határértéket nem lépik túl. Ehelyett a szolgáltatás megpróbálja biztosítani, hogy ha a memóriát erősen megkérdezi, a memória a foglalási tanácsok / beállítások alapján kerül felosztásra.

A következő példa korlátozza a memóriát ( -m ) 500M-re és beállítja a memóriafoglalást 200M-re.

 $ docker run -it -m 500M --memory-reservation 200M ubuntu:14.04 /bin/bash
Ebben a konfigurációban, ha a tároló 200M-nál nagyobb és 500M-nál kisebb memóriát fogyaszt, a következő rendszer memória megismétlődik, megkísérli összezúzni a tároló memóriáját 200M alatt.

A következő példában a memóriafoglalást 1G-ra kell beállítani, a memória korlátozása nélkül.

 $ docker run -it --memory-reservation 1G ubuntu:14.04 /bin/bash
A tartály annyi memóriát használhat, amennyire szüksége van. A memóriafoglalási beállítás biztosítja, hogy a tároló nem sokáig fogyaszt túl nagy memóriát, mert minden memória visszanyerése összezsugorítja a tároló fogyasztását a foglaláshoz.

Alapértelmezés szerint a rendszermag megöli a tárolóban lévő folyamatokat, ha egy memória (OOM) hiba lép fel. A viselkedés megváltoztatásához használja a --oom-kill-disable beállítást. Csak tiltsa le az OOM gyilkos konténereken, ahol szintén beállította a -m/--memory opciót. Ha a -m flag nincs beállítva, akkor ez azt eredményezheti, hogy a gazdagép elfogy a memóriából, és megköveteli, hogy a gazdagép rendszerfolyamatait megöli a memória szabaddá tétele érdekében.

A következő példa 100M-ra korlátozza a memóriát, és letiltja az OOM gyilkosát ehhez a tartályhoz:

 $ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
A következő példa a zászló használatának veszélyes módját szemlélteti:

 $ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
A konténer korlátlan memóriával rendelkezik, ami a gazdagép számára a memória kiürítését eredményezheti, és megköveteli, hogy megölik a rendszerfolyamatokat a memória felszabadítása érdekében. A --oom-score-adj paraméter megváltoztatható annak érdekében, hogy kiválassza a konténerek elsőbbségét, amikor a rendszer ki van --oom-score-adj a memóriából, negatív pontszámokkal pedig kevésbé valószínű, hogy megöltek és pozitív pontszámokat nagyobb valószínűséggel.

A kernel memória korlátai

A rendszermag memóriája alapvetően különbözik a felhasználói memóriától, mivel a rendszermag memóriája nem cserélhető ki. A cserélhetetlenség lehetővé teszi, hogy a konténer túlságosan kernel memóriát fogyasztva blokkolja a rendszer szolgáltatásait. A rendszermag memóriája a következőket tartalmazza:

verem oldalak
lapos oldalak
aljzat memória nyomása
tcp memória nyomás
Beállíthatja a rendszermag memória korlátját, hogy korlátozza az ilyen típusú memóriát. Például minden egyes folyamat egyes kötegoldalakat fogyaszt. A rendszermag memóriájának korlátozásával megakadályozhatja az új folyamatok létrehozását, ha a rendszermag memóriahasználata túl magas.

A rendszermag memória soha nem teljesen független a felhasználói memóriától. Ehelyett korlátozza a rendszermag memóriát a felhasználói memória korlátain belül. Tegyük fel, hogy az "U" a felhasználói memória korlátja és "K" a rendszermag korlátja. A határértékek három lehetséges módja van:

választási lehetőség Eredmény
U! = 0, K = inf (alapértelmezett) Ez a normál memória korláto zási mechanizmus már jelen van a kernel memória használata előtt. A rendszermag memóriáját teljesen figyelmen kívül hagyja.
U! = 0, K <U A rendszermag memória a felhasználói memória egy részhalmaza. Ez a beállítás olyan telepítések esetén hasznos, ahol a memória összmennyisége túlzsúfolt. A rendszermag memóriahatárok leküzdése nem feltétlenül ajánlott, mivel a doboz még mindig elmarad a nem regenerálható memóriából. Ebben az esetben beállíthatja a K-t úgy, hogy az összes csoport összege soha ne legyen nagyobb, mint a teljes memória. Ezután szabadon beállíthatja az U-t a rendszer szolgáltatásminőségének kárára.
U! = 0, K> U Mivel a rendszermag memóriaterheket a felhasználói számlálóhoz is táplálják, a reklamáció a tároló számára mindkét típusú memória számára aktiválódik. Ez a konfiguráció biztosítja az adminisztrátor számára a memória egységes nézetét. Ezenkívül olyan felhasználók számára is hasznos, akik csak a rendszermag memóriahasználatát szeretnék követni.
Példák:

 $ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
A memóriát és a rendszermemóriát úgy állítottuk be, hogy a tárolóban lévő folyamatok összesen 500M memóriát használjanak, ebben az 500M-os memóriában 50M-es rendszermag memóriaterületek lehetnek.

 $ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
A rendszermag memóriát -m nélkül állítjuk be , így a tárolóban lévő folyamatok annyi memóriát használhatnak, amennyit csak akarnak, de csak 50M rendszermemóriát használhatnak.

Swappiness korlát

Alapértelmezés szerint a tartály rendszermagja felcserélheti az anonim oldalak százalékát. Ha ezt a százalékot egy konténerre kívánja állítani, adja meg a --memory-swappiness értéket 0 és 100 között. A 0 érték kikapcsolja a névtelen --memory-swappiness . A 100-as érték az összes névtelen oldalt cserélhetővé teszi.Alapértelmezésben, ha nem használja --memory-swappiness, a memória swappiness érték kerül örökölt a szülő.

Például beállíthatja:

 $ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
Beállítása --memory-swappinessopció akkor hasznos, ha meg akarja őrizni a tartály munkakészlet, és hogy elkerüljék csere teljesítmény szankciókat.

CPU megosztás megszorítás

Alapértelmezésben az összes konténer kap ugyanolyan arányban CPU. Ez az arány lehet módosítani megváltoztatásával a konténer CPU részesedése súlyozás képest súlyozását minden más futó konténerek.

Ha módosítani aránya az alapértelmezett 1024, használja a -cvagy --cpu-shareszászló beállítani a súlyozást 2. vagy magasabb. Ha 0 van beállítva, akkor a rendszer figyelmen kívül hagyja az értéket és az alapértelmezett 1024.

Az arány csak akkor érvényes, ha a CPU-intenzív folyamatok futnak. Ha a feladatokat egyetlen konténer tétlen, más tartály használhatja a megmaradt CPU időt. A tényleges összeg CPU idő függ a konténerek száma a rendszeren futó.

Vegyük például három tartály, az egyik egy cpu-share 1024 és két másik van egy cpu-share beállítása 512. Ha egy folyamat mindhárom konténerek próbálja használni 100% CPU, az első tartály kapna 50% -a teljes CPU időt. Ha hozzá egy negyedik tartályt egy cpu-share 1024, az első tartály csak egyre 33% a CPU. A megmaradt tartályokat kap 16,5%, 16,5% és 33% a CPU.

Egy multi-core rendszer, a részvények a CPU időben vannak elosztva az összes CPU magok. Még ha egy tartály csak kevesebb, mint 100% CPU idő, akkor 100% -ban az egyes CPU-mag.

Vegyük például a rendszer több mint három magot. Ha elkezd egy tartályból a futás egy folyamat, és egy másik tartályba a futó két folyamat, ez azt eredményezheti, hogy a következő részlege CPU részvények:{ C0 }-c=512{ C1 }-c=1024

 PID container CPU CPU share 100 {C0} 0 100% of CPU0 101 {C1} 1 100% of CPU1 102 {C1} 2 100% of CPU2
CPU időszak megszorítás

Az alapértelmezett CPU CFS (teljesen igazságos Scheduler) időszak 100ms. Tudjuk használni --cpu-periodbeállítani időszak CPU, hogy korlátozza a tartály a CPU használat. És általában --cpu-periodmeg kell dolgozni --cpu-quota.

Példák:

 $ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
Ha van 1 CPU, ez azt jelenti, hogy a tartály 50% CPU értékű futásidejű minden 50 ms.

Amellett, hogy használja --cpu-periodés --cpu-quotabeállítására CPU időszakban korlátok, lehetőség van arra, hogy meghatározza --cpusaz úszó szám elérni ugyanazt a célt. Például, ha van 1 CPU, akkor --cpus=0.5fogja elérni ugyanazt az eredményt, mint a beállítás --cpu-period=50000és a --cpu-quota=25000(50% CPU).

Az alapértelmezett érték --cpusaz 0.000, ami azt jelenti, nincs korlátozás.

További információkért tekintse meg a CFS dokumentáció sávszélességkorlátozást .

Cpuset megszorítás

Mi lehet állítani CPU, amelyben futtatását teszi lehetővé a konténerek.

Példák:

 $ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
Ez azt jelenti, folyamatok tartályban lehet végrehajtani CPU 1 és a CPU 3.

 $ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
Ez azt jelenti, folyamatok tartályban lehet végrehajtani CPU 0, 1 CPU és a CPU 2.

Mi lehet állítani mems, amelyben futtatását teszi lehetővé a konténerek. Csak akkor érvényes a NUMA rendszerek.

Példák:

 $ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
Ez a példa korlátozza a folyamatok a tartályban, hogy csak memóriát a memóriából csomópontok 1 és 3.

 $ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
Ez a példa korlátozza a folyamatok a tartályban, hogy csak memóriát a memóriából csomópontok 0, 1 és 2.

CPU kvóta megszorítás

A --cpu-quotazászló korlátozza a tároló a CPU használat. Az alapértelmezett 0 érték lehetővé teszi a tartály, hogy 100% -os CPU erőforrás (1 CPU). A CFS (teljesen igazságos Scheduler) kezeli erőforrás allokációt végrehajtó folyamatok és az alapértelmezett Linux ütemező által használt kernel. Ezt az értéket 50000 korlátozzák a tartály 50% CPU erőforrás. Mert több CPU, állítsa be a --cpu-quotaszükséges. További információkért tekintse meg a CFS dokumentáció sávszélességkorlátozást .

Block IO sávszélesség (Blkio) kényszer

Alapértelmezésben az összes konténer kap ugyanolyan arányban blokk IO sávszélesség (blkio). Ez az arány 500. módosításához ez az arány, a változás a tartály blkio viszonyított tömeg súlyozását minden más futó konténerek felhasználásával --blkio-weightzászlót.

Megjegyzés: A blkio súly beállítás csak a közvetlen IO. Pufferolt IO jelenleg nem támogatott.

A --blkio-weightzászló beállíthatja a súlyozási közötti értékre 10 1000. Például, az alábbi parancsokkal hozzon létre két konténerek különböző blkio súlya:

 $ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash $ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
Ha blokkolni IO a két konténer ugyanabban az időben, például:

 $ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
Megtudja, hogy ez az arány az idő ugyanaz, mint az aránya blkio súlyok a két konténer.

A --blkio-weight-device="DEVICE_NAME:WEIGHT"zászló állítja egy adott eszköz súlyát. A DEVICE_NAME:WEIGHTjelentése egy karaktersorozattal kettősponttal elválasztott eszköz neve és a súly. Például, hogy állítsa /dev/sdaeszköz súly 200:

 $ docker run -it \ --blkio-weight-device "/dev/sda:200" \ ubuntu
Ha megadtuk a --blkio-weightés --blkio-weight-device, Docker használja --blkio-weightaz alapértelmezett súly és használja --blkio-weight-device, hogy felülbírálja az alapértelmezett egy új értéket egy adott eszköz. A következő példa egy alapértelmezett súlya 300és felülbírálja az alapértelmezés /dev/sdabeállítás, súly 200:

 $ docker run -it \ --blkio-weight 300 \ --blkio-weight-device "/dev/sda:200" \ ubuntu
A --device-read-bpszászló korlátozza az olvasási sebesség (bájt per másodperc) egy eszköz. Például ez a parancs létrehoz egy tartályt, és korlátozza az olvasási sebességet 1mbmásodpercenként /dev/sda:

 $ docker run -it --device-read-bps /dev/sda:1mb ubuntu
A --device-write-bpszászló korlátozza az írási sebesség (bájt másodpercenként), hogy egy eszközt. Például ez a parancs létrehoz egy tartályt, és korlátozza az írási sebességet 1mbmásodpercenként /dev/sda:

 $ docker run -it --device-write-bps /dev/sda:1mb ubuntu
Mindkét zászlók hogy mérték a <device-path>:<limit>[unit]formátumban. Írási és olvasási aránya kell egy pozitív egész szám. Megadhatja a ráta kb(kilobájt), mb(megabájt) vagy gb(gigabájt).

A --device-read-iopszászló határértékek olvasható ráta (IO másodpercenként) egy eszköz. Például ez a parancs létrehoz egy tartályt, és korlátozza az olvasási sebességet 1000IO másodpercenként /dev/sda:

 $ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
A --device-write-iopszászló korlátok levelet arány (IO per second) egy eszközhöz. Például ez a parancs létrehoz egy tartályt, és korlátozza az írási sebességet 1000IO másodpercenként /dev/sda:

 $ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
Mindkét zászlók hogy mérték a <device-path>:<limit>formátumban. Írási és olvasási aránya kell egy pozitív egész szám.

további csoportok

 --group-add: Add additional groups to run as
Alapértelmezésben a dokkoló tartály folyamat fut a kiegészítő csoportok felnézett az adott felhasználó. Ha valaki meg akarja hozzá inkább, hogy a csoportok listája, akkor lehet használni ezt a zászlót:

 $ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777
Runtime kiváltság és Linux képességeit

 --cap-add: Add Linux capabilities --cap-drop: Drop Linux capabilities --privileged=false: Give extended privileges to this container --device=[]: Allows you to run devices inside the container without the --privileged flag.
Alapértelmezésben Docker tartályok „privilegizált”, és nem például futtatni egy Docker démon belül Docker tartályba. Ez azért van, mert alapértelmezés szerint a tartály nem férhetnek hozzá semmilyen eszköz, hanem a „kiváltságos” tartály férjen az összes eszköz (lásd a dokumentációt cgroups eszközök ).

Ha az üzemeltető hajt végre docker run --privileged, Docker lehetővé teszi hozzáférést biztosít az összes eszköz a fogadó, valamint meg néhány konfiguráció AppArmorral vagy SELinux, hogy a konténer szinte mindegy hozzáférést a gazdaszervezet futó folyamatokat kívül konténerek a gazda. További információkért fut --privilegedelérhető a Docker Blog .

Ha azt szeretnénk, hogy korlátozza a hozzáférést egy adott eszköz vagy eszközök segítségével a --devicezászlót. Ez lehetővé teszi, hogy meghatározza egy vagy több eszköz lesz elérhető a tartályon belül.

 $ docker run --device=/dev/snd:/dev/snd ...
Alapértelmezésben a tartály képes lesz read, writeés mknodezeket az eszközöket. Ezt felül lehet bírálni egy harmadik :rwmsor lehetőséget, hogy minden egyes --devicezászló:

 $ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc Command (m for help): q $ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc You will not be able to write the partition table. Command (m for help): q $ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc crash.... $ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc fdisk: unable to open /dev/xvdc: Operation not permitted
Amellett, hogy --privilegedaz üzemeltető lehet finomszemcsés felett a képességeit használja --cap-addés --cap-drop. Alapértelmezésben Docker van egy alapértelmezett lista a képességeket, amelyek tartják. Az alábbi táblázat a Linux képes lehetőségeket, amelyek alapértelmezés szerint engedélyezve vannak, és el lehet dobni.

Capability Key képesség leírása
SETPCAP Módosíthatja folyamatban képességeket.
mknod Készítsen speciális fájlok mknod (2).
AUDIT_WRITE Írja bejegyzések kernel ellenőrzési napló.
chown Önkényes változtatásokat fájlba UID és GID (lásd chown (2) bekezdés).
net_raw Használja RAW és a csomag aljzatok.
DAC_OVERRIDE Bypass fájl olvasási, írási és futtatási jogot ellenőrzéseket.
FOWNER Bypass engedélyt a műveletek ellenőrzését, hogy normál körülmények között fájlrendszer UID a folyamat, hogy megfeleljen az UID a fájl.
FSETID Nem világos, set-felhasználói azonosító és a set-group-ID engedély bitet, ha egy fájlt módosítani.
MEGÖL Bypass engedélyt ellenőrzi jeleket.
setgid Önkényesen manipulációk folyamat csoport- és kiegészítő GID listát.
SETUID Önkényesen manipulációknak folyamat UID.
NET_BIND_SERVICE Kötődnek a socket internetes domain privilegizált portok (port szám 1024-nél kisebb).
SYS_CHROOT Felhasználási chroot (2), change root könyvtárba.
SETFCAP Állítsa fájl képességeit.
A következő táblázat mutatja a képességek, amelyek nem kapják meg alapértelmezés szerint adhatunk hozzá.

Capability Key képesség leírása
SYS_MODULE Ki- és berakodása kernel modulokat.
SYS_RAWIO Végre I / O port műveletek (iopl (2) és a ioperm (2)).
SYS_PACCT Használja acct (2), kapcsoló folyamat számviteli be- vagy kikapcsolása.
SYS_ADMIN Végezze el a tartományban rendszerfelügyelet műveleteket.
SYS_NICE Emeljük folyamat szép érték (szép (2), setpriority (2)) és módosítsa a szép érték tetszőleges folyamatok.
SYS_RESOURCE Felülbírálása erõforráskorlátozás.
SYS_TIME Set rendszer órát (settimeofday (2), stime (2), adjtimex (2) bekezdés); megállapított valós idejű (hardver) órát.
SYS_TTY_CONFIG Használata vhangup (2); alkalmaznak különböző privilegizált ioctl (2) műveletek virtuális terminálok.
audit_control Engedélyezése és letiltása kernel könyvvizsgálat; megváltoztatni könyvvizsgálati szűrő szabályok; letölteni ellenőrzési állapot és szabályai.
MAC_OVERRIDE Hagyjuk MAC konfiguráció, vagy állapota megváltozik. Megvalósult a Smack LSM.
MAC_ADMIN Felülbírálása Kötelező hozzáférés-vezérlés (MAC). Megvalósult a Smack Linux biztonsági modul (LSM).
NET_ADMIN Végre a különböző hálózattal kapcsolatos műveleteket.
SYSLOG Végezze kiváltságos syslog (2) műveleteket.
DAC_READ_SEARCH Bypass fájl olvasási engedéllyel ellenőrzések és könyvtár olvasni és végrehajtási jogot ellenőrzéseket.
LINUX_IMMUTABLE Állítsa be a FS_APPEND_FL és FS_IMMUTABLE_FL i-node zászlókat.
NET_BROADCAST Tedd aljzat adások, és hallgatni multicasts.
IPC_LOCK Lock memória (MLOCK (2), mlockall (2), mmap (2), shmctl (2) bekezdés).
IPC_OWNER Bypass engedélyt ellenőrzi műveletek System V IPC tárgyakat.
SYS_PTRACE Trace tetszőleges folyamatok segítségével ptrace (2).
SYS_BOOT Használja reboot (2) és kexec_load (2), reboot, és betölti az új kernel későbbi végrehajtását.
BÉRLET Létrehozza lízing tetszőleges fájlokat (lásd fcntl (2) bekezdés).
WAKE_ALARM Trigger valamit, felébred a rendszert.
BLOCK_SUSPEND Foglalkoztatnak funkciók, amelyek blokkolják a rendszer felfüggeszti.
További referencia áll rendelkezésre információ a képességek (7) - Linux férfi oldal

Mindkét zászlók támogatja az értéke ALL, tehát ha az üzemeltető azt akarja, hogy az összes képességét, de MKNODtudták használni:

 $ docker run --cap-add=ALL --cap-drop=MKNOD ...
Kölcsönhatásban áll a hálózati verem használata helyett --privilegedkellene használni --cap-add=NET_ADMIN, hogy módosítsa a hálózati interfészeket.

 $ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy RTNETLINK answers: Operation not permitted $ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
Felmászik egy FUSE alapú fájlrendszer, akkor össze kell mind --cap-add, és --device:

 $ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt fuse: failed to open /dev/fuse: Operation not permitted $ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt fusermount: mount failed: Operation not permitted $ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs # sshfs sven@10.10.10.20:/home/sven /mnt The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established. ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6. Are you sure you want to continue connecting (yes/no)? yes sven@10.10.10.20's password: root@30aa0cfaf1b5:/# ls -la /mnt/src/docker total 1516 drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 . drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 .. -rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore -rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git -rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore ....
Az alapértelmezett seccomp profilt fogja igazítani a kiválasztott képességek, annak érdekében, hogy a létesítmények használatából által megengedett képességeit, így nem kell beállítani ezt, mert Docker 1.12. A Docker 1,10 és 1,11 ez nem történt meg, és szükséges lehet, hogy egy egyéni seccomp profilt, vagy használjon --security-opt seccomp=unconfined, ha hozzá képességeit.

Naplózás meghajtók (log-vezető)

A tartály lehet más naplózó vezető, mint a Docker démon. A következő --log-driver=VALUEa docker runparancsot a tartály naplózási driver. A következő lehetőségek állnak rendelkezésre:

Sofőr Leírás
none Kikapcsoljuk a naplózást a tartályba. docker logsnem lesz elérhető ez a meghajtó.
json-file Alapértelmezett fakitermelés driver Docker. Írások JSON üzenetek fájlba. Nincs naplózás lehetőséget támogat az illesztőprogram.
syslog Syslog fakitermelés driver Docker. Írások log üzeneteket syslog.
journald Journald fakitermelés driver Docker. Írja napló üzeneteket journald.
gelf Graylog Extended Log Format (GELF) fakitermelés driver Docker. Írások a naplózott üzeneteket a GELF végpont likeGraylog vagy Logstash.
fluentd Fluentd fakitermelés driver Docker. Írások log üzeneteket fluentd(előre input).
awslogs Amazon CloudWatch Rönk bejelentkezés driver Docker. Írások log üzeneteket Amazon CloudWatch Naplók
splunk Splunk fakitermelés driver Docker. Írások log üzenetek splunksegítségével Event Http Collector.
A docker logsparancs csak a json-fileés journaldfakitermelés járművezetők. További információt a dolgozó fakitermelés vezetők, lásd konfigurálása naplózási vezető .

Elsőbbség Dockerfile kép alapértékekre

Ha egy fejlesztő épít egy képet a Dockerfile vagy amikor elköveti, a fejlesztő lehet állítani számos alapértelmezett paraméterek lép életbe, amikor a kép elindul, mint egy konténer.

Négy Dockerfile parancsokat nem lehet felülbírálni a futás: FROM, MAINTAINER, RUNés ADD. Minden más van egy megfelelő kihagyást docker run. Majd megy át, amit a fejlesztő részére, már minden Dockerfile utasítást, és hogyan az üzemeltető felülírhatja ezt a beállítást.

CMD (alapértelmezett parancs vagy opciók)
BelépésiPont (alapértelmezett parancs végrehajtását a Runtime)
ÉRJE (Bejövő portok)
ENV (Környezeti változók)
ÁLLAPOTFELMÉRÉS
VOLUME (Shared Filesystems)
USER
WORKDIR
CMD (alapértelmezett parancs vagy opciós)

Emlékezzünk a választható COMMANDa Docker parancssori:

 $ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
Ez a parancs opcionális, mert az a személy, aki létrehozta a IMAGEtalán már biztosított alapértelmezett COMMANDa Dockerfile CMDutasítást. Mivel az üzemeltető (a személy fut a tartályt a képen), akkor felülírhatja, hogy CMDutasítást csak megadásával új COMMAND.

Ha a kép is meghatároz egy ENTRYPOINT, akkor a CMDvagy COMMANDkap hozzáfűzve érvek az ENTRYPOINT.

BelépésiPont (alapértelmezett parancs végrehajtását futásidőben)

 --entrypoint="": Overwrite the default entrypoint set by the image
Az ENTRYPOINTa kép hasonlít egy COMMAND, mert meghatározza, hogy milyen futtatható fut, amikor a tartály elindul, de ez (szándékosan) nehezebb felülírni. Az ENTRYPOINTad tartály alapértelmezett jellege vagy viselkedés, úgy, hogy ha egy meghatározott ENTRYPOINTfuttathatja a tartályt úgy, mintha, hogy a bináris , kiegészítve az alapértelmezett beállításokat, és akkor át több lehetőség révén COMMAND. De néha a kezelő szeretné futtatni valami mást a tartály belsejében, így felülbírálhatja az alapértelmezett ENTRYPOINTfutási időben segítségével karakterláncot adja meg az új ENTRYPOINT. Íme egy példa arra, hogyan fut a héj egy tartály, amely be van állítva, hogy automatikusan futtatni valami mást (például /usr/bin/redis-server):

 $ docker run -it --entrypoint /bin/bash example/redis
vagy két példát, hogyan kell átadni további paramétereket, hogy BelépésiPont:

 $ docker run -it --entrypoint /bin/bash example/redis -c ls -l $ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
Akkor vissza a konténerek BelépésiPont átadásával egy üres karakterlánc, például:

 $ docker run -it --entrypoint="" mysql bash
Megjegyzés : passz --entrypointtörli ki minden alapértelmezett parancs készlet a képre (azaz minden olyan CMDutasítást a Dockerfile használt építeni).

ÉRJE (bejövő portok)

A következő runparancs opciók dolgozni konténer hálózat:

 --expose=[]: Expose a port or a range of ports inside the container. These are additional to those exposed by the `EXPOSE` instruction -P : Publish all exposed ports to the host interfaces -p=[] : Publish a container᾿s port or a range of ports to the host format: ip:hostPort:containerPort | ip::containerPort | hostPort:containerPort | containerPort Both hostPort and containerPort can be specified as a range of ports. When specifying ranges for both, the number of container ports in the range must match the number of host ports in the range, for example: -p 1234-1236:1234-1236/tcp When specifying a range for hostPort only, the containerPort must not be a range. In this case the container port is published somewhere within the specified hostPort range. (eg, `-p 1234-1236:1234/tcp`) (use 'docker port' to see the actual mapping) --link="" : Add link to another container (<name or id>:alias or <name or id>)
Kivéve az EXPOSEirányelv egy kép fejlesztő nem kapott ekkora befolyása hálózatba. Az EXPOSEutasítás meghatározza a kezdeti bejövő portokat szolgáltatásnyújtás. Ezek a portok állnak folyamatok a tartály belsejében. Az üzemben használja a --exposelehetőséget, hogy hozzá a kitett port.

Hogy ki a tartály belső port, egy operátor lehet kezdeni a tartályt -Pvagy a -pzászlót. Az exponált port hozzáférhető a gazda és a portok állnak rendelkezésre minden ügyfél, amely elérheti a gazda.

Az -Popció közzéteszi az összes port a host interfészeket. Docker kötődik mindegyik szabadon port véletlenszerű port a gépen. A tartomány a portok belül egy ideiglenes portot tartományban által meghatározott /proc/sys/net/ipv4/ip_local_port_range. Használja a -pzászlót, hogy kifejezetten Térkép egyetlen kikötő vagy kikötők.

A port száma a tartályba (ha a szolgáltatás figyel) nem kell, hogy megfeleljen a port számát téve a külső tartály (ahol az ügyfelek csatlakozni). Például a tartály belsejében egy HTTP szolgáltatás sem figyel a 80-as porton (és így a kép fejlesztő meghatározza EXPOSE 80a Dockerfile). A futási a port lehet kötve 42800 a gazda. Ahhoz, hogy megtalálja a leképezést a befogadó kikötők és a kitett port használja docker port.

Ha az üzemeltető --linkindításakor egy új ügyfél tartály az alapértelmezett híd hálózat, akkor az ügyfél konténer elérheti a kitett port keresztül magánhálózat felületen. Ha --linkhasználunk indításakor egy tartályt egy felhasználó által definiált hálózati leírt Docker hálózat áttekintése , az biztosítja a nevű alias a tartály van kapcsolva.

ENV (környezeti változók)

Docker automatikusan beállítja néhány környezeti változó amikor egy Linux tartályba. Docker nem határoz meg a környezeti változók létrehozásakor a Windows tartályba.

A környezeti változók beállítása Linux konténerek:

Változó Érték
HOME Alapján állítjuk be az értéke USER
HOSTNAME A host társított a tartály
PATH Tartalmazza a legnépszerűbb könyvtárak, mint például a /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
TERM xterm ha a tartályt kiosztott egy ál-TTY
Továbbá, az üzemeltető meg semmilyen környezeti változót a konténerben egy vagy több -ezászlók, sőt kényszerítő fent említett, vagy a már meghatározott a fejlesztő egy Dockerfile ENV. Ha az üzemeltető nevét egy környezeti változót megadása nélkül értéket, akkor az aktuális érték a megnevezett változó szaporítják a tartályba környezete:

 $ export today = Wednesday $ docker run -e "deep=purple" -e today --rm alpine env PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME = d2219b854598 deep = purple today = Wednesday HOME = /root
 PS C:\> docker run --rm -e "foo=bar" microsoft/nanoserver cmd /s /c set ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\ContainerAdministrator\AppData\Roaming CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files COMPUTERNAME=C2FAEFCC8253 ComSpec=C:\Windows\system32\cmd.exe foo=bar LOCALAPPDATA=C:\Users\ContainerAdministrator\AppData\Local NUMBER_OF_PROCESSORS=8 OS=Windows_NT Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps PATHEXT=.COM;.EXE;.BAT;.CMD PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 62 Stepping 4, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=3e04 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PUBLIC=C:\Users\Public SystemDrive=C: SystemRoot=C:\Windows TEMP=C:\Users\ContainerAdministrator\AppData\Local\Temp TMP=C:\Users\ContainerAdministrator\AppData\Local\Temp USERDOMAIN=User Manager USERNAME=ContainerAdministrator USERPROFILE=C:\Users\ContainerAdministrator windir=C:\Windows
Hasonlóképpen a kezelő beállíthatja a HOSTNAME (Linux) vagy COMPUTERNAME (Windows) a -h.

ÁLLAPOTFELMÉRÉS

  --health-cmd Command to run to check health --health-interval Time between running the check --health-retries Consecutive failures needed to report unhealthy --health-timeout Maximum time to allow one check to run --health-start-period Start period for the container to initialize before starting health-retries countdown --no-healthcheck Disable any container-specified HEALTHCHECK
Példa:

 $ docker run --name=test -d \ --health-cmd='stat /etc/passwd || exit 1' \ --health-interval=2s \ busybox sleep 1d $ sleep 2; docker inspect --format='{{.State.Health.Status}}' test healthy $ docker exec test rm /etc/passwd $ sleep 2; docker inspect --format='{{json .State.Health}}' test { "Status": "unhealthy", "FailingStreak": 3, "Log": [ { "Start": "2016-05-25T17:22:04.635478668Z", "End": "2016-05-25T17:22:04.7272552Z", "ExitCode": 0, "Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..." }, { "Start": "2016-05-25T17:22:06.732900633Z", "End": "2016-05-25T17:22:06.822168935Z", "ExitCode": 0, "Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..." }, { "Start": "2016-05-25T17:22:08.823956535Z", "End": "2016-05-25T17:22:08.897359124Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" }, { "Start": "2016-05-25T17:22:10.898802931Z", "End": "2016-05-25T17:22:10.969631866Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" }, { "Start": "2016-05-25T17:22:12.971033523Z", "End": "2016-05-25T17:22:13.082015516Z", "ExitCode": 1, "Output": "stat: can't stat '/etc/passwd': No such file or directory\n" } ] }
Az egészségi állapot is megjelenik a docker pskimeneten.

Tmpfs (mount tmpfs fájlrendszereket)

 --tmpfs =[] : Create a tmpfs mount with: container-dir[:<options>], where the options are identical to the Linux 'mount -t tmpfs -o' command.
Az alábbi példa csatolta üres tmpfs a tartályba a rw, noexec, nosuidés size=65536klehetőségeket.

 $ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
VOLUME (megosztott fájlrendszereket)

 -v, --volume=[host-src:]container-dest[:<options>]: Bind mount a volume. The comma-delimited `options` are [rw|ro], [z|Z], [[r]shared|[r]slave|[r]private], and [nocopy]. The 'host-src' is an absolute path or a name value. If neither 'rw' or 'ro' is specified then the volume is mounted in read-write mode. The `nocopy` modes is used to disable automatic copying requested volume path in the container to the volume storage location. For named volumes, `copy` is the default mode. Copy modes are not supported for bind-mounted volumes. --volumes-from="": Mount all volumes from the given container(s)
Megjegyzés : Ha a systemd kezelni a Docker démon start és stop, a systemd egység fájl van egy opció, hogy ellenőrizzék tartó szaporítás a Docker maga a démon, az úgynevezett MountFlags. Ennek értéke beállítás is okozhatja Docker, hogy nem látja tartó szaporítás változások a csatolási pontot. Például, ha ez az érték slave, akkor lehet, hogy nem tudja használni a sharedvagy rsharedszaporítás egy kötet.

A kötetek parancsok bonyolult ahhoz, hogy saját dokumentációt szakaszban adatok kezelése konténerekben . A fejlesztő definiálhat egy vagy több VOLUME„s társított egy képet, de csak a kezelő hozzáférést egyik tartályból a másikba (vagy a tartályból a térfogatra szerelt a gazda).

A container-destmindig legyen egy abszolút útvonal, például /src/docs. A host-srclehet akár egy abszolút útvonal, vagy egy nameérték. Ha megad egy abszolút elérési utat az host-dir, Docker bind-tartók az utat meg kell adni. Ha a kínálat name, Docker teremt nevű hangerőt, hogy name.

Egy nameértéket kell kezdődnie alfanumerikus karaktert, majd a-z0-9, _(aláhúzás), .(időszak) vagy -(kötőjellel). Az abszolút útvonal kezdete egy /(perjel).

Például megadhatja sem /foo, vagy fooegy host-srcérték. Ha a kínálat a /fooértéket, Docker teremt kötődnek mount. Ha a kínálat a fooleírásban Docker teremt nevű kötetet.

USER

root(Id = 0) az alapértelmezett felhasználó egy tartályon belül. A kép fejlesztő létrehozhat további felhasználókat. Azok a felhasználók által elérhető neve. Amikor elhaladnak egy azonosítószám, a felhasználónak nem kell, hogy létezik a tartályba.

A fejlesztő beállíthatja az alapértelmezett felhasználó futtatni az első eljárás a Dockerfile USERutasítást. Amikor elkezdjük a tartály, az üzemeltető felülbírálja az USERutasítást úgy, hogy a -ulehetőség.

 -u="", --user="": Sets the username or UID used and optionally the groupname or GID for the specified command. The followings examples are all valid: --user=[ user | user:group | uid | uid:gid | user:gid | uid:group ]
Megjegyzés: ha át számazonosító-, meg kell tartományban 0-2147483647.

WORKDIR

Az alapértelmezett munkakönyvtárát futó bináris egy tartályon belül van a gyökérkönyvtárban ( /), de a fejlesztő lehet állítani egy másik alapértelmezett a Dockerfile WORKDIRparancsot. Az üzemeltető felülbírálhatja ezt:

 -w="": Working directory inside the container