docker-build - Online în cloud

PROGRAM:

NUME

docker-build - Construiește o nouă imagine din codul sursă la PATH

REZUMAT

docher construi [--build-arg[=[],--cpu-parts[=0,--cgroup-parent[=CGROUP-PARENT]]
[--Ajutor] [-f|--fişier[=PATH/Dockerfile,--force-rm] [--izolare[=lipsă,--fără-cache]
[--Trage] [-q|--Liniște] [--rm[=adevărat,-t|--etichetă[=[],-m|--memorie[=MEMORIE]]
[--schimb-memorie[=LIMITĂ,--shm-size[=SHM-SIZE,--cpu-perioada[=0,--cpu-quota[=0]]
[--cpuset-cpus[=CPUSET-CPUS,--cpuset-mems[=CPUSET-MEMS,--ulimit[=[]]] CALEA | URL | -

DESCRIERE

Acesta va citi Dockerfile din directorul specificat în PATH. De asemenea, trimite orice
alte fișiere și directoare găsite în directorul curent către demonul Docker. The
conținutul acestui director ar fi folosit de ADD comenzile găsite în Dockerfile.

Atenție, acest lucru va trimite o mulțime de date către demonul Docker, în funcție de conținutul
directorul curent. Compilarea este rulată de demonul Docker, nu de CLI, deci întregul
contextul trebuie transferat demonului. Docker CLI raportează „Se trimite contextul de compilare
la demonul Docker" când contextul este trimis demonului.

Când URL-ul către o arhivă tarball sau către un singur Dockerfile este dat, nu este trimis niciun context
de la client la demonul Docker. În acest caz, fișierul Dockerfile de la rădăcina fișierului
arhiva și restul arhivei vor fi folosite ca context al construcției. Când un Git
depozitul este setat ca URL-ul, depozitul este clonat local și apoi trimis ca
context.

OPŢIUNI

-f, --fişier=PATH/Dockerfile
Calea către fișierul Docker de utilizat. Dacă calea este o cale relativă și tu ești
construirea dintr-un director local, atunci calea trebuie să fie relativă la acesta
director. Dacă construiți dintr-o adresă URL de la distanță care indică fie a
tarball sau un depozit Git, atunci calea trebuie să fie relativă la rădăcina lui
contextul îndepărtat. În toate cazurile, fișierul trebuie să fie în contextul de construire.
Valoarea implicită este Dockerfile.

--build-arg=variabil
numele și valoarea lui a buildarg.

De exemplu, dacă doriți să transmiteți o valoare pentru Http proxy, Utilizare
--build-arg=http_proxy="http://some.proxy.url"

Utilizatorii transmit aceste valori în timpul construirii. Docker folosește buildargs ca
context de mediu pentru comenzile rulate prin Dockerfile ALERGA instrucție
sau pentru extinderea variabilă în alte instrucțiuni Dockerfile. Acest lucru nu este menit
pentru transmiterea valorilor secrete. ⟨/reference/builder/#arg⟩

--force-rm=adevărat|fals
Îndepărtați întotdeauna recipientele intermediare, chiar și după construcții nereușite. Valoarea implicită este
fals.

--izolare="lipsă"
Izolarea specifică tipul de tehnologie de izolare utilizată de containere.

--fără-cache=adevărat|fals
Nu utilizați memoria cache când construiți imaginea. Valoarea implicită este fals.

--Ajutor
Imprimați declarația de utilizare

--Trage=adevărat|fals
Încercați întotdeauna să extrageți o versiune mai nouă a imaginii. Valoarea implicită este fals.

-q, --Liniște=adevărat|fals
Suprimați rezultatul de compilare și imprimați ID-ul imaginii în caz de succes. Valoarea implicită este fals.

--rm=adevărat|fals
Scoateți containerele intermediare după o construcție reușită. Valoarea implicită este adevărat.

-t, --etichetă=""
Nume de depozit (și opțional cu etichete) pentru a fi aplicate imaginii rezultate în
caz de succes.

-m, --memorie=MEMORIE
Limită de memorie

--schimb-memorie=LIMITĂ
O valoare limită egală cu memoria plus swap. Trebuie folosit cu -m (--memorie) steag. The
schimba LIMITĂ ar trebui să fie întotdeauna mai mare decât -m (--memorie) valoare.

Formatul LIMITĂ is [ ]. Unitatea poate fi b (octeți), k (kiloocteți), m
(megaocteți) sau g (gigaocteți). Dacă nu specificați o unitate, b este folosit. Setați LIMIT la -1 la
activați schimbul nelimitat.

--shm-size=SHM-SIZE
Dimensiunea /dev/shm. Formatul este . număr trebuie să fie mai mare decât 0.
Unitatea este opțională și poate fi b (octeți), k (kiloocteți), m (megaocteți) sau g (gigaocteți).
Dacă omiteți unitatea, sistemul folosește octeți.
Dacă omiteți complet dimensiunea, sistemul folosește 64m.

--cpu-parts=0
Acțiuni CPU (greutate relativă).

În mod implicit, toate containerele primesc aceeași proporție de cicluri CPU.
Partajarea CPU este o „greutate relativă”, în raport cu setarea implicită de 1024.
Această valoare implicită este definită aici:

pisică /sys/fs/cgroup/cpu/cpu.shares
1024

Puteți modifica această proporție ajustând cota procesorului containerului
ponderea raportată la greutatea tuturor celorlalte containere aflate în funcțiune.

Pentru a modifica proporția de la valoarea implicită de 1024, utilizați --cpu-parts
flag pentru a seta ponderarea la 2 sau mai mare.

Flag de partajare a procesorului containerului
{C0} 60% din CPU --cpu-shares=614 (614 este 60% din 1024)
{C1} 40% din CPU --cpu-shares=410 (410 este 40% din 1024)

Proporția este aplicată numai atunci când rulează procese care consumă intens CPU.
Când sarcinile dintr-un container sunt inactive, celelalte containere pot folosi
timpul rămas de la CPU. Cantitatea reală de timp CPU utilizată variază în funcție de
numărul de containere care rulează pe sistem.

De exemplu, luați în considerare trei containere, unde unul are --cpu-shares=1024 și
alti doi au --cpu-shares=512. Când procese în toate trei
containerele încearcă să utilizeze 100% din CPU, primul container ar primi
50% din timpul total al procesorului. Dacă adăugați un al patrulea recipient cu --cpu-shares=1024,
primul container primește doar 33% din CPU. Recipientele rămase
primesc 16.5%, 16.5% și 33% din CPU.

Container CPU share Semnalați timpul CPU
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%

Pe un sistem multi-core, cotele din timpul CPU sunt distribuite pe CPU
miezuri. Chiar dacă un container este limitat la mai puțin de 100% din timpul CPU, poate
utilizați 100% din fiecare nucleu individual al procesorului.

De exemplu, luați în considerare un sistem cu mai mult de trei nuclee. Dacă începi unul
recipient {C0} cu --cpu-shares=512 rulează un proces și un alt container
{C1} cu --cpu-shares=1024 rulând două procese, acest lucru poate duce la următoarele
împărțirea părților CPU:

PID container CPU partajare CPU
100 {C0} 0 100% din CPU0
101 {C1} 1 100% din CPU1
102 {C1} 2 100% din CPU2

--cpu-perioada=0
Limitați perioada CPU CFS (Completely Fair Scheduler).

Limitați utilizarea procesorului containerului. Acest flag determină nucleul să restricționeze
utilizarea procesorului containerului la perioada pe care o specificați.

--cpu-quota=0
Limitați cota CPU CFS (Completely Fair Scheduler).

În mod implicit, containerele rulează cu resursa CPU completă. Acest steag determină nucleul
restrângeți utilizarea procesorului containerului la cota pe care o specificați.

--cpuset-cpus=CPUSET-CPUS
CPU-uri în care să se permită execuția (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Noduri de memorie (MEM) în care să se permită execuția (0-3, 0,1). Eficient doar pe
sisteme NUMA.

De exemplu, dacă aveți patru noduri de memorie pe sistem (0-3), utilizați --cpuset-mems=0,1 la
asigurați-vă că procesele din containerul dvs. Docker utilizează numai memoria din primele două memorie
noduri.

--cgroup-parent=CGROUP-PARENT
Calea spre cgrupuri sub care se află containerul cgroup sunt create.

Dacă calea nu este absolută, calea este considerată relativ la cgrupuri calea
procesul init. Grupurile C sunt create dacă nu există deja.

--ulimit=[]
Ulimitați opțiunile

Pentru mai multe informații despre limită vedea
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

EXEMPLE

Clădire an imagine folosind a Dockerfile situat în interiorul il curent director

Imaginile Docker pot fi create folosind comanda build și un Dockerfile:

docker build .

În timpul procesului de construire, Docker creează imagini intermediare. Pentru a le păstra, tu
trebuie să se stabilească în mod explicit --rm=fals.

docker build --rm=false .

O bună practică este să creați un subdirector cu un nume asociat și să creați fișierul Docker
în acel director. De exemplu, un director numit mongo poate conține un Dockerfile to
creați o imagine Docker MongoDB. De asemenea, se poate folosi un alt director numit httpd
stocați fișiere Dockerfile pentru imaginile serverului web Apache.

De asemenea, este o practică bună să adăugați fișierele necesare pentru imagine în subdirector.
Aceste fișiere vor fi apoi specificate cu COPIE or ADD instrucțiuni din Dockerfile.

Notă: dacă includeți un fișier tar (o practică bună), atunci Docker va extrage automat
conținutul fișierului tar specificat în ADD instrucțiuni în cele specificate
țintă.

Clădire an imagine și denumire acea imagine

O bună practică este să dai un nume imaginii pe care o construiești. Rețineți că numai a-z0-9-_.
ar trebui folosit pentru consecvență. Nu există reguli stricte aici, dar cel mai bine este să dai
considerație de nume.

-t/--etichetă steag este folosit pentru a redenumi o imagine. Aici sunt cateva exemple:

Deși nu este o practică bună, numele imaginilor pot fi arbitrare:

docker build -t myimage .

O abordare mai bună este de a oferi un depozit, nume și etichetă complet calificat și semnificativ
(unde eticheta în acest context înseamnă calificativul după „:”). În acest exemplu noi
construiți o imagine JBoss pentru depozitul Fedora și dați-i versiunea 1.0:

docker build -t fedora/jboss:1.0 .

Următorul exemplu este pentru depozitul de utilizatori „whenry” și folosește Fedora și JBoss și oferă
este versiunea 2.1:

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

Dacă nu furnizați o etichetă de versiune, Docker va aloca Ultimele:

docker build -t whenry/fedora-jboss .

Când enumerați imaginile, imaginea de mai sus va avea eticheta Ultimele.

Puteți aplica mai multe etichete unei imagini. De exemplu, puteți aplica Ultimele eticheta la a
imagine nou construită și adăugați o altă etichetă care face referire la o anumită versiune. De exemplu, să
etichetați o imagine atât ca whenry/fedora-jboss:latest și whenry/fedora-jboss:v2.1, folosește
Următor:

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

Deci redenumirea unei imagini este arbitrară, dar ar trebui să se ia în considerare o convenție utilă
acest lucru are sens pentru consumatori și ar trebui să ia în considerare și comunitatea Docker
convenții.

Clădire an imagine folosind a URL-ul

Acest lucru va clona depozitul GitHub specificat de la adresa URL și îl va folosi ca context. The
Dockerfile la rădăcina depozitului este folosit ca Dockerfile. Acest lucru funcționează numai dacă
Depozitul GitHub este un depozit dedicat.

docker build github.com/scollier/purpletest

Notă: Puteți seta un depozit Git arbitrar prin intermediul git:// schemă.

Clădire an imagine folosind a URL-ul la a tarball'ed context

Aceasta va trimite URL-ul propriu-zis demonului Docker. Daemonul va aduce tarball-ul
arhivați, decomprimați-l și utilizați conținutul său ca context de construcție. Dockerfile la
rădăcina arhivei și restul arhivei vor fi folosite ca context al construcției.
Dacă treci de un -f PATH/Dockerfile de asemenea, sistemul va căuta acel fișier
în interiorul conținutului tarball-ului.

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

Notă: formatele de compresie acceptate sunt „xz”, „bzip2”, „gzip” și „identity” (nu
comprimare).

Specifica izolare tehnologie pentru recipient (--izolare)

Această opțiune este utilă în situațiile în care rulați containere Docker pe Windows.
--izolare= opțiunea setează tehnologia de izolare a containerului. Pe Linux, singurul
sprijinit este lipsă opțiunea care utilizează spații de nume Linux. Pe Microsoft Windows, puteți
specificati aceste valori:

· lipsă: Folosiți valoarea specificată de demonul Docker --exec-opt . Dacă daemon face
nu specifica o tehnologie de izolare, Microsoft Windows foloseste proces ca implicit
valoare.

· proces: Numai izolarea spațiului de nume.

· hiperv: Izolare bazată pe partiții hypervisor Hyper-V.

Specificând --izolare flag fără valoare este același cu setarea
--isolation="implicit".

ISTORIE

Martie 2014, compilat inițial de William Henry (whenry at redhat dot com) pe baza
material sursă docker.com și lucrări interne. iunie 2014, actualizat de Sven Dowideit
⟨[e-mail protejat]⟩ iunie 2015, actualizat de Sally O'Malley ⟨[e-mail protejat]⟩

Utilizați docker-build online folosind serviciile onworks.net