Software containers are a convenient way to run your apps in multipleisolated user-space instances. You can run containers on Linux or Windows Serverpublic VM images, or on aContainer-Optimized OS image. Containers letyour apps run with fewer dependencies on the host virtual machine (VM) andrun independently from other containerized apps that you deploy to thesame VM instance. These characteristics make containerizedapps more portable, easier to deploy, and easier to maintain at scale.

This document describes some of the more common container technologies thatyou can use to run containers on Compute Engine instances. You canuse these technologies on most of thepublic VM images thatCompute Engine provides.

Run containers on Compute Engine when you need complete control overyour container environment and your container orchestration tools.

Alternatively, you can useGoogle Kubernetes Engine (GKE) tosimplify cluster management and container orchestration tasks so that youdon't need to manage the underlying VM instances. GKEprovides a managed environment for deploying, managing, and scaling yourcontainerized applications using Google infrastructure.

The GKE environment consists of multiple machines (specifically,Compute Engine instances) grouped together to form acluster.When you run a GKE cluster, you gain the benefit ofadvanced cluster management features such as load-balancing, node pools, node auto-repair,automatic scaling and upgrades, and logging and monitoringthat Google Cloud provides.

Learn how tocreate a GKE clusterwith node poolsrunning Microsoft Windows Server.

Container technologies that run on Compute Engine

In general, Compute Engine instances can run almost any containertechnology or tool. You can run several different types of containers on modernLinux operating systems. You can alsorun Docker on Windows Server 2016 or later. The followinglist includes several common tools that you can use to run and managecontainerized apps:

• Docker andPodman are two popular containertechnologies that let you run containerized apps.
• Kubernetes is a containerorchestration platform that you can use to manage and scale your runningcontainers across multiple instances or within a hybrid-cloud environment.
• Containers on Compute Engineprovide an easy way to deploy containers to Compute Engine VM instancesormanaged instance groups.
• You can convert your existing systems intoLXD images and runthem within Compute Engine VM instances for a lift-and-shiftmigration solution. LXD runs on Ubuntu images.

Additionally, you can useArtifact Registryto manage container image versions. Artifact Registry serves as a centrallocation to store and manage your container images before you deploy thoseimages to Kubernetes on Compute Engine or toGoogle Kubernetes Engine clusters.

Container-optimized VM images

Compute Engine provides severalpublic VM images that you can useto create instances and run your container workloads. Some of these public VMimages have a minimalistic container-optimized operating system that includesnewer versions of Docker, Podman, or Kubernetes preinstalled. The following publicimage families are designed specifically to run containers:

• Container-Optimized OS from Google
  • Includes: Docker, Kubernetes
  • Image project:cos-cloud
  • Image family:cos-stable
• Fedora CoreOS
  • Includes: Podman, Docker
  • Image project:fedora-coreos-cloud
  • Image family:fedora-coreos-stable
• Ubuntu
  • Includes: LXD
  • Image project:ubuntu-os-cloud
  • Image family:ubuntu-2004-lts

If you need to run specific container tools and technologies on images that donot include them by default,install those technologies manually.

Installing container technologies on your instances

To launch a single container on an instance, you can specify a container imagewhen youcreate an instance.Compute Engine automatically supplies an up-to-dateContainer-Optimized OS image with Docker installed and launches yourcontainer when the VM starts up. For more information, seeDeploying containers on VMs.

Alternatively, you can run your container workloads on Compute Engineusing whatever container technologies and orchestration tools that you need. Youcancreate an instance from apublic VM image and then install thecontainer technologies that you want. For example:

• Install Docker on Compute Engine instances so that you can run yourDocker container images on those instances.
  • Install Docker on Linux instances
  • Install Docker on Windows Server instances
• Install Podman on Compute Engine instances as an alternative to the Dockercontainer runtime.
• Install Kubernetes on your instances to provide container orchestration for both Docker and OpenContainer Initiative (OCI) containers.

In some situations, you might require specific versions of these technologiesto ensure that they operate together correctly. For example, Kubernetesusually runs best with specific versions of Docker. Typically, you caninstall the latest versions of these technologies for the best result.

Installing Docker on Windows Server images

Windows Server 2016 and later versions include container support. If you plan torun Docker containers on a Windows Server instance, you can either installDocker on a Windows Server base image or use marketplace imagesfrom Mirantis.

If you want to install Docker CE on the Windows Server base image, then followthe steps outlined below.

Start bycreating a Windows Server instanceusing a Windows Server 2019 or laterpublic image.For the best container support, we recommend that you use the most recentLTSC version ofWindows Server.For more information about LTSC, seeWindows Server servicingchannels.

Install Docker

Install Docker on Windows. For more information, seePrep Windows for containers.Restart the instance after the installation is complete.

Additional setup steps

At this point you can use Docker to run containers in the instance. For example,the following command downloads the Windowsnanoserver container image andruns a command prompt inside ananoserver container:

PS C:\>docker run -it mcr.microsoft.com/windows/nanoserver:1809 cmd.exe

Docker's default network MTU is 1500 bytes. If you have configured yourVPC network MTU to 1500 bytes as well, you can ignore the restof this section. However, if you are using the defaultVPC MTU of 1460 bytes in your network, you have to do someadditional configuration on each instance.

Set the MTU for all network interfaces (bothEthernet and vEthernet) to1460 by running the following commands in aPowerShell terminal on each instance:

PS C:\>Get-NetAdapter | Where-Object Name -like "*Ethernet*" | ForEach-Object {  & netsh interface ipv4 set subinterface $_.InterfaceIndex mtu=1460 store=persistent}

PS C:\>netsh interface ipv4 show subinterfaces   MTU  MediaSenseState   Bytes In  Bytes Out  Interface------  ---------------  ---------  ---------  -------------4294967295            1          0          0  Loopback Pseudo-Interface 1  1460                1     306804     668688  Ethernet  1460                1          0       1282  vEthernet (nat)

Even after changing the instance's MTU, connectivity from containers to theinternet might be unstable because, by default, the container's networkinterface also uses an MTU of1500. For commands to set the MTU correctly forevery container, see thecontainer MTU section.

You might need to periodically re-execute these MTU commands as you configureDocker networking. For full details, see theknown issuessection.

Running Windows containers

There are many resources available for getting started with Windows containers:

• Microsoft provides extensiveWindows containers documentation.

• Docker Hub can be used as arepository for storing and pulling Windows containers.

  Note: As of November 1, 2020, Docker Hubrate limits apply to unauthenticated or authenticated pull requests on theDocker Free plan. To avoid disruptions and have greater control over yoursoftware supply chain, you can migrate your dependencies toArtifact Registry.

Known issues with Windows containers

Deprecation of Windows Server 2019 for Containers images

Google offered a Windows Server image family with the Mirantis ContainerRuntime (previously Docker EE) pre-installed:

• Windows
  • Includes: Docker
  • Image project:windows-cloud
  • Image family:windows-2019-core-for-containers

In early 2023, Microsoft ceaseddistributing and supporting the Mirantis Container Runtime for Windows Server. While Google was able tocontinue publishing this image family until October 30, 2023, the image familyis now deprecated, and all images within the family have been marked obsolete.

Virtual machines based on these images created prior to October 30, 2023 willcontinue to run without interruption. However, instance creation for newinstances based on these images will fail after that date.

Custom images derived from these images prior to October 30, 2023 will continueto function. However, custom images will not automatically receive any PatchTuesday Windows updates, nor will they receive updated versions of the MirantisContainer Runtime.

If you want to continue using images with the Mirantis Container Runtimepre-installed,Mirantis Inc offers images on Google Cloud Marketplace. The cost of these VM images includes support andlicensing for Mirantis Container Runtime directly from Mirantis. Customersinterested in using the standalone Mirantis Container Runtime can also downloadit directly from the Mirantis website.

If you want to migrate to an alternative container runtime like Docker CE,please follow the instructionsabove.

Containers are incompatible across Windows versions

Containers built on earlier versions of Windows don't work inCompute Engine instances running more recent versions of Windows.Docker pulls the Windows Server 2019 version of a container by default. Thismeans that running the following command in an instance running Windows Serverversion 1709 or newer results in an error:

PS C:\>docker run -it mcr.microsoft.com/windows/nanoserver cmd.exedocker: Error response from daemon: container9a1eb8bbcba4e91792be65f3c40b5a1aee062f02fbc60a78444b47d043438069 encountered anerror during CreateContainer: failure in a Windows system call: The operatingsystem of the container does not match the operating system of the host.(0xc0370101)

Microsoft'sWindows container versioncompatibility page contains more information. To work around Windows container versionincompatibilities, specify the tag corresponding to your Windowsversion when pulling and running containers. For example, in a Windows Server,version 20H2 instance, use the following command to run a command prompt in theversion 20H2nanoserver container instead of the default 2019 LTSC (1809) container:

PS C:\>docker run -it mcr.microsoft.com/windows/nanoserver:1809 cmd.exe

MTU incompatibilities affect instance and container connectivity

When you create a container network on a Windows instance using thedockernetwork create orNew-VMSwitch commands, the MTU of the instance's networkinterface is typicallyforced to1500. Thedefault network interface inside of a new Docker container also typicallyuses an MTU of1500.If your VPC network has an MTU of1460, you mightexperience the following issues:

• The RDP session can stop and you might be unable to reconnect. This is knownto happen when creating atransparent containernetwork.

• DNS resolution inside the container might fail.

• DNS resolution is successful, but establishing an HTTP connection from thecontainer to the internet might fail.

The recommended workaround for these limitations requires two steps:setting the MTU for the instance's network interfaces to1460andsetting the MTU for the container network interfacesto1460. Alternatively, you canset the MTU for the VPC to1500, but thisrequires stopping or migrating all of your VMs.

1. Setting the MTU for the Windows instance's network interfaces

Run the following command in a PowerShell terminal on the Windows instance toset the MTU for all network interfaces (both Ethernet and vEthernet):

PS C:\>Get-NetAdapter | Where-Object Name -like "*Ethernet*" | ForEach-Object {  & netsh interface ipv4 set subinterface $_.InterfaceIndex mtu=1460 store=persistent}

Check that the instance's Ethernet and vEthernet interface MTUs are set to1460 using this command:

PS C:\>netsh interface ipv4 show subinterfaces   MTU  MediaSenseState   Bytes In  Bytes Out  Interface------  ---------------  ---------  ---------  -------------4294967295            1          0          0  Loopback Pseudo-Interface 1  1460                1  628295912    2613170  Ethernet  1460                1      37793     223909  vEthernet (nat)

If you are unable to run these commands because you can no longer connect toan instance by using RDP, you canconnect to the instance through the serialconsole, start acmdprompt and run thenetsh commands there to repair the MTU. To avoid having todo this, we recommend executing anydocker network ... orNew-VMSwitchcommands as part of a script that also executes the MTU repair command.

2. Setting the MTU for the Windows container network interfaces

The MTU for a Windows container must be set while the container is running,either from inside the container or from the instance hosting the container. IfPowerShell is available in your container, you can run this commandinteractively or from a script in the container to correctly set the MTU:

PS C:\>Get-NetAdapter | Where-Object Name -like "vEthernet*" | ForEach-Object {  & netsh interface ipv4 set subinterface $_.InterfaceIndex mtu=1460 store=persistent}

Or, you can run this command on the Windows instance to set the MTU for allrunning containers:

PS C:\>Get-NetIPInterface -IncludeAllCompartments |  Where-Object InterfaceAlias -like "vEthernet*" |  Set-NetIPInterface -IncludeAllCompartments -NlMtuBytes 1460

Hyper-V containers fail to start

Hyper-V containers are not supported on Compute Engine at this time.

What's next

• Create and start an instancethat you can use to run container applications.
• Learn aboutCompute Engine instances.
• Learn more aboutGoogle Kubernetes Engine, which youcan use to run your containers on Google Cloud withoutmanaging Compute Engine instances yourself.
• Learn more aboutKubernetes.
• Learn how to useArtifact Registry to storeyour container images privately within Google Cloud.