Comparação dos pacotes de criação V2 x V3

Um buildpack converte o código-fonte em um executável e é usado para oferecer uma maneira simples, confiável e repetível de criar contêineres. O Kf é compatível com os pacotes de criação V2 e V3, e é importante entender as diferenças entre eles.

Buildpacks V2

A maioria dos aplicativos do Cloud Foundry já usa pacotes de criação V2. Ao usar pacotes de versão V2 com Kf, os binários do ciclo de vida e os pacotes de versão são transferidos por download e configurados nos URLs do Git. Em seguida, o Kf usa a CLI lifecycle para executar cada buildpack no código-fonte.

Prós

  • Pronto para mudanças de pipeline ou código.

Contras

  • Buildpack legado substituído pela V3.
  • Desempenho e confiabilidade mais fracos. O pipeline de criação do Kf requer mais E/S para os pacotes de criação V2.
  • Menos recursos da comunidade.
  • O Kf é compatível apenas com repositórios git OSS.

Buildpacks V3

Os buildpacks da V3 são um projeto da Cloud Native Computing Foundation (CNCF) com uma especificação bem definida, uma CLI (pacote) e uma comunidade em crescimento que está inovando em diferentes linguagens e frameworks. Google Cloud também tem o próprio conjunto de buildpacks do Google Cloud.

Os pacotes de criação V3 têm dois contêineres OCI gerais:

  • Imagem do builder
  • Executar imagem

Imagem do builder

A imagem do builder é usada enquanto seu código-fonte está sendo integrado a um contêiner executável. A imagem tem os scripts detect necessários e outros utilitários para compilar o código-fonte.

Executar imagem

A imagem de execução é a imagem base em que um contêiner foi criado. Isso significa que é a imagem base que será executada quando o app for executado.

Camadas

Os pacotes de criação da V3 usam camadas para compor o contêiner final. Cada buildpack incluído em um build tem a oportunidade de manipular as variáveis do sistema de arquivos e do ambiente do App. Essa abordagem de camadas permite que os pacotes de compilação sejam mais finos e genéricos.

Os buildpacks da V3 são criados em contêineres OCI. Isso exige que a imagem do builder da V3 seja armazenada em um registro de contêiner ao qual o pipeline de compilação do Kf tenha acesso. O pipeline de compilação usa a imagem do builder para aplicar os scripts subjacentes para criar o código-fonte em um contêiner executável.

Prós

Contras

  • Pode exigir atualizações de código/processo. Por exemplo, o buildpack Java requer código-fonte, enquanto o buildpack V2 requer um arquivo jar.
  • Os pacotes de versão V3 são mais recentes e podem exigir validação adicional, já que o pacote está sendo desenvolvido pela comunidade.

Pilhas do Kf

Ver pilhas

Ao enviar um app, o pipeline de compilação determina o buildpack com base na pilha selecionada (especificada pela sinalização --stack ou pelo manifesto).

Para ver quais pilhas estão disponíveis em um espaço primeiro, verifique se o espaço está segmentado:

kf target -s myspace

O subcomando kf stacks pode ser usado para listar as pilhas:

kf stacks

A saída mostra as pilhas V2 e V3:

Getting stacks in Space: myspace
Version  Name                                Build Image                                                                                          Run Image                                                                                          Description
V2       cflinuxfs3                          cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5      cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V3       org.cloudfoundry.stacks.cflinuxfs3  cloudfoundry/cnb:cflinuxfs3@sha256:f96b6e3528185368dd6af1d9657527437cefdaa5fa135338462f68f9c9db3022  cloudfoundry/run:full-cnb@sha256:dbe17be507b1cc6ffae1e9edf02806fe0e28ffbbb89a6c7ef41f37b69156c3c2  A large Cloud Foundry stack based on Ubuntu 18.04

Configurar pilhas

A configuração da pilha pode ser atualizada editando o recurso personalizado kfsystem:

kubectl edit kfsystem kfsystem

Este exemplo define os buildpacks Google Cloud como uma pilha V3:

spec:
  kf:
    config:
      spaceStacksV3:
      - name: google
        description: Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
        buildImage: gcr.io/buildpacks/builder:v1
        runImage: gcr.io/buildpacks/gcp/run:v1

Esta nova pilha agora pode ser enviada:

kf push myapp --stack google

Este exemplo configura o buildpack Ruby V2 e define os padrões do pipeline de compilação para usar pilhas V2:

spec:
  kf:
    config:
      spaceDefaultToV3Stack: false
      spaceBuildpacksV2:
      - name: ruby_buildpack
        url: https://github.com/cloudfoundry/ruby-buildpack
      spaceStacksV2:
      - name: cflinuxfs3
        image: cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5

Migração

Observação: no momento, esse recurso está em fase experimental e sujeito a alterações.

O Kf tem uma ferramenta de migração que pode unir um pacote de build V2. O resultado é um buildpack V3 que pode ser usado em um builder V3. O buildpack encapsulado pode ser usado em qualquer lugar onde os buildpacks V3 estejam disponíveis.

kf wrap-v2-buildpack gcr.io/your-project/v2-go-buildpack https://github.com/cloudfoundry/go-buildpack --publish

Isso criará uma imagem de buildpack chamada gcr.io/your-project/v2-go-buildpack. Ele pode ser usado para criar um builder seguindo os documentos disponíveis em create a builder.

Esse subcomando usa as seguintes CLIs de forma transparente:

  • go
  • git
  • pack

Recomendamos que você use o Editor do Cloud Shell para garantir que cada subcomando esteja disponível no caminho e na versão corretos.

Problemas conhecidos

A seguir estão recursos que ainda não funcionam com o Kf. Se uma delas for de alta prioridade, entre em contato com seu representante de vendas:

  • Registros de contêiner particular para imagens do criador da V3.
  • Armazenamento em cache da V3.
  • Buildpacks V2 que exigem credenciais Git.