kaniko

kaniko - Construa imagens no Kubernetes

NOTA: kaniko não é um produto do Google com suporte oficial

Limitações e armadilhas

As seguintes condições devem ser atendidas:

1. Você precisa de acesso a máquinas de construção executando as arquiteturas desejadas (executar Kaniko em um emulador, por exemplo, QEMU também deve ser possível, mas vai além do escopo desta documentação). Isso é algo para se ter em mente ao usar ferramentas de construção SaaS, como github.com ou gitlab.com, dos quais, no momento em que este artigo foi escrito, nenhum suporta executores SaaS não x86_64 (GitHub,GitLab), então esteja preparado para trazer o seu próprio máquinas (GitHub,GitLab.

2. Kaniko precisa ser capaz de rodar nas arquiteturas desejadas. No momento em que este artigo foi escrito, o contêiner Kaniko oficial suporta linux/amd64, linux/arm64, linux/s390x e linux/ppc64le (não em imagens *-debug).

3. O registro de contêiner de sua escolha deve ser compatível com OCIv1 ou Docker v2.2.

Exemplo de pipeline de CI (GitLab)

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.

Construindo as imagens de contêiner separadas

gitlab-ci.yml:

 # define um trabalho para construir o containersbuild-container: stage: container-build
  # executa compilações paralelas para as arquiteturas desejadas
  paralelo:matriz:
      - ARCO: amd64
  tags:# execute cada compilação em um executor pré-configurado adequado (deve corresponder à arquitetura de destino)- runner-${ARCH}
  imagem: nome: gcr.io/kaniko-project/executor:debugentrypoint: [""]
  script:# construa a imagem do contêiner para o arco atual usando kaniko- >- /kaniko/executor --context "${CI_PROJECT_DIR}" --dockerfile "${CI_PROJECT_DIR}/Dockerfile" # envie a imagem para o registro do contêiner GitLab, adicione o arco atual como tag. --destination "${CI_REGISTRY_IMAGE}:${ARCH}"

Mesclando os manifestos do contêiner

gitlab-ci.yml:

 # definir um trabalho para criar e enviar um manifestmerge-manifests mesclado: stage: container-build
  # todos os contêineres devem ser compilados antes de serem mesclados
  # alternativamente, o trabalho pode ser configurado para ser executado posteriormente
  precisa:
    - trabalho: artefatos de construção de contêiner: falso
  tags:# pode ser executado em qualquer arquitetura suportada pela ferramenta de manifesto image-runner-xyz
  imagem: nome: mplatform/manifest-tool:alpineentrypoint: [""]
  roteiro:
    - >- manifest-tool # autoriza no registro do seu contêiner --username=${CI_REGISTRY_USER} --password=${CI_REGISTRY_PASSWORD} push from-args # define as arquiteturas que você deseja mesclar --platforms linux/amd64,linux/arm64 # "ARCH" será automaticamente substituído por manifest-tool # pelo arco apropriado das definições da plataforma --template ${CI_REGISTRY_IMAGE}:ARCH # O nome da imagem final combinada que será enviada para o seu registro --target ${CI_REGISTRY_IMAGE}

Sobre a adição de tags versionadas

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:

• Se você estiver interessado apenas em criar lançamentos marcados, você pode simplesmente usar a variável CI_COMMIT_TAG predefinida do GitLab ao executar um pipeline de tags.

• Quando você (como nós) deseja construir adicionalmente imagens de contêiner fora dos lançamentos, as coisas ficam um pouco mais complicadas. No nosso caso, adicionamos um trabalho adicional que é executado antes dos trabalhos de construção e mesclagem (não se esqueça de estender a seção de 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: estágio: pré-container-build-stage
  tags:
    - corredor-xyz
  imagem: busybox
  script:# Todas as outras ramificações são marcadas com o hash SHA do commit atualmente construído- |      # Se o pipeline for executado na ramificação padrão: Defina a tag como "latest" if test "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH"; then tag="latest" # Se o pipeline for um pipeline de tags, defina a tag como a tag de commit do git elif test -n "$CI_COMMIT_TAG"; then tag="$CI_COMMIT_TAG" # Else defina a tag para git commit sha else tag="$CI_COMMIT_SHA" fi - echo "tag=$tag" > build.env
  # analisa a tag para os trabalhos de construção e mesclagem.
  # Veja: https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job
  artefatos: relatórios: dotenv: build.env

Comparação com outras ferramentas

Ferramentas semelhantes incluem:

• Kit de construção

• imagem

• construção de orca

• umoci

• construir

• FTL

• Regras do Bazel_docker

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.

Comunidade

Grupo do Google de usuários kaniko

Para contribuir com kaniko, consulte DEVELOPMENT.md e CONTRIBUTING.md.

Limitações

mtime e instantâneo

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:

• Com o modo instantâneo somente de tempo ( --snapshot-mode=time ), kaniko pode perder completamente as alterações introduzidas pelos comandos RUN .

• Com o modo de instantâneo padrão ( --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.

Comandos Dockerfile --chown suporte

Kaniko atualmente suporta os comandos COPY --chown e ADD --chown Dockerfile. Não suporta RUN --chown .

Referências

• Kaniko - Construindo imagens de contêiner no Kubernetes sem Docker.