Escolha uma estratégia compatível com a OCI

Esta página oferece uma vista geral do processo de compilação do Cloud Foundry a partir do qual tem de fazer a migração e fornece uma descrição das várias formas de migrar desse processo para um processo que cria contentores compatíveis com a OCI.

Vista geral do processo de compilação do Cloud Foundry

Quando uma aplicação é enviada para o Cloud Foundry, passa por uma fase de compilação em que o código-fonte é compilado pelos buildpacks do Cloud Foundry v2.

O resultado de um processo de compilação do Cloud Foundry cria um arquivo executável conhecido como droplet. Os Droplets não são diretamente compatíveis com a especificação da Open Container Initiative (OCI) para executar contentores no Cloud Run.

Quando migra aplicações do Cloud Foundry para o Cloud Run, tem de alterar o processo de compilação da aplicação para gerar imagens OCI padrão da indústria (por vezes, denominadas imagens Docker).

Diagrama que descreve como são criados os Droplets do Cloud Foundry

Estratégias para alcançar imagens compatíveis com a OCI

Existem três estratégias de migração que pode escolher para criar contentores compatíveis com a OCI:

Modificar uma aplicação do Cloud Foundry (lift and shift)

Os componentes principais do ecossistema Cloud Foundry (Buildpacks v2, Stemcells, etc.) são de código aberto. Isto significa que pode recriar o processo de contentorização da aplicação seguindo o nosso guia para "Dockerizar" os componentes de compilação principais para criar uma nova imagem compatível com a OCI.

Prós:

  • Requer a menor quantidade de refatoração e personalização da aplicação.
  • O processo é repetível para todas as instâncias da aplicação.

Desvantagens:

  • O pipeline para criar contentores de aplicações é autogerido.
  • Os componentes mais antigos do Cloud Foundry têm manutenção e apoio técnico reduzidos.
  • Existem custos de manutenção de segurança contínuos, incluindo:
    • Reconstruir rotineiramente os componentes de compilação para garantir que recebe patches de segurança.
    • Reconstruir rotineiramente as aplicações "dockerizadas" para aplicar as atualizações de segurança dos componentes de compilação reconstruídos.

Usar Cloud Native Buildpacks

A especificação Cloud Native Buildpacks (CNB) foi criada para modernizar e unificar o ecossistema de buildpacks. Os criadores compatíveis com a especificação CNB seguem normas abertas e criam imagens em conformidade com a OCI. Três fornecedores de CNB comuns são:

Prós:

  • Os responsáveis pela manutenção dos buildpacks e os fornecedores de plataformas são responsáveis pela manutenção dos buildpacks.
  • Os buildpacks suportam a rebase de contentores em novas imagens para atualizações de segurança rápidas sem reconstruir contentores de aplicações.
  • Os buildpacks geram imagens OCI portáteis.
  • O projeto CNB está em incubação na Cloud Native Computing Foundation (CNCF) e tem uma comunidade ativa de responsáveis pela manutenção e colaboradores.

Desvantagens:

  • Lacunas de funcionalidade e configuração entre os buildpacks v2 e v3.
  • As frameworks e as integrações instaladas em seu nome nos buildpacks Java v2 podem não estar disponíveis no buildpack CNB Java.

Usar ficheiros Dockerfile autogeridos

Pode criar Dockerfiles totalmente novos para colocar a sua aplicação em contentores. Consulte o artigo sobre a criação de contentores para saber mais sobre as imagens de contentores aceites pelo Cloud Run.

Prós:

  • Oferece-lhe a maior flexibilidade na conceção das suas aplicações.
  • Tire partido das ferramentas de contentores e das estratégias de criação existentes da sua empresa.

Desvantagens:

  • A dockerização e a configuração personalizada têm de ser realizadas para cada aplicação, o que pode levar a depurações e reescritas demoradas.
  • É difícil padronizar as implementações em várias equipas.
  • A aplicação de patches a imagens requer uma recriação e uma reimplementação completas.

Recomendações

As equipas com restrições de recursos e que pretendem mover o maior número possível de aplicações devem considerar primeiro a estratégia de Lift and Shift para modificar o Cloud Foundry. Quando as aplicações forem modernizadas para serem imagens compatíveis com a OCI, recomendamos que considere usar os Cloud Native Buildpacks ou os Dockerfiles autogeridos.

As equipas que estão prontas para migrar imediatamente devem experimentar os Cloud Native Buildpacks e, em seguida, mudar para Dockerfiles autogeridos se precisarem de um elevado nível de controlo sobre o respetivo ambiente.

O que se segue