docker-build - Online in de cloud

PROGRAMMA:

NAAM

docker-build - Bouw een nieuwe afbeelding op basis van de broncode op PATH

KORTE INHOUD

havenarbeider bouw [--build-arg[=[],--cpu-aandelen[=0,--cgroup-ouder[=CGROEP-OUDER]]
[--help] [-f|--het dossier[=PATH/Dockerbestand,--kracht-rm] [--isolatie[=verzuim,--geen cache]
[--trekken] [-q|--stil] [--rm[=waar,-t|--label[=[],-m|--geheugen[=GEHEUGEN]]
[--geheugen-swap[=LIMIT,--shm-maat[=SHM-MAAT,--cpu-periode[=0,--cpu-quotum[=0]]
[--cpuset-cpu's[=CPUSET-CPU,--cpuset-mems[=CPUSET-MEMS,--ulimit[=[]]] PAD | URL | -

PRODUCTBESCHRIJVING

Hiermee wordt het Dockerbestand gelezen uit de map die is opgegeven in PATH. Het verzendt ook eventuele
andere bestanden en mappen in de huidige map naar de Docker-daemon. De
inhoud van deze map zou worden gebruikt door ADD opdrachten gevonden in het Dockerbestand.

Waarschuwing: hierdoor worden veel gegevens naar de Docker-daemon verzonden, afhankelijk van de inhoud van
de huidige map. De build wordt uitgevoerd door de Docker-daemon, niet door de CLI, dus het geheel
context moet worden overgebracht naar de daemon. De Docker CLI rapporteert "Buildcontext verzenden
naar Docker-daemon" wanneer de context naar de daemon wordt verzonden.

Wanneer de URL naar een tarballarchief of naar een enkel Dockerbestand wordt opgegeven, wordt er geen context verzonden
van de client naar de Docker-daemon. In dit geval wordt het Dockerbestand in de root van het
archief en de rest van het archief zal worden gebruikt als de context van de build. Wanneer een Git
repository is ingesteld als de URL, wordt de repository lokaal gekloond en vervolgens verzonden als de
context.

OPTIES

-f, --het dossier=PATH/Dockerbestand
Pad naar het Dockerbestand dat moet worden gebruikt. Als het pad een relatief pad is en jij dat ook bent
bouwen vanuit een lokale map, dan moet het pad relatief daaraan zijn
map. Als u bouwt vanaf een externe URL die verwijst naar a
tarball of een Git-repository, dan moet het pad relatief zijn ten opzichte van de root van
de verre context. In alle gevallen moet het bestand zich binnen de buildcontext bevinden.
De standaard is Dockerfile.

--build-arg=variabele
naam en waarde van a bouwarg.

Als u bijvoorbeeld een waarde wilt doorgeven voor http-proxy, Gebruik dan
--build-arg=http_proxy="http://some.proxy.url"

Gebruikers geven deze waarden door tijdens het bouwen. Docker maakt gebruik van de bouwargs de
omgevingscontext voor opdracht(en) die worden uitgevoerd via de Dockerfile's VLUCHTEN instructie
of voor variabele uitbreiding in andere Dockerfile-instructies. Dit is niet de bedoeling
voor het doorgeven van geheime waarden. ⟨/referentie/builder/#arg⟩

--kracht-rm=waar|vals
Verwijder altijd tussencontainers, zelfs na mislukte builds. De standaardwaarde is
vals.

--isolatie="verzuim"
Isolatie specificeert het type isolatietechnologie dat door containers wordt gebruikt.

--geen cache=waar|vals
Gebruik geen cache bij het bouwen van de afbeelding. De standaardwaarde is vals.

--help
Gebruiksverklaring afdrukken

--trekken=waar|vals
Probeer altijd een nieuwere versie van de afbeelding op te halen. De standaardwaarde is vals.

-q, --stil=waar|vals
Onderdruk de build-uitvoer en druk de afbeeldings-ID af bij succes. De standaardwaarde is vals.

--rm=waar|vals
Verwijder tussencontainers na een succesvolle build. De standaardwaarde is waar.

-t, --label=""
Namen van opslagplaatsen (en optioneel met tags) die moeten worden toegepast op de resulterende afbeelding in
geval van succes.

-m, --geheugen=GEHEUGEN
Geheugenlimiet

--geheugen-swap=LIMIT
Een grenswaarde gelijk aan geheugen plus swap. Moet worden gebruikt met de -m (--geheugen) vlag. De
ruilen LIMIT moet altijd groter zijn dan -m (--geheugen) waarde.

Het formaat van LIMIT is [ ]. Eenheid kan zijn b (byte), k (kilobytes), m
(megabytes), of g (gigabyte). Als u geen eenheid opgeeft, b is gebruikt. Stel LIMIET in op -1 naar
onbeperkt wisselen inschakelen.

--shm-maat=SHM-MAAT
De grootte van /dev/shm. Het formaat is . aantal moet groter zijn dan 0.
Eenheid is optioneel en kan dat zijn b (byte), k (kilobytes), m (megabytes), of g (gigabyte).
Als u de eenheid weglaat, gebruikt het systeem bytes.
Als u de grootte geheel weglaat, gebruikt het systeem 64m.

--cpu-aandelen=0
CPU-aandelen (relatief gewicht).

Standaard krijgen alle containers hetzelfde aandeel CPU-cycli.
CPU-shares is een 'relatief gewicht', relatief ten opzichte van de standaardinstelling van 1024.
Deze standaardwaarde wordt hier gedefinieerd:

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

U kunt deze verhouding wijzigen door het CPU-aandeel van de container aan te passen
weging ten opzichte van de weging van alle andere lopende containers.

Om de verhouding van de standaardwaarde van 1024 te wijzigen, gebruikt u de --cpu-aandelen
vlag om de weging in te stellen op 2 of hoger.

Vlag van container-CPU-share
{C0} 60% van CPU --cpu-shares=614 (614 is 60% van 1024)
{C1} 40% van CPU --cpu-shares=410 (410 is 40% van 1024)

De verhouding wordt alleen toegepast als er CPU-intensieve processen actief zijn.
Wanneer taken in de ene container inactief zijn, kunnen de andere containers de
overgebleven CPU-tijd. De werkelijke hoeveelheid CPU-tijd die wordt gebruikt, varieert afhankelijk van de computer
het aantal containers dat op het systeem draait.

Denk bijvoorbeeld aan drie containers, waar er één is --cpu-shares=1024 en
twee anderen hebben dat wel --cpu-shares=512. Wanneer processen in alle drie
containers proberen 100% van de CPU te gebruiken, zou de eerste container ontvangen
50% van de totale CPU-tijd. Als u een vierde container toevoegt met --cpu-shares=1024,
de eerste container krijgt slechts 33% van de CPU. De overige containers
ontvangen 16.5%, 16.5% en 33% van de CPU.

Container CPU-share Markeer CPU-tijd
{C0} 100% --cpu-aandelen=1024 33%
{C1} 50% --cpu-aandelen=512 16.5%
{C2} 50% --cpu-aandelen=512 16.5%
{C4} 100% --cpu-aandelen=1024 33%

Op een multi-coresysteem wordt het aandeel van de CPU-tijd verdeeld over de CPU
kernen. Zelfs als een container beperkt is tot minder dan 100% van de CPU-tijd, kan dat wel
gebruik 100% van elke individuele CPU-kern.

Overweeg bijvoorbeeld een systeem met meer dan drie kernen. Als je er een begint
houder {C0} met --cpu-shares=512 één proces en een andere container uitvoeren
{C1} met --cpu-shares=1024 Als u twee processen uitvoert, kan dit het volgende tot gevolg hebben
verdeling van CPU-aandelen:

PID-container CPU CPU-aandeel
100 {C0} 0 100% van CPU0
101 {C1} 1 100% van CPU1
102 {C1} 2 100% van CPU2

--cpu-periode=0
Beperk de CPU CFS-periode (Completely Fair Scheduler).

Beperk het CPU-gebruik van de container. Deze vlag zorgt ervoor dat de kernel de
CPU-gebruik van de container tot de periode die u opgeeft.

--cpu-quotum=0
Beperk het CPU CFS-quotum (Completely Fair Scheduler).

Standaard worden containers uitgevoerd met de volledige CPU-bron. Deze vlag zorgt ervoor dat de kernel
beperk het CPU-gebruik van de container tot het quotum dat u opgeeft.

--cpuset-cpu's=CPUSET-CPU
CPU's waarin uitvoering mogelijk is (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Geheugenknooppunten (MEM's) waarin uitvoering mogelijk is (0-3, 0,1). Alleen effectief op
NUMA-systemen.

Als u bijvoorbeeld vier geheugenknooppunten op uw systeem heeft (0-3), gebruikt u --cpuset-mems=0,1 naar
zorg ervoor dat de processen in uw Docker-container alleen geheugen uit de eerste twee geheugens gebruiken
knooppunten.

--cgroup-ouder=CGROEP-OUDER
Pad naar cgroepen waaronder de container cgroep zijn gemaakt.

Als het pad niet absoluut is, wordt het pad beschouwd als relatief ten opzichte van de cgroepen pad van de
initiëren proces. Cgroepen worden gemaakt als ze nog niet bestaan.

--ulimit=[]
Ulimit opties

Voor meer informatie over ulimit zien
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

Voorbeelden

Gebouw an beeld gebruik a Dockerfile gelegen binnen the actueel directory

Docker-images kunnen worden gebouwd met behulp van de opdracht build en een Dockerfile:

havenarbeider gebouwd.

Tijdens het bouwproces maakt Docker tussenafbeeldingen. Om ze te behouden, jij
moet expliciet worden ingesteld --rm=onwaar.

docker build --rm=false .

Een goede gewoonte is om een ​​submap met een gerelateerde naam te maken en het Dockerbestand te maken
in die map. Een map met de naam mongo kan bijvoorbeeld een Dockerfile to bevatten
maak een Docker MongoDB-image. Op dezelfde manier kan een andere map met de naam httpd worden gebruikt
bewaar Dockerfiles voor Apache-webserverafbeeldingen.

Het is ook een goede gewoonte om de bestanden die nodig zijn voor de afbeelding toe te voegen aan de submap.
Deze bestanden worden vervolgens gespecificeerd met de extensie COPY or ADD instructies in de Dockerfile.

Opmerking: als u een tar-bestand opneemt (een goede gewoonte), wordt Docker automatisch uitgepakt
de inhoud van het tar-bestand dat is opgegeven in het ADD instructie in het opgegeven
doelwit.

Gebouw an beeld en naamgeving uit die beeld

Een goede gewoonte is om een ​​naam te geven aan de afbeelding die u aan het opbouwen bent. Merk op dat alleen a-z0-9-_.
moet worden gebruikt voor consistentie. Er zijn hier geen harde regels, maar het is het beste om de
namen overweging.

De -t/--label vlag wordt gebruikt om een ​​afbeelding te hernoemen. Hier zijn enkele voorbeelden:

Hoewel het geen goede gewoonte is, kunnen afbeeldingsnamen willekeurig zijn:

docker build -t mijnimage .

Een betere aanpak is het bieden van een volledig gekwalificeerde en betekenisvolle repository, naam en tag
(waarbij de tag in deze context de kwalificatie na de teken betekent). In dit voorbeeld wij
bouw een JBoss image voor de Fedora repository en geef het versie 1.0:

docker build -t fedora/jboss:1.0 .

Het volgende voorbeeld is voor de "whenry" gebruikersrepository en gebruikt Fedora en JBoss en geeft
het is versie 2.1:

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

Als u geen versietag opgeeft, zal Docker deze toewijzen laatste:

docker build -t wanneerry/fedora-jboss .

Wanneer u de afbeeldingen vermeldt, heeft de afbeelding hierboven de tag laatste.

U kunt meerdere tags op een afbeelding toepassen. U kunt bijvoorbeeld de laatste labelen naar een
nieuw gebouwde afbeelding en voeg nog een tag toe die verwijst naar een specifieke versie. Bijvoorbeeld naar
tag een afbeelding beide als wanneerry/fedora-jboss: nieuwste en wanneerry/fedora-jboss:v2.1, gebruik het
volgende:

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

Het hernoemen van een afbeelding is dus willekeurig, maar er moet rekening worden gehouden met een bruikbare conventie
dat is logisch voor consumenten en moet ook rekening houden met de Docker-gemeenschap
conventies.

Gebouw an beeld gebruik a URL

Hiermee wordt de opgegeven GitHub-repository van de URL gekloond en als context gebruikt. De
Dockerfile in de root van de repository wordt gebruikt als Dockerfile. Dit werkt alleen als de
GitHub-repository is een speciale repository.

docker bouwt github.com/scollier/purpletest

Opmerking: je kunt een willekeurige Git-repository instellen via de git:// schema.

Gebouw an beeld gebruik a URL naar a tarball'ed verband

Hierdoor wordt de URL zelf naar de Docker-daemon verzonden. De daemon haalt de tarball op
archiveren, decomprimeren en de inhoud ervan gebruiken als buildcontext. Het Dockerbestand op de
root van het archief en de rest van het archief zal worden gebruikt als de context van de build.
Als u een -f PATH/Dockerbestand optie ook, zal het systeem naar dat bestand zoeken
in de inhoud van de tarball.

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

Let op: ondersteunde compressieformaten zijn 'xz', 'bzip2', 'gzip' en 'identity' (geen
compressie).

Specificeren isolatie technologie voor houder (--isolatie)

Deze optie is handig in situaties waarin u Docker-containers op Windows gebruikt.
De --isolatie= optie stelt de isolatietechnologie van een container in. Op Linux, de enige
ondersteund is de verzuim optie die Linux-naamruimten gebruikt. Op Microsoft Windows kan dat
specificeer deze waarden:

· verzuim: Gebruik de waarde gespecificeerd door de Docker daemon's --exec-opt . Indien de demon doet
geen isolatietechnologie specificeren, gebruikt Microsoft Windows als standaard
waarde.

· : Alleen naamruimte-isolatie.

· hyperv: Hyper-V hypervisor-partitie-gebaseerde isolatie.

Specificeren van de --isolatie flag zonder waarde is hetzelfde als instelling
--isolation="standaard".

GESCHIEDENIS

Maart 2014, oorspronkelijk samengesteld door William Henry (whenry bij redhat dot com) op basis van
docker.com bronmateriaal en intern werk. Juni 2014, bijgewerkt door Sven Dowideit
⟨[e-mail beveiligd]⟩ Juni 2015, bijgewerkt door Sally O'Malley ⟨[e-mail beveiligd]⟩

Gebruik docker-build online met behulp van onworks.net-services