Os buildpacks são usados pelo Kf para transformar o código-fonte de um aplicativo em uma imagem executável. O Cloud Native Buildpacks usa a versão mais recente da API Buildpack v3, e empresas como VMware e Heroku estão adicionando a disponibilidade da v3 aos buildpacks atuais.
O Kf aceita buildpacks aceitos pela V2 e pela V3 da especificação da API Buildpack.
Comparação entre buildpacks da V2 e da V3
| Buildpacks da V2 | Buildpacks da V3 | |
|---|---|---|
| Nomes alternativos | Buildpacks do Cloud Foundry | Cloud Native Buildpacks (CNB), imagens de builder |
| Status | Sendo substituído | Atual |
| Propriedade | Cloud Foundry | Buildpacks.io |
| Pilha | Compartilhado pelo builder e pelo ambiente de execução | Pode ser diferente para builder e ambiente de execução |
| Desenvolvimento local | Não é possível | Sim, com a CLI de pack |
| Buildpacks personalizados | Disponível no ambiente de execução | Precisa ser incorporado ao builder |
Ciclo de vida do buildpack
| Etapa | Cloud Foundry | Kf com buildpacks da V2 | Kf com buildpacks da V3 |
|---|---|---|---|
| Local de origem | Serviço de BITS | Container Registry | Container Registry |
| Local do buildpack | BOSH/HTTP | HTTP | Container Registry |
| Local da pilha | BOSH | Container Registry | Container Registry |
| Resultado | Droplet (binário de app sem pilha) | Imagem (Droplet em uma pilha) | Imagem |
| Ambiente de execução | Droplet montado sobre a pilha e executado | Executar a imagem produzida | Executar a imagem produzida |
O Kf sempre produz uma imagem completa e executável como resultado do processo de build. O Cloud Foundry, por outro lado, produz partes de uma imagem executável no tempo de build, e o restante é adicionado no ambiente de execução.
O Kf optou por seguir o modelo de sempre produzir uma imagem completa pelos seguintes motivos:
- As imagens podem ser exportadas, executadas no local e inspecionadas estaticamente
- Mais segurança e auditoria com ferramentas como a autorização binária
- As implantações de apps são reproduzíveis.
Kf e buildpacks
O Kf armazena a lista global de buildpacks e pilhas no ConfigMap config-defaults no namespace kf.
Cada espaço reflete esses buildpacks no campo de status.
No caso de um espaço buildpack-docs, é possível executar o seguinte para conferir a configuração completa relacionada:
$ kf space buildpack-docs
Getting Space buildpack-docs
API Version: kf.dev/v1alpha1
Kind: Space
Metadata:
Creation Timestamp: 2020-02-14T15:09:52Z
Name: buildpack-docs
Self Link: /apis/kf.dev/v1alpha1/spaces/buildpack-docs
UID: 0cf1e196-4f3c-11ea-91a4-42010a80008d
Status:
Build Config:
Buildpacks V2:
- Name: staticfile_buildpack
URL: https://github.com/cloudfoundry/staticfile-buildpack
Disabled: false
- Name: java_buildpack
URL: https://github.com/cloudfoundry/java-buildpack
Disabled: false
Stacks V2:
- Image: cloudfoundry/cflinuxfs3
Name: cflinuxfs3
Stacks V3:
- Build Image: cloudfoundry/cnb:cflinuxfs3
Description: A large Cloud Foundry stack based on Ubuntu 18.04
Name: org.cloudfoundry.stacks.cflinuxfs3
Run Image: cloudfoundry/run:full-cnb
Na seção Build Config, há três campos a serem observados:
- Os buildpacks V2 contêm uma lista de buildpacks compatíveis com a V2 na ordem em que serão executados
- Pilhas V2 indicam as que podem ser escolhidas para acionar um build do buildpack V2
- Pilhas V3 indica as que podem ser escolhidas para acionar um build do buildpack V3
Também é possível listar as pilhas usando kf stacks:
$ kf stacks
Getting stacks in Space: buildpack-docs
Version Name Build Image Run Image Description
V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3
V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04
Como as imagens de build da V3 já têm buildpacks integrados, use kf buildpacks para conferir a lista:
$ kf buildpacks
Getting buildpacks in Space: buildpack-docs
Buildpacks for V2 stacks:
Name Position URL
staticfile_buildpack 0 https://github.com/cloudfoundry/staticfile-buildpack
java_buildpack 1 https://github.com/cloudfoundry/java-buildpack
V3 Stack: org.cloudfoundry.stacks.cflinuxfs3:
Name Position Version Latest
org.cloudfoundry.jdbc 0 v1.0.179 true
org.cloudfoundry.jmx 1 v1.0.180 true
org.cloudfoundry.go 2 v0.0.2 true
org.cloudfoundry.tomcat 3 v1.1.102 true
org.cloudfoundry.distzip 4 v1.0.171 true
org.cloudfoundry.springboot 5 v1.1.2 true
...
Como personalizar buildpacks da V3
Você pode personalizar os buildpacks disponíveis para os desenvolvedores criando sua própria imagem de builder exatamente com os buildpacks a que eles têm acesso. Você também pode usar imagens de builder publicadas por outros autores.
Usar uma imagem de builder de terceiros
Uma lista de pilhas de CNB publicadas está disponível na CLI do buildpack pack. No momento em que este artigo foi escrito, a saída de pack suggest-stacks era assim:
$ pack suggest-stacks
Stacks maintained by the community:
Stack ID: heroku-18
Description: The official Heroku stack based on Ubuntu 18.04
Maintainer: Heroku
Build Image: heroku/pack:18-build
Run Image: heroku/pack:18
Stack ID: io.buildpacks.stacks.bionic
Description: A minimal Cloud Foundry stack based on Ubuntu 18.04
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:base-cnb
Run Image: cloudfoundry/run:base-cnb
Stack ID: org.cloudfoundry.stacks.cflinuxfs3
Description: A large Cloud Foundry stack based on Ubuntu 18.04
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:full-cnb
Run Image: cloudfoundry/run:full-cnb
Stack ID: org.cloudfoundry.stacks.tiny
Description: A tiny Cloud Foundry stack based on Ubuntu 18.04, similar to distroless
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:tiny-cnb
Run Image: cloudfoundry/run:tiny-cnb
Para modificar o Kf para usar a pilha publicada pelo Heroku, edite o ConfigMap config-defaults no namespace kf.
Adicione uma entrada à chave spaceStacksV3 como esta:
$ kubectl edit configmap config-defaults -n kf
spaceStacksV3: |
- name: org.cloudfoundry.stacks.cflinuxfs3
description: A large Cloud Foundry stack based on Ubuntu 18.04
buildImage: cloudfoundry/cnb:cflinuxfs3
runImage: cloudfoundry/run:full-cnb
- name: heroku-18
description: The official Heroku stack based on Ubuntu 18.04
buildImage: heroku/pack:18-build
runImage: heroku/pack:18
Em seguida, execute stacks novamente:
$ kf stacks
Getting stacks in Space: buildpack-docs
Version Name Build Image Run Image Description
V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3
V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04
V3 heroku-18 heroku/pack:18-build heroku/pack:18 The official Heroku stack based on Ubuntu 18.04
Criar sua própria imagem de builder
A CLI do buildpack pack é usada para criar sua própria imagem de builder. Siga a documentação Como trabalhar com builders usando create-builder de pack para criar sua própria imagem de builder. Uma vez criada, envie-a para um registro de contêiner e adicione-a ao ConfigMap config-defaults.
Como configurar uma pilha padrão
Os apps vão receber uma pilha padrão, se não houver uma no manifesto. A pilha padrão é a primeira na lista de pilhas da V2 ou da V3. A menos que seja substituída, uma pilha da V2 é escolhida devido à compatibilidade com o Cloud Foundry.
Você pode forçar o Kf a usar uma pilha da V3 em vez de uma da V2 definindo o
campo spaceDefaultToV3Stack no ConfigMap config-defaults
do namespace kf como "true":
$ kubectl edit configmap config-defaults -n kf
spaceDefaultToV3Stack: "true"
Essa opção também pode ser modificada por espaço, alterando a configuração do
campo spec.buildConfig.defaultToV3Stack para true ou false. Se essa configuração não estiver definida,
o valor do ConfigMap config-defaults será usado.
Valor de config-defaults para spaceDefaultToV3Stack |
spec.buildConfig.defaultToV3Stack do espaço |
Pilha padrão |
|---|---|---|
| não definido | não definido | V2 |
"false" |
não definido | V2 |
"true" |
não definido | V3 |
| qualquer um | false |
V2 |
| qualquer um | true |
V3 |