docker-build – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

docker-build – Erstellen Sie ein neues Image aus dem Quellcode unter PATH

ZUSAMMENFASSUNG

Docker bauen [--build-arg[=[]]] [--cpu-anteile[=0]] [--cgroup-parent[=CGROUP-PARENT]]
[--help] [-f|--Datei[=PATH/Dockerfile]] [--force-rm] [--Isolation[=Standard]] [--no-cache]
[--ziehen] [-q|--ruhig] [--rm[=was immer dies auch sein sollte.]] [-t|--Schild[=[]]] [-m|--Erinnerung[=SPEICHER]]
[--Memory-Swap[=LIMIT]] [--shm-größe[=SHM-GRÖSSE]] [--CPU-Periode[=0]] [--CPU-Quote[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-speicher[=CPUSET-MEMS]] [--ulimit[=[]]] PFAD | URL | -

BESCHREIBUNG

Dadurch wird die Docker-Datei aus dem in angegebenen Verzeichnis gelesen PATH. Es sendet auch alle
andere im aktuellen Verzeichnis gefundene Dateien und Verzeichnisse an den Docker-Daemon weiter. Der
Der Inhalt dieses Verzeichnisses würde von verwendet werden ADD Befehle, die in der Docker-Datei gefunden werden.

Achtung, dadurch werden je nach Inhalt viele Daten an den Docker-Daemon gesendet
das aktuelle Verzeichnis. Der Build wird vom Docker-Daemon ausgeführt, nicht von der CLI, also vom Ganzen
Der Kontext muss an den Daemon übertragen werden. Die Docker-CLI meldet „Build-Kontext wird gesendet
to Docker daemon“, wenn der Kontext an den Daemon gesendet wird.

Wenn die URL zu einem Tarball-Archiv oder zu einer einzelnen Docker-Datei angegeben wird, wird kein Kontext gesendet
vom Client zum Docker-Daemon. In diesem Fall die Docker-Datei im Stammverzeichnis von
Archiv und der Rest des Archivs werden als Kontext des Builds verwendet. Wenn ein Git
Das Repository ist als festgelegt URL, wird das Repository lokal geklont und dann als gesendet
Kontext.

OPTIONAL

-f, --Datei=PATH/Dockerfile
Pfad zur zu verwendenden Docker-Datei. Wenn der Pfad ein relativer Pfad ist und Sie es sind
Wenn Sie aus einem lokalen Verzeichnis erstellen, muss der Pfad relativ dazu sein
Verzeichnis. Wenn Sie von einer Remote-URL aus erstellen, die auf a
Tarball oder ein Git-Repository, dann muss der Pfad relativ zum Stammverzeichnis von sein
der Remote-Kontext. In allen Fällen muss sich die Datei im Build-Kontext befinden.
Die Standardeinstellung ist Dockerfile.

--build-arg=Variable
Name und Wert eines buildarg.

Wenn Sie beispielsweise einen Wert für übergeben möchten HTTP-Proxy, benutzen Sie
--build-arg=http_proxy="http://some.proxy.url"

Benutzer übergeben diese Werte zur Build-Zeit. Docker verwendet die buildargs wie die
Umgebungskontext für Befehle, die über die Docker-Dateien ausgeführt werden RENNE Unterricht
oder zur Variablenerweiterung in anderen Dockerfile-Anweisungen. Das ist nicht gemeint
zur Übergabe geheimer Werte. ⟨/reference/builder/#arg⟩

--force-rm=was immer dies auch sein sollte.|falsch
Entfernen Sie immer Zwischenbehälter, auch nach erfolglosen Builds. Die Standardeinstellung ist
falsch.

--Isolation="Standard"
Isolation gibt die Art der Isolationstechnologie an, die von Containern verwendet wird.

--no-cache=was immer dies auch sein sollte.|falsch
Verwenden Sie beim Erstellen des Images keinen Cache. Die Standardeinstellung ist falsch.

--help
Nutzungserklärung drucken

--ziehen=was immer dies auch sein sollte.|falsch
Versuchen Sie immer, eine neuere Version des Bildes abzurufen. Die Standardeinstellung ist falsch.

-q, --ruhig=was immer dies auch sein sollte.|falsch
Unterdrücken Sie die Build-Ausgabe und drucken Sie die Bild-ID bei Erfolg. Die Standardeinstellung ist falsch.

--rm=was immer dies auch sein sollte.|falsch
Entfernen Sie Zwischencontainer nach einem erfolgreichen Build. Die Standardeinstellung ist was immer dies auch sein sollte..

-t, --Schild=""
Repository-Namen (und optional mit Tags), die auf das resultierende Bild angewendet werden sollen
Erfolgsfall.

-m, --Erinnerung=SPEICHER
Speicherlimit

--Memory-Swap=LIMIT
Ein Grenzwert gleich Speicher plus Swap. Muss mit dem verwendet werden -m (--Erinnerung) Flagge. Die
tauschen LIMIT sollte immer größer sein als -m (--Erinnerung) Wert.

Das Format von LIMIT is [ ]. Einheit kann sein b (Byte), k (Kilobyte), m
(Megabyte), oder g (Gigabyte). Wenn Sie keine Einheit angeben, b wird genutzt. LIMIT auf setzen -1 zu
unbegrenzten Tausch aktivieren.

--shm-größe=SHM-GRÖSSE
Größe von / dev / shm. Das Format ist . Anzahl muss größer sein als 0.
Die Einheit ist optional und kann sein b (Byte), k (Kilobyte), m (Megabyte), oder g (Gigabyte).
Wenn Sie die Einheit weglassen, verwendet das System Bytes.
Wenn Sie die Größe ganz weglassen, verwendet das System 64m.

--cpu-anteile=0
CPU-Anteile (relatives Gewicht).

Standardmäßig erhalten alle Container den gleichen Anteil an CPU-Zyklen.
Bei den CPU-Anteilen handelt es sich um eine „relative Gewichtung“, relativ zur Standardeinstellung von 1024.
Dieser Standardwert wird hier definiert:

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

Sie können dieses Verhältnis ändern, indem Sie den CPU-Anteil des Containers anpassen
Gewichtung relativ zur Gewichtung aller anderen laufenden Container.

Um das Verhältnis vom Standardwert von 1024 zu ändern, verwenden Sie die --cpu-anteile
Flag, um die Gewichtung auf 2 oder höher festzulegen.

Container-CPU-Freigabe-Flag
{C0} 60 % der CPU --cpu-shares=614 (614 ist 60 % von 1024)
{C1} 40 % der CPU --cpu-shares=410 (410 ist 40 % von 1024)

Der Anteil wird nur angewendet, wenn CPU-intensive Prozesse ausgeführt werden.
Wenn Aufgaben in einem Container inaktiv sind, können die anderen Container sie verwenden
verbleibende CPU-Zeit. Die tatsächlich genutzte CPU-Zeit variiert je nach
die Anzahl der Container, die auf dem System ausgeführt werden.

Stellen Sie sich zum Beispiel drei Container vor, von denen einer vorhanden ist --cpu-shares=1024 und
zwei andere haben --cpu-shares=512. Bei Prozessen in allen drei
Container versuchen, 100 % der CPU zu nutzen, die der erste Container erhalten würde
50 % der gesamten CPU-Zeit. Wenn Sie einen vierten Container mit hinzufügen --cpu-shares=1024,
Der erste Container erhält nur 33 % der CPU. Die restlichen Container
erhalten 16.5 %, 16.5 % und 33 % der CPU.

Container-CPU-Anteil Flag-CPU-Zeit
{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 %

Auf einem Mehrkernsystem werden die Anteile der CPU-Zeit auf die CPU verteilt
Kerne. Selbst wenn ein Container auf weniger als 100 % der CPU-Zeit beschränkt ist, ist dies möglich
Nutzen Sie 100 % jedes einzelnen CPU-Kerns.

Stellen Sie sich beispielsweise ein System mit mehr als drei Kernen vor. Wenn Sie eins starten
Container {C0} mit --cpu-shares=512 einen Prozess und einen anderen Container ausführen
{C1} mit --cpu-shares=1024 Wenn zwei Prozesse ausgeführt werden, kann dies zu Folgendem führen
Aufteilung der CPU-Anteile:

PID-Container CPU CPU-Anteil
100 {C0} 0 100 % von CPU0
101 {C1} 1 100 % von CPU1
102 {C1} 2 100 % von CPU2

--CPU-Periode=0
Begrenzen Sie den CPU-CFS-Zeitraum (Completely Fair Scheduler).

Begrenzen Sie die CPU-Auslastung des Containers. Dieses Flag bewirkt, dass der Kernel die Datei einschränkt
CPU-Auslastung des Containers auf den von Ihnen angegebenen Zeitraum.

--CPU-Quote=0
Begrenzen Sie das CPU-CFS-Kontingent (Completely Fair Scheduler).

Standardmäßig werden Container mit der vollen CPU-Ressource ausgeführt. Dieses Flag veranlasst den Kernel dazu
Beschränken Sie die CPU-Auslastung des Containers auf das von Ihnen angegebene Kontingent.

--cpuset-cpus=CPUSET-CPU
CPUs, in denen die Ausführung zugelassen werden soll (0-3, 0,1).

--cpuset-speicher=CPUSET-MEMS
Speicherknoten (MEMs), in denen die Ausführung ermöglicht werden soll (0-3, 0,1). Nur wirksam am
NUMA-Systeme.

Wenn Ihr System beispielsweise über vier Speicherknoten (0-3) verfügt, verwenden Sie --cpuset-mems=0,1 zu
Stellen Sie sicher, dass die Prozesse in Ihrem Docker-Container nur Speicher aus den ersten beiden Speicher verwenden
Knoten.

--cgroup-parent=CGROUP-PARENT
Weg nach Gruppen unter dem der Container steht Kontrollgruppe erstellt werden.

Wenn der Pfad nicht absolut ist, wird er als relativ zum betrachtet Gruppen Weg des
Init-Prozess. Kontrollgruppen werden erstellt, sofern sie noch nicht vorhanden sind.

--ulimit= []
Ulimit-Optionen

Weitere Informationen zu unlimit sehen
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

Beispiele:

Building an Image Verwendung von a Dockerfile located innerhalb Strom Verzeichnis

Docker-Images können mit dem Build-Befehl und einer Docker-Datei erstellt werden:

Docker-Build.

Während des Build-Prozesses erstellt Docker Zwischenimages. Um sie zu behalten, Sie
muss explizit gesetzt werden --rm=false.

Docker Build --rm=false .

Eine gute Vorgehensweise besteht darin, ein Unterverzeichnis mit einem entsprechenden Namen zu erstellen und die Docker-Datei zu erstellen
in diesem Verzeichnis. Beispielsweise kann ein Verzeichnis namens mongo eine Docker-Datei enthalten
Erstellen Sie ein Docker MongoDB-Image. Ebenso kann ein anderes Verzeichnis namens httpd verwendet werden
Speichern Sie Docker-Dateien für Apache-Webserver-Images.

Es empfiehlt sich außerdem, die für das Bild erforderlichen Dateien dem Unterverzeichnis hinzuzufügen.
Diese Dateien werden dann mit angegeben COPY or ADD Anweisungen in der Dockerfile.

Hinweis: Wenn Sie eine TAR-Datei einschließen (eine bewährte Vorgehensweise), wird Docker die Datei automatisch extrahieren
Der Inhalt der darin angegebenen TAR-Datei ADD Anweisung in die angegebene
Ziel.

Building an Image und Benennung zur Verbesserung der Gesundheitsgerechtigkeit Image

Eine gute Vorgehensweise besteht darin, dem Image, das Sie erstellen, einen Namen zu geben. Beachten Sie, dass nur a-z0-9-_.
sollte aus Gründen der Konsistenz verwendet werden. Hier gibt es keine strengen Regeln, aber es ist am besten, die zu geben
Namen berücksichtigen.

Das -t/--Schild Flag wird verwendet, um ein Bild umzubenennen. Hier sind einige Beispiele:

Obwohl dies keine gute Vorgehensweise ist, können Bildnamen willkürlich sein:

docker build -t myimage .

Ein besserer Ansatz besteht darin, ein vollständig qualifiziertes und aussagekräftiges Repository, einen Namen und ein Tag bereitzustellen
(wobei das Tag in diesem Zusammenhang das Qualifikationsmerkmal nach dem „:“ bedeutet). In diesem Beispiel wir
Erstellen Sie ein JBoss-Image für das Fedora-Repository und geben Sie ihm die Version 1.0:

docker build -t fedora/jboss:1.0 .

Das nächste Beispiel ist für das Benutzer-Repository „whenry“ und verwendet Fedora und JBoss und gibt
Es ist die Version 2.1:

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

Wenn Sie kein Versions-Tag angeben, weist Docker es zu neueste:

docker build -t whenry/fedora-jboss .

Wenn Sie die Bilder auflisten, wird das Bild oben mit dem Tag versehen neueste.

Sie können einem Bild mehrere Tags zuweisen. Sie können beispielsweise die anwenden neueste Tag zu a
Erstellen Sie ein neu erstelltes Image und fügen Sie ein weiteres Tag hinzu, das auf eine bestimmte Version verweist. Zum Beispiel, um
Taggen Sie ein Bild sowohl als whenry/fedora-jboss:latest und whenry/fedora-jboss:v2.1, Verwenden Sie die
wie folgt vor:

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

Das Umbenennen eines Bildes ist also willkürlich, es sollte jedoch auf eine sinnvolle Konvention geachtet werden
Das ist für Verbraucher sinnvoll und sollte auch die Docker-Community berücksichtigen
Konventionen.

Building an Image Verwendung von a URL

Dadurch wird das angegebene GitHub-Repository von der URL geklont und als Kontext verwendet. Der
Als Dockerfile wird die Dockerfile im Stammverzeichnis des Repositorys verwendet. Dies funktioniert nur, wenn die
Das GitHub-Repository ist ein dediziertes Repository.

Docker-Build github.com/scollier/purpletest

Hinweis: Sie können ein beliebiges Git-Repository über festlegen git:// Schema.

Building an Image Verwendung von a URL zu a tarballiert Kontext

Dadurch wird die URL selbst an den Docker-Daemon gesendet. Der Daemon ruft den Tarball ab
Archiv, dekomprimieren Sie es und verwenden Sie seinen Inhalt als Build-Kontext. Die Docker-Datei am
Das Stammverzeichnis des Archivs und der Rest des Archivs werden als Kontext des Builds verwendet.
Wenn Sie eine bestehen -f PATH/Dockerfile Wenn Sie diese Option ebenfalls auswählen, sucht das System nach dieser Datei
im Inhalt des Tarballs.

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

Hinweis: Unterstützte Komprimierungsformate sind „xz“, „bzip2“, „gzip“ und „identity“ (Nr
Kompression).

Angeben Isolierung Technologie für Container (--Isolation)

Diese Option ist in Situationen nützlich, in denen Sie Docker-Container unter Windows ausführen.
Das --isolation= Die Option legt die Isolationstechnologie eines Containers fest. Unter Linux das einzige
Unterstützt wird das Standard Option, die Linux-Namespaces verwendet. Unter Microsoft Windows ist das möglich
Geben Sie diese Werte an:

· Standard: Verwenden Sie den vom Docker-Daemon angegebenen Wert --exec-opt . Wenn der Daemon die
keine Isolationstechnologie angeben, Microsoft Windows verwendet Prozessdefinierung als Standardeinstellung
Wert.

· Prozessdefinierung: Nur Namespace-Isolation.

· hyperv: Hyper-V-Hypervisor-Partitionsbasierte Isolierung.

Angabe der --Isolation Flag ohne Wert ist dasselbe wie Setzen
--isolation="default".

GESCHICHTE

März 2014, ursprünglich zusammengestellt von William Henry (whenry bei redhat dot com), basierend auf
Quellmaterial und interne Arbeit von docker.com. Juni 2014, aktualisiert von Sven Dowideit
⟨[E-Mail geschützt] ⟩ Juni 2015, aktualisiert von Sally O'Malley ⟨[E-Mail geschützt] ⟩

Verwenden Sie Docker-Build online mit den onworks.net-Diensten