Elegir una estrategia compatible con OCI

En esta página se ofrece una descripción general del proceso de compilación de Cloud Foundry del que debes migrar y se describen las distintas formas de migrar a un proceso que compile contenedores compatibles con OCI.

Descripción general del proceso de compilación de Cloud Foundry

Cuando se envía una aplicación a Cloud Foundry, pasa por una fase de compilación en la que el código fuente se compila mediante los paquetes de compilación de Cloud Foundry v2.

El resultado de un proceso de compilación de Cloud Foundry crea un archivo ejecutable conocido como droplet. Los droplets no son directamente compatibles con la especificación de la iniciativa de contenedores abiertos (OCI) para ejecutar contenedores en Cloud Run.

Cuando migres aplicaciones de Cloud Foundry a Cloud Run, debes cambiar el proceso de compilación de la aplicación para generar imágenes OCI estándar del sector (a veces denominadas imágenes Docker).

Diagrama que describe cómo se crean los droplets de Cloud Foundry

Estrategias para conseguir imágenes compatibles con OCI

Puedes elegir entre tres estrategias de migración para crear contenedores compatibles con OCI:

Modificar una aplicación de Cloud Foundry (lift and shift)

Los componentes principales del ecosistema de Cloud Foundry (compilaciones v2, Stemcells, etc.) son de código abierto. Esto significa que puedes volver a crear el proceso de contenerización de la aplicación siguiendo nuestra guía para "dockerizar" los componentes principales de la compilación y crear una nueva imagen compatible con OCI.

Ventajas:

  • Requiere la menor cantidad de refactorización y personalización de aplicaciones.
  • El proceso se puede repetir en todas las instancias de la aplicación.

Inconvenientes:

  • La canalización para crear contenedores de aplicaciones se gestiona automáticamente.
  • El mantenimiento y la asistencia de los componentes antiguos de Cloud Foundry han disminuido.
  • Hay costes de mantenimiento de seguridad continuos, entre los que se incluyen los siguientes:
    • Recompilamos periódicamente los componentes de compilación para asegurarnos de que recibes parches de seguridad.
    • Recompilar periódicamente las aplicaciones "dockerizadas" para incorporar las actualizaciones de seguridad de los componentes de compilación recompilados.

Usar Cloud Native Buildpacks

La especificación Cloud Native Buildpacks (CNB) se creó para modernizar y unificar el ecosistema de buildpacks. Los compiladores compatibles con la especificación de CNB siguen estándares abiertos y crean imágenes compatibles con OCI. Tres proveedores habituales de CNB son:

Ventajas:

  • Los mantenedores de buildpacks y los proveedores de plataformas son responsables del mantenimiento de los buildpacks.
  • Los buildpacks admiten la rebase de contenedores en imágenes nuevas para que las actualizaciones de seguridad sean rápidas sin tener que volver a crear los contenedores de las aplicaciones.
  • Los paquetes de compilación generan imágenes OCI portátiles.
  • El proyecto CNB se está incubando en la Cloud Native Computing Foundation (CNCF) y cuenta con una comunidad activa de mantenedores y colaboradores.

Inconvenientes:

  • Diferencias en la funcionalidad y la configuración entre los paquetes de compilación de la versión 2 y la versión 3.
  • Es posible que los frameworks y las integraciones instalados en tu nombre en los paquetes de compilación de Java v2 no estén disponibles en el paquete de compilación de Java CNB.

Usar Dockerfiles autogestionados

Puedes crear archivos Docker completamente nuevos para crear contenedores de tu aplicación. Consulta la sección sobre creación de contenedores para obtener información sobre las imágenes de contenedor aceptadas por Cloud Run.

Ventajas:

  • Te ofrece la mayor flexibilidad a la hora de diseñar tus aplicaciones.
  • Aprovecha las herramientas y las estrategias de compilación de contenedores de tu empresa.

Inconvenientes:

  • La dockerización y la configuración personalizada deben realizarse en cada aplicación, lo que puede llevar mucho tiempo de depuración y reescritura.
  • Es difícil estandarizar las implementaciones en varios equipos.
  • Para aplicar parches a las imágenes, es necesario volver a compilar y desplegar todo.

Recomendaciones

Los equipos que tienen recursos limitados y quieren migrar tantas aplicaciones como sea posible deberían considerar primero la estrategia Lift and Shift para modificar Cloud Foundry. Una vez que las aplicaciones se hayan modernizado para que sean imágenes compatibles con OCI, te recomendamos que uses Cloud Native Buildpacks o Dockerfiles autogestionados.

Los equipos que estén listos para migrar inmediatamente deberían probar Cloud Native Buildpacks y, a continuación, pasar a Dockerfiles autogestionados si necesitan un alto nivel de control sobre su entorno.

Siguientes pasos