As montagens Bind apareceram nos primeiros dias do Docker. Em comparação com os volumes, a montagem de ligação tem recursos limitados. Quando você usa a montagem de ligação, os arquivos ou diretórios no host são montados no contêiner. O arquivo ou diretório é referenciado por seu caminho completo ou relativo no host. Por outro lado, ao usar um volume, crie um novo diretório no diretório de armazenamento do Docker no host, e o Docker gerencia o conteúdo do diretório.
O arquivo ou diretório não precisa existir no host Docker. Se ainda não existir, crie-o sob demanda. O desempenho das montagens de ligação é muito bom, mas elas dependem do sistema de arquivos do host, que possui uma estrutura de diretório utilizável específica. Se você estiver desenvolvendo um novo aplicativo Docker, considere usar volumes nomeados . Você não pode usar os comandos da CLI do Docker para gerenciar diretamente as montagens de ligação.
Selecione -vou --mountmarque
Inicialmente, -vou --volumemarcado para contêineres separados, --mountrotulado para serviços de cluster. No entanto, a partir do Docker 17.06, você também pode --mountser usado independentemente do contêiner. Normalmente, a --mountexpressão da marca é mais clara e detalhada. A maior diferença é a -vsintaxe para todas as combinações de opções em um campo e as --mountopções de sintaxe separadas. A seguir está uma comparação de sintaxe de cada tag.
Dica: Novos usuários recomendam o uso da
--mountgramática, usuários experientes podem estar mais familiarizados-vou com a--volumegramática, mas também incentivam o uso da--mountgramática, pois estudos mostraram que é mais fácil de usar.
-vOu--volume: Consiste em três campos, separados por dois pontos (:). Os campos devem ser organizados na ordem correta e o significado de cada campo não é intuitivo o suficiente.- Para montagens de ligação, o primeiro campo é o caminho do arquivo ou diretório no host.
- O segundo campo é o caminho onde o arquivo ou diretório no contêiner é montado.
- O terceiro campo é opcional, é uma lista separada por vírgulas de opções, tais como
ro,consistent,delegated,cached,zeZ. Essas opções serão discutidas abaixo neste artigo.
--mount: Uma pluralidade de chaves - pares de valores, separados por vírgulas, cada chave - o valor de uma das<key>=<value>tuplas.--mountSintaxe do que-vou--volumemais detalhada, mas a ordem das chaves não é importante, o valor da tag também é mais fácil de entender.- O tipo de montagem (
type), que pode serbind,volumeoutmpfs. Este tópico discute montagens de ligação, portanto, o type (type) é sempre montagem de ligação (bind). - A origem do mount (
source). Para montagens de ligação, este é o caminho do arquivo ou diretório no host daemon do Docker. Você pode ser usadosourceousrcespecificado. - Target (
destination), o caminho onde o arquivo ou diretório no contêiner é montado como seu valor. Ele pode ser usadodestination,dstoutargetespecificar. readonlyA opção (se houver), a montagem de ligação será montada no contêiner como somente leitura .bind-propagationOpção (se houver), altere a propagação da vinculação . Os valores possíveis sãorprivate,private,rshared,shared,rslaveouslaveum.consistencyOpções (se houver), valores possíveisconsistent,delegatedoucachedum. Esta configuração se aplica apenas ao Docker Desktop para Mac e é ignorada em outras plataformas.--mountTag não suporta rótulos selinux usados para modificarzouZopções.
- O tipo de montagem (
O exemplo a seguir mostra o mais simultaneamente possível --mounte as -vduas sintaxes, e a primeira mostra --mount.
-vE --mounta diferença entre o comportamento
Porque -ve -volumemarcação Docker tem sido uma parte, o seu comportamento não pode ser alterado. Isso significa -ve -mountentre há um comportamento diferente.
Se você usar -vou -volumepara vincular montagens no arquivo host do Docker ou o diretório não existir, ele -vo criará. É sempre criado como um diretório.
Se você estiver usando --mountmontagens de ligação no arquivo host do Docker ou o diretório não existir, o Docker não o criará automaticamente para você, mas gerará um erro.
Inicie o contêiner com montagem de ligação
Considere uma situação: você tem um diretório source, ao construir o código-fonte, a peça de trabalho é salva em outro diretório source/target/em. Você deseja trabalhar no /app/diretório do contêiner está disponível, e cada vez que você deseja construir o código-fonte no host de desenvolvimento, o contêiner pode acessar o novo edifício. Use o seguinte comando para target/catalogar a montagem por ligação no contêiner /app/. No sourcediretório do comando de execução. Em hosts Linux ou macOS, o $(pwd)subcomando se expande para o diretório de trabalho atual.
Abaixo --mounte os -vexemplos produzirão os mesmos resultados. A menos que seja removido após executar o primeiro devtestrecipiente de amostra , ou não possa executá-los ao mesmo tempo.
--mount：
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app \
nginx:latest
-v：
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app \
nginx:latest
Use para docker inspect devtestverificar se as montagens de ligação foram criadas corretamente. Ver Mountsparte:
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/source/target",
"Destination": "/app",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
],
Isso indica que a montagem é uma bindmontagem, que mostra a origem e o destino corretos, também é mostrada montada legível e gravável e está configurada para espalhar rprivate.
Pare o recipiente:
$ docker container stop devtest
$ docker container rm devtest
Diretório não vazio montado no contêiner
Se você ligar-montar para um diretório não vazio no contêiner, o conteúdo existente do diretório será sobrescrito pela ligação-montagem. Isso pode ser benéfico, por exemplo, quando você deseja testar uma nova versão do aplicativo sem construir uma nova imagem. No entanto, também pode ser surpreendente que esse comportamento seja diferente dos volumes do docker .
Este exemplo é projetado para ser extremo, o host usando apenas o /tmp/diretório de /usr/conteúdo do diretório do container de recarga . Na maioria dos casos, isso fará com que o contêiner não funcione corretamente.
--mountE -vexemplos dos mesmos resultados.
--mount：
$ docker run -d \
-it \
--name broken-container \
--mount type=bind,source=/tmp,target=/usr \
nginx:latest
docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".
-v：
$ docker run -d \
-it \
--name broken-container \
-v /tmp:/usr \
nginx:latest
docker: Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"nginx\": executable file not found in $PATH".
O contêiner foi criado, mas não iniciado. Delete isso:
$ docker container rm broken-container
Use montagem de ligação somente leitura
Para alguns aplicativos de desenvolvimento, o contêiner precisa gravar para vincular montagens, de modo que as alterações sejam propagadas de volta para o host Docker. Em outras ocasiões, o contêiner só precisa de acesso de leitura.
Este exemplo modifica o exemplo acima, mas monta roo diretório como uma montagem de ligação somente leitura , adicionando-o à lista de opções (vazia por padrão) após o ponto de montagem no contêiner . Quando houver várias opções, separe-as com vírgulas.
--mountE -vexemplos dos mesmos resultados.
--mount：
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app,readonly \
nginx:latest
-v：
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app:ro \
nginx:latest
Use para docker inspect devtestverificar se as montagens de ligação foram criadas corretamente. Ver Mountsparte:
"Mounts": [
{
"Type": "bind",
"Source": "/tmp/source/target",
"Destination": "/app",
"Mode": "ro",
"RW": false,
"Propagation": "rprivate"
}
],
Pare o recipiente:
$ docker container stop devtest
$ docker container rm devtest
Configure a propagação de ligação
Para montagens e volumes de bind, os padrões de propagação de bind são ambos rprivate. Ele só pode ser configurado para montagem de ligação e só pode ser configurado em um host Linux. A propagação de vinculação é um tópico avançado e muitos usuários nunca precisam configurá-la.
A propagação de ligação se refere a se uma montagem criada em uma determinada montagem de ligação ou volume nomeado pode ser propagada para uma cópia da montagem. Considere um ponto de /mntmontagem, monte-o /tmp. O controle de propagação é fornecido /tmp/amontado para permitir ou não o /mnt/auso. Cada configuração de propagação tem uma contraparte recursiva. No caso de recursão, considere /tmp/atambém ser montado como /foo. Configuração de controle de propagação /mnt/ae / ou /tmp/aa presença ou ausência.
| Configurações de disseminação | Descrição |
|---|---|
| compartilhado | As submontagens da montagem original são expostas à montagem da réplica e as submontagens da réplica também são propagadas para a montagem original. |
| escravo | Semelhante à montagem compartilhada, mas apenas em uma direção. Se a montagem original expõe a submontagem, a réplica pode vê-lo. No entanto, se a cópia montar uma submontagem pública, a montagem original não poderá vê-la. |
| privado | A montagem é privada. As submontagens da montagem original não são expostas à montagem da réplica e as submontagens da réplica não são expostas à montagem original. |
| rshared | O mesmo que compartilhado, mas a propagação também se estende a pontos de montagem aninhados em qualquer ponto de montagem original ou duplicado. |
| rslave | O mesmo que o escravo, mas a propagação também se estende a pontos de montagem aninhados em qualquer ponto de montagem original ou de réplica. |
| privado | Padrões. O mesmo que privado, isso significa que os pontos de montagem em qualquer lugar nos pontos de montagem originais ou duplicados não se propagarão em nenhuma direção. |
Antes de configurar a propagação de ligação no ponto de montagem, o sistema de arquivos do host precisa suportar a propagação de ligação.
Para obter mais informações sobre a propagação de ligação, consulte a documentação da subárvore compartilhada do kernel Linux .
O seguinte exemplo de target/diretório duplo é montado na embarcação, o segundo conjunto de roopções de carregamento e rslavepropagação de opções de ligação.
--mountE -vexemplos dos mesmos resultados.
--mount：
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,target=/app \
--mount type=bind,source="$(pwd)"/target,target=/app2,readonly,bind-propagation=rslave \
nginx:latest
-v：
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app \
-v "$(pwd)"/target:/app2:ro,rslave \
nginx:latest
Agora, se você o criar /app/foo/, /app2/foo/ele também existe.
Configurar tags selinux
Se estiver usando selinux, você pode adicionar zou Zopções para modificar a montagem do selinux para rotular os contêineres do arquivo host ou diretório. Isso afetará arquivos ou diretórios no host e terá consequências além do escopo do Docker.
zA opção indica que o conteúdo de montagem de ligação é compartilhado entre vários contêineres.ZA opção indica que o conteúdo de montagem de ligação é privado e não compartilhado.
Seja extremamente cuidadoso ao usar essas opções . Use ZOpções do diretório do sistema montado por ligação (como /homeou /usr) para que seu host não funcione, você pode precisar remarcar manualmente o arquivo de hosts.
IMPORTANTE: Ao usar montagens de ligação para serviço, o selinux marca (
:Ze:Z) e:roserá ignorado. Veja moby / moby # 32579 para detalhes .
Este exemplo define a zopção de especificar que vários contêineres podem compartilhar ligações de conteúdo montadas:
Você não pode usar a --mounttag para modificar o rótulo selinux.
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app:z \
nginx:latest
Configure a consistência de montagem para macOS
O Docker Desktop para Mac usa a osxfspartir de diretórios compartilhados do macOS e arquivos espalhados para a VM Linux. Essa disseminação disponibiliza esses diretórios e arquivos para contêineres do Docker em execução no Docker Desktop para Mac.
Por padrão, esses compartilhamentos são completamente consistentes, o que significa que sempre que ocorre uma operação de gravação no host macOS ou por meio de uma montagem no contêiner, as alterações são descarregadas no disco para que todos os participantes no compartilhamento tenham uma Visualização de consistência completa. Em alguns casos, a consistência completa pode afetar gravemente o desempenho. O Docker 17.05 e as versões superiores apresentam algumas opções para ajustar as configurações de consistência por montagem e por contêiner. As seguintes opções estão disponíveis:
consistentOudefault: A configuração padrão para consistência total, conforme descrito acima.delegated: A visualização de montagem do tempo de execução do contêiner é autoritativa. As atualizações feitas no contêiner podem demorar antes de serem visíveis no host.cached: A visualização de montagem do host macOS é autorizada. As atualizações feitas no host podem demorar antes de ficarem visíveis no contêiner.
Essas opções são completamente ignoradas em todos os sistemas operacionais host, exceto macOS.
--mountE -vexemplos dos mesmos resultados.
--mount：
$ docker run -d \
-it \
--name devtest \
--mount type=bind,source="$(pwd)"/target,destination=/app,consistency=cached \
nginx:latest
-v：
$ docker run -d \
-it \
--name devtest \
-v "$(pwd)"/target:/app:cached \
nginx:latest
Autor:
Tradutor do site oficial do Docker : Technical Zemin
Editor: Links dos Versos Técnicos
: texto em inglês