Compare os Buildpacks V2 e V3

Um buildpack converte o código fonte num executável e é usado para oferecer uma forma simples, fiável e repetível de criar contentores. O Kf suporta os buildpacks V2 e V3, e é importante compreender as diferenças entre eles.

V2 buildpacks

A maioria das aplicações do Cloud Foundry já usa buildpacks V2. Quando usa buildpacks V2 com o Kf, os binários do ciclo de vida e os buildpacks são transferidos e configurados a partir dos respetivos URLs git. Em seguida, o Kf usa a CLI lifecycle para executar cada buildpack no código fonte.

Vantagens

  • Pronto a usar sem alterações de pipeline nem de código.

Desvantagens

  • O buildpack antigo foi substituído pela V3.
  • Desempenho e fiabilidade mais fracos. O pipeline de compilação do Kf requer mais E/S para os buildpacks V2.
  • Menos recursos da comunidade.
  • O Kf só suporta repositórios git de software de código aberto.

Buildpacks V3

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

Os buildpacks da V3 têm dois contentores OCI abrangentes:

  • Imagem do criador
  • Executar imagem

Imagem do criador

A imagem do criador é usada enquanto o código-fonte está a ser criado num contentor executável. A imagem tem os scripts detect necessários e outras utilidades para compilar o código-fonte.

Executar imagem

A imagem de execução é a imagem base sobre a qual um contentor é criado. Isto significa que é a imagem base que é executada quando a app é executada.

Camadas

Os buildpacks da V3 usam camadas para compor o contentor final. Cada buildpack incluído numa compilação tem a oportunidade de manipular o sistema de ficheiros e as variáveis de ambiente da app. Esta abordagem em camadas permite que os buildpacks sejam mais simples e genéricos.

Os buildpacks V3 são criados em contentores OCI. Isto requer que a imagem do criador da V3 seja armazenada num registo de contentores ao qual o pipeline de compilação do Kf tenha acesso. O pipeline de compilação usa a imagem do compilador para aplicar os scripts subjacentes de modo a compilar o código-fonte num contentor executável.

Vantagens

Desvantagens

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

Kf Stacks

Ver pilhas

Quando envia uma app, o pipeline de compilação determina o buildpack com base na pilha selecionada (especificada através da flag --stack ou do manifesto).

Para ver que conjuntos estão disponíveis num espaço, certifique-se primeiro de que um espaço é segmentado:

kf target -s myspace

Em seguida, pode usar o subcomando kf stacks para listar as associações:

kf stacks

O resultado 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

Configure pilhas

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

kubectl edit kfsystem kfsystem

Este exemplo define os Google Cloud buildpacks 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

Agora, é possível enviar este novo conjunto:

kf push myapp --stack google

Este exemplo configura o buildpack Ruby V2 e define as predefinições do pipeline de compilação para usar stacks 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 pacote de compilação da V2 para a V3

O Kf fornece uma pilha V3 para criar aplicações que foram criadas com pacotes de compilação V2 padrão, usando uma pilha denominada kf-v2-to-v3-shim. A pilha kf-v2-to-v3-shim é criada de acordo com a API de pacotes de compilação V3 padrão. É criada uma imagem do criador mantida pela Google com cada lançamento do Kf, seguindo o processo de buildpack padrão. A imagem do criador 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. É importante ter em atenção que os buildpacks V3 não contêm o ficheiro binário dos buildpacks V2 referenciados. Em alternativa, são referenciadas as imagens do buildpack V2 e os bits são transferidos no momento da criação da app (através da execução de kf push).

No momento da compilação da app, o pacote de compilação V2 é transferido do repositório git correspondente. Quando a deteção V3 é executada, delega no script de deteção V2 transferido. Para o primeiro grupo de buildpacks que passa na deteção, o processo avança para o passo de compilação, que delega a execução da compilação no script do criador V2 transferido.

Os seguintes buildpacks da V2 são suportados na pilha kf-v2-to-v3-shim:

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: migre apps criadas com buildpacks padrão da V2

Para criar apps 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 deteta automaticamente o tempo de execução com os buildpacks V2 envolvidos. A imagem da app resultante é criada com a norma V3 e o pipeline de compilação, mas o criador do buildpack V2 equivalente.

Opção 2: migre apps criadas com buildpacks V2 personalizados

O Kf tem uma ferramenta de migração de buildpacks que pode usar um buildpack V2 e envolvê-lo com um buildpack V3. Em seguida, o buildpack envolvido 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

Esta ação cria uma imagem do pacote de compilação com o nome gcr.io/your-project/v2-go-buildpack. Em seguida, pode ser usado para criar um criador seguindo a documentação criar um criador.

Este subcomando usa as seguintes CLIs de forma transparente:

  • go
  • git
  • pack
  • unzip

Recomendamos que use o editor do Cloud Shell para garantir que cada subcomando está disponível no caminho correto e é a versão correta.

Problemas conhecidos

Seguem-se as funcionalidades que ainda não funcionam com o Kf. Se uma delas for de alta prioridade para a sua organização, contacte o seu representante de vendas:

  • Registos de contentores privados para imagens de criação V3.
  • Colocação em cache da V3.
  • Buildpacks V2 que requerem credenciais do Git.