Acerca de los contenedores del sistema Linux

La CLI de Migrate to Containers te permite migrar aplicaciones basadas en Linux a entornos contenerizados. Usa un contenedor de sistema Linux precompilado que funciona como un gestor de arranque para los servicios que requiere la aplicación modernizada. Con Migrate to Containers para aplicaciones Linux, puedes modernizar una amplia gama de aplicaciones sin estado para que se ejecuten en Google Kubernetes Engine (GKE), Cloud Run y clústeres de GKE.

Para obtener más información, consulta el artículo Arquitectura de la CLI de Migrate to Containers.

En este documento se proporcionan detalles sobre los contenedores del sistema Linux de Migrate to Containers, que se usan como parte de la solución para ejecutar aplicaciones migradas con Migrate to Containers.

Migración mediante un contenedor de sistema Linux

Migrate to Containers descubre los archivos y procesos de la aplicación de origen. A continuación, genera artefactos, como un Dockerfile, un manifiesto de Kubernetes y una configuración de Skaffold.

La función principal de un contenedor del sistema Linux es iniciar los servicios que se ejecutaban originalmente en la instancia de máquina virtual de origen, incluidos los servicios de aplicaciones y del sistema operativo pertinentes.

El archivo Dockerfile se usa para compilar la imagen de la VM migrada. Un Dockerfile de un contenedor de un sistema Linux suele ser similar al siguiente:

# Please refer to the documentation:
# https://cloud.google.com/migrate/anthos/docs/dockerfile-reference

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime

FROM scratch

# Tar containing data captured from the source VM
ADD vmFiles.tar.gz /

COPY --from=service-manager-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml

ADD logs.yaml /code/config/logs/logsArtifact.yaml

ADD services-config.yaml /.m4a/

ADD tempfiles.yaml  /.m4a/

# If you want to update parts of the image, add your commands here.
# For example:
# RUN apt-get update
# RUN apt-get install -y \
#       package1=version \
#       package2=version \
#       package3=version
# RUN yum update
# RUN wget http://github.com

ENTRYPOINT ["/ko-app/service-manager-runtime", "start", "-c", "/.m4a/"]

Cuando ejecutas una migración, las siguientes instrucciones de Dockerfile copian o añaden los datos de la máquina virtual desde la fuente original a la imagen de Docker:

• La siguiente instrucción añade el archivo tar que contiene los datos capturados de la VM de origen a la imagen de Docker:

  ADD vmFiles.tar.gz /
  

  Migrate to Containers crea este archivo tar. Contiene el sistema de archivos raíz de la VM de origen con todo lo que se proporciona en los filtros del plan de migración y cualquier carpeta proporcionada en el plan de migración de datos que se haya filtrado.

• La siguiente instrucción importa el tiempo de ejecución de Migrate to Containers del repositorio de Docker a la imagen de Docker:

  FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/service-manager-runtime:1.0.0 as service-manager-runtime
  

• La siguiente instrucción copia el tiempo de ejecución de Migrate to Containers en la imagen de Docker:

  COPY --from=service-manager-runtime / /
  

Haz clic para ver los detalles del archivo de tiempo de ejecución de Migrate to Containers

/ko-app/service-manager-runtime es el archivo de tiempo de ejecución principal de Migrate to Containers. Se trata de un sistema de inicialización creado para contenedores. Hace lo siguiente:

• Lee el archivo /.m4a/services-config.yaml y ejecuta los archivos binarios especificados en orden según el método de ejecución especificado, como daemonize, not daemonize o wait for finish.
• Recoge los registros especificados en el archivo /code/config/logs/logsArtifact.yaml y los imprime en stdout del contenedor. En el caso de los clústeres de GKE, también se asegura de que los registros se envíen a Cloud Logging.

Mantenimiento de cargas de trabajo migradas

Puedes crear una nueva canalización para tu aplicación a partir de los artefactos migrados. Puede que tengas una canalización diferente para cada aplicación. Puedes mantener tu flujo de integración y despliegue continuos, que generó la aplicación original basada en máquinas virtuales, y añadir los pasos pertinentes que transformen los ejecutables generados en contenedores del sistema Linux.

En el siguiente diagrama se muestra un ejemplo de flujo de trabajo con Migrate to Containers:

En este diagrama se muestra el proceso de cambio de una aplicación.

Se envía un cambio en el código fuente o una nueva ruta del SO al repositorio de Git. El origen se compila en función de la configuración actual y se crea una nueva imagen. La nueva imagen incluye la capa de tiempo de ejecución de Migrate to Containers.

En el entorno de prueba, un desarrollador realiza pruebas preliminares para confirmar si la nueva imagen funciona correctamente. Después de la fase de pruebas, se crea una nueva imagen de contenedor del sistema y se envía al entorno de desarrollo o de pruebas, que se implementa posteriormente en producción.