docker-build - Online na nuvem

PROGRAMA:

NOME

docker-build - Construir uma nova imagem a partir do código-fonte em PATH

SINOPSE

docker construir [--build-arg[=[]]] [--cpu-shares[=0]] [--cgroup-pai[=CGROUP-PAI]]
[--Socorro] [-f|--Arquivo[=PATH / Dockerfile]] [--force-rm] [--isolamento[=omissão]] [--sem cache]
[--puxar] [-q|--quieto] [--rm[=verdadeiro]] [-t|--marcação[=[]]] [-m|--memória[=MEMÓRIA]]
[- troca de memória[=LIMITE]] [--shm-tamanho[=TAMANHO SHM]] [--cpu-período[=0]] [--cpu-cota[=0]]
[--cpuset-cpus[=CPUSET-CPU]] [--cpuset-mems[=CPUSET-MEMS]] [--ulimit[=[]]] CAMINHO | URL | -

DESCRIÇÃO

Isso lerá o Dockerfile do diretório especificado em PATH. Ele também envia qualquer
outros arquivos e diretórios encontrados no diretório atual para o daemon do Docker. o
o conteúdo deste diretório seria usado por ADD comandos encontrados no Dockerfile.

Aviso, isso enviará muitos dados ao daemon do Docker, dependendo do conteúdo do
o diretório atual. A compilação é executada pelo daemon do Docker, não pela CLI, portanto, todo
o contexto deve ser transferido para o daemon. O Docker CLI relata "Enviando contexto de construção
ao daemon do Docker "quando o contexto é enviado ao daemon.

Quando o URL para um arquivo tarball ou para um único Dockerfile é fornecido, nenhum contexto é enviado
do cliente para o daemon do Docker. Neste caso, o Dockerfile na raiz do
arquivo e o resto do arquivo será usado como o contexto da construção. Quando um Git
repositório é definido como o URL, o repositório é clonado localmente e, em seguida, enviado como o
contexto.

OPÇÕES

-f, --Arquivo=PATH / Dockerfile
Caminho para o Dockerfile a ser usado. Se o caminho é relativo e você é
construir a partir de um diretório local, então o caminho deve ser relativo àquele
diretório. Se você estiver construindo a partir de um URL remoto apontando para um
tarball ou um repositório Git, então o caminho deve ser relativo à raiz de
o contexto remoto. Em todos os casos, o arquivo deve estar dentro do contexto de construção.
O padrão é dockerfile.

--build-arg=variável
nome e valor de um construir.

Por exemplo, se você deseja passar um valor para proxy HTTP, usar
--build-arg = http_proxy = "http://some.proxy.url"

Os usuários passam esses valores no momento da construção. Docker usa o buildargs como o
contexto de ambiente para comandos executados por meio do Dockerfile CORRE instrução
ou para expansão variável em outras instruções do Dockerfile. Isso não é para dizer
para transmitir valores secretos. ⟨/ Reference / builder / # arg⟩

--force-rm=verdadeiro|falso
Sempre remova os contêineres intermediários, mesmo após compilações malsucedidas. O padrão é
falso.

--isolamento="omissão"
O isolamento especifica o tipo de tecnologia de isolamento usada pelos contêineres.

--sem cache=verdadeiro|falso
Não use o cache ao construir a imagem. O padrão é falso.

--Socorro
Imprimir declaração de uso

--puxar=verdadeiro|falso
Sempre tente obter uma versão mais recente da imagem. O padrão é falso.

-q, --quieto=verdadeiro|falso
Suprima a saída da construção e imprima o ID da imagem em caso de sucesso. O padrão é falso.

--rm=verdadeiro|falso
Remova os contêineres intermediários após uma construção bem-sucedida. O padrão é verdadeiro.

-t, --marcação= ""
Nomes de repositório (e opcionalmente com tags) a serem aplicados à imagem resultante em
caso de sucesso.

-m, --memória=MEMÓRIA
Limite de memória

- troca de memória=LIMITE
Um valor limite igual a memória mais troca. Deve ser usado com o -m (--memória) bandeira. o
trocar LIMITE deve sempre ser maior do que -m (--memória) valor.

O formato de LIMITE is [ ]. Unidade pode ser b (byte), k (quilobytes), m
(megabytes), ou g (gigabytes). Se você não especificar uma unidade, b é usado. Defina LIMIT para -1 para
permitir troca ilimitada.

--shm-tamanho=TAMANHO SHM
Tamanho de / dev / shm. O formato é . número deve ser superior a 0.
A unidade é opcional e pode ser b (byte), k (quilobytes), m (megabytes), ou g (gigabytes).
Se você omitir a unidade, o sistema usará bytes.
Se você omitir o tamanho inteiramente, o sistema usa 64m.

--cpu-shares=0
Compartilhamento de CPU (peso relativo).

Por padrão, todos os contêineres obtêm a mesma proporção de ciclos de CPU.
Os compartilhamentos da CPU são um 'peso relativo', em relação à configuração padrão de 1024.
Este valor padrão é definido aqui:

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

Você pode alterar esta proporção ajustando a participação da CPU do contêiner
ponderação em relação à ponderação de todos os outros contêineres em funcionamento.

Para modificar a proporção do padrão de 1024, use o --cpu-shares
sinalizador para definir a ponderação para 2 ou superior.

Sinalizador de compartilhamento de CPU do contêiner
{C0} 60% da CPU --cpu-shares = 614 (614 é 60% de 1024)
{C1} 40% da CPU --cpu-shares = 410 (410 é 40% de 1024)

A proporção é aplicada apenas quando processos com uso intensivo de CPU estão em execução.
Quando as tarefas em um contêiner estão ociosas, os outros contêineres podem usar o
sobra de tempo de CPU. A quantidade real de tempo de CPU usado varia de acordo com
o número de contêineres em execução no sistema.

Por exemplo, considere três contêineres, onde um tem --cpu-shares = 1024 e
dois outros têm --cpu-shares = 512. Quando os processos em todos os três
contêineres tentam usar 100% da CPU, o primeiro contêiner receberá
50% do tempo total da CPU. Se você adicionar um quarto contêiner com --cpu-shares = 1024,
o primeiro contêiner obtém apenas 33% da CPU. Os recipientes restantes
recebem 16.5%, 16.5% e 33% da CPU.

Tempo de CPU do sinalizador de compartilhamento de CPU do contêiner
{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%

Em um sistema com vários núcleos, as partes do tempo da CPU são distribuídas pela CPU
núcleos. Mesmo se um contêiner estiver limitado a menos de 100% do tempo de CPU, ele pode
use 100% de cada núcleo de CPU individual.

Por exemplo, considere um sistema com mais de três núcleos. Se você começar um
recipiente {C0} com --cpu-shares = 512 executando um processo e outro contêiner
{C1} com --cpu-shares = 1024 executando dois processos, isso pode resultar no seguinte
divisão de compartilhamentos de CPU:

Compartilhamento de CPU do contêiner PID
100 {C0} 0 100% da CPU0
101 {C1} 1 100% da CPU1
102 {C1} 2 100% da CPU2

--cpu-período=0
Limite o período de CPU CFS (Completely Fair Scheduler).

Limite o uso da CPU do contêiner. Este sinalizador faz com que o kernel restrinja o
o uso da CPU do contêiner para o período que você especificar.

--cpu-cota=0
Limite a cota de CPU CFS (Completely Fair Scheduler).

Por padrão, os contêineres são executados com o recurso completo da CPU. Este sinalizador faz com que o kernel
restringir o uso da CPU do contêiner à cota que você especificar.

--cpuset-cpus=CPUSET-CPU
CPUs nas quais permitir a execução (0-3, 0,1).

--cpuset-mems=CPUSET-MEMS
Nós de memória (MEMs) nos quais permitir a execução (0-3, 0,1). Efetivo somente em
Sistemas NUMA.

Por exemplo, se você tiver quatro nós de memória em seu sistema (0-3), use --cpuset-mems = 0,1 para
garantir que os processos em seu contêiner do Docker usem apenas a memória dos dois primeiros
nós.

--cgroup-pai=CGROUP-PAI
Caminho para grupos sob o qual o contêiner é cgrupo são criados.

Se o caminho não for absoluto, o caminho é considerado relativo ao grupos caminho do
processo de inicialização. Os cgroups são criados se ainda não existirem.

--ulimit= []
Opções Ulimit

Para mais informações sobre ulimit Vejo
⟨Https: //docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

EXEMPLOS

Prédio an imagem utilização a dockerfile localizado dentro que o atual anuário

As imagens do Docker podem ser construídas usando o comando build e um Dockerfile:

construção docker.

Durante o processo de construção, o Docker cria imagens intermediárias. A fim de mantê-los, você
deve definir explicitamente --rm = false.

docker build --rm = false.

Uma boa prática é fazer um subdiretório com um nome relacionado e criar o Dockerfile
nesse diretório. Por exemplo, um diretório chamado mongo pode conter um Dockerfile para
crie uma imagem Docker MongoDB. Da mesma forma, outro diretório chamado httpd pode ser usado para
armazenar Dockerfiles para imagens do servidor da web Apache.

Também é uma boa prática adicionar os arquivos necessários para a imagem ao subdiretório.
Esses arquivos serão então especificados com o CÓPIA or ADD instruções no dockerfile.

Nota: Se você incluir um arquivo tar (uma boa prática), o Docker irá extrair automaticamente
o conteúdo do arquivo tar especificado no ADD instrução no especificado
alvo.

Prédio an imagem e nomeando que imagem

Uma boa prática é dar um nome à imagem que você está construindo. Observe que apenas a-z0-9-_.
deve ser usado para consistência. Não existem regras rígidas aqui, mas é melhor dar o
consideração de nomes.

A -t/--marcação flag é usado para renomear uma imagem. aqui estão alguns exemplos:

Embora não seja uma boa prática, os nomes das imagens podem ser arbitrários:

docker build -t myimage.

Uma abordagem melhor é fornecer um repositório, nome e tag totalmente qualificados e significativos
(onde a tag neste contexto significa o qualificador após ":"). Neste exemplo nós
construir uma imagem JBoss para o repositório Fedora e fornecer a versão 1.0:

docker build -t fedora / jboss: 1.0.

O próximo exemplo é para o repositório do usuário "whenry" e usa Fedora e JBoss e dá
é a versão 2.1:

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

Se você não fornecer uma tag de versão, o Docker atribuirá mais recente:

docker build -t whenry / fedora-jboss.

Quando você listar as imagens, a imagem acima terá a tag mais recente.

Você pode aplicar várias marcas a uma imagem. Por exemplo, você pode aplicar o mais recente marcar para um
imagem recém-construída e adicione outra tag que faça referência a uma versão específica. Por exemplo, para
marcar uma imagem como whenry / fedora-jboss: mais recente e whenry / fedora-jboss: v2.1, Utilize o
A seguir:

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

Portanto, renomear uma imagem é arbitrário, mas deve-se considerar uma convenção útil
isso faz sentido para os consumidores e também deve levar em consideração a comunidade Docker
convenções.

Prédio an imagem utilização a URL

Isso clonará o repositório GitHub especificado do URL e o usará como contexto. o
Dockerfile na raiz do repositório é usado como Dockerfile. Isso só funciona se o
O repositório GitHub é um repositório dedicado.

docker build github.com/scollier/purpletest

Observação: você pode definir um repositório Git arbitrário por meio do git: // esquema.

Prédio an imagem utilização a URL para a tarball contexto

Isso enviará a própria URL para o daemon do Docker. O daemon irá buscar o tarball
arquivar, descompactar e usar seu conteúdo como contexto de construção. O Dockerfile no
a raiz do arquivo e o resto do arquivo serão usados ​​como o contexto da construção.
Se você passar por um -f PATH / Dockerfile opção também, o sistema irá procurar por esse arquivo
dentro do conteúdo do tarball.

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

Nota: os formatos de compressão suportados são 'xz', 'bzip2', 'gzip' e 'identidade' (não
compressão).

Especificar isolamento tecnologia para recipiente (--isolamento)

Essa opção é útil em situações em que você está executando contêineres do Docker no Windows.
A --isolation = opção define a tecnologia de isolamento de um contêiner. No Linux, o único
suportado é o omissão opção que usa namespaces do Linux. No Microsoft Windows, você pode
especifique estes valores:

· omissão: Use o valor especificado pelo daemon do Docker --exec-opt . Se o demônio parece
não especificar uma tecnologia de isolamento, o Microsoft Windows usa processo como seu padrão
valor.

· processo: Apenas isolamento de namespace.

· hiperv: Isolamento baseado em partição de hipervisor Hyper-V.

Especificando o --isolamento sinalizar sem um valor é o mesmo que definir
--isolation = "padrão".

HISTÓRIA

Março de 2014, Compilado originalmente por William Henry (whenry at redhat ponto com) com base em
material de origem e trabalho interno da docker.com. Junho de 2014, atualizado por Sven Dowideit
⟨[email protegido]⟩ Junho de 2015, atualizado por Sally O'Malley ⟨[email protegido]⟩

Use docker-build online usando serviços onworks.net