docker-build - En ligne dans le Cloud

PROGRAMME:

Nom

docker-build - Construire une nouvelle image à partir du code source de PATH

SYNOPSIS

docker construire [--build-arg[=[]]] [--cpu-partages[=0]] [--cgroup-parent[=GROUPE-PARENT]]
[--Aidez-moi] [-f|--déposer[=CHEMIN/Fichier Docker]] [--force-rm] [--isolement[=défaut]] [--pas de cache]
[--tirer] [-q|--silencieux] [--rm[=oui]] [-t|--étiqueter[=[]]] [-m|--Mémoire[=MÉMOIRE]]
[--échange de mémoire[=LIMIT]] [--shm-taille[=TAILLE SHM]] [--cpu-période[=0]] [--cpu-quota[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] CHEMIN | URL | -

DESCRIPTION

Cela lira le Dockerfile à partir du répertoire spécifié dans PATH. Il envoie également tout
autres fichiers et répertoires trouvés dans le répertoire actuel au démon Docker. Les
le contenu de ce répertoire serait utilisé par ADD commandes trouvées dans le Dockerfile.

Attention, cela enverra beaucoup de données au démon Docker en fonction du contenu de
le répertoire courant. La construction est exécutée par le démon Docker, pas par la CLI, donc l'ensemble
le contexte doit être transféré au démon. Le Docker CLI signale "Envoi du contexte de construction
au démon Docker" lorsque le contexte est envoyé au démon.

Lorsque l'URL d'une archive tar ou d'un seul Dockerfile est fournie, aucun contexte n'est envoyé
du client au démon Docker. Dans ce cas, le Dockerfile à la racine du
archive et le reste de l'archive sera utilisé comme contexte de la construction. Quand un Git
le référentiel est défini comme le URL, le référentiel est cloné localement puis envoyé en tant que
contexte

OPTIONS

-f, --déposer=CHEMIN/Fichier Docker
Chemin d'accès au Dockerfile à utiliser. Si le chemin est un chemin relatif et que vous êtes
construire à partir d'un répertoire local, alors le chemin doit être relatif à celui
annuaire. Si vous construisez à partir d'une URL distante pointant vers un
tarball ou un référentiel Git, le chemin doit être relatif à la racine de
le contexte distant. Dans tous les cas, le fichier doit se trouver dans le contexte de génération.
La valeur par défaut est Dockerfile.

--build-arg=variable
nom et valeur d'un construction.

Par exemple, si vous souhaitez transmettre une valeur pour http proxy, utilisation
--build-arg=http_proxy="http://some.proxy.url"

Les utilisateurs transmettent ces valeurs au moment de la génération. Docker utilise le args de construction car
contexte d'environnement pour les commandes exécutées via le Dockerfile COURT instruction
ou pour l'expansion de variables dans d'autres instructions Dockerfile. Cela ne veut pas dire
pour transmettre des valeurs secrètes. ⟨/reference/builder/#arg⟩

--force-rm=oui|non
Retirez toujours les conteneurs intermédiaires, même après des constructions infructueuses. La valeur par défaut est
non.

--isolement="défaut"
Isolation spécifie le type de technologie d'isolation utilisée par les conteneurs.

--pas de cache=oui|non
N'utilisez pas le cache lors de la création de l'image. La valeur par défaut est non.

--Aidez-moi
Imprimer la déclaration d'utilisation

--tirer=oui|non
Essayez toujours d'extraire une version plus récente de l'image. La valeur par défaut est non.

-q, --silencieux=oui|non
Supprimez la sortie de génération et imprimez l'ID d'image en cas de succès. La valeur par défaut est non.

--rm=oui|non
Supprimez les conteneurs intermédiaires après une génération réussie. La valeur par défaut est oui.

-t, --étiqueter= ""
Noms de référentiel (et éventuellement avec des balises) à appliquer à l'image résultante dans
cas de réussite.

-m, --Mémoire=MÉMOIRE
Limite de mémoire

--échange de mémoire=LIMIT
Une valeur limite égale à la mémoire plus l'échange. Doit être utilisé avec le -m (--Mémoire) drapeau. Les
échange LIMIT doit toujours être plus grand que -m (--Mémoire) valeur.

Le format de LIMIT is [ ]. L'unité peut être b (octets), k (kilooctets), m
(mégaoctets), ou g (gigaoctets). Si vous ne spécifiez pas d'unité, b est utilisé. Réglez LIMIT sur -1 à
activer l'échange illimité.

--shm-taille=TAILLE SHM
Taille de / dev / shm. Le format est . nombre doit être supérieure 0.
L'unité est facultative et peut être b (octets), k (kilooctets), m (mégaoctets), ou g (gigaoctets).
Si vous omettez l'unité, le système utilise des octets.
Si vous omettez complètement la taille, le système utilise 64m.

--cpu-partages=0
Parts CPU (poids relatif).

Par défaut, tous les conteneurs reçoivent la même proportion de cycles CPU.
Les parts de CPU sont un « poids relatif », par rapport au paramètre par défaut de 1024.
Cette valeur par défaut est définie ici :

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

Vous pouvez modifier cette proportion en ajustant la part CPU du conteneur
pondération par rapport à la pondération de tous les autres conteneurs en cours d'exécution.

Pour modifier la proportion par défaut de 1024, utilisez le --cpu-partages
flag pour définir la pondération sur 2 ou plus.

Indicateur de partage du processeur du conteneur
{C0} 60% du CPU --cpu-shares=614 (614 est 60% de 1024)
{C1} 40% du CPU --cpu-shares=410 (410 est 40% de 1024)

La proportion n'est appliquée que lorsque des processus gourmands en ressources CPU sont en cours d'exécution.
Lorsque les tâches d'un conteneur sont inactives, les autres conteneurs peuvent utiliser le
temps CPU restant. La quantité réelle de temps CPU utilisé varie selon
le nombre de conteneurs exécutés sur le système.

Par exemple, considérons trois conteneurs, où l'un a --cpu-shares=1024 ainsi que
deux autres ont --cpu-shares=512. Lorsque les processus dans les trois
conteneurs tentent d'utiliser 100 % du processeur, le premier conteneur recevra
50% du temps CPU total. Si vous ajoutez un quatrième conteneur avec --cpu-shares=1024,
le premier conteneur n'obtient que 33% du CPU. Les conteneurs restants
reçoivent 16.5%, 16.5% et 33% du CPU.

Part de CPU du conteneur Marquer le temps 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 %

Sur un système multicœur, les parts de temps CPU sont réparties sur le CPU
noyaux. Même si un conteneur est limité à moins de 100 % du temps CPU, il peut
utiliser 100 % de chaque cœur de processeur individuel.

Par exemple, considérons un système avec plus de trois cœurs. Si vous en démarrez un
récipient {C0} avec --cpu-shares=512 exécuter un processus et un autre conteneur
{C1} avec --cpu-shares=1024 l'exécution de deux processus, cela peut entraîner ce qui suit
division des parts CPU :

Partage CPU du conteneur PID
100 {C0} 0 100 % du processeur0
101 {C1} 1 100 % du processeur1
102 {C1} 2 100 % du processeur2

--cpu-période=0
Limitez la période CPU CFS (Complètement Fair Scheduler).

Limitez l'utilisation du processeur du conteneur. Ce drapeau force le noyau à restreindre le
l'utilisation du processeur du conteneur à la période que vous spécifiez.

--cpu-quota=0
Limitez le quota CPU CFS (Complètement Fair Scheduler).

Par défaut, les conteneurs s'exécutent avec la ressource CPU complète. Ce drapeau fait que le noyau
restreindre l'utilisation du processeur du conteneur au quota que vous spécifiez.

--cpuset-cpus=CPUSET-CPU
CPU dans lesquels autoriser l'exécution (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Nœuds de mémoire (MEM) dans lesquels autoriser l'exécution (0-3, 0,1). Uniquement efficace sur
systèmes NUMA.

Par exemple, si vous avez quatre nœuds de mémoire sur votre système (0-3), utilisez --cpuset-mems=0,1 à
assurez-vous que les processus de votre conteneur Docker n'utilisent que la mémoire des deux premières mémoires
nœuds.

--cgroup-parent=GROUPE-PARENT
Chemin de groupes de contrôle sous lequel le conteneur groupe de contrôle sont créées.

Si le chemin n'est pas absolu, le chemin est considéré comme relatif au groupes de contrôle chemin du
processus d'initialisation. Les groupes de contrôle sont créés s'ils n'existent pas déjà.

--ulimit= []
Options illimitées

Pour plus d'informations sur ulimit sur le lien
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

EXEMPLES

Développement an image en utilisant a Dockerfile situé à l'intérieur le actuel annuaire

Les images Docker peuvent être créées à l'aide de la commande build et d'un fichier Docker :

construction de docker.

Pendant le processus de génération, Docker crée des images intermédiaires. Afin de les conserver, vous
doit explicitement définir --rm=faux.

docker build --rm=false .

Une bonne pratique consiste à créer un sous-répertoire avec un nom connexe et à créer le Dockerfile
dans ce répertoire. Par exemple, un répertoire appelé mongo peut contenir un Dockerfile pour
créer une image Docker MongoDB. De même, un autre répertoire appelé httpd peut être utilisé pour
stocker les Dockerfiles pour les images du serveur Web Apache.

Il est également recommandé d'ajouter les fichiers requis pour l'image dans le sous-répertoire.
Ces fichiers seront ensuite spécifiés avec le COPY or ADD instructions dans le Dockerfile.

Remarque : si vous incluez un fichier tar (une bonne pratique), Docker extraira automatiquement
le contenu du fichier tar spécifié dans le ADD instruction dans le spécifié
cible.

Développement an image ainsi que nommage qui image

Une bonne pratique consiste à donner un nom à l'image que vous construisez. Notez que seul a-z0-9-_.
doit être utilisé par souci de cohérence. Il n'y a pas de règles strictes ici, mais il est préférable de donner le
considération des noms.

La -t/--étiqueter flag est utilisé pour renommer une image. Voici quelques exemples:

Bien que ce ne soit pas une bonne pratique, les noms d'images peuvent être arbitraires :

docker build -t monimage .

Une meilleure approche consiste à fournir un référentiel, un nom et une balise pleinement qualifiés et significatifs
(où la balise dans ce contexte signifie le qualificatif après le ":"). Dans cet exemple, nous
construisez une image JBoss pour le référentiel Fedora et donnez-lui la version 1.0 :

docker build -t fedora/jboss:1.0 .

L'exemple suivant concerne le référentiel d'utilisateurs "whenry" et utilise Fedora et JBoss et donne
c'est la version 2.1 :

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

Si vous ne fournissez pas de balise de version, Docker attribuera Nouveautés:

docker build -t whenry/fedora-jboss .

Lorsque vous listez les images, l'image ci-dessus aura la balise Nouveautés.

Vous pouvez appliquer plusieurs balises à une image. Par exemple, vous pouvez appliquer le Nouveautés étiqueter sur un
image nouvellement construite et ajoutez une autre balise qui fait référence à une version spécifique. Par exemple, pour
tag une image à la fois comme whenry/fedora-jboss:dernier ainsi que quandry/fedora-jboss:v2.1, Utilisez l'
Suivante à la suite:

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

Renommer une image est donc arbitraire mais il faut tenir compte d'une convention utile
cela a du sens pour les consommateurs et devrait également prendre en compte la communauté Docker
conventions.

Développement an image en utilisant a URL

Cela clonera le référentiel GitHub spécifié à partir de l'URL et l'utilisera comme contexte. Les
Dockerfile à la racine du référentiel est utilisé comme Dockerfile. Cela ne fonctionne que si le
Le référentiel GitHub est un référentiel dédié.

docker construire github.com/scollier/purpletest

Remarque : Vous pouvez définir un référentiel Git arbitraire via le aller: // schéma.

Développement an image en utilisant a URL à a tarballé contexte

Cela enverra l'URL elle-même au démon Docker. Le démon va chercher l'archive
archive, décompressez-le et utilisez son contenu comme contexte de construction. Le Dockerfile au
racine de l'archive et le reste de l'archive sera utilisé comme contexte de la construction.
Si vous passez un -f CHEMIN/Fichier Docker également, le système recherchera ce fichier
à l'intérieur du contenu de l'archive tar.

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

Remarque : les formats de compression pris en charge sont 'xz', 'bzip2', 'gzip' et 'identity' (non
compression).

Spécifier seul sans souci en récipient (--isolement)

Cette option est utile dans les situations où vous exécutez des conteneurs Docker sous Windows.
La --isolement= L'option définit la technologie d'isolation d'un conteneur. Sous Linux, le seul
pris en charge est le défaut option qui utilise les espaces de noms Linux. Sous Microsoft Windows, vous pouvez
spécifiez ces valeurs :

· défaut: Utilisez la valeur spécifiée par le démon Docker --exec-opt . Si l' démon
ne spécifiez pas de technologie d'isolation, Microsoft Windows utilise processus par défaut
valeur.

· processus: isolation de l'espace de noms uniquement.

· hyperv: Isolation basée sur la partition de l'hyperviseur Hyper-V.

Spécification du --isolement indicateur sans valeur est le même que le paramètre
--isolation="default".

HISTOIRE

Mars 2014, à l'origine compilé par William Henry (whenry chez redhat dot com) basé sur
le matériel source de docker.com et le travail interne. Juin 2014, mis à jour par Sven Dowideit
⟨[email protected]⟩ Juin 2015, mis à jour par Sally O'Malley ⟨[email protected]⟩

Utiliser docker-build en ligne à l'aide des services onworks.net