Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/compute/docs/containers/migrate-containers below:

Migrate containers that were deployed on VMs during VM creation | Compute Engine Documentation

The container startup agent in Compute Engine is deprecated. This agent lets you deploy containers on Compute Engine instances when you create VMs.

This document describes how to migrate existing containers that the startup agent created on your VMs or managed instance groups (MIGs) to other Google Cloud services.

Based on your requirements, choose one of the following options to migrate the containers that were deployed on VMs using the deprecated method:

• If you want to continue running containers on individual VMs and MIGs, use startup scripts or cloud-init.
• If you have stateless container applications and small to medium jobs, use Cloud Run.
• If your container is a batch job that has a definite end state and requires additional computing resources, use Batch.
• If you need advanced control and scalability or if you can't meet your requirements with the other options, use GKE on Google Cloud.

For more use cases and alternative solutions, see Compare the container deployment options.

When you configure a container during VM creation, Compute Engine uses the container startup agent to read the gce-container-declaration metadata that stores the container information, and to deploy the container on the VM.

The following options for deploying containers directly on a VM or MIG that use the container startup agent and the gce-container-metadata are deprecated.

To determine whether any instances in your project use the deprecated container metadata, run the following Google Cloud CLI command that lists instances with the gce-container-declaration metadata key and value:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

This command provides a list of all VM instances in your configured project that contain the gce-container-declaration metadata key. The metadata key uniquely identifies VMs that are in scope of the deprecation. If you are using multiple projects, run this command across all of the active projects.

If you have a specific instance that you want to validate, run the following Google Cloud CLI command:

  gcloud compute instances describe VM_NAME --format="(metadata.items)"

Replace VM_NAME with the name of the VM instance that you want to validate.

For more information about viewing metadata, see View and query metadata.

The following table summarizes the use cases for running containers on VMs and recommends alternative container solutions for migrating your workloads:

When you transition from the Compute Engine container startup agent to an alternative solution, consider the following required changes and the potential effort of implementing them:

• VMs running Container-Optimized OS: Take full ownership of VM and container runtime setup, configuration, security, and maintenance, which often involves scripting with startup scripts or cloud-init.
• Cloud Run or Batch: Ensure that your applications are stateless and fit the request-driven or job-based execution model. This approach might involve adapting applications to work with external state management services.
• GKE: Adopt Kubernetes principles, define workloads by using Kubernetes manifest files, and manage cluster resources.

You can run a basic container on a VM using a startup script.

Consider the following points when you use a startup script to configure containers:

• You can use a startup script for basic scenarios. For advanced configuration, consider using cloud-init.
• Because you are creating a new VM with a container configured using the startup script, you must plan for the transition of any workloads deployed on the existing VMs.
• Test and ensure that everything works as expected before you route traffic to your newly created VM with a container.

To create a VM and to deploy a container on a VM or a MIG, do the following:

1. Map current container on VM metadata to startup script command
2. Create a startup script based on the existing metadata configuration
3. Create a VM by using the startup script or Create a MIG by using the startup script.

You can map the VM metadata or gcloud flags to docker run arguments and include this in your startup script for creating VMs.

Some gcloud flags translate directly to VM metadata. These flags also translate directly to docker run flags. If you have an existing container on a VM, you can read the VM metadata configuration and build a startup script using the equivalent docker run commands.

  # Get your existing VM instance configuration in yaml format
  gcloud compute instances describe VM_NAME --format="(metadata.items)"

The output is similar to the following:

  metadata:
    items:
    - key: gce-container-declaration
      value: |
        spec:
          containers:
          - args:
            - '"hello world!"'
            command:
            - echo
            env:
            - name: ONE
              value: '1'
            image: docker.io/library/busybox
            name: my-instance
            securityContext:
              privileged: true
            stdin: true
            tty: true
          restartPolicy: Always
    - key: google-logging-enabled
      value: 'true'

Use the following table to map existing specification to docker run commands:

The following examples show how to include the docker commands in your startup script:

• Example 1: runs a standalone container in a VM based on Container-Optimized OS.

• Example 2: runs a web server container in a VM based on Container-Optimized OS.

Run a standalone container in a VM based on Container-Optimized OS:

#!/bin/bash

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull busybox:latest

# Run docker container from image in docker hub
docker run busybox:latest \
  echo "hello world!"

Run a web server container in a VM based on Container-Optimized OS:

#!/bin/bash

# Enable incoming traffic
iptables -A INPUT -j ACCEPT

# A name for the container
CONTAINER_NAME="my-app-container"

# Stop and remove the container if it exists
docker stop $CONTAINER_NAME || true
docker rm $CONTAINER_NAME || true

# Pull the latest version of the container image from Docker Hub
docker pull nginx:latest

# Run docker container from image in docker hub
docker run \
  --name=$CONTAINER_NAME \
  --privileged \
  --restart=always \
  --tty \
  --detach \
  --network="host" \
  nginx:latest

This section describes the additional configuration parameters for deploying containers on your VMs.

For more information about these options, see Configure options to run a container.

If you need access to container images from gcr.io or pkg.dev, use the docker-credential-gcr tool, which is preinstalled in Container-Optimized OS, and configure authentication to Artifact Registry for Docker. Run the following command before you run the container:

  # Set home directory to save docker credentials
  HOME=/home/appuser

  # Configure docker with credentials for gcr.io and pkg.dev
  docker-credential-gcr configure-docker

For more information, see Configure authentication to Artifact Registry for Docker.

We recommend using Cloud Logging by enabling a logging agent on a VM.

Alternatively, if you want to change the logging driver, you can include the --log-driver parameter with your docker run command:

  # Use Cloud Logging logging driver
  docker run --log-driver=gcplogs nginx:latest

For more information, see Using Cloud Logging with Container-Optimized OS

Container-Optimized OS denies incoming traffic by default, so you must add iptables rules to allow that traffic. Note that these commands configure the host operating system's internal firewall. Additionally, you must configure your Virtual Private Cloud firewall to allow that traffic to the new VM

For more information, see Use VPC firewall rules.

  # Enable all incoming and routed traffic
  iptables -A INPUT -p -j ACCEPT
  iptables -A FORWARD -p -j ACCEPT

For more information, see Configuring the host firewall.

If volumes are attached to the container, the container metadata includes the volumes entry and a volumeMounts array. The name of an entry in volumes corresponds to the name of an entry in volumeMounts, and the other way around. For each volume that you collect, gather the required information either from the volumes or from the volumeMounts entry.

If no volumes are attached to the container, you can skip this section and directly create a VM by using the startup script.

For more information about disks and file system on Container-Optimized OS, see Disks and file system overview.

To mount an empty tmpfs file system to a container, specify the --tmpfs argument with your docker run command. For example, to mount a cache file system to your nginx container, run the following command:

  # mount a cache file system to the nginx container
  docker run -d --name=$CONTAINER_NAME --tmpfs /var/cache/nginx:rw,size=512m,noexec,nosuid,nodev --network="host" nginx:latest

For more information about mounting tmpfs file systems, see tmpfs mounts.

To mount a directory from a host VM to a container, specify the --mount argument with the docker run command:

  # mount a read-only directory to the nginx container
  docker run -d --name=$CONTAINER_NAME --mount type=bind,source=/var/www/html,target=/usr/share/nginx/html,ro nginx:latest

For more information, see Bind mounts.

Mounting a disk to the container requires additional steps. To mount a disk, first mount it on the VM, and then mount that disk to the container:

1. To mount the disk to the VM, run the following command:

   #!/bin/bash
   
   DISK_DEVICE_NAME="my-persistent-disk" # This name MUST match the 'device-name' in the gcloud --disk flag
   DISK_BY_ID_PATH="/dev/disk/by-id/google-${DISK_DEVICE_NAME}"
   HOST_MOUNT_POINT="/mnt/disks/my-persistent-disk" # This is the path where the disk will be mounted on the VM
   CONTAINER_MOUNT_PATH="/usr/share/my-persistent-disk" # This is the path where the disk will be mounted in the container
   
   # format a disk as an ext4 filesystem, if it doesn't already contain one
   file -sL $DISK_BY_ID_PATH | grep -q filesystem || \
           mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_BY_ID_PATH
   
   # create a directory for mounting point
   sudo mkdir -p "${HOST_MOUNT_POINT}"
   
   # mount a disk to the VM
   sudo mount -o defaults,discard "${DISK_BY_ID_PATH}" "${HOST_MOUNT_POINT}"
   

2. After you mount the disk to the VM, add the --mount flag with the docker run command to mount the disk to the container:

   docker run -d --name=$CONTAINER_NAME --mount type=bind,source="${HOST_MOUNT_POINT}",target="${CONTAINER_MOUNT_PATH}",readonly nginx:latest
   

After creating a startup script with your container configuration, use this startup script to create a VM based on Container-Optimized OS. For more information about creating a VM based on Container-Optimized OS, see Create an instance from a public image.

For more information about using startup scripts, see Using startup scripts on Linux VMs.

1. In the Google Cloud console, go to the Create an instance page.

   Go to Create an instance

   If prompted, select your project and click Continue. The Create an instance page appears and displays the Machine configuration pane.

2. In the Machine configuration pane, select the machine family and machine type for your VM.

3. In the navigation menu, click OS and storage. In the Operating system and storage pane that appears, configure your boot disk by doing the following:

   1. Click Change. The Boot disk pane appears and displays the Public images tab.
   2. In the Operating system list, select Container Optimized OS.
   3. In the Version list, select the OS version.
   4. In the Boot disk type list, select the type of the boot disk.
   5. (Optional) If you need additional disks, add disks in the Additional disks section.
   6. Click Select.

4. In the navigation menu, click Advanced.

   1. In the Automation section, paste the startup script that you created for your container deployment.

5. To create and start the VM, click Create.

When using gcloud CLI, store a startup script in a separate file.

1. To create a VM by using a startup script, run the following command:

   gcloud compute instances create VM_NAME \
       --zone=ZONE \
       --image-family=IMAGE_FAMILY \
       --image-project=IMAGE_PROJECT \
       --machine-type=MACHINE_TYPE \
       --metadata-from-file=startup-script=STARTUP_SCRIPT_FILE
   

   Replace the following:

   • VM_NAME: name of the new VM.
   • ZONE: zone to create the instance in.
   • IMAGE_PROJECT: the Container-Optimized OS image project that contains the image, for example, cos-cloud.
   • IMAGE_FAMILY: the Container-Optimized OS image family, for example, cos-stable.
   • MACHINE_TYPE: machine type for the new VM, which can be a predefined machine type or a custom machine type.
   • STARTUP_SCRIPT_FILE: the relative path on your machine to the startup script file, for example, ./startup_script.sh.

   Example:

   # Create COS-based VM by using a startup script
   gcloud compute instances create "cos-instance-with-startup-script" \
   --zone="us-central1-c" \
   --machine-type="e2-medium" \
   --image-family="cos-stable" \
   --image-project="cos-cloud" \
   --metadata-from-file=startup-script="./startup_script.sh"
   

2. Verify that Compute Engine created the VM by running the following command:

   gcloud compute instances describe VM_NAME
   

   Replace VM_NAME with the name of the VM you created.

To create a VM, you can use the google_compute_instance resource.

provider "google" {
project = "PROJECT_ID"
}

resource "google_compute_instance" "cos_vm_instance" {
name         = "VM_NAME"
machine_type = "MACHINE_TYPE"
zone         = "ZONE"

# Use a Container-Optimized OS image for the boot disk
boot_disk {
  initialize_params {
    image = "IMAGE_PROJECT/IMAGE_FAMILY"
  }
}

# Attaches the instance to the default network
network_interface {
  network = "default"
}

# Specify the relative path to the startup script on your local machine
metadata = {
  startup-script = file("STARTUP_SCRIPT_FILE")
}
}

Replace the following:

• VM_NAME: name of the new VM
• ZONE: zone to create the instance in.
• IMAGE_PROJECT: the Container-Optimized OS image project that contains the image, for example, cos-cloud.
• IMAGE_FAMILY: the Container-Optimized OS image family, for example, cos-stable.
• MACHINE_TYPE: machine type for the new VM, which can be a predefined machine type or a custom machine type.
• STARTUP_SCRIPT_FILE: the relative path on your machine to the startup script file, for example, ./startup_script.sh.

Example:

provider "google" {
  project = "my-project"
}

resource "google_compute_instance" "my_container_vm" {
  name = "my-container-vm-startup"
  machine_type = "e2-medium"
  zone = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "cos-cloud/cos-stable"
    }
  }

  network_interface {
    network = "default"
  }

  metadata = {
    startup-script = file("./startup_script.sh")
  }
}

After creating an instance template using the startup script, use one of the following methods to create a MIG.

For more information about creating MIGs, see Create a managed instance group.

1. Create an instance template that is based on the startup script you created in the previous section.

   1. In the Operating system section, select a Container Optimized OS and version.
   2. In the Automation section, paste the startup script that you created for the container deployment.

2. Create a MIG by using the instance template created in the previous step.

1. Create an instance template by using the instance-templates create command.

   You must use a Container-Optimized OS image for the VM. You can specify the relative path to the startup script file in the --metadata-from-file flag.

2. Create a MIG by using the instance template created in the previous step.

Example:

  # Create the instance template that uses a startup script
  gcloud compute instance-templates create startup-template \
      --machine-type=e2-medium \
      --image-family=cos-stable \
      --image-project=cos-cloud \
      --metadata-from-file=startup-script=./startup_script.sh

  # Create the managed instance group
    gcloud compute instance-groups managed create startup-mig \
      --template=startup-template \
      --size=2 \
      --zone=us-central1-a

Use the google_compute_instance_template and google_compute_instance_group_manager resources to create an instance template and a MIG, as shown in the following example:

Example:

resource "google_compute_instance_template" "startup_template" {
  name_prefix = "startup-template-"
  machine_type = "e2-medium"
  disk {
    source_image = "cos-cloud/cos-stable"
    auto_delete  = true
    boot         = true
  }

  network_interface {
    network = "default"
  }
  metadata = {
    startup-script = file("./startup_script.sh")
}
}

resource "google_compute_instance_group_manager" "startup_mig" {
  name               = "startup-mig"
  base_instance_name = "startup-vm"
  zone               = "us-central1-a"
  version {
    instance_template = google_compute_instance_template.startup_template.id
  }
  target_size = 2
}

After successful creation of a VM or a MIG, validate that your application is running on the container and working as expected. To fix any issues, see Troubleshooting.

If the application is running successfully on your new VMs created using the startup script, you can delete the VMs and MIGs that use the deprecated method of deploying containers.

This section provides troubleshooting information for issues that you might encounter when using startup scripts.

When you run the docker-credential-gcr configure-dockercommand in a startup script, you might get the following error message:

ERROR: Unable to save docker config: mkdir /root/.docker: read-only file system

This error occurs because docker-credential-gcr attempts to write credentials to the /root/.docker/config.json file. The root file system on Container-Optimized OS is read-only, so you can't write to it.

To resolve this issue, set the environment variable $HOME to point to a custom home directory before you run the docker commands.

Example:

  HOME=/home/appuser
  docker-credential-gcr configure-docker
  

To troubleshoot issues that might occur when you configure containers on VMs using a startup script, view the startup script logs and the container logs.

• To view startup script logs on the VM instance, run the following command:

  sudo journalctl | grep "startup script"
  

• To view logs from the Docker container, run the docker logs command:

  docker logs CONTAINER_NAME
  

  Replace CONTAINER_NAME with the name of your container.

For troubleshooting other issues, see the following documents:

• Cloud Logging overview
• Using Cloud Logging with Container-Optimized OS
• Troubleshooting the Docker daemon
• Troubleshoot and diagnose
• Troubleshoot Terraform
• Troubleshooting when running a basic web server
• Building internet connectivity for private VMs

You can use cloud-init, an industry-standard and cross-platform solution, to deploy containers on VMs running Container-Optimized OS. This tool lets you run custom configuration during the VM creation or startup. For more information, see Using cloud-init with the Cloud config format.

This section describes the managed services provided by Google Cloud that you can use to deploy containers.

Cloud Run is a good option for stateless container applications and small to medium jobs.

Key features of Cloud Run include the following:

• You can choose to only allocate CPUs during request processing, or always allocate CPUs.
• You can run a stateless container application or execute a job as one-off, on a schedule, or as part of a workflow.
• You can configure timeouts for each request or task.
• It's highly scalable and secure.
• It has integrated load balancing and autoscaling.

For more information about deploying containers on Cloud Run, see Deploying container images to Cloud Run

Batch is a fully managed service that lets you schedule, queue, and execute batch processing workloads on Google Cloud resources. It's designed for running batch-style, parallelizable workloads, including those packaged in containers.

For more information about deploying containers on Batch, see the following documents:

• Get started
• Create and run a basic job

If you are running complex applications, microservices, continuous operation and need fine-grained control and scalability, Google Kubernetes Engine (GKE) is the offering that is best suited. For more information about deploying containers on GKE. see the following documents:

• GKE overview
• Quickstart: Deploy an app to a GKE cluster
• Deploying a containerized web application

If you have any questions about the migration process or if you need assistance, review the FAQ or contact Google Cloud Support.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4