Escolha uma estratégia em conformidade com a OCI

Nesta página, apresentamos uma visão geral do processo de compilação do Cloud Foundry que você precisa migrar e uma descrição das várias maneiras de migrar para um processo que cria contêineres compatíveis com OCI.

Visão geral do processo de build do Cloud Foundry

Quando um aplicativo é enviado para o Cloud Foundry, ele passa por um estágio de criação em que o código-fonte é compilado pelos buildpacks do Cloud Foundry v2.

A saída de um processo de compilação do Cloud Foundry cria um arquivo executável conhecido como droplet. Os gotículas não são diretamente compatíveis com a especificação Open Container Initiative (OCI) para executar contêineres no Cloud Run.

Ao migrar aplicativos do Cloud Foundry para o Cloud Run, você precisa alterar o processo de criação do aplicativo para gerar imagens OCI padrão do setor (às vezes chamadas de imagens do Docker).

Diagrama que descreve como as gotículas do Cloud Foundry são criadas

Estratégias para conseguir imagens em conformidade com OCI

Há três estratégias de migração que você pode escolher para criar contêineres compatíveis com OCI:

Como modificar um aplicativo do Cloud Foundry (migração lift-and-shift)

Os principais componentes do ecossistema do Cloud Foundry (Buildpacks v2, Stemcells etc.) são de código aberto. Isso significa que é possível recriar o processo de conteinerização do aplicativo seguindo nosso guia para "Dockerize" os principais componentes de compilação para criar uma nova imagem compatível com OCI.

Vantagens:

  • Ela exige o mínimo de refatoração e personalização de aplicativos.
  • O processo pode ser repetido em todas as instâncias do aplicativo.

Desvantagens:

  • O pipeline para criar contêineres de aplicativos é autogerenciado.
  • Componentes mais antigos do Cloud Foundry diminuíram a manutenção e o suporte.
  • Há custos contínuos de manutenção de segurança, incluindo:
    • Recriar rotineiramente os componentes do build para garantir que você receba patches de segurança.
    • Recriar rotineiramente os aplicativos "dockerized" para assumir as atualizações de segurança dos componentes de compilação recriados.

Como usar Buildpacks nativos do Cloud

A especificação Cloud Native Buildpacks (CNB) foi criada para modernizar e unificar o ecossistema de pacotes de build. Os criadores compatíveis com a especificação CNB seguem padrões abertos e criam imagens compatíveis com OCI. Três provedores CNB comuns são:

Vantagens:

  • Os mantenedores do buildpack e os provedores de plataforma são responsáveis pela manutenção do buildpack.
  • Os Buildpacks são compatíveis com a rebase dos contêineres em novas imagens para atualizações de segurança rápidas sem recriar os contêineres de aplicativos.
  • Os Buildpacks geram imagens OCI portáteis.
  • O projeto CNB está em desenvolvimento na Cloud Native Computing Foundation (CNCF) e tem uma comunidade ativa de mantenedores e colaboradores.

Desvantagens:

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

Como usar Dockerfiles autogerenciados

É possível criar Dockerfiles completamente novos para conteinerizar seu aplicativo. Consulte Como criar contêineres para saber mais sobre as imagens de contêiner aceitas pelo Cloud Run.

Vantagens:

  • Oferece mais flexibilidade no design dos seus aplicativos.
  • Aproveite as ferramentas de contêiner e as estratégias de criação da sua empresa.

Desvantagens:

  • A Dockerização e a configuração personalizada precisam ser realizadas para cada aplicativo, o que pode levar a depuração e regravações possivelmente demoradas.
  • Difícil de padronizar implementações em várias equipes.
  • A aplicação de patches de imagens requer a recompilação e a reimplantação completas.

recomendações

As equipes com recursos limitados e que pretendem mover o maior número possível de aplicativos precisam considerar primeiro a estratégia de migração lift-and-shift para modificar o Cloud Foundry. Depois que os aplicativos forem modernizados para se tornarem imagens compatíveis com OCI, recomendamos que você use Buildpacks nativos da nuvem ou Dockerfiles autogerenciados.

As equipes que estão prontas para migrar imediatamente precisam testar os Buildpacks nativos da nuvem e depois mudar para Dockerfiles autogerenciados se precisarem de um alto nível de controle sobre o ambiente.

Próximas etapas