homem
v1.23.2
As seguintes condições devem ser atendidas:
Cabe a você encontrar a ferramenta de automação que melhor atenda às suas necessidades. Recomendamos o uso de um sistema CI/CD moderno, como fluxos de trabalho GitHub ou GitLab CI. Como nós (os autores) usamos o GitLab CI, os exemplos a seguir são adaptados para esta plataforma específica, mas os princípios subjacentes devem ser aplicados em qualquer outro lugar e os exemplos são mantidos simples o suficiente, para que você possa acompanhar, mesmo sem qualquer experiências anteriores com esta plataforma específica. Em caso de dúvida, visite a página de referência gitlab-ci.yml para uma visão geral abrangente das palavras-chave do GitLab CI.
gitlab-ci.yml:
# define a job for building the containers
build-container :
stage : container-build
# run parallel builds for the desired architectures
parallel :
matrix :
- ARCH : amd64
- ARCH : arm64
tags :
# run each build on a suitable, preconfigured runner (must match the target architecture)
- runner-${ARCH}
image :
name : gcr.io/kaniko-project/executor:debug
entrypoint : [""]
script :
# build the container image for the current arch using kaniko
- >-
/kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile
"${CI_PROJECT_DIR}/Dockerfile" # push the image to the GitLab container
registry, add the current arch as tag. --destination
"${CI_REGISTRY_IMAGE}:${ARCH}" gitlab-ci.yml:
# define a job for creating and pushing a merged manifest
merge-manifests :
stage : container-build
# all containers must be build before merging them
# alternatively the job may be configured to run in a later stage
needs :
- job : container-build
artifacts : false
tags :
# may run on any architecture supported by manifest-tool image
- runner-xyz
image :
name : mplatform/manifest-tool:alpine
entrypoint : [""]
script :
- >-
manifest-tool # authorize against your container registry
--username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push
from-args # define the architectures you want to merge --platforms
linux/amd64,linux/arm64 # "ARCH" will be automatically replaced by
manifest-tool # with the appropriate arch from the platform definitions
--template ${CI_REGISTRY_IMAGE}:ARCH # The name of the final, combined
image which will be pushed to your registry --target ${CI_REGISTRY_IMAGE} Para simplificar, evitamos deliberadamente usar imagens marcadas com versão (todas as compilações serão marcadas como "mais recentes") nos exemplos anteriores, pois achamos que isso adiciona muito código específico à plataforma e ao fluxo de trabalho.
No entanto, para qualquer pessoa interessada em como lidamos com o versionamento (dinâmico) no GitLab, aqui está um breve resumo:
CI_COMMIT_TAG predefinida do GitLab ao executar um pipeline de tags.needs dos trabalhos de construção e mesclagem de acordo), que definirá a tag como latest ao executar no branch padrão, ao hash de commit quando executado em outras ramificações e à tag de lançamento quando executado em um pipeline de tags.gitlab-ci.yml:
container-get-tag :
stage : pre-container-build-stage
tags :
- runner-xyz
image : busybox
script :
# All other branches are tagged with the currently built commit SHA hash
- |
# If pipeline runs on the default branch: Set tag to "latest"
if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then
tag="latest"
# If pipeline is a tag pipeline, set tag to the git commit tag
elif test -n "$CI_COMMIT_TAG"; then
tag="$CI_COMMIT_TAG"
# Else set the tag to the git commit sha
else
tag="$CI_COMMIT_SHA"
fi
- echo "tag=$tag" > build.env
# parse tag to the build and merge jobs.
# See: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
artifacts :
reports :
dotenv : build.env Ferramentas semelhantes incluem:
Todas essas ferramentas criam imagens de contêiner com abordagens diferentes.
BuildKit (e img ) pode funcionar como um usuário não root de dentro de um contêiner, mas requer que seccomp e AppArmor sejam desabilitados para criar contêineres aninhados. Na verdade, kaniko não cria contêineres aninhados, portanto, não exige que o seccomp e o AppArmor sejam desativados. BuildKit oferece suporte a contêineres multi-arch de "construção cruzada" aproveitando o QEMU.
orca-build depende do runc para construir imagens a partir de Dockerfiles, que não podem ser executadas dentro de um contêiner (por motivos semelhantes aos img acima). kaniko não usa runc , portanto não requer o uso de técnicas de namespace do kernel. No entanto, orca-build não requer Docker ou qualquer daemon privilegiado (portanto, compilações podem ser feitas totalmente sem privilégios).
umoci funciona sem quaisquer privilégios e também não tem restrições quanto ao sistema de arquivos raiz que está sendo extraído (embora exija manipulação adicional se o seu sistema de arquivos for suficientemente complicado). No entanto, ele não possui ferramentas de construção semelhantes Dockerfile (é uma ferramenta de nível ligeiramente inferior que pode ser usada para construir tais construtores - como orca-build ).
Buildah é especializada na construção de imagens OCI. Os comandos do Buildah replicam todos os comandos encontrados em um Dockerfile. Isso permite construir imagens com e sem Dockerfiles sem exigir nenhum privilégio de root. O objetivo final do Buildah é fornecer uma interface coreutils de nível inferior para construir imagens. A flexibilidade de construir imagens sem Dockerfiles permite a integração de outras linguagens de script no processo de construção. Buildah segue um modelo fork-exec simples e não funciona como um daemon, mas é baseado em uma API abrangente em golang, que pode ser vendida em outras ferramentas.
FTL e Bazel visam alcançar a criação mais rápida possível de imagens Docker para um subconjunto de imagens. Eles podem ser considerados um "caminho rápido" de caso especial que pode ser usado em conjunto com o suporte para Dockerfiles gerais que o kaniko fornece.
Grupo do Google de usuários kaniko
Para contribuir com kaniko, consulte DEVELOPMENT.md e CONTRIBUTING.md.
Ao tirar um instantâneo, os algoritmos de hash de kaniko incluem (ou no caso de --snapshot-mode=time , use apenas) o mtime de um arquivo para determinar se o arquivo foi alterado. Infelizmente, há um atraso entre o momento em que as alterações em um arquivo são feitas e o momento em que o mtime é atualizado. Isso significa:
--snapshot-mode=time ), kaniko pode perder totalmente as alterações introduzidas pelos comandos RUN .--snapshot-mode=full ), se kaniko adicionará ou não uma camada no caso em que um comando RUN modifica um arquivo , mas o conteúdo não muda é teoricamente não determinístico. Isto não afeta o conteúdo que ainda estará correto, mas afeta o número de camadas.Observe que essas questões são atualmente apenas teóricas. Se você perceber que esse problema ocorre, abra um problema.
--chown suporte Kaniko atualmente suporta os comandos COPY --chown e ADD --chown Dockerfile. Não suporta RUN --chown .
