New enhanced runtime

The original Linux service manager for Migrate to Containers relied on sysv init and systemd. The simplified Linux service manager replaces it with a simplified, container friendly alternative.

This simplified Linux service manager adds functionality that lets you deploy your migrated container workloads to:

• GKE Autopilot clusters

• Cloud Run

The simplified Linux service manager also resolves compatibility issues with Kubernetes plugins. For example the simplified Linux service manager removes the requirement of defining a hostpath for /sys/fs/cgroup in the deployment_spec.yaml file, the need to create privileged containers, and the configuration changes required when deploying containers to Anthos clusters on AWS that use workload identity.

Before you begin

• Migrate to Containers supplies a tool that you run on a VM workload to determine the workload's fit for migration to a container. For more information, see Using the fit assessment tool.

About GKE Autopilot clusters

Autopilot is a mode of operation in Google Kubernetes Engine (GKE) that is designed to reduce the operational cost of managing clusters, optimize your clusters for production, and yield higher workload availability. In Autopilot mode, GKE provisions and manages the cluster's underlying infrastructure, including nodes and node pools, giving you an optimized cluster with a hands-off experience.

Note: Autopilot is supported for GKE clusters but is not supported for Anthos clusters.

See Autopilot overview for more details.

About Cloud Run

Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable by web requests or Pub/Sub events. The simplified Linux service manager lets you deploy your migrated container workloads on Cloud Run.

Note: The container workload must be stateless to be deployed on Cloud Run. See Developing your service for more information, including the complete list of requirements for deploying containers on Cloud Run.

About Anthos clusters on AWS and workload identity

Workload identity for Anthos clusters on AWS lets you bind Kubernetes service accounts to AWS IAM accounts with specific permissions. Workload identity uses AWS IAM permissions to block unwanted access to cloud resources.

The current runtime lets you deploy your migrated workloads to Anthos clusters on AWS that use workload identity. However, you must perform additional steps to configure your deployment environment by setting the following environment variables for your specific init system:

• AWS_ROLE_ARN: The Amazon Resource Name (ARN) of the IAM role.
• AWS_WEB_IDENTITY_TOKEN_FILE: The path where the token is stored.

The simplified Linux service manager lets you deploy your containers without performing this additional configuration.

Using workload identity with Migrate to Containers and GKE

Migrate to Containers and GKE lets you deploy your migrated workloads to Anthos cluster on AWS. In some cases, you might use the same cluster as both the processing cluster and the deployment cluster. If you have enabled workload identity on your deployment cluster, then you have to ensure that you configure your deployment environment correctly to support Migrate to Containers and GKE.

Note: While Migrate to Containers and GKE supports processing clusters using 1.5.1 or later of Anthos cluster on AWS, and deployment clusters running 1.4 or later, to support workload identity you must use version 1.6 or later.

Additionally, you must ensure that any services started as part of the init process are configured correctly for workload identity. The steps you perform depend on the service manager for your cluster. See Deploying a Linux workload to a target cluster for the configuration steps.

Changes from the existing runtime

To use the simplified Linux service manager, you should be aware of the following changes and limitations from the existing runtime.

New services-config.yaml artifact file added

If you enable the simplified Linux service manager, Migrate to Containers creates a new artifact file, services-config.yaml, when you generate the migration artifacts. Use this file to control application initialization on a deployed container. See Using services-config.yaml for more information.

Note: The services-config.yaml is only created when you perform a new migration using Migrate to Containers version 1.13.1. It is not created when you convert an existing migration from a previous version to version 1.13.1.

Readiness probes

When using the current runtime, Migrate to Containers adds a readiness probe in the deployment_spec.yaml file. When you enable the simplified Linux service manager, no readiness probe is added.

If you want to add a readiness probe, we recommend that you use an HTTP readiness probe. See Define readiness probes for more information.

Note: You can add the simplified Linux service manager readiness probe to your Service definition:

        readinessProbe:
          exec:
            command:
            - /.m4a/gamma status

However, this probe might return a false negative result.

syslog support

The simplified Linux service manager creates a Unix socket at /dev/log to support the syslog. The simplified Linux service manager forwards these log messages to stdout so that they are recorded by Kubernetes as container logs.

Limitations

You should be aware of the following limitations when using the simplified Linux service manager.

Workload limitations

The simplified Linux service manager works best with the following types of workloads:

Image	Operating system	Services
Compute Engine Ubuntu 12.04	Ubuntu 12.04	apache2
Compute Engine Ubuntu 14.04	Ubuntu 14.04	redis, mysql, apache2
Compute Engine Ubuntu 18.04	Ubuntu 18.04	apache2, mysql, redis-server, tomcat
RHEL SAP 7.4	Red Hat	httpd
Bitnami	Ubuntu	bitnami
Compute Engine Memcached image	Debian 10.9	bitnami
Compute Engine Marketplace wordpress	Debian 9.13	apache2, mysql, php
Compute Engine Marketplace tomcat	Debian 9.13	tomcat8
Compute Engine Marketplace jenkins	Debian 10.9	apache2, jenkins
Compute Engine Marketplace moodle	Debian 9.13	apache2, mysql, php7.4-fpm, phpsessionclean
Compute Engine Marketplace Odoo	Debian 9.13	odoo, nginx
Compute Engine Marketplace Opencart	Debian 9.13	apache2, mysql, php7.0-fpm, supervisor, mariadb
Compute Engine Marketplace Erpnext	Debian 10.9	nginx, redis-server, supervisor, mariadb
Compute Engine Marketplace wildfly	Debian 10.10	wildfly, cron

systemd limitations

If you are using systemd as your init system, be aware of the following limitations:

• systemd service types of simple,exec, and notify are treated as exec service. That means the service is considered started if exec succeeds.

• Notify sockets are supported for sd_notify() for READY=1 messages only.

  You can provide other readiness checks if needed. For example, HTTP check or other types of check.

• Socket type unit files are not supported. Sockets are not created and no environment variables are created.

Updates for version 1.9.0

The simplified Linux service manager for version 1.9.0 contains the following updates:

• The Linux service manager has been released for general availability, and is no longer in Public Preview.

• The procedure to Convert existing container workloads to support Autopilot has been changed. You now need to edit both the Dockerfile and the deployment_spec.yaml file for an existing migration to convert it.

• The config.yaml file has been renamed to services-config.yaml.

Updates for version 1.8.1

The simplified Linux service manager was originally released in Public Preview as part of Migrate to Containers version 1.8. The simplified Linux service manager for version 1.8.1 contains the following updates:

• You no longer set an annotation in the migration plan to enable the simplified Linux service manager. Instead, you now set v2kServiceManager. See Deploy containers to Autopilot clusters for more.

• The environment variable HC_GAMMA_RUNTIME has been renamed to HC_V2K_SERVICE_MANAGER.

• The prestart and poststart entries in the services-config.yaml file now automatically populated. See Using services-config.yaml for more.

• Added support to the services-config.yaml file that lets you specify environment variables at the global level or at the application level. See Using services-config.yaml for more.

• Added logging support that lets you customize log data written to Cloud Logging. See Customize log data written to Cloud Logging for more.