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 buildpacks V2 e V3. É importante entender as diferenças entre eles.

Buildpacks V2

A maioria dos aplicativos do Cloud Foundry já usa buildpacks V2. Ao usar buildpacks V2 com o Kf, os binários do ciclo de vida e os buildpacks 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 alterações de pipeline ou código.

Contras

• Buildpack legado substituído pelo V3.
• Desempenho e confiabilidade mais fracos. O pipeline de build do Kf requer mais E/S para os buildpacks V2.
• Menos recursos da comunidade.
• O Kf é compatível apenas com repositórios de código aberto (OSS) do Git.

Buildpacks V3

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

Os buildpacks V3 têm dois contêineres OCI gerais:

• Imagem do builder
• Imagem de execução

Imagem do builder

A imagem do builder é usada enquanto o código-fonte é 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.

Observação: a maioria dos buildpacks não empacota os compiladores com a imagem do builder. Em vez disso, eles podem fazer com que os pipelines de build baixem todas as dependências necessárias para a compilação.

Imagem de execução

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

Camadas

Os buildpacks V3 usam camadas para compor o contêiner final. Cada buildpack incluído em um build pode manipular o sistema de arquivos e as variáveis do ambiente do aplicativo. Essa abordagem de camadas permite que os buildpacks sejam mais leves e genéricos.

Os buildpacks V3 são criados em contêineres OCI. Isso exige que a imagem do builder V3 seja armazenada em um Container Registry que o pipeline de build do Kf possa acessar. O pipeline de build usa a imagem do builder para aplicar os scripts e criar o código-fonte em um contêiner executável.

Prós

• Imagem do builder e de execução com suporte do Google.
• Funciona com vários produtos do Google Cloud , como o Cloud Build.
• Comunidade em crescimento e registro de buildpack.

Contras

• Pode exigir atualizações de código/processo. Por exemplo, o buildpack Java precisa de código-fonte, enquanto o buildpack V2 requer um arquivo jar.
• Os buildpacks V3 são mais recentes e podem exigir validação complementar (se usar buildpacks desenvolvidos pela comunidade).

Pilhas do Kf

Exibir pilhas

Ao enviar um aplicativo, o pipeline de build determina o buildpack com base na pilha selecionada (especificada pela flag --stack ou pelo manifesto).

Para conferir as pilhas disponíveis em um Space, verifique se ele está direcionado:

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
V2       cflinuxfs3                          cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5      cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V3       kf-v2-to-v3-shim                    gcr.io/kf-releases/v2-to-v3:v2.7.0                                                                   gcr.io/buildpacks/gcp/run:v1                                                                       This is a stack added by the integration tests to assert that v2->v3 shim works
V3       google                              gcr.io/buildpacks/builder:v1                                                                         gcr.io/buildpacks/gcp/run:v1                                                                       Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
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

Edite o recurso personalizado kfsystem para atualizar a configuração de pilhas:

kubectl edit kfsystem kfsystem

Este exemplo define os buildpacks do 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 pode ser enviada:

kf push myapp --stack google

Neste exemplo, o buildpack Ruby V2 é configurado e os padrões do pipeline de build são definidos 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 do buildpack V2 para V3

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

O Kf fornece uma pilha V3 para aplicativos criados com buildpacks V2 padrão, usando uma pilha chamada kf-v2-to-v3-shim. A pilha kf-v2-to-v3-shim é criada de acordo com a API de buildpacks V3 padrão. Uma imagem do builder mantida pelo Google é criada em cada versão do Kf, de acordo com o processo de buildpack padrão. A imagem do builder agrega uma lista de buildpacks V3 criados pelo mesmo processo usado com o comando kf wrap-v2-buildpack. As imagens do buildpack V3 são criadas com as imagens do buildpack V2 padrão. Os buildpacks V3 não contêm o binário dos buildpacks V2 referenciados. Em vez disso, as imagens do buildpack V2 são referenciadas, e os bits são baixados no tempo de build do aplicativo (ao executar kf push).

No tempo de build do aplicativo, o buildpack V2 é baixado do repositório Git correspondente. Quando a detecção da V3 é executada, ela delega ao script de detecção V2 baixado. Após o primeiro grupo de buildpack aprovado na detecção, ele prossegue para a etapa de build, que delega a execução ao script do builder V2 baixado.

A pilha kf-v2-to-v3-shim oferece suporte aos seguintes buildpacks V2:

Buildpack	Repositório Git
java_buildpack	https://github.com/cloudfoundry/java-buildpack
dotnet_core_buildpack	https://github.com/cloudfoundry/dotnet-core-buildpack
nodejs_buildpack	https://github.com/cloudfoundry/nodejs-buildpack
go_buildpack	https://github.com/cloudfoundry/go-buildpack
python_buildpack	https://github.com/cloudfoundry/python-buildpack
binary_buildpack	https://github.com/cloudfoundry/binary-buildpack
nginx_buildpack	https://github.com/cloudfoundry/nginx-buildpack

Opção 1: migrar aplicativos criados com buildpacks V2 padrão

Para criar aplicativos com a pilha kf-v2-to-v3-shim, use o seguinte comando:

kf push myapp --stack kf-v2-to-v3-shim

A pilha kf-v2-to-v3-shim detectará automaticamente o ambiente de execução com os buildpacks V2 vinculados. A imagem de aplicativo resultante é criada com o pipeline de build e o V3 padrão, exceto o builder do buildpack V2 equivalente.

Opção 2: migrar aplicativos criados com buildpacks V2 personalizados

O Kf tem uma ferramenta de migração que vincula um buildpack V2 a um buildpack V3. O buildpack vinculado pode ser usado em qualquer lugar em que 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 vai criar uma imagem de buildpack chamada gcr.io/your-project/v2-go-buildpack. Ela pode ser usada para criar um builder, de acordo com a documentação de criação de builders.

Esse subcomando usa as seguintes CLIs de forma transparente:

• go
• git
• pack
• unzip

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

Os recursos a seguir ainda não funcionam com o Kf. Se algum deles for prioridade para a organização, entre em contato com seu representante de vendas:

• Registros privados de contêineres para imagens do build V3.
• Armazenamento em cache da V3.
• Buildpacks V2 que exigem credenciais do Git.