As imagens de "distração" contêm apenas seu aplicativo e suas dependências de tempo de execução. Eles não contêm gerentes de pacotes, conchas ou outros programas que você esperaria encontrar em uma distribuição Linux padrão.
Para mais informações, consulte esta palestra (vídeo).
Desde março de 2023, as imagens de distração usam os manifestos de OCI, se você vir erros referenciando application/vnd.oci.image.manifest.v1+json
ou application/vnd.oci.image.index.v1+json
, atualize sua ferramenta de contêiner (Docker, Jib, etc) a mais recente.
Restringir o que está em seu contêiner de tempo de execução a precisamente o que é necessário para o seu aplicativo é uma melhor prática empregada pelo Google e outros gigantes da tecnologia que usam contêineres em produção por muitos anos. Melhora o sinal do ruído dos scanners (por exemplo, CVE) e reduz o ônus de estabelecer a proveniência para o que você precisa.
As imagens de distridade são muito pequenas . A menor imagem com distração, gcr.io/distroless/static-debian12
, é em torno de 2 mib. Isso representa cerca de 50% do tamanho da alpine
(~ 5 MIB) e menos de 2% do tamanho do debian
(124 MIB).
Essas imagens são construídas usando o Bazel, mas também podem ser usadas através de outras ferramentas de construção de imagens do Docker.
As imagens a seguir são publicadas e atualizadas no projeto Distroless (consulte Support_Policy para obter cronogramas de suporte)
Imagem | Tags | Sufixos de arquitetura |
---|---|---|
gcr.io/distroless/static-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/base-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/base-nossl-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/cc-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/python3-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64 |
gcr.io/distroless/java-base-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, S390X, PPC64LE |
gcr.io/distroless/java17-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, S390X, PPC64LE |
gcr.io/distroless/java21-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, PPC64LE |
gcr.io/distroless/nodejs18-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/nodejs20-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
gcr.io/distroless/nodejs22-debian12 | mais recente, não-robusta, depuração, depuração-não-nonroot | AMD64, ARM64, ARM, S390X, PPC64LE |
Essas imagens se referem a índices de imagem com referências a todas as arquiteturas suportadas. Imagens específicas da arquitetura podem ser referenciadas diretamente usando um sufixo de arquitetura adicional na tag, como gcr.io/distroless/static-debian12:latest-amd64
Quaisquer outras tags são consideradas depreciadas e não são mais atualizadas
Todas as imagens de distração são assinadas por Cosign com ênfase (sem chave) - este é o único mecanismo suportado a partir de novembro de 2023. Recomendamos verificar qualquer imagem distroleira que você use antes de criar sua imagem. Você pode verificar a assinatura sem chave de qualquer imagem distrasta com:
cosign verify $IMAGE_NAME --certificate-oidc-issuer https://accounts.google.com --certificate-identity [email protected]
Observe que as imagens de distração por padrão não contêm um shell. Isso significa que o comando DockerFile ENTRYPOINT
, quando definido, deve ser especificado em forma vector
, para evitar o prefixo do tempo de execução do contêiner com um shell.
Isso funciona:
ENTRYPOINT ["myapp"]
Mas isso não funciona:
ENTRYPOINT "myapp"
Pelas mesmas razões, se o ponto de entrada estiver definido como o vetor vazio, o comando CMD deverá ser especificado em forma vector
(consulte os exemplos abaixo). Observe que, por padrão, as imagens estáticas, base e CC têm o ponto de entrada do vetor vazio. Imagens com um tempo de execução de idioma incluído têm um padrão específico de idioma (consulte: Java, NodeJS, Python3).
As compilações multi-estágios do Docker facilitam o uso de imagens distraídas. Siga estas etapas para começar:
Escolha a imagem base certa para sua pilha de aplicativos.
Escreva um arquivo do Docker de várias etapas. Nota: Isso requer o Docker 17.05 ou superior.
A idéia básica é que você terá um estágio para construir seus artefatos de aplicativos e insira -os na sua imagem de distração de tempo de execução. Se você quiser saber mais, consulte a documentação sobre compilações com vários estágios.
Aqui está um exemplo rápido para ir:
# Start by building the application.
FROM golang:1.18 as build
WORKDIR /go/src/app
COPY . .
RUN go mod download
RUN CGO_ENABLED=0 go build -o /go/bin/app
# Now copy it into our base image.
FROM gcr.io/distroless/static-debian12
COPY --from=build /go/bin/app /
CMD [ "/app" ]
Você pode encontrar outros exemplos aqui:
Para executar qualquer exemplo, vá ao diretório para o idioma e corra
docker build -t myapp .
docker run -t myapp
Para executar o Node.js Express App Node-Express e expor as portas do contêiner:
npm install # Install express and its transitive dependencies
docker build -t myexpressapp . # Normal build command
docker run -p 3000:3000 -t myexpressapp
Isso deve expor o aplicativo expresso ao seu localhost: 3000
Para uma documentação completa sobre como usar o Bazel para gerar imagens de contêineres, consulte o repositório Bazel-Contrib/Regras_OCI.
Para documentação e exemplo sobre como usar o Debian Package Manager baseado em GO (atual) para gerar a Bazel Config, consulte ./debian_package_manager para documentação e exemplos sobre como usar as regras do Bazel Package Manager (não usadas neste repositório), consulte. /package_manager
Exemplos podem ser encontrados neste repositório no diretório de exemplos.
Temos alguns exemplos sobre como executar algumas pilhas de aplicativos comuns no diretório /exemplos. Veja aqui para:
Veja aqui exemplos sobre como concluir algumas tarefas comuns à sua imagem:
Veja aqui mais informações sobre como essas imagens são construídas e lançadas.
As imagens de distridade são baseadas no Debian 12 (Livroworm). As imagens são explicitamente marcadas com os sufixos da versão Debian (por exemplo, -debian12
). Especificar uma imagem sem a distribuição atualmente selecionará imagens -debian12
, mas isso mudará no futuro para uma versão mais recente do Debian. Pode ser útil fazer referência explicitamente da distribuição, para evitar a quebra de compilações quando a próxima versão do Debian for lançada.
A distridade rastreia os lançamentos do Debian Upstream, usando ações do GitHub para gerar automaticamente uma solicitação de tração quando houver atualizações.
As imagens de distridade são mínimas e não têm acesso à concha. A imagem :debug
definida para cada idioma fornece um shell BusyBox para entrar.
Por exemplo:
cd examples/python3/
Edite o Dockerfile
para alterar a imagem final para :debug
:
FROM gcr.io/distroless/python3-debian12:debug
COPY . /app
WORKDIR /app
CMD [ "hello.py" , "/etc" ]
Em seguida, construa e inicie com um ponto de entrada do shell:
$ docker build -t my_debug_image .
$ docker run --entrypoint=sh -ti my_debug_image
/app # ls
BUILD Dockerfile hello.py
NOTA: Se a imagem que você está usando já tiver uma tag, por exemplo,
gcr.io/distroless/java17-debian12:nonroot
, use o tagdebug-<existing tag>
em vez disso, por exemplo,gcr.io/distroless/java17-debian12:debug-nonroot
.
NOTA: O LDD não está instalado na imagem base, pois é um script de shell, você pode copiá -lo ou baixá -lo.
Se o seu projeto usa distração, envie um PR para adicionar seu projeto aqui!