docker-build - Online nel cloud

PROGRAMMA:

NOME

docker-build - Crea una nuova immagine dal codice sorgente su PATH

SINOSSI

scaricatore di porto costruire [--build-arg[=[],--cpu-condivisioni[=0,--cgroup-genitore[=GRUPPO-GENITORE]]
[--Aiuto] [-f|--file[=PERCORSO/fileDocker,--forza-rm] [--isolamento[=difetto,--nessuna cache]
[--tiro] [-q|--silenzioso] [--rm[=vero,-t|--etichetta[=[],-m|--memoria[=MEMORIA]]
[--scambio di memoria[=LIMITE,--shm-dimensione[=TAGLIA SHM,--cpu-periodo[=0,--quota-cpu[=0]]
[--cpuset-cpus[=CPUSET-CPU,--cpuset-mems[=CPUSET-MEMS,--ulimit[=[]]] PERCORSO | URL | -

DESCRIZIONE

Questo leggerà il Dockerfile dalla directory specificata in PERCORSO. Invia anche qualsiasi
altri file e directory trovati nella directory corrente per il demone Docker. Il
il contenuto di questa directory verrebbe utilizzato da ADD comandi trovati all'interno del Dockerfile.

Attenzione, questo invierà molti dati al demone Docker a seconda del contenuto di
la directory corrente. La build è eseguita dal demone Docker, non dalla CLI, quindi il tutto
contesto deve essere trasferito al demone. La Docker CLI riporta "Invio contesto build
al demone Docker" quando il contesto viene inviato al demone.

Quando viene fornito l'URL di un archivio tar o di un singolo Dockerfile, non viene inviato alcun contesto
dal client al demone Docker. In questo caso, il Dockerfile alla radice del
archivio e il resto dell'archivio verrà utilizzato come contesto della build. Quando un Git
repository è impostato come URL, il repository viene clonato localmente e quindi inviato come
contesto.

VERSIONI

-f, --file=PERCORSO/fileDocker
Percorso del Dockerfile da utilizzare. Se il percorso è un percorso relativo e tu lo sei
costruendo da una directory locale, quindi il percorso deve essere relativo a quella
directory. Se stai costruendo da un URL remoto che punta a a
tarball o un repository Git, il percorso deve essere relativo alla radice di
il contesto remoto. In tutti i casi, il file deve essere all'interno del contesto di compilazione.
L'impostazione predefinita è Dockerfile.

--build-arg=variabile
nome e valore di a costruire.

Ad esempio, se vuoi passare un valore per http_proxy, Utilizzare
--build-arg=http_proxy="http://some.proxy.url"

Gli utenti passano questi valori in fase di compilazione. Docker utilizza il buildar la
contesto dell'ambiente per i comandi eseguiti tramite i file Docker CORRERE istruzione
o per l'espansione delle variabili in altre istruzioni Dockerfile. Questo non è significato
per il passaggio di valori segreti. ⟨/reference/builder/#arg⟩

--forza-rm=vero|falso
Rimuovere sempre i contenitori intermedi, anche dopo build non riuscite. L'impostazione predefinita è
falso.

--isolamento="difetto"
Isolation specifica il tipo di tecnologia di isolamento utilizzata dai contenitori.

--nessuna cache=vero|falso
Non utilizzare la cache durante la creazione dell'immagine. L'impostazione predefinita è falso.

--Aiuto
Stampa dichiarazione di utilizzo

--tiro=vero|falso
Cerca sempre di estrarre una versione più recente dell'immagine. L'impostazione predefinita è falso.

-q, --silenzioso=vero|falso
Elimina l'output della build e stampa l'ID immagine in caso di successo. L'impostazione predefinita è falso.

--rm=vero|falso
Rimuovere i contenitori intermedi dopo una compilazione riuscita. L'impostazione predefinita è vero.

-t, --etichetta=""
Nomi di repository (e facoltativamente con tag) da applicare all'immagine risultante in
caso di successo.

-m, --memoria=MEMORIA
Limite di memoria

--scambio di memoria=LIMITE
Un valore limite uguale a memoria più swap. Deve essere utilizzato con il -m (--memoria) bandiera. Il
swap LIMITE dovrebbe essere sempre più grande di -m (--memoria) valore.

Il formato di LIMITE is [ ]. L'unità può essere b (byte), k (kilobyte), m
(megabyte), o g (gigabyte). Se non specifichi un'unità, b viene utilizzato. Imposta LIMIT su -1 a
abilitare lo scambio illimitato.

--shm-dimensione=TAGLIA SHM
Taglia di /dev/shm. Il formato è . numero deve essere maggiore 0.
L'unità è opzionale e può essere b (byte), k (kilobyte), m (megabyte), o g (gigabyte).
Se si omette l'unità, il sistema utilizza i byte.
Se ometti completamente la dimensione, il sistema utilizza 64m.

--cpu-condivisioni=0
Condivisioni CPU (peso relativo).

Per impostazione predefinita, tutti i contenitori ottengono la stessa proporzione di cicli CPU.
Le condivisioni CPU sono un "peso relativo", relativo all'impostazione predefinita di 1024.
Questo valore predefinito è definito qui:

gatto /sys/fs/cgroup/cpu/cpu.shares
1024

Puoi modificare questa proporzione regolando la condivisione della CPU del contenitore
ponderazione relativa alla ponderazione di tutti gli altri contenitori in esecuzione.

Per modificare la proporzione dal valore predefinito di 1024, utilizzare il --cpu-condivisioni
flag per impostare la ponderazione su 2 o superiore.

Flag condivisione CPU contenitore
{C0} 60% della CPU --cpu-shares=614 (614 è il 60% di 1024)
{C1} 40% della CPU --cpu-shares=410 (410 è il 40% di 1024)

La proporzione viene applicata solo quando sono in esecuzione processi a uso intensivo della CPU.
Quando le attività in un contenitore sono inattive, gli altri contenitori possono utilizzare il
tempo CPU residuo. La quantità effettiva di tempo della CPU utilizzata varia a seconda di
il numero di contenitori in esecuzione sul sistema.

Ad esempio, considera tre contenitori, dove uno ha --cpu-share=1024 ed
altri due hanno --cpu-share=512. Quando i processi in tutti e tre
i container tentano di utilizzare il 100% della CPU, il primo container riceverebbe
50% del tempo totale della CPU. Se aggiungi un quarto contenitore con --cpu-share=1024,
il primo contenitore ottiene solo il 33% della CPU. I restanti contenitori
ricevono il 16.5%, il 16.5% e il 33% della CPU.

Condivisione CPU contenitore Segnala tempo CPU
{C0} 100% --cpu-share=1024 33%
{C1} 50% --cpu-share=512 16.5%
{C2} 50% --cpu-share=512 16.5%
{C4} 100% --cpu-share=1024 33%

Su un sistema multi-core, le quote di tempo della CPU sono distribuite sulla CPU
nuclei. Anche se un contenitore è limitato a meno del 100% del tempo della CPU, può
utilizzare il 100% di ogni singolo core della CPU.

Ad esempio, considera un sistema con più di tre core. Se ne inizi uno
contenitore {C0} con --cpu-share=512 eseguire un processo e un altro contenitore
{C1} con --cpu-share=1024 l'esecuzione di due processi, ciò può comportare quanto segue
divisione delle quote CPU:

Contenitore PID Condivisione CPU CPU
100 {C0} 0 100% della CPU0
101 {C1} 1 100% della CPU1
102 {C1} 2 100% della CPU2

--cpu-periodo=0
Limita il periodo CFS (Completely Fair Scheduler) della CPU.

Limita l'utilizzo della CPU del contenitore. Questo flag fa sì che il kernel limiti il
l'utilizzo della CPU del contenitore per il periodo specificato.

--quota-cpu=0
Limita la quota CFS (Completely Fair Scheduler) della CPU.

Per impostazione predefinita, i contenitori vengono eseguiti con la risorsa CPU completa. Questo flag fa sì che il kernel
limitare l'utilizzo della CPU del contenitore alla quota specificata.

--cpuset-cpus=CPUSET-CPU
CPU in cui consentire l'esecuzione (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Nodi di memoria (MEM) in cui consentire l'esecuzione (0-3, 0,1). Efficace solo su
sistemi NUMA.

Ad esempio, se hai quattro nodi di memoria sul tuo sistema (0-3), usa --cpuset-mems=0,1 a
assicurati che i processi nel tuo contenitore Docker utilizzino solo la memoria delle prime due memorie
i nodi.

--cgroup-genitore=GRUPPO-GENITORE
percorso per cgroup sotto il quale si trova il contenitore cgruppo sono creati.

Se il percorso non è assoluto, il percorso è considerato relativo al cgroup percorso del
inizia il processo. I Cgroup vengono creati se non esistono già.

--ulimit= []
Opzioni limite

Per ulteriori informazioni su ulimit vedere
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

ESEMPI

Costruzione an Immagine utilizzando a Dockerfile collocato interno , il corrente elenco

Le immagini Docker possono essere create utilizzando il comando build e un Dockerfile:

costruzione della finestra mobile.

Durante il processo di compilazione Docker crea immagini intermedie. Per mantenerli, tu
deve essere impostato esplicitamente --rm=falso.

build della finestra mobile --rm=false .

Una buona pratica è creare una sottodirectory con un nome correlato e creare il Dockerfile
in quella directory. Ad esempio, una directory chiamata mongo può contenere un Dockerfile per
creare un'immagine Docker MongoDB. Allo stesso modo, un'altra directory chiamata httpd può essere usata per
memorizzare i file Docker per le immagini del server Web Apache.

È anche una buona pratica aggiungere i file necessari per l'immagine alla sottodirectory.
Questi file verranno quindi specificati con il COPIA or ADD istruzioni nel Dockerfile.

Nota: se includi un file tar (una buona pratica), Docker verrà estratto automaticamente
il contenuto del file tar specificato all'interno del ADD istruzione nello specificato
bersaglio.

Costruzione an Immagine ed di denominazione che Immagine

Una buona pratica è dare un nome all'immagine che stai costruendo. Nota che solo a-z0-9-_.
dovrebbe essere usato per coerenza. Non ci sono regole rigide qui, ma è meglio dare il
considerazione sui nomi.

I -t/--etichetta flag viene utilizzato per rinominare un'immagine. Ecco alcuni esempi:

Sebbene non sia una buona pratica, i nomi delle immagini possono essere arbitrari:

docker build -t miaimmagine .

Un approccio migliore consiste nel fornire un repository, un nome e un tag completi e significativi
(dove il tag in questo contesto indica il qualificatore dopo il ":"). In questo esempio noi
costruisci un'immagine JBoss per il repository Fedora e dagli la versione 1.0:

docker build -t fedora/jboss:1.0 .

Il prossimo esempio è per il repository utente "whenry" e usa Fedora e JBoss e dà
è la versione 2.1:

docker build -t Whenry/fedora-jboss:v2.1 .

Se non fornisci un tag di versione, Docker lo assegnerà con i più recenti:

docker build -t quandory/fedora-jboss .

Quando elenchi le immagini, l'immagine sopra avrà il tag con i più recenti.

Puoi applicare più tag a un'immagine. Ad esempio, puoi applicare il con i più recenti tagga a
immagine appena creata e aggiungi un altro tag che fa riferimento a una versione specifica. Ad esempio, a
tagga un'immagine sia come quandory/fedora-jboss:latest ed quandory/fedora-jboss:v2.1, Usa il
seguenti:

docker build -t quando/fedora-jboss:latest -t quando/fedora-jboss:v2.1 .

Quindi rinominare un'immagine è arbitrario, ma si dovrebbe prendere in considerazione un'utile convenzione
che ha senso per i consumatori e dovrebbe anche tenere conto della comunità Docker
convegni.

Costruzione an Immagine utilizzando a URL

Questo clonerà il repository GitHub specificato dall'URL e lo utilizzerà come contesto. Il
Dockerfile alla radice del repository viene utilizzato come Dockerfile. Funziona solo se il
Il repository GitHub è un repository dedicato.

build docker github.com/scollier/purpletest

Nota: puoi impostare un repository Git arbitrario tramite il partire:// schema.

Costruzione an Immagine utilizzando a URL a a tarball'ed contesto

Questo invierà l'URL stesso al demone Docker. Il demone recupererà il tarball
archiviarlo, decomprimerlo e utilizzare il suo contenuto come contesto di compilazione. Il Dockerfile al
root dell'archivio e il resto dell'archivio verranno utilizzati come contesto della build.
Se passi un -f PERCORSO/fileDocker anche l'opzione, il sistema cercherà quel file
all'interno del contenuto del tarball.

docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz

Nota: i formati di compressione supportati sono 'xz', 'bzip2', 'gzip' e 'identity' (no
compressione).

Specificare da solo la tecnologia per contenitore (--isolamento)

Questa opzione è utile in situazioni in cui si eseguono container Docker su Windows.
I --isolamento= opzione imposta la tecnologia di isolamento di un contenitore. Su Linux, l'unico
supportato è il difetto opzione che utilizza gli spazi dei nomi Linux. Su Microsoft Windows, puoi
specificare questi valori:

· difetto: usa il valore specificato dal demone Docker --exec-opz . Se il demone effettua
non specificare una tecnologia di isolamento, utilizza Microsoft Windows processi come impostazione predefinita
valore.

· processi: solo isolamento dello spazio dei nomi.

· ipervelocitàNota: isolamento basato su partizione hypervisor Hyper-V.

Specificando il --isolamento flag senza valore equivale a setting
--isolation="predefinito".

STORIA

Marzo 2014, originariamente compilato da William Henry (whenry at redhat dot com) basato su
materiale sorgente docker.com e lavoro interno. Giugno 2014, aggiornato da Sven Dowideit
⟨[email protected]⟩ Giugno 2015, aggiornato da Sally O'Malley ⟨[email protected]⟩

Usa docker-build online utilizzando i servizi onworks.net