official images
1.0.0
As imagens oficiais do Docker são imagens selecionadas hospedadas no Docker Hub. Os principais princípios são:
Concentre-se em software gratuito e de código aberto
Suporta múltiplas arquiteturas
Exemplifique as práticas recomendadas Dockerfile
Reconstruir ativamente para atualizações e correções de segurança
Siga as recomendações iniciais
Adicione um comportamento mínimo de qualidade de vida para o ambiente de contêiner onde for adequado
Consulte a documentação do Docker para uma boa visão geral de alto nível do programa.
Em essência, nós nos esforçamos para seguir as recomendações do upstream sobre como eles pretendem que seu software seja consumido. Muitas imagens são mantidas em colaboração com o projeto upstream relevante, caso não sejam mantidas diretamente por eles. Além disso, pretendemos exemplificar as melhores práticas para Dockerfiles servirem de referência ao criar ou derivar suas próprias imagens deles.
(Se você é representante de um upstream para o qual existe uma imagem e gostaria de se envolver, consulte a seção Manutenção abaixo!)
Algumas imagens foram portadas para outras arquiteturas e muitas delas são oficialmente suportadas (em vários graus).
arm32v6 ): https://hub.docker.com/u/arm32v6/arm32v7 ): https://hub.docker.com/u/arm32v7/arm64v8 ): https://hub.docker.com/u/arm64v8/amd64 ): https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ): https://hub.docker.com/u/arm32v5/ppc64le ): https://hub.docker.com/u/ppc64le/s390x ): https://hub.docker.com/u/s390x/mips64le ): https://hub.docker.com/u/mips64le/riscv64 ): https://hub.docker.com/u/riscv64/i386 ): https://hub.docker.com/u/i386/ A partir de 12/09/2017, essas outras arquiteturas são incluídas nas imagens não prefixadas por meio de "listas de manifestos" (também conhecidas como "índices" na especificação de imagem OCI), de modo que, por exemplo, docker run hello-world deveria execute como está em todas as plataformas suportadas.
Se você estiver curioso sobre como eles são construídos, acesse https://doi-janky.infosiftr.net/job/multiarch/ para ver o andaime de construção.
Veja a seção multiarquitetura abaixo para recomendações sobre como adicionar mais arquiteturas a uma imagem oficial.
Sim! Temos um repositório dedicado de FAQ onde tentamos coletar outras dúvidas comuns (tanto sobre o programa quanto sobre nossas práticas).
Obrigado pelo seu interesse no projeto de imagens oficiais do Docker! Nós nos esforçamos para tornar essas instruções o mais simples e diretas possível, mas se você estiver perdido, não hesite em nos procurar no Libera.Chat IRC no canal #docker-library ou criando um problema no GitHub aqui.
Certifique-se de se familiarizar com os Repositórios Oficiais no Docker Hub e com as Melhores práticas para escrever Dockerfiles na documentação do Docker. Estas serão a base do processo de revisão realizado pelos mantenedores oficiais das imagens. Se desejar que o processo de revisão seja mais tranquilo, certifique-se de que seus Dockerfile cumpram todos os pontos mencionados lá, bem como abaixo, antes de enviar uma solicitação pull.
Além disso, as descrições do Hub para essas imagens estão atualmente armazenadas separadamente no repositório docker-library/docs , cujo arquivo README.md explica mais sobre como está estruturado e como contribuir para isso. Esteja preparado para enviar um PR lá também, aguardando a aceitação de sua imagem aqui.
Como as imagens oficiais pretendem ser ferramentas de aprendizagem para aqueles que são novos no Docker, bem como as imagens base para usuários avançados criarem suas versões de produção, revisamos cada Dockerfile proposto para garantir que ele atenda a um padrão mínimo de qualidade e facilidade de manutenção. Embora alguns desses padrões sejam difíceis de definir (devido à subjetividade), o máximo possível é definido aqui, ao mesmo tempo que aderimos às "Melhores Práticas" quando apropriado.
Uma lista de verificação que pode ser usada pelos mantenedores durante a revisão pode ser encontrada em NEW-IMAGE-CHECKLIST.md .
As alterações de versão e as correções de segurança devem ser atendidas em tempo hábil.
Se você não representa o upstream e o upstream se interessar em manter a imagem, medidas devem ser tomadas para garantir uma transição suave da manutenção da imagem para o upstream.
Para upstreams interessados em assumir a manutenção de um repositório existente, o primeiro passo é envolver-se no repositório existente. Fazer comentários sobre problemas, propor mudanças e tornar-se conhecido dentro da "comunidade de imagens" (mesmo que essa "comunidade" seja apenas o mantenedor atual) são pontos importantes para começar a garantir que a transição não seja surpreendente para os colaboradores e usuários existentes.
Ao assumir um repositório existente, certifique-se de que todo o histórico Git do repositório original seja mantido no novo repositório mantido pelo upstream para garantir que o processo de revisão não seja paralisado durante a transição. Isso é feito mais facilmente bifurcando o novo do repositório existente, mas também pode ser feito buscando os commits diretamente do original e enviando-os para o novo repositório (ou seja, git fetch https://github.com/jsmith/example.git master , git rebase FETCH_HEAD , git push -f ). No GitHub, uma alternativa é mover a propriedade do repositório git. Isso pode ser feito sem conceder acesso de administrador do grupo ao repositório do outro proprietário:
A reconstrução do mesmo Dockerfile deve resultar no empacotamento da mesma versão da imagem, mesmo que a segunda compilação ocorra várias versões depois, ou a compilação falhe completamente, de modo que uma reconstrução inadvertida de um Dockerfile marcado como 0.1.0 não termine contendo 0.2.3 . Por exemplo, se estiver usando apt para instalar o programa principal da imagem, certifique-se de fixá-lo em uma versão específica (ex: ... apt-get install -y my-package=0.1.0 ... ). Para pacotes dependentes instalados pelo apt normalmente não há necessidade de fixá-los em uma versão.
Nenhuma imagem oficial pode ser derivada ou depender de imagens não oficiais (permitindo o scratch não imagem e as exceções intencionalmente limitadas fixadas em .external-pins - veja também .external-pins/list.sh ).
Todas as imagens oficiais devem fornecer uma interface consistente. Um usuário iniciante deve ser capaz de docker run official-image bash (ou sh ) sem precisar aprender sobre --entrypoint . Também é bom que usuários avançados aproveitem o ponto de entrada, para que possam docker run official-image --arg1 --arg2 sem precisar especificar o binário a ser executado.
Caso o processo de inicialização não precise de argumentos, basta usar CMD :
CMD [ "irb" ] Se houver uma inicialização que precise ser feita no início, como a criação do banco de dados inicial, use um ENTRYPOINT junto com CMD :
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] Certifique-se de que docker run official-image bash (ou sh ) também funcione. A maneira mais fácil é verificar o comando esperado e se for outra coisa, basta exec "$@" (executar o que foi passado, mantendo corretamente os argumentos escapados).
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ " Se a imagem contém apenas o executável principal e suas bibliotecas vinculadas (ou seja, sem shell), então não há problema em usar o executável como ENTRYPOINT , já que é a única coisa que pode ser executada:
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ] O indicador mais comum de que isso é apropriado é que o Dockerfile da imagem começa do scratch ( FROM scratch ).
Tente tornar o Dockerfile fácil de entender/ler. Pode ser tentador, por uma questão de brevidade, colocar detalhes complicados de inicialização em um script independente e simplesmente adicionar um comando RUN no Dockerfile . No entanto, isso faz com que o Dockerfile resultante seja excessivamente opaco e é improvável que tais Dockerfile sejam aprovados na revisão. Em vez disso, é recomendado colocar todos os comandos para inicialização no Dockerfile como combinações de comandos RUN ou ENV apropriadas. Para encontrar bons exemplos, veja as imagens oficiais atuais.
Alguns exemplos no momento da escrita:
Seguindo as diretrizes do Docker, é altamente recomendável que a imagem resultante seja apenas uma preocupação por contêiner; predominantemente, isso significa apenas um processo por contêiner, portanto não há necessidade de um sistema init completo. Existem duas situações em que um processo semelhante ao init seria útil para o contêiner. O primeiro é o tratamento de sinais. Se o processo iniciado não manipular SIGTERM ao sair, ele não será eliminado, pois é o PID 1 no contêiner (consulte "NOTA" no final da seção Primeiro plano na documentação do docker). A segunda situação seria a colheita de zumbis. Se o processo gerar processos filhos e não os colher adequadamente, isso levará a uma tabela de processos completa, o que pode impedir que todo o sistema gere novos processos. Para ambas as preocupações, recomendamos o tini. É incrivelmente pequeno, tem dependências externas mínimas, preenche cada uma dessas funções e faz apenas as partes necessárias de coleta e encaminhamento de sinal.
Certifique-se de usar tini no CMD ou ENTRYPOINT conforme apropriado.
É melhor instalar o tini a partir de um pacote fornecido pela distribuição (ex. apt-get install tini ). Se o tini não estiver disponível na sua distribuição ou for muito antigo, aqui está um trecho de um Dockerfile para adicionar no tini:
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --versionEste é um lugar onde a experiência acaba superando a documentação no caminho para a iluminação, mas as dicas a seguir podem ajudar:
Evite COPY / ADD sempre que possível, mas quando necessário, seja o mais específico possível (ou seja, COPY one-file.sh /somewhere/ em vez de COPY . /somewhere ).
A razão para isso é que o cache para instruções COPY considera as alterações do arquivo mtime como uma falha de cache, o que às vezes pode tornar o comportamento do cache de COPY imprevisível, especialmente quando .git faz parte do que precisa ser COPY ed (por exemplo).
Certifique-se de que as linhas com menor probabilidade de alteração venham antes das linhas com maior probabilidade de alteração (com a ressalva de que cada linha deve gerar uma imagem que ainda seja executada com êxito, sem suposições de linhas posteriores).
Por exemplo, a linha que contém o número da versão do software ( ENV MYSOFTWARE_VERSION 4.2 ) deve vir depois de uma linha que configura o arquivo .list do repositório APT ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list ).
O Dockerfile deve ser escrito para ajudar a mitigar ataques de interceptação durante a construção. Nossos requisitos se concentram em três objetivos principais: verificação da fonte, verificação do autor e verificação do conteúdo; estes são realizados respectivamente da seguinte forma: usando https sempre que possível; importação de chaves PGP com impressão digital completa no Dockerfile para verificação de assinaturas; incorporando somas de verificação diretamente no Dockerfile . Todos os três devem ser usados quando possível. Apenas https e soma de verificação incorporada podem ser usados quando nenhuma assinatura é publicada. Como último recurso, apenas uma soma de verificação incorporada é aceitável se o site não tiver https disponível e nenhuma assinatura.
O objetivo de recomendar o uso de https para baixar os artefatos necessários é garantir que o download seja de uma fonte confiável, o que também torna a interceptação muito mais difícil.
O objetivo de recomendar a verificação de assinatura PGP é garantir que apenas um usuário autorizado publique o artefato fornecido. Ao importar chaves PGP, use o serviço keys.openpgp.org quando possível (preferindo keyserver.ubuntu.com caso contrário). Consulte também a seção FAQ sobre chaves e verificação.
O objetivo de recomendar a verificação da soma de verificação é verificar se o artefato está conforme o esperado. Isso garante que, quando o conteúdo remoto for alterado, o Dockerfile também será alterado e fornecerá uma interrupção natural do cache docker build . Como bônus, isso também evita o download acidental de artefatos mais recentes do que o esperado em arquivos com versão inadequada.
Abaixo estão alguns exemplos:
Preferencial : download via https, importação completa de impressão digital da chave PGP e verificação asc , soma de verificação incorporada verificada.
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# installAlternativa : impressão digital de chave completa importada para o apt, que verificará assinaturas e somas de verificação quando os pacotes forem baixados e instalados.
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (Como observação lateral, rm -rf /var/lib/apt/lists/* é aproximadamente o oposto de apt-get update - garante que a camada não inclua os ~ 8 MB extras de dados da lista de pacotes APT e impõe o uso apropriado apt-get update .)
Alternativa menos segura : incorpore a soma de verificação no Dockerfile .
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# installNota: o uso de SHA1 ou MD5 deve ser considerado uma "soma de verificação de último recurso", pois ambos são considerados geralmente inseguros:
Inaceitável : baixe o arquivo por http(s) sem verificação.
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install Por padrão, os contêineres Docker são executados com privilégios reduzidos: recursos Linux na lista de permissões, grupos de controle e um perfil Seccomp padrão (1.10+ com suporte de host). O software executado em um contêiner pode exigir privilégios adicionais para funcionar corretamente, e há diversas opções de linha de comando para personalizar a execução do contêiner. Consulte docker run Reference e Seccomp for Docker para referência.
Os repositórios oficiais que exigem privilégios adicionais devem especificar o conjunto mínimo de opções de linha de comando para o software funcionar e ainda podem ser rejeitados se isso introduzir problemas significativos de portabilidade ou segurança. Em geral, --privileged não é permitido, mas uma combinação das opções --cap-add e --device pode ser aceitável. Além disso, --volume pode ser complicado, pois há muitos locais de sistemas de arquivos host que introduzem problemas de portabilidade/segurança (por exemplo, soquete X11).
Para atualizações de imagem que constituem uma correção de segurança, recomendamos algumas coisas para ajudar a garantir que sua atualização seja mesclada, criada e lançada o mais rápido possível:
[email protected] com alguns dias (úteis) de antecedência para nos avisar e uma estimativa de tempo (para que possamos agendar o horário para a atualização recebida de forma adequada).[security] no título da sua solicitação pull (por exemplo, [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 ). Cada repositório pode especificar várias arquiteturas para toda e qualquer tag. Se nenhuma arquitetura for especificada, as imagens serão criadas no Linux em amd64 (também conhecido como x86-64). Para especificar mais ou diferentes arquiteturas, use o campo Architectures (lista delimitada por vírgulas, os espaços em branco são cortados). Arquiteturas válidas são encontradas no arquivo oci-platform.go do Bashbrew:
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64 As Architectures de qualquer tag devem ser um subconjunto estrito das Architectures da tag FROM .
As imagens devem ter um único Dockerfile por entrada no arquivo de biblioteca que pode ser usado para múltiplas arquiteturas. Isto significa que cada arquitetura suportada terá a mesma linha FROM (por exemplo, FROM debian:bookworm ). Consulte golang , docker , haproxy e php para obter exemplos de arquivos de biblioteca usando um Dockerfile por entrada e veja seus respectivos repositórios git, por exemplo, Dockerfile s.
Se diferentes partes do Dockerfile acontecerem apenas em uma arquitetura ou outra, use o fluxo de controle (por exemplo, if / case ) junto com dpkg --print-architecture ou apk -print-arch para detectar a arquitetura do espaço do usuário. Use uname apenas para detecção de arquitetura quando ferramentas mais precisas não puderem ser instaladas. Veja golang para obter um exemplo em que algumas arquiteturas exigem a construção de binários a partir dos pacotes fonte originais e algumas apenas baixam a versão binária.
Para imagens base como debian será necessário ter um Dockerfile diferente e um contexto de construção para ADD binários específicos da arquitetura e esta é uma exceção válida ao acima. Como essas imagens usam as mesmas Tags , elas precisam estar na mesma entrada. Use os campos específicos da arquitetura para GitRepo , GitFetch , GitCommit e Directory , que são a arquitetura concatenada com hífen ( - ) e o campo (por exemplo, arm32v7-GitCommit ). Qualquer arquitetura que não tenha um campo específico de arquitetura usará o campo padrão (por exemplo, no arm32v7-Directory significa que Directory será usado para arm32v7 ). Veja os arquivos debian ou ubuntu na biblioteca para exemplos. A seguir está um exemplo para hello-world :
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
Consulte a seção de formato de instrução para obter mais informações sobre o formato do arquivo de biblioteca.
A proposta de uma nova imagem oficial não deve ser feita de ânimo leve. Esperamos e exigimos um compromisso de manter a sua imagem (incluindo e especialmente atualizações oportunas, conforme apropriado, conforme mencionado acima).
Os arquivos de definição da biblioteca são arquivos de texto simples encontrados no diretório library/ do repositório official-images . Cada arquivo de biblioteca controla o conjunto atual "suportado" de tags de imagem que aparecem na descrição do Docker Hub. Tags removidas de um arquivo de biblioteca não são removidas do Docker Hub, para que versões antigas possam continuar disponíveis para uso, mas não são mantidas pelo upstream ou pelo mantenedor da imagem oficial. Tags no arquivo de biblioteca são construídas apenas através de uma atualização naquele arquivo de biblioteca ou como resultado da atualização de sua imagem base (ou seja, uma imagem FROM debian:bookworm seria reconstruída quando debian:bookworm fosse construída). Somente o que estiver no arquivo da biblioteca será reconstruído quando uma base tiver atualizações.
Dada esta política, vale a pena esclarecer alguns casos: versões preenchidas, release candidate e builds de integração contínua. Quando um novo repositório é proposto, é comum incluir algumas versões mais antigas e não suportadas na solicitação pull inicial com o acordo de removê-las logo após a aceitação. Não confunda isto com um arquivo histórico abrangente, o que não é a intenção. Outro caso comum em que o termo "suportado" é um pouco ampliado é com candidatos a lançamento. Um candidato a lançamento é, na verdade, apenas uma convenção de nomenclatura para lançamentos que se espera que sejam de vida mais curta, portanto, são totalmente aceitáveis e incentivados. Ao contrário de um release candidate, as compilações de integração contínua que possuem um ciclo de lançamento totalmente automatizado baseado em confirmações de código ou em uma programação regular não são apropriadas.
É altamente recomendável que você navegue em alguns dos conteúdos library/ arquivos existentes (e no histórico para ter uma ideia de como eles mudam ao longo do tempo) antes de criar um novo para se familiarizar com as convenções predominantes e ajudar ainda mais a simplificar o processo de revisão (para que podemos nos concentrar no conteúdo em vez da formatação esotérica ou no uso/nomeação de tags).
O nome do arquivo de definição determinará o nome do repositório de imagens que ele cria no Docker Hub. Por exemplo, o arquivo library/ubuntu criará tags no repositório ubuntu .
As tags de um repositório devem refletir as versões ou variações do upstream. Por exemplo, Ubuntu 14.04 também é conhecido como Ubuntu Trusty Tahr, mas muitas vezes simplesmente como Ubuntu Trusty (especialmente em uso), então ubuntu:14.04 (número da versão) e ubuntu:trusty (nome da versão) são aliases apropriados para o mesmo conteúdo da imagem. No Docker, a tag latest é um caso especial, mas é um nome um pouco impróprio; latest é realmente a tag "default". Quando alguém faz docker run xyz , o Docker interpreta isso como docker run xyz:latest . Dado esse histórico, nenhuma outra tag contém a string latest , já que não é algo que os usuários sejam esperados ou incentivados a digitar (ou seja, xyz:latest deve realmente ser usado simplesmente como xyz ). Dito de outra forma, ter um alias para a "versão mais alta da série 2.2 de XYZ" deve ser xyz:2.2 , não xyz:2.2-latest . Da mesma forma, se houver uma variante Alpine de xyz:latest , ela deverá ter o alias de xyz:alpine , não xyz:alpine-latest ou xyz:latest-alpine .
É fortemente encorajado que as tags de número de versão recebam apelidos que tornem mais fácil para o usuário permanecer na versão "mais recente" de uma série específica. Por exemplo, dadas as versões 2.3.7 e 2.2.4 do software XYZ atualmente suportadas, os aliases sugeridos seriam Tags: 2.3.7, 2.3, 2, latest e Tags: 2.2.4, 2.2 , respectivamente. Neste exemplo, o usuário pode usar xyz:2.2 para usar facilmente a versão de patch mais recente da série 2.2, ou xyz:2 se for necessária menos granularidade (Python é um bom exemplo de onde isso é obviamente mais útil - python:2 e python:3 são muito diferentes e podem ser consideradas como a tag latest para cada uma das principais faixas de lançamento do Python).
Conforme descrito acima, latest é realmente "padrão", portanto, a imagem para a qual é um alias deve refletir qual versão ou variação do software os usuários devem usar se não souberem ou não se importarem com a versão que usam. Usando o Ubuntu como exemplo, ubuntu:latest aponta para a versão LTS mais recente, visto que é o que a maioria dos usuários deveria usar se soubessem que querem o Ubuntu, mas não sabem ou não se importam com qual versão (especialmente considerando que será a versão mais "estável" e bem suportada em um determinado momento).
O formato do arquivo de manifesto é oficialmente baseado no RFC 2822 e, como tal, deve ser familiar para pessoas que já estão familiarizadas com os "cabeçalhos" de muitos protocolos/formatos populares da Internet, como HTTP ou e-mail.
As principais adições são inspiradas na forma como o Debian normalmente usa 2822 - ou seja, as linhas que começam com # são ignoradas e as "entradas" são separadas por uma linha em branco.
A primeira entrada são os metadados "globais" da imagem. O único campo obrigatório na entrada global é Maintainers , cujo valor é separado por vírgula no formato Name <email> (@github) ou Name (@github) . Qualquer campo especificado na entrada global será o padrão para o restante das entradas e poderá ser substituído em uma entrada individual.
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
O Bashbrew irá buscar o código do repositório Git ( GitRepo ) no commit especificado ( GitCommit ). Se o commit referenciado não estiver disponível ao buscar master do GitRepo associado, será necessário fornecer um valor para GitFetch para informar ao Bashbrew qual ref buscar para obter o commit necessário.
A imagem construída será marcada como <manifest-filename>:<tag> (ou seja, library/golang com um valor de Tags de 1.6, 1, latest criará tags de golang:1.6 , golang:1 e golang:latest ).
Opcionalmente, se Directory estiver presente, o Bashbrew procurará o Dockerfile dentro do subdiretório especificado em vez de na raiz (e Directory será usado como o "contexto" para a construção em vez do nível superior do repositório). Se File estiver presente, o nome de arquivo especificado em vez de Dockerfile será usado.
Consulte a seção multiarquitetura para obter detalhes sobre como especificar um GitRepo , GitFetch , GitCommit ou Directory diferente para uma arquitetura específica.
library/ pasta. Seu nome será o nome do seu repositório no Hub. Bashbrew ( bashbrew ) é uma ferramenta para clonar, construir, marcar e enviar imagens oficiais do Docker. Consulte o README do Bashbrew para obter mais informações.
