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 pacotes de criação 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. O 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
- O Google permite criar e executar a imagem.
- Funciona com vários produtos do Google Cloud, como o Cloud Build.
- Comunidade de crescimento e registro de buildpack.
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 myspaceO subcomando kf stacks pode ser usado para listar as pilhas:
kf stacksA 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
A configuração da pilha pode ser atualizada editando o recurso personalizado kfsystem:
kubectl edit kfsystem kfsystemEste 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 agora pode ser enviada:
kf push myapp --stack googleEste 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 do Buildpack V2 para V3
O Kf fornece uma pilha V3 para criar aplicativos criados com pacotes de criação V2 padrão, usando uma pilha chamada kf-v2-to-v3-shim. A pilha kf-v2-to-v3-shim é criada seguindo a API buildpacks padrão V3. Uma imagem do builder mantida pelo Google é criada em cada versão do Kf de acordo com o processo do 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 usando as imagens buildpack padrão V2. É importante observar que os buildpacks do 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 transferidos por download no momento da compilação do aplicativo (executando kf push).
No momento da criação, o buildpack V2 é transferido por download pelo repositório Git correspondente. Quando a detecção da V3 é executada, ela delega ao script de detecção V2 transferido por download. Após o primeiro grupo de buildpack que passar na detecção, ele prossegue para a etapa de build, que delega a execução do build ao script de builder V2 transferido por download.
Os seguintes buildpacks 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: migrar apps criados com buildpacks padrão V2
Para criar aplicativos com a pilha kf-v2-to-v3-shim, use o seguinte comando:
kf push myapp --stack kf-v2-to-v3-shimA pilha kf-v2-to-v3-shim detectará automaticamente o ambiente de execução com os buildpacks V2 encapsulados. A imagem de aplicativo resultante é criada usando o pipeline padrão e da versão V3, 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 de buildpack que pode pegar um buildpack V2 e uni-lo a um buildpack 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 --publishIsso 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:
gogitpackunzip
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.