Introduction¶

This documentation provides information on how to deploy Mirantis Container Runtime (MCR). The documentation is intended to help operators to understand the core concepts of the product.

The information provided in this documentation set is being constantly improved and amended based on the feedback and kind requests from the consumers of MCR.

Product Overview¶

Mirantis Container Runtime (MCR) enables you to power your business-critical applications with the industry-leading enterprise container engine. You can run containers on any platform with a fully supported and highly secure container runtime. MCR provides the core functionality and security compliance needed to enable your container orchestration solution of choice with certified proven support for both Kubernetes and Swarm. The most common use cases include:

Container orchestration solution: Organisations often have unique container orchestration requirements and may choose to utilise alternative systems to manage their containers. MCR provides freedom to select the best orchestration solution for your needs whilst still ensuring you have a secure, trusted, and supported container runtime to run your mission-critical workloads.
Secure and validated containers: The challenges in ensuring that the software supply chain is secure does not stop at the container orchestration solution. The key part of securing your container solution is ensuring that only validated and trusted containers can be deployed and run. MCR combined with Mirantis Secure Registry (MSR) gives you the ability to validate and sign your container images to ensure that only approved images can be run in your environment.
Secure validated encryption: Regulated industries need to meet federal regulations to ensure that appropriate levels of encryption are enabled. MCR provides FIPS 140-2 Validated cryptography ensuring that you meet the highest standards necessary to comply with the federal requirements.
Multiple operating systems and infrastructures: With the drive towards multi-cloud and hybrid cloud, computing organisations need to support multiple operating systems on multiple platforms. MCR is certified to run on multiple operating systems, including CentOS, RHEL, Ubuntu, and Windows, for consistent runtime regardless of the platform.

Reference Architecture¶

The Mirantis Container Runtime (MCR) Reference Architecture is a work in progress, the intent of which is to keep MCR users apprised of the technical details that pertain to the differences between MCR and Docker Engine.

Storage driver compatibility¶

overlay2 is the only storage driver supported by MCR 25.0, with the exception of btrfs, which MCR supports on SLES.

MCR storage driver compatibility¶
Graphdriver	MCR 25.0	MCR 23.0
overlay2	Supported	Supported
btrfs	Supported only on SLES. Unsupported on all other Linux platforms.	Supported only on SLES. Unavailable on all other Linux platforms.
vfs	Unsupported. Made available for debugging purposes only.	Unsupported. Made available for debugging purposes only.

Deployment Guide¶

Mirantis Container Runtime (MCR) is a client-server application with these major components:

A server which is a type of long-running program called a daemon process (the dockerd command).
A REST API which specifies interfaces that programs can use to talk to the daemon and instruct it what to do.
A command line interface (CLI) client (the docker command).

MCR can be installed on several Linux distros as well as on Windows.

Note

MCR is derived from the Moby project, an open framework created by Docker Inc. As such, most of the product commands and setup instruction are identical to those for Docker Engine.

Install MCR on Linux distros¶

FIPS 140-2 cryptographic module support¶

Federal Information Processing Standards (FIPS) Publication 140-2 is a United States Federal security requirement for cryptographic modules.

A variant of MCR that makes use of a FIPS 140-2 certified cryptographic module is available for supported Linux distros. You can obtain this FIPS-mode MCR variant in the stable-25.0/fips update channel. All FIPS-mode variants of the software components have version numbers that contain the +fips identifier as a suffix.

Note

MCR supports FIPS 140-2, however MKE and MSR currently do not.

To confirm that a FIPS-mode version of MCR is installed, confirm that the docker info command lists fips under Security Options:

Security Options:
 fips

Install Mirantis Container Runtime for Oracle Linux¶

Warning

Mirantis Container Runtime (MCR) does not support the Oracle Linux Unbreakable Enterprise Kernel (UEK).

You can install Mirantis Container Runtime (MCR) either through the use of a repository, or by downloading and installing RPM packages.

Install and upgrade MCR from a repository¶

Mirantis recommends that you install MCR from our Docker repository using DNF, a tool for RPM-based distributions that works with your repositories to manage dependencies and provide automatic updates.

Note

It is not necessary to uninstall older versions of Docker or Mirantis Container Runtime prior to upgrading as package conflicts are resolved automatically by DNF.

Set up the repository¶

You only need to set the repository up once. After doing so, you can install MCR from the repo and repeatedly upgrade the software as necessary.

Create or modify the /etc/yum.repos.d/docker-ee.repo file to contain the following:

[mirantis]
name=Mirantis Container Runtime
baseurl=https://repos.mirantis.com/oraclelinux/$releasever/$basearch/<update-channel>
enabled=1
gpgcheck=1
gpgkey=https://repos.mirantis.com/oraclelinux/gpg
module_hotfixes=true

Note

$releasever and $basearch are repo variables that must be placed into the /etc/yum.repos.d/docker-ee.repo file exactly as written.
The final baseurl path segment is the update channel, which determines which MCR releases will be available for installation and upgrade. The value for the latest MCR 25.0.x patch is stable-25.0 and the value for the latest MCR 25.0.x patch with the FIPS-mode variant is stable-25.0/fips.

Install from the repository¶

Run the following command to install MCR from the repository:

sudo dnf install docker-ee

If you are prompted to accept the GPG key, first verify that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9.

Upgrade from the repository¶

Run dnf upgrade to keep your MCR installation up to date with the latest MCR release that is available in the update channel you selected during the repository setup.

Install and upgrade MCR from a package¶

If for some reason you cannot use the repository MCR install method, you can perform manual installation with the .rpm package files for your release. Be aware, though, that you will need to download new packages each time you want to upgrade MCR.

Install with a package¶

Download the packages for your Oracle Linux distribution, the links for which are available in the MCR release notes.

Install MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Upgrade from a package¶

Download the newer .rpm packages for your Oracle Linux version.

Upgrade MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Initial setup¶

The Docker service is not started automatically at MCR installation. The docker group is created, but without any users added to the group.

Configure Docker to start at boot up and start Docker.
```
sudo systemctl enable --now docker.service
```
Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:
```
sudo docker run hello-world
```

Important

Use sudo to run docker commands. For information on how to allow non-privileged users to run docker commands, refer to the official Docker documentation Manage Docker as a non-root user.

Uninstall Mirantis Container Runtime¶

Uninstall the Mirantis Container Runtime package:
```
sudo dnf remove docker-ee
```
Delete all images, containers, and volumes, as these are not automatically removed from your host:
```
sudo rm -rf /var/lib/docker
```

Delete all other Docker-related resources:

sudo rm -rf /run/docker /var/run/docker /etc/docker

Manually delete any edited configuration files.

Install Mirantis Container Runtime for Red Hat Enterprise Linux¶

You can install Mirantis Container Runtime (MCR) either through the use of a repository, or by downloading and installing RPM packages.

Install and upgrade MCR from a repository¶

Note

It is not necessary to uninstall older versions of Docker or Mirantis Container Runtime prior to upgrading as package conflicts are resolved automatically by DNF.

Set up the repository¶

You only need to set the repository up once. After doing so, you can install MCR from the repo and repeatedly upgrade the software as necessary.

Create or modify the /etc/yum.repos.d/docker-ee.repo file to contain the following:

[mirantis]
name=Mirantis Container Runtime
baseurl=https://repos.mirantis.com/rhel/$releasever/$basearch/<update-channel>
enabled=1
gpgcheck=1
gpgkey=https://repos.mirantis.com/rhel/gpg
module_hotfixes=true

Note

$releasever and $basearch are repo variables that must be placed into the /etc/yum.repos.d/docker-ee.repo file exactly as written.
The final baseurl path segment is the update channel, which determines which MCR releases will be available for installation and upgrade. The value for the latest MCR 25.0.x patch is stable-25.0 and the value for the latest MCR 25.0.x patch with the FIPS-mode variant is stable-25.0/fips.

Install from the repository¶

Run the following command to install MCR from the repository:

sudo dnf install docker-ee

If you are prompted to accept the GPG key, first verify that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9.

Upgrade from the repository¶

Run dnf upgrade to keep your MCR installation up to date with the latest MCR release that is available in the update channel you selected during the repository setup.

Install and upgrade MCR from a package¶

Install with a package¶

Download the packages for your RHEL distribution, the links for which are available in the MCR release notes.

Install MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Upgrade from a package¶

Download the newer .rpm packages for your RHEL version.

Upgrade MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Initial setup¶

The Docker service is not started automatically at MCR installation. The docker group is created, but without any users added to the group.

Configure Docker to start at boot up and start Docker.
```
sudo systemctl enable --now docker.service
```
Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:
```
sudo docker run hello-world
```

Important

Use sudo to run docker commands. For information on how to allow non-privileged users to run docker commands, refer to the official Docker documentation Manage Docker as a non-root user.

Uninstall Mirantis Container Runtime¶

Uninstall the Mirantis Container Runtime package:
```
sudo dnf remove docker-ee
```
Delete all images, containers, and volumes, as these are not automatically removed from your host:
```
sudo rm -rf /var/lib/docker
```

Delete all other Docker-related resources:

sudo rm -rf /run/docker /var/run/docker /etc/docker

Manually delete any edited configuration files.

Install Mirantis Container Runtime for Rocky Linux¶

You can install Mirantis Container Runtime (MCR) either through the use of a repository, or by downloading and installing RPM packages.

Install and upgrade MCR from a repository¶

Note

It is not necessary to uninstall older versions of Docker or Mirantis Container Runtime prior to upgrading as package conflicts are resolved automatically by DNF.

Set up the repository¶

You only need to set the repository up once. After doing so, you can install MCR from the repo and repeatedly upgrade the software as necessary.

Create or modify the /etc/yum.repos.d/docker-ee.repo file to contain the following:

[mirantis]
name=Mirantis Container Runtime
baseurl=https://repos.mirantis.com/rocky/$releasever/$basearch/<update-channel>
enabled=1
gpgcheck=1
gpgkey=https://repos.mirantis.com/rocky/gpg
module_hotfixes=true

Note

$releasever and $basearch are repo variables that must be placed into the /etc/yum.repos.d/docker-ee.repo file exactly as written.
The final baseurl path segment is the update channel, which determines which MCR releases will be available for installation and upgrade. The value for the latest MCR 25.0.x patch is stable-25.0 and the value for the latest MCR 25.0.x patch with the FIPS-mode variant is stable-25.0/fips.

Install from the repository¶

Run the following command to install MCR from the repository:

sudo dnf install docker-ee

If you are prompted to accept the GPG key, first verify that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9.

Upgrade from the repository¶

Run dnf upgrade to keep your MCR installation up to date with the latest MCR release that is available in the update channel you selected during the repository setup.

Install and upgrade MCR from a package¶

Install with a package¶

Download the packages for your Rocky Linux distribution, the links for which are available in the MCR release notes.

Install MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Upgrade from a package¶

Download the newer .rpm packages for your Rocky Linux version.

Upgrade MCR.

sudo dnf install path/to/downloaded/packages/*.rpm

Initial setup¶

The Docker service is not started automatically at MCR installation. The docker group is created, but without any users added to the group.

Configure Docker to start at boot up and start Docker.
```
sudo systemctl enable --now docker.service
```
Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:
```
sudo docker run hello-world
```

Important

Use sudo to run docker commands. For information on how to allow non-privileged users to run docker commands, refer to the official Docker documentation Manage Docker as a non-root user.

Uninstall Mirantis Container Runtime¶

Uninstall the Mirantis Container Runtime package:
```
sudo dnf remove docker-ee
```
Delete all images, containers, and volumes, as these are not automatically removed from your host:
```
sudo rm -rf /var/lib/docker
```

Delete all other Docker-related resources:

sudo rm -rf /run/docker /var/run/docker /etc/docker

Manually delete any edited configuration files.

Install Mirantis Container Runtime for SLES¶

Warning

Mirantis Container Runtime (MCR) is not supported on OpenSUSE.

You can install Mirantis Container Runtime (MCR) either through the use of a repository, or by downloading and installing RPM packages.

Install and upgrade MCR from a repository¶

Mirantis recommends that you install MCR from our Docker repository using Zypper, SUSE Linux Enterprise’s package manager. This method provides a level of automation with the MCR dependencies installation and updates automation.

Note

It is not necessary to uninstall older versions of Docker or Mirantis Container Runtime prior to upgrading as package conflicts are resolved automatically by Zypper.

Set up the repository¶

You only need to set the repository up once. After doing so, you can install MCR from the repo and repeatedly upgrade the software as necessary.

Add the repository to Zypper:
```
sudo zypper addrepo --refresh
'https://repos.mirantis.com/sles/$releasever_major/$basearch/<update-channel>'
mirantis
```
Note
- The $releasever_major and ja$basearchmmy are repo variables that must be passed verbatim to the :command:`zypper`command without being expanded by your shell.
- The final path segment of the repo URL is the update channel, which determines which MCR releases will be available for installation and upgrade. The value for the latest MCR 25.0.x patch is stable-25.0 and the value for the latest MCR 25.0.x patch with the FIPS-mode variant is stable-25.0/fips.

Import the GPG key from the repository:

sudo rpm --import https://repos.mirantis.com/sles/gpg

Install from the repository¶

Run the following command to install MCR from the repository:

sudo zypper install docker-ee

If you are prompted to accept the GPG key, verify first that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E899E5 FF2E 7668 2BC9.

Upgrade from the repository¶

Run zypper update to keep your MCR installation up to date with the latest MCR release that is available in the update channel you selected during the repository setup.

Install and upgrade MCR from a package¶

Download the official Mirantis GPG key.
Download the SLES packages, the links for which are available in the MCR release notes.
Import the official Mirantis GPG key:
```
sudo rpm --import path/to/mirantis/gpg
```

Install MCR.

sudo zypper install path/to/downloaded/packages/*.rpm

Upgrade from a package¶

Download the newer .rpm packages for your SLES version.

Upgrade MCR.

sudo zypper install path/to/downloaded/packages/*.rpm

Initial setup¶

The Docker service is not started automatically at MCR installation. The docker group is created, but without any users added to the group.

Configure Docker to start at boot up and start Docker.
```
sudo systemctl enable --now docker.service
```
Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:
```
sudo docker run hello-world
```

Important

Use sudo to run docker commands. For information on how to allow non-privileged users to run docker commands, refer to the official Docker documentation Manage Docker as a non-root user.

Uninstall Mirantis Container Runtime¶

Uninstall the Mirantis Container Runtime package:
```
sudo zypper remove docker-ee
```
Delete all images, containers, and volumes, as these are not automatically removed from your host:
```
sudo rm -rf /var/lib/docker
```

Delete all other Docker-related resources:

sudo rm -rf /run/docker /var/run/docker /etc/docker

Manually delete any edited configuration files.

At start up, Docker creates a DOCKER iptables chain. The SUSE firewall may block access to this chain, however, which can prevent you from running containers with published ports. In such cases, errors may present, such as:

WARNING: IPv4 forwarding is disabled. Networking will not work.
docker: Error response from daemon: driver failed programming external
        connectivity on endpoint adoring_ptolemy
        (0bb5fa80bc476f8a0d343973929bb3b7c039fc6d7cd30817e837bc2a511fce97):
        (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 80 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)).

If such errors do present, adjust the start-up script order to make it so that the firewall starts before Docker starts, and so that Docker stops before the firewall stops. For more information, refer to the official SLES systemd daemon documentation.

Miratis recommends that you use the overlay2 storage driver, which is the default for all new MCR installations. This applies even when /var/lib/docker is on a btrfs filesystem.

MCR provides the btrfs storage driver for purposes of compatibility with existing deployments. MCR automatically uses the btrfs storage driver if it detects the presence of existing images in /var/lib/docker that were stored with the btrfs driver.

Install Mirantis Container Runtime for Ubuntu¶

You can install Mirantis Container Runtime (MCR) either through the use of a repository, or by downloading and installing DEB packages.

Install and upgrade MCR from a repository¶

Mirantis recommends that you install MCR from our Docker repository using APT, the Ubuntu package manager. This method provides a level of automation with the MCR dependencies installation and updates automation.

Note

It is not necessary to uninstall older versions of Docker or Mirantis Container Runtime prior to upgrading as package conflicts are resolved automatically by APT.

Set up the repository¶

You only need to set the repository up once. After doing so, you can install MCR from the repo and repeatedly upgrade the software as necessary.

Install the necessary packages for setting up the repository:
```
sudo apt update && sudo apt install curl gnupg
```

Import the GPG key:

sudo gpg --batch --yes \
  --output /usr/share/keyrings/mirantis-archive-keyring.pgp --dearmor \
  <<< $(curl -fsSL https://repos.mirantis.com/ubuntu/gpg)

Verify that the GPG key has the fingerprint DD91 1E99 5A64 A202 E859 07D6 BC14 F10B 6D08 5F96:

$ gpg --show-keys --with-fingerprint --keyid-format=short \
  /usr/share/keyrings/mirantis-archive-keyring.pgp

Expected output:

pub   rsa4096/6D085F96 2017-02-22 [SCEA]
     Key fingerprint = DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96
uid                    Docker Release (EE deb) <docker@docker.com>
sub   rsa4096/91A29FA3 2017-02-22 [S]

Add the repository to your sources.list. To do this, create a text file in /etc/apt/sources.list.d/mirantis.sources:
```
Types: deb
URIs: https://repos.mirantis.com/ubuntu
Suites: <value-depends-on-Ubuntu-version>
Architectures: amd64
Components: <determines-update-channel>
Signed-by: /usr/share/keyrings/mirantis-archive-keyring.pgp
```
Note
- The Suites parameter setting is jammy for Ubuntu 22.04 and focal for Ubuntu 20.04.
- The Components parameter setting sets the update channel, which determines which MCR releases will be available for installation and upgrade. The value for the latest MCR 25.0.x patch is stable-25.0 and the value for the latest MCR 25.0.x patch with the FIPS-mode variant is stable-25.0/fips.

Install from the repository¶

Run the following command to install MCR from the repository:

sudo apt update && sudo apt install docker-ee

Any existing MCR installation is replaced.

Upgrade from the repository¶

Run apt update && apt upgrade to keep your MCR installation up to date with the latest MCR release that is available in the update channel you selected during the repository setup.

Install and upgrade MCR from a package¶

If for some reason you cannot use the repository MCR install method, you can perform manual installation with the .deb package files for your release. Be aware, though, that you will need to download new packages each time you want to upgrade MCR.

Install from a package¶

Download the .deb packages for your Ubuntu version from the release-notes.

Install MCR.

sudo dnf install path/to/downloaded/packages/*.deb

Upgrade from a package¶

Download the newer .deb packages for your Ubuntu version.

Upgrade MCR.

sudo dnf install path/to/downloaded/packages/*.deb

Initial setup¶

On installation, the Docker service starts automatically and is configured to start thereafter at boot up. The docker group is created, but without any users added to the group.

Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:

sudo docker run hello-world

Important

Use sudo to run docker commands. For information on how to allow non-privileged users to run docker commands, refer to the official Docker documentation Manage Docker as a non-root user.

Uninstall Mirantis Container Runtime¶

Uninstall the Mirantis Container Runtime package.
```
sudo apt purge docker-ee
```
Delete all images, containers, and volumes, as these are not automatically removed from your host:
```
sudo rm -rf /var/lib/docker
```

Delete all other Docker-related resources:

sudo rm -rf /run/docker /var/run/docker /etc/docker

Manually delete any edited configuration files.

Run MCR as a non-root user¶

MCR nodes in rootless mode cannot belong to a MKE cluster.

For information on rootless mode installation and configuration, refer to the Docker documentation Run the Docker daemon as a non-root user (Rootless mode).

Install MCR on Windows Servers¶

Mirantis Container Runtime (MCR) enables native Docker containers on Windows Server. The Mirantis Container Runtime installation package includes everything you need to run Docker on Windows Server. This topic describes pre-install considerations, and how to download and install Mirantis Container Runtime.

Note

Refer to the MCR 25.0 Compatibility Matrix for information on which Windows Server versions are supported.

System requirements¶

Windows OS CPU and RAM requirements that must be met are specified in the Windows Server Requirements.

Install MCR with an Internet connection¶

Mirantis provides an installation script to ease MCR installation on a Windows Server machine. The script uses default values, thus allowing it to be run without configuration. You can, however, override the default values with script parameters and env variables. Parameter values take precedence over env variables. Both take precedence over inbuilt default values.

The installation script must be executed from an elevated command prompt. If you want to change the default daemon values, ensure that you have the alternative cofigurations and the related collateral in place prior to executing the script. For example, if you want to enable TLS, store the certificates and write the daemon configuration file before invoking the script.

Obtain the installation script for MCR for Windows Server at https://get.mirantis.com/install.ps1.

(Optional): Allow downloaded script files to run in the current session

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;

Run the installation script.

The installer will issue a prompt, should it require a reboot.

Note

The installation script installs a numerically higher version by default. The latest tag, however, explicitly denotes the binary that was last pushed, which may not be a numerically higher version.

Test your MCR installation by running the hello-world container.

docker run hello-world:nanoserver

The container starts, prints the Hello from Docker! message, and then exits.

Unable to find image 'hello-world:nanoserver' locally
nanoserver: Pulling from library/hello-world
bce2fbc256ea: Pull complete
3ac17e2e6106: Pull complete
8cac44e17f16: Pull complete
5e160e4d8db3: Pull complete
Digest: sha256:25eac12ba40f7591969085ab3fb9772e8a4307553c14ea72d0e6f98b2c8ced9d
Status: Downloaded newer image for hello-world:nanoserver

Hello from Docker!
This message shows that your installation appears to be working correctly.

FIPS 140-2 cryptographic module support¶

Federal Information Processing Standards (FIPS) Publication 140-2 is a United States Federal security requirement for cryptographic modules.

A variant of MCR that makes use of a FIPS 140-2 certified cryptographic module is available for Windows Server. You can obtain this FIPS-mode MCR variant in the stable-25.0/fips channel. The install script downloads MCR from the stable-25.0/fips channel by default whenever the Windows host is running in FIPS mode. To install FIPS-mode MCR on a system that is not in FIPS mode, pass the -Channel stable-25.0/fips option to install.ps1.

Note

FIPS 140-2 is only supported in MCR. MKE and MSR currently do not support FIPS 140-2.

Hint

To check that the Windows host is running in FIPS mode, run the following command in PowerShell:

[System.Security.Cryptography.Cryptoconfig]::AllowOnlyFipsAlgorithms

The host is running in FIPS mode if the command prints True.

To confirm that a FIPS-mode version of MCR is installed, confirm that the docker info command lists fips under Security Options:

Security Options:
 fips

Install MCR offline¶

If your hardware is air-gapped you can still install MCR. To do so, download the installer and copy the files to the air-gapped machine (the default installation assumes that the zipped files and script are in the same location).

On any Internet connected system, go to https://get.mirantis.com/install.ps1 to obtain the MCR for Windows Server installation script.

(Optional): Allow the downloaded script files to run in the current session.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;

Run the installation script with the -DownloadOnly parameter. As per the parameter name, this action only downloads the zip file (no installation is performed).
```
.\<installation-script> -DownloadOnly
```
Copy the installation script and the installation zip file over to the air-gapped machine and run the install with the -Offline parameter.
```
.\<installation-script> -Offline
```
If prompted, reboot the installer.

Install a specific version¶

Use the following three parameters separately or in tandem to install a specific version of MCR for Windows Server.

Caution

MCR does not support using earlier versions of containerd than the version with which it is released. For supported containerd versions, refer to the Major component versions section of the required MCR version in rn-23-01.

.\install.ps1 -Channel
.\install.ps1 -ContainerdVersion
.\install.ps1 -DockerVersion

For example, the installation script will always use the latest GA.

For parameter descriptions, refer to Install script usage.

Update MCR¶

To update MCR to the most recent release, download the latest copy of the installation script and rerun the installation steps.

Obtain the installation script for MCR for Windows Server at https://get.mirantis.com/install.ps1.

(Optional): Allow downloaded script files to run in the current session.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process

Run the installation script.

Install script usage¶

The installation script uses the parameters detailed below.

Parameter	Description
.PARAMETER DownloadUrl	[Alternately specified by $Env:DOWNLOAD_URL] Specifies an alternative repository in which to download container runtime packages.
.PARAMETER Channel	[Alternately specified by $Env:CHANNEL] Specifies which channel to use for picking the binaries. Default: `stable-25.0/fips` if Windows is configured to run in FIPS mode, otherwise the default is `stable-25.0`.
.PARAMETER DockerVersion	[Alternately specified by $Env:DOCKER_VERSION] Specifies the version number for the DockerEE binaries to install. The latest version is the default.
.PARAMETER ContainerdVersion	[Alternately specified by $Env:CONTAINERD_VERSION] Specifies the version number for the containerd binaries to install The latest version is the default.
.PARAMETER DryRun	If specified, list different steps to use without actually invoking those steps.
.PARAMETER Uninstall	If specified, uninstalls all packages. This includes unregistering the corresponding services and removing paths for the package from the registry. All other script parameters (except `DryRun` and `DestPath`) are ignored if this switch is specified. Common parameters such as -Verbose are still honored.
.PARAMETER Ver	Print version info for the script and exit.
.PARAMETER NoServiceStarts	If specified, services are not started on successful install. By default, all services installed by the script are left in a running state before exit.
.PARAMETER DestPath	Path to the directory under which binaries will be installed. Default: %PROGRAMDATA%
.PARAMETER OfflinePackagesPath	The folder for airgap/offline scenarios. For use when the offline or `DownloadOnly` parameters are specified. Used to either save the downloaded packages for later offline use or for pointing to previously downloaded packages for offline install.
.PARAMETER Offline	Install packages in offline/airgap mode. By default, the current directory is used to locate previously downloaded packages, a setting that can be overridden by using the `OfflinePackagesPath` parameter.
.PARAMETER DownloadOnly	Download and save packages for later offline/airgap install.
.PARAMETER EngineOnly	Skip all steps except those related to MCR.

Install script notes¶

The script supports airgap functionality by providing access to download packages while online, as well as to install those selfsame packages while offline.

For downloads, ensure that the script has access to the internet. Use the -DownloadOnly parameter. By default, the script will use the current directory to store the packages after download, a setting that can be changed by specifying the path explicitly with the -OfflinePackagesPath parameter.

For offline/airgap install, use the -Offline parameter. By default, the script searches for pacakages in the current directory, a setting that can be changed by specifying the -OfflinePackagesPath parameter.

While downloading using -DownloadOnly parameter, confirm that the download path is accessible to the script, especially if you run the script without administrative rights.

The following is required so that the script can be invoked with named parameters (for example, -ContainerdVersion 1.3.4...). If a parameter is used, its type is checked by powershell - we give a higher precedence to the parameters specified in this manner versus the same value specified by env vars.

Parameters received at invocation time. Some of these values are merged with values specified by env vars - see reconcileParams. Others are used as-is.

Disable MCR telemetry¶

Refer to Configure telemetry for information on how to disable the telemetry function in MCR.

Uninstall MCR¶

Use the following commands to remove MCR from a Windows Server.

Leave any active Docker Swarms.
```
docker swarm leave --force
```
Prune container data.
```
docker system prune -all
```
Run the installation script using the uninstall flag to remove MCR from the system.

Install the license¶

Warning

Users are not authorized to run MCR without a valid license. For more information, refer to Mirantis Agreements and Terms.

For MCR to recognize your license, you must apply your customer license file at runtime.

To make MCR aware of your license and entitlement, perform the following for each node that will host MCR:

Download the license file.

If you purchased a license from the Mirantis Store, the license file is available through a link in your confirmation email. Otherwise, contact Mirantis Sales and Support to gain access to the file.
Locate the daemon data directory.

The default daemon data directory is /var/lib/docker on Linux and %PROGRAMDATA%\docker on Windows. The location of the directory may be different, however, if the daemon data directory path was previously reconfigured in the data-root property in the daemon.json file or through the passing of the --data-root flag during MCR start up.
Copy the license file to the daemon data directory and name it docker.lic The license must be readable by the account/user that runs the docker daemon.

Note

Whenever an MKE license is applied to an MKE cluster, the license is also applied to all MCR nodes in the cluster. The inverse is not true, though, so MKE users should apply their license through the MKE web UI to bypass having to apply the license to individual MCR nodes.

Configure telemetry¶

By default, MCR automatically records and transmits data to Mirantis for monitoring and analysis purposes. The data collected provides the Mirantis Customer Success Organization with information that helps us to better understand the operational use of MCR by our customers. It also provides key feedback in the form of product usage statistics, which enable our product teams to enhance Mirantis products and services.

To disable the telemetry function, set features.telemetry to false in your daemon.json file.
Note
- The daemon.json file is located at /etc/docker/daemon.json on Linux systems and at %PROGRAMDATA%\docker\config\daemon.json on Windows systems.
```
{"features":{"telemetry":false}}
```
Important

You can only disable the telemetry function for MCR instances to which a valid license has been applied. Once the applied license expires, MCR resumes telemetry transmission to Mirantis.
To re-enable the telemetry function, change the setting to true or remove it entirely.
To apply configuration changes following an edit of the daemon.json file, you must restart the daemon or reload its configuration.
To send the telemetry, verify that dockerd is able to resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Use MCR with Kubernetes¶

Customers who use MCR with Kubernetes directly (without MKE) must use a plugin maintained by Kubernetes called dockershim for Kubernetes 1.23 and below or a plugin maintained by Mirantis called cri-docker (included in MCR) for Kubernetes 1.24 and above.

To configure cri-docker:

systemctl enable cri-docker.service

Use MCR with Docker Swarm¶

Mirantis Container Runtime (MCR) supports the use of Docker Swarm.

The following Docker documentation topics offer detailed information that can help you to run MCR in swarm mode:

Security¶

Several Docker resources are available which cover the basics of Mirantis Container Runtime security, including:

Docker Security Documentation describes the fundamentals, such as namespaces and control groups, the attack surface of the Docker daemon, and other kernel security features.
CIS Docker Community Edition Benchmark details the various security-related options in MCR.
Docker Bench Security is a script that audits your configuration of MCR against the CIS Benchmark.

Antivirus and antimalware¶

When antivirus and antimalware software products scan files in use by MCR, these files can lock in a way that causes Docker commands to hang or causes orphaned snapshots to leak disk space. To circumvent these problems, you can add the Docker data directory to the software’s exclusion list, which is by default /var/lib/docker on Linux systems and %ProgramData%\docker on Windows Server systems. As a result of this action, though, viruses or malware in local Docker images, writable layers of containers, or volumes will go undetected.

Note

If you choose to exclude the Docker data directory from background virus scanning, Mirantis recommends that you schedule recurring tasks for stopping MCR, for scanning the data directory, and for restarting MCR. Make sure to stagger these recurring tasks, though, as running them in sync can cause a system outage.

Docker Content Trust¶

When transferring data among networked systems, trust is a central concern. In particular, when communicating over an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data a system operates on. You use Docker Engine to push and pull images to a public or private registry. Docker Content Trust (DCT) gives you the ability to verify both the integrity and the publisher of all the data received from a registry over any channel.

Docker Content Trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side or runtime verification of the integrity and publisher of specific image tags.

Through DCT, image publishers can sign their images and image consumers can verify the signatures of the images they pull. Publishers could be individuals or organizations manually signing their content or automated software supply chains signing content as part of their release process.

Image tags and DCT¶

An individual image record has the following identifier:

[REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]

A particular image REPOSITORY can have multiple tags. For example, latest and 3.1.2 are both tags on the mongo image. An image publisher can build an image and tag combination many times changing the image with each build.

DCT is associated with the TAG portion of an image. Each image repository has a set of keys that image publishers use to sign an image tag. Image publishers have discretion on which tags they sign.

An image repository can contain an image with one tag that is signed and another tag that is not. For example, consider the Mongo image repository. The latest tag could be unsigned while the 3.1.6 tag could be signed. It is the responsibility of the image publisher to decide if an image tag is signed or not. In this representation, some image tags are signed, others are not:

Publishers can choose to sign a specific tag or not. As a result, the content of an unsigned tag and that of a signed tag with the same name may not match. For example, a publisher can push a tagged image someimage:latest and sign it. Later, the same publisher can push an unsigned someimage:latest image. This second push replaces the last unsigned tag latest but does not affect the signed latest version. The ability to choose which tags they can sign allows publishers to iterate over the unsigned version of an image before officially signing it.

Image consumers can enable DCT to ensure that images they use are signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. Enabling DCT is a bit like applying a “filter” to your registry. Consumers “see” only signed image tags while the less desirable, unsigned image tags are “invisible” to them.

To the consumer who has not enabled DCT, nothing changes with regard to how they work with Docker images. Every image is visible regardless of whether it is signed or not.

Docker Content Trust Keys¶

Trust for an image tag is managed through the use of signing keys. A key set is created when an operation using DCT is first invoked. A key set consists of the following classes of keys:

an offline key that is the root of DCT for an image tag
repository or tagging keys that sign tags
server-managed keys such as the timestamp key, which provides freshness security guarantees for your repository

The following image depicts the various signing keys and their relationships:

Warning

Once lost, the root key is not recoverable.

You should back up the root key somewhere safe. Given that it is only required to create new repositories, you should store it offline in hardware. For details on securing, and backing up your keys, make sure you read Manage keys for content trust.

Signing Images with Docker Content Trust¶

Within the Docker CLI, you can sign and push a container image with the $ docker trust command syntax. This is built on top of the Notary feature set, more information for which can be found in the Notary Github Repository.

A prerequisite for signing an image is a container image Registry with a Notary server attached, such as a Mirantis Secure Registry or Docker Hub. Instructions for standing up a self-hosted environment can be found in the Docker official documentation, Deploy Notary Server with Compose.

A delegation key pair is required to sign a container image. These keys can be generated locally using $ docker trust key generate or generated by a certificate authority. If you are using Mirantis Kubernetes Engine, the Client Bundle provides adequate keys for a delegation.

To sign images with Docker Content Trust:

Add the delegation private key to the local Docker trust repository, which by default is stored in ~/.docker/trust/.

If you are generating delegation keys with $ docker trust key generate, the private key is automatically added to the local trust store.

If you are importing a separate key, such as one from a MKE Client Bundle, you must use the $ docker trust key load command:

$ docker trust key generate jeff
Generating key for jeff...
Enter passphrase for new jeff key with ID 9deed25:
Repeat passphrase for new jeff key with ID 9deed25:
Successfully generated and loaded private key. Corresponding public key
available: /home/ubuntu/Documents/mytrustdir/jeff.pub

If you have an existing key, run the following command:

$ docker trust key load key.pem --name jeff
Loading key from "key.pem"...
Enter passphrase for new jeff key with ID 8ae710e:
Repeat passphrase for new jeff key with ID 8ae710e:
Successfully imported key from key.pem

Add the delegation public key to the Notary server. Each delegation key in Notary is specific to a particular image repository. If this is the first time you are adding a delegation to that repository, this command will also initiate the repository, using a local Notary canonical root key. To understand more about initiating a repository, and the role of delegations, refer to the official Docker documentation, Delegations for content trust.
```
$ docker trust signer add --key cert.pem jeff msr.example.com/admin/demo
Adding signer "jeff" to msr.example.com/admin/demo...
Enter passphrase for new repository key with ID 10b5e94:
```

Use the delegation private key to sign a particular tag and push the signature up to the registry.

$ docker trust sign msr.example.com/admin/demo:1
Signing and pushing trust data for local image msr.example.com/admin/demo:1, may overwrite remote trust data
The push refers to repository [msr.example.com/admin/demo]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed msr.example.com/admin/demo:1

Alternatively, once the keys have been imported an image can be pushed with the $ docker push command:

$ export DOCKER_CONTENT_TRUST=1

$ docker push msr.example.com/admin/demo:1
The push refers to repository [msr.example.com/admin/demo:1]
7bff100f35cb: Pushed
1: digest: sha256:3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e size: 528
Signing and pushing trust metadata
Enter passphrase for signer key with ID 8ae710e:
Successfully signed msr.example.com/admin/demo:1

To view remote trust data for a tag or repository:

Run the $ docker trust inspect command to view remote trust data for a tag or a repository:

$ docker trust inspect --pretty msr.example.com/admin/demo:1

Signatures for msr.example.com/admin/demo:1

SIGNED TAG          DIGEST                                                             SIGNERS
1                   3d2e482b82608d153a374df3357c0291589a61cc194ec4a9ca2381073a17f58e   jeff

List of signers and their keys for msr.example.com/admin/demo:1

SIGNER              KEYS
jeff                8ae710e3ba82

Administrative keys for msr.example.com/admin/demo:1

  Repository Key:    10b5e94c916a0977471cc08fa56c1a5679819b2005ba6a257aa78ce76d3a1e27
  Root Key:  84ca6e4416416d78c4597e754f38517bea95ab427e5f95871f90d460573071fc

To remove remote trust data for a tag:

Run the $ docker trust revoke command to remove remote trust data for a tag:

$ docker trust revoke msr.example.com/admin/demo:1
Enter passphrase for signer key with ID 8ae710e:
Successfully deleted signature for msr.example.com/admin/demo:1

Runtime Enforcement with Docker Content Trust¶

Note

Runtime enforcement is a feature that is exclusive to MCR. It is not available in Moby or Docker CE.
The implementation is separate from the only run signed images feature of Mirantis Kubernetes Engine.

Docker Content Trust within the Mirantis Container Runtime prevents a user from using a container image from an untrusted source. It will also prevent a user from building a container image from a base layer from an untrusted source. Trusted sources can include Official Docker Images, found on the Docker Hub or User trusted sources, with repositories and tags signed with the commands detailed in Signing Images with Docker Content Trust.

Engine Signature Verification prevents the following:

$ docker container run of an unsigned or altered image.
$ docker pull of an unsigned or altered image.
$ docker build where the FROM image is not signed or is not scratch.

Note

The implicit pulls and runs performed by worker nodes for a Swarm service on $ docker service create and $ docker service update are also verified. Tag resolution of services requires that all nodes in the Swarm including managers have content trust enabled and similarly configured.

DCT does not verify that the filesystem of a running container has not been altered from what was in the image. For example, it does not prevent a container from writing to the filesystem, once the container is running. Moreover, it does not prevent the image filesystem from being altered on the disk of a Docker host. DCT will also not prevent unsigned images from being imported, loaded, or created.

Enabling DCT within the Mirantis Container Runtime¶

DCT is controlled by the Docker Engine configuration file, which by default is located at /etc/docker/daemon.json. For more information on the configuration file, refer to the official docker documentation, Daemon configuration file.

Note

The configuration can be set only on Linux machines.

The content-trust section is based around a mode option that instructs the engine on whether to enforce signed images, and a trust-pinning section that instructs the engine on which sources to trust.

Mode can take one of three values: disabled, permissive, or enforced.

disabled: Verification is not active and the remainder of the content-trust related configuration is ignored. This is the default value if mode is not specified.
permissive: Verification will be performed, while failures are only logged. Images that cannot be verified successfully can still be pulled and run. This configuration is intended for testing of changes related to content-trust. The results of the signature verification are displayed in the MCR daemon logs.
enforced: Content trust is enforced, thus an image that cannot be verified successfully is not pulled or run.

{
    "content-trust": {
        "mode": "<variable-type>"
    }
}

Official Docker images¶

Note

The IDs of all Notary root keys that are used to verify Docker Official Images are embedded in MCR.

If you want to configure MCR so that only Docker Official Images can be used, you can configure your daemon to do so using the embedded key IDs:

{
  "content-trust": {
    "trust-pinning": {
      "official-library-images": true
    },
    "mode": "enforced"
  }
}

User-signed images¶

There are two options for trust pinning user-signed images: Notary Canonical Root Key ID and Notary Root key ID.

Notary canonical root key ID¶

The Notary Canonical Root Key ID, or DCT Root Key, describes only the root key used to sign a repository, or rather its respective keys. This is the root key on the host that originally signed the repository, such as your workstation. It can be retrieved from the workstation that signed the repository through $ grep -r "root" ~/.docker/trust/private/ (assuming your trust data is at ~/.docker/trust/*). It is expected that this canonical ID has initiated multiple image repositories (mymsr/user1/image1 and mymsr/user1/image2).

Retrieve root ID:

$ grep -r "root" ~/.docker/trust/private
/home/ubuntu/.docker/trust/private/0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403.key:role:
root

Use a canonical ID. In the example that follows, the canonical ID has signed two repos, mymsr/user1/repo1 and mymsr/user1/repo2. Note that wildcards are allowed.

{
  "content-trust": {
    "trust-pinning": {
      "root-keys": {
        "mymsr/user1/*": [
          "0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403"
        ]
      }
    },
    "mode": "enforced"
  }
}

Notary root key ID¶

The Notary Root key ID, or DCT Certificate ID, describes the same as the Notary Canonical Root Key ID; the ID is unique per repository. For example, mymsr/user1/image1 and mymsr/usr1/image2 will each have a unique certificate ID. A certificate ID can be retrieved through a $ docker trust inspect command, labeled as a root-key, referring back to the Notary key name. This is designed for when different users are signing their own repositories, such as when there is no central signing server. As a cert-id is more granular, it would take priority if a conflict occurs over a root ID.

Retrieve root ID:

$ docker trust inspect mymsr/user1/repo1 | jq -r '.[].AdministrativeKeys[] | select(.Name=="Root") | .Keys[].ID'
9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168

Use cert IDs by specifying two repositories with their DCT root ID.

 {
   "content-trust": {
     "trust-pinning": {
       "cert-ids": {
          "mymsr/user1/repo1": [
            "9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168"
          ],
          "mymsr/user2/repo1": [
            "544cf09f294860f9d5bc953ad80b386063357fd206b37b541bb2c54166f38d08"
          ]
       }
     },
     "mode": "enforced"
   }
}

Using DCT in an offline environment¶

If your engine is unable to communicate to the registry, DCT can be enabled to trust cached signature data. This is configured through the allow-expired-cached-trust-data option.

{
  "content-trust": {
    "trust-pinning": {
      "official-library-images": true,
      "root-keys": {
        "mymsr/user1/*": [
          "0b6101527b2ac766702e4b40aa2391805b70e5031c04714c748f914e89014403"
        ]
      },
      "cert-ids": {
        "mymsr/user2/repo1": [
          "9430d6e31e3b3e240957a1b62bbc2d436aafa33726d0fcb50addbf7e2dfa2168"
        ],
      }
    },
    "mode": "enforced",
    "allow-expired-cached-trust-data": true
  }
}

Client Enforcement with Docker Content Trust¶

Content trust is disabled by default in the Docker Client. To enable it, set the DOCKER_CONTENT_TRUST environment variable to 1. This prevents users from working with tagged images unless they contain a signature.

When DCT is enabled in the Docker client, docker CLI commands that operate on tagged images must either have content signatures or explicit content hashes. The commands that operate with DCT are:

push
build
create
pull
run

For example, with DCT enabled a docker pull someimage:latest command only succeeds if someimage:latest is signed. However, an operation with an explicit content hash always succeeds as long as the hash exists:

$ docker pull msr.example.com/user/image:1
Error: remote trust data does not exist for msr.example.com/user/image: msr.example.com does not have trust data for msr.example.com/user/image

$ docker pull msr.example.com/user/image@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1: Pulling from user/image
ff3a5c916c92: Pull complete
a59a168caba3: Pull complete
Digest: sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1
Status: Downloaded newer image for msr.example.com/user/image@sha256:ee7491c9c31db1ffb7673d91e9fac5d6354a89d0e97408567e09df069a1687c1

Open Source Components and Licenses¶

Click any product component license below to download a text file of that license to your local system.

Get Support¶

Mirantis Container Runtime (MCR) subscriptions provide access to prioritized support for designated contacts from your company, agency, team, or organization. MCR service levels are based on your subscription level and the cloud or cluster that you designate in your technical support case. Our support offerings are described on the Enterprise-Grade Cloud Native and Kubernetes Support page. You may inquire about Mirantis support subscriptions by using the contact us form.

The CloudCare Portal is the primary way that Mirantis interacts with customers who are experiencing technical issues. Access to the CloudCare Portal requires prior authorization by your company, agency, team, or organization, and a brief email verification step. After Mirantis sets up its backend systems at the start of the support subscription, a designated administrator at your company, agency, team, or organization, can designate additional contacts. If you have not already received and verified an invitation to our CloudCare Portal, contact your local designated administrator, who can add you to the list of designated contacts. Most companies, agencies, teams, and organizations have multiple designated administrators for the CloudCare Portal, and these are often the persons most closely involved with the software. If you do not know who your local designated administrator is, or you are having problems accessing the CloudCare Portal, you may also send an email to Mirantis support at support@mirantis.com.

Once you have verified your contact details and changed your password, you and all of your colleagues will have access to all of the cases and resources purchased. Mirantis recommends that you retain your Welcome to Mirantis email, because it contains information on how to access the CloudCare Portal, guidance on submitting new cases, managing your resources, and other related issues.

We encourage all customers with technical problems to use the knowledge base, which you can access on the Knowledge tab of the CloudCare Portal. We also encourage you to review the MKE product documentation and release notes prior to filing a technical case, as the problem may already be fixed in a later release or a workaround solution provided to a problem experienced by other customers.

One of the features of the CloudCare Portal is the ability to associate cases with a specific MKE cluster. These are referred to in the Portal as “Clouds”. Mirantis pre-populates your customer account with one or more Clouds based on your subscription(s). You may also create and manage your Clouds to better match how you use your subscription.

Mirantis also recommends and encourages customers to file new cases based on a specific Cloud in your account. This is because most Clouds also have associated support entitlements, licenses, contacts, and cluster configurations. These greatly enhance the ability of Mirantis to support you in a timely manner.

You can locate the existing Clouds associated with your account by using the Clouds tab at the top of the portal home page. Navigate to the appropriate Cloud and click on the Cloud name. Once you have verified that the Cloud represents the correct MKE cluster and support entitlement, you can create a new case via the New Case button near the top of the Cloud page.

One of the key items required for technical support of most MKE cases is the support bundle. This is a compressed archive in ZIP format of configuration data and log files from the cluster. There are several ways to gather a support bundle, each described in the paragraphs below. After you obtain a support bundle, you can upload the bundle to your new technical support case by following the instructions in the Mirantis knowledge base, using the Detail view of your case.

Obtain a full-cluster support bundle using the MKE web UI¶

Log in to the MKE web UI as an administrator.
In the left-side nagivation panel, navigate to <user name> and click Support Bundle.

It may take several minutes for the download to complete.

Note

The default name for the generated support bundle file is docker-support-<cluster-id>-YYYYmmdd-hh_mm_ss.zip. Mirantis suggests that you not alter the file name before submittal to the customer portal. However, if necessary, you can add a custom string between docker-support and <cluster-id>, as in: docker-support-MyProductionCluster-<cluster-id>-YYYYmmdd-hh_mm_ss.zip.
Submit the support bundle to Mirantis by clicking Share support bundle on the success prompt that displays when the support bundle finishes downloading.

Note

Mirantis uses the support bundles you submit for product improvement purposes. Be aware, though that these submissions are not sent directly to the Mirantis Customer Support team that is assigned to the particular issue.
Fill in the Jira feedback dialog, and click Submit.

Obtain a single-node support bundle using the CLI¶

Use SSH to log into a node and run:

MKE_VERSION=$((docker container inspect ucp-proxy \
--format '{{index .Config.Labels "com.docker.ucp.version"}}' \
2>/dev/null || echo -n 3.8.0)|tr -d [[:space:]])

docker container run --rm \
  --name ucp \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --log-driver none \
  mirantis/ucp:${MKE_VERSION} \
  support > \
  docker-support-${HOSTNAME}-$(date +%Y%m%d-%H_%M_%S).tgz

Important

If SELinux is enabled, include the following additional flag: --security-opt label=disable.

Note

The CLI-derived support bundle only contains logs for the node on which you are running the command. If your MKE cluster is highly available, collect support bundles from all manager nodes.

Add the --submit option to the support command to submit the support bundle to Mirantis Customer Support. The support bundle will be sent, along with the following information:
- Cluster ID
- MKE version
- MCR version
- OS/architecture
- Cluster size
Note

Mirantis uses the support bundles you submit for product improvement purposes. Be aware, though that these submissions are not sent directly to the Mirantis Customer Support team that is assigned to the particular issue.

For more information on the support command, refer to mke-cli-support.

Use PowerShell to obtain a support bundle¶

Run the following command on Windows worker nodes to collect the support information and automatically place it in a zip file:

$MKE_SUPPORT_DIR = Join-Path -Path (Get-Location) -ChildPath 'dsinfo'
$MKE_SUPPORT_ARCHIVE = Join-Path -Path (Get-Location) -ChildPath $('docker-support-' + (hostname) + '-' + (Get-Date -UFormat "%Y%m%d-%H_%M_%S") + '.zip')
$MKE_PROXY_CONTAINER = & docker container ls --filter "name=ucp-proxy" --format "{{.Image}}"
$MKE_REPO = if ($MKE_PROXY_CONTAINER) { ($MKE_PROXY_CONTAINER -split '/')[0] } else { 'mirantis' }
$MKE_VERSION = if ($MKE_PROXY_CONTAINER) { ($MKE_PROXY_CONTAINER -split ':')[1] } else { '3.6.0' }
docker container run --name windowssupport `
-e UTILITY_CONTAINER="$MKE_REPO/ucp-containerd-shim-process-win:$MKE_VERSION" `
-v \\.\pipe\docker_engine:\\.\pipe\docker_engine `
-v \\.\pipe\containerd-containerd:\\.\pipe\containerd-containerd `
-v 'C:\Windows\system32\winevt\logs:C:\eventlogs:ro' `
-v 'C:\Windows\Temp:C:\wintemp:ro' $MKE_REPO/ucp-dsinfo-win:$MKE_VERSION
docker cp windowssupport:'C:\dsinfo' .
docker rm -f windowssupport
Compress-Archive -Path $MKE_SUPPORT_DIR -DestinationPath $MKE_SUPPORT_ARCHIVE

Release Notes¶

Important

Mirantis Container Runtime 25.0 follows the version numbering scheme of the upstream Moby and Docker CLI projects. Mirantis may skip upstream versions released in short succession, though, and opt instead to release a patch that contains the content of all upstream versions released in the intervening period since the previous MCR 25.0 patch release.
Users running MSR 2.9.16 or earlier must upgrade to MSR 2.9.17 or later before upgrading to MCR 25.0.

MCR 25.0.7 current

Initial release of MCR 25.0.x, which introduces the following features and improvements:

Alternative OCI Runtimes
Container Device Interface (CDI) support
OpenTelemetry tracing
Overhaul of release versioning and packaging
FIPS changes
Changes to MCR telemetry

Learn more

25.0.7¶

Release date	Name	Upstream release
2024-DEC-04	MCR 25.0.7	Moby 25.0.7 and Docker CLI 25.0.7

Highlights¶

Enhancement	Detail
Alternative OCI Runtimes	MCR now incorporates upstream changes that allow for alternative OCI runtimes with cri-dockerd. Thus, users can now create containers with compatible alternative runtimes, such as Kata or gVisor.
Container Device Interface (CDI) support	MCR now supports the Container Device Interface (CDI) on Linux platforms, which allows for the automation of a copious amount of device configuration through the use of spec files. Note CDI is an experimental feature that must be manually enabled through the setting of the feature flag in the daemon.json file.
OpenTelemetry tracing	MCR supports tracing through Engine API requests using OpenTelemetry, allowing for the configuration of OpenTelemetry through the use of its common environment variables. For information on how to use this feature, refer to the official OpenTelemetry documentation.

Changelog¶

MCR 25.0.7 comprises the Moby 25.0.7 upstream release. In addition, changes are included for the interceding upstream 24.0 release, for which there was no MCR release.

Changes specific to MCR¶

Overhaul of release versioning and packaging
- Greater emphasis and differentiation is now placed on Product Version versus Major component versions. Product Version is based on the upstream engine release version, but is distinct from it.
- Major Linux releases are no longer published to the stable channel and must instead be installed from their major version specific channel. This change greatly reduces the chance of performing accidental upgrades between major releases.
  - MCR 25.0.7 is installed from the stable-25.0 channel.
  - Windows releases continue to be published to the stable channel.
- MCR components are built from soft-forks of upstream projects, which combine an upstream software release with patches that Mirantis maintains. Such components can be identified by a software version in which the patch version indicator is followed by the character m and another number. This is the m-revision, the revision of the Mirantis patch set for the given upstream release of the software.
  
  Note
  
  Several software components are built from unmodified upstream sources. These components use the upstream version directly, and can be identified by their lack of an m-revision component.
FIPS changes
- All MCR 25.0.x releases are provided in two types.
  - The FIPS-mode MCR type always operates in a FIPS 140-2 compliant mode.
  - The non-FIPS MCR type cannot be configured to operate in a FIPS 140-2 compliant mode of operation.
- Installing the FIPS-mode MCR type requires the use of a FIPS channel, which for MCR 25.0.7 is stable-25.0/fips. A similar pattern will persist through future MCR releases.
- FIPS binaries can be identified by +fips in the package or software version. Some packages, such as runc, do not have a specific +fips version, while some packages, such as containerd shims, contain non- +fips binaries. This is both normal and expected, as +fips versions are built only for packages that use cryptography.
MCR telemetry changes
- Users can no longer disable telemetry for MCR instancees that are unlicensed. This includes cases wherein the license is expired or malformed. In the event that the user has configured telemetry to be disabled, MCR will ignore the configuration and print an ERROR level message to the daemon logs.

Changes from upstream¶

The upstream pull requests detailed in the sections that follow are those that pertain to the MCR product. For the complete list of changes and pull requests upstream, refer to the GitHub milestones.

Bug fixes and enhancements

docker/cli#4214 The docker stack command no longer validates the build section of Compose files.
moby/moby#43739 Fix lingering healthcheck processes after timeout is reached.
moby/moby#44285 Reduce the overhead of container startup when using the overlay2 storage driver.
moby/moby#44503 API: Handle multiple before= and since= filters in GET /images.
moby/moby#44664 Fix numerous bugs in the embedded DNS resolver implementation used by user-defined networks.
moby/moby#45494 Add execDuration field to the map of event attributes.
moby/swarmkit#3121, moby/moby#45291 Swarm-level networks can now be created with the Windows internal, l2bridge, and nat drivers.
moby/moby#45573 Fix an issue where DNS query NXDOMAIN replies from external servers were forwarded to the client as SERVFAIL.
moby/moby#45562 Fix an issue where docker pull --platform would report No such image regarding another tag pointing to the same image.
moby/moby#45571 Fix an issue where insecure registry configuration would be forgotten during config reload.
moby/moby#45568 API: Fix an issue where POST /commit did not accept empty request body.
moby/moby#45620 Fix builds potentially failing with exit code: 4294967295 when performing many concurrent build stages.
moby/moby#45810 Fix a Swarm CSI issue where the Topology field was not propagated into NodeCSIInfo.
moby/moby#45703, moby/swarmkit#3122, moby/swarmkit#3128 Fix failures to add new Swarm managers caused by a very large raft log.
moby/moby#45824 name_to_handle_at(2) is now always allowed in the default seccomp profile.
moby/moby#45637 Fix an issue that prevented encrypted Swarm overlay networks from working on ports other than the default (4789).
moby/moby#45643 Fix an exception caused by attaching a terminal to an exec with a non-existent command.
moby/moby#45790 Fix host-gateway with BuildKit by passing the IP as a label (also requires docker/buildx#1894).
moby/moby#45774 Fix an issue where POST /containers/{id}/stop would forcefully terminate the container when the request was canceled, instead of waiting until the specified timeout for a ‘graceful’ stop.
moby/moby#45746 Improve compatibility with non-runc container runtimes by more correctly setting resource constraint parameters in the OCI config.
moby/moby#45747, rootless-containers/rootlesskit#369 Fix an issue caused by overlapping subuid/subgid ranges in certain configurations (e.g. LDAP) in rootless mode.
moby/moby#45856 Greatly reduce CPU and memory usage while populating the Debug section of GET /info.
docker/cli#4393 Fix an issue where debug information was not correctly printed during docker info when only the client is in debug mode.
docker/cli#4395 Fix issues related to hung connections when connecting to hosts over an SSH connection.
docker/cli#4423 Properly report errors parsing volume specifications from the command line.
docker/cli#4450 Fix a panic caused when auths: null is found in the CLI config file.
moby/moby#46137 Warn when pulling Docker Image Format v1, and Docker Image manifest version 2, schema 1 images from all registries.
moby/moby#46366 Fix live-restore of volumes with custom volume options.
moby/moby#46214 Fix network isolation iptables rules preventing IPv6 Neighbor Solicitation packets from being exchanged between containers.
moby/moby#46215 Fix dockerd.exe --register-service not working when the binary is in the current directory on Windows.
docker/cli#4500 Add a hint suggesting the use of a PAT to docker login against Docker Hub.
docker/cli#4517 Improve shell startup time for users of Bash completion for the CLI.
docker/cli#4508 Improve the speed of some commands by skipping GET /_ping when possible.
docker/cli#4512 Fix credential scopes when using a PAT to docker manifest inspect an image on Docker Hub.
docker/cli#4544 Fix docker events not supporting --format=json.
moby/moby#46703 Write overlay2 layer metadata atomically.
moby/moby#46564 Fix “Rootful-in-Rootless” Docker-in-Docker on systemd version 250 and later.
moby/moby#44395 Fix dockerd-rootless-setuptools.sh when username contains a backslash.
moby/moby#46651 Fix a bug that would prevent network sandboxes to be fully deleted when stopping containers with no network attachments and when dockerd --bridge=none is used.
moby/moby#46700 Fix data corruption with zstd output.
moby/moby#46406 Fix the conditions under which the container’s MAC address is applied.
moby/moby#46448 Improve the performance of the stats collector.
moby/moby#46857 Live restore: Containers with auto remove (docker run --rm) are no longer forcibly removed on engine restart.
moby/moby#46352 API: Fix error message for invalid policies at ValidateRestartPolicy.
moby/moby#45847 API: Update /info endpoint to use singleflight.
docker/cli#4346 Add an error message for when specifying a Dockerfile filename with -f, and also using stdin.
docker/cli#4419 Add support for mac-address and link-local-ip fields in --network long format.
moby/moby#45906 Add support for specifying multiple --network flags with docker container create and docker run.
moby/moby#46455 Automatically enable IPv6 on a network when an IPv6 subnet is specified.
moby/moby#46790 Add support for overlay networks over IPv6 transport.
moby/moby#43980 Configuration reloading is now more robust: if there’s an error during the configuration reload process, no configuration changes are applied.
moby/moby#47051 Live restore: containers that are live-restored will now be given another health-check start period when the daemon restarts.
moby/moby#47044 Container health status is flushed to disk less frequently, reducing wear on flash storage.
moby/moby#46251 Ensure network names are unique.
moby/moby#46471 Ensure that overlay2 layer metadata is correct.
moby/moby#46515 Fix Downloading progress message on image pull.
moby/moby#46183 Fix NetworkConnect and ContainerCreate with improved data validation, and return all validation errors at once.
moby/moby#46446 Fix com.docker.network.host_ipv4 option when IPv6 and ip6tables are enabled.
moby/moby#46213 Fix daemon’s cleanupContainer if containerd is stopped.
moby/moby#46146 Fix returning incorrect HTTP status codes for libnetwork errors.
moby/moby#46034 Fix various issues with images/json API filters and image list.
moby/moby#46863 CIFS volumes now resolves FQDN correctly.
moby/moby#47000 Improve validation of the userland-proxy-path daemon configuration option. Validation now happens during daemon startup, instead of producing an error when starting a container with port-mapping.
moby/moby#46406 Set the MAC address of container’s interface when network mode is a short network ID.
moby/moby#45917 Sort unconsumed build arguments before display in build output.
moby/moby#44598 The docker image save tarball output is now OCI compliant.
moby/moby#45280 The daemon no longer appends ACCEPT rules to the end of the INPUT iptables chain for encrypted overlay networks. Depending on firewall configuration, a rule may be needed to permit incoming encrypted overlay network traffic.
moby/moby#45464 Unpacking layers with extended attributes onto an incompatible filesystem will now fail instead of silently discarding extended attributes.
moby/moby#45887 Update daemon MTU option to BridgeConfig and display warning on Windows.
moby/moby#45759 Validate IPAM config when creating a network. Automatically fix networks created prior to this release where --ip-range is larger than --subnet.
moby/moby#46603 Containers connected only to internal networks will now have no default route set, making the connect syscall fail-fast.
moby/moby#47136 Fix an issue in detecting whether a remote build context is a Git repository.
moby/moby#47163 Swarm: Fixed start_interval not being passed to the container config.
moby/moby#47304 Ensure that a generated MAC address is not restored when a container is restarted, but a configured MAC address is preserved.
moby/moby#47294 Fix docker save <image>@<digest> producing an OCI archive with index without manifests.
moby/moby#47323 Fix a bug where trying to install a plugin using a digest revision would cause a panic.
moby/moby#47243 Fix an issue with the journald log driver preventing container logs from being followed correctly with systemd version 255.
moby/moby#47341 seccomp: Update the builtin seccomp profile to include syscalls added in kernel v5.17 - v6.7 to align the profile with the profile used by containerd.
moby/moby#47307, moby/moby#47337 Windows: Fix cache not being used when building images based on Windows versions older than the host’s version.
moby/moby#47466 Fix docker start failing when used with --checkpoint
moby/moby#47393 API: To preserve backwards compatibility, make read-only mounts non-recursive by default when using older clients (API versions < v1.44).
moby/moby#47451 API: GET /images/{id}/json omits the Created field (previously it was 0001-01-01T00:00:00Z) if the Created field was missing from the image config.
moby/moby#47387 API: Populate a missing Created field in GET /images/{id}/json with 0001-01-01T00:00:00Z for API versions <= 1.43.
moby/moby#47470 API: Fix a regression that caused API socket connection failures to report an API version negotiation failure instead.
moby/moby#47527 Fix multiple parallel docker build runs leaking disk space.
moby/moby#47589 CVE-2024-29018: Do not forward requests to external DNS servers for a container that is only connected to an ‘internal’ network. Previously, requests were forwarded if the host’s DNS server was running on a loopback address, like systemd’s 127.0.0.53.

GitHub milestones¶

The GitHub milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 24.0 and 25.0 releases.

Major component versions¶

Version detail for the major components that comprise MCR 25.0.7 is presented in the table below:

Component	Upstream Version	Mirantis Version
Moby	25.0.7	25.0.7m1
Docker CLI	25.0.7	25.0.7m1
containerd	1.7.23	1.7.23m1
runc	1.5.15	1.5.15m1
cri-dockerd	0.3.0	–
buildx	0.12.1	0.12.1m1
Fipster (Go runtime)	go1.22.9-m1	–
buildkit	0.12.5	–
rootlesskit	2.0.2	–

Release Compatibility Matrix¶

MCR 25.0 Compatibility Matrix¶

Mirantis Container Runtime (MCR) enables containers to run efficiently on any substrate, powering business critical applications at leading companies worldwide.

Mirantis validates MCR for the operating system environments specified here, adhering to the MKE, MSR, and MCR Maintenance Lifecycle. Support for MCR is defined in the Mirantis Cloud Native Platform Subscription Services agreement.

Note

Users running MSR 2.9.16 or earlier must upgrade to MSR 2.9.17 or later before upgrading to MCR 25.0.x.
MKE 3.5.x and 3.4.x do not support Windows Server 2022.
OS distributed versions not listed in the following matrix are not supported under Standard Support Subscriptions. For such versions, contact your Mirantis rep to discuss support options.

MCR	Max. supported Client API	Platform	Versions
25.0.7	1.44	Oracle Linux 1	9.3, 9.2, 9.1, 9.0, 8,6
		RHEL	9.4, 9.3, 9.2, 9.1, 9.0, 8.10, 8.9, 8.8, 8.7, 8.6, 8.5, 8.4, 8.3, 8.2, 8.1, 8.0
		Rocky Linux	9.2, 9.1, 9.0, 8.8, 8.7
		SLES	15 SP6, 15 SP5
		Ubuntu	22.04.3, 20.04.6, 20.04.5, 20.04.4 2, 20.04.3, 20.04.2, 20.04.1, 20.04.0
		Microsoft Windows Enterprise Server	2022, 2019

1: Regarding the Oracle Linux kernel, only Red Hat Compatible Kernel (RHCK) is supported. Unbreakable Enterprise Kernel (UEK) is not supported.
2: A known critical issue is present in the 5.13.0-1028-aws and 5.13.0-1029-aws kernels of the Ubuntu AMIs on AWS. The issue was resolved in the 5.13.0-1030-aws kernel. If you are an AWS user, refer to Docker container creation causes kernel oops on linux-aws 5.13.0.1028.31~20.04.22 and Docker container ports cannot be allocated, otherwise check with your cloud provider.

MKE, MSR, and MCR Maintenance Lifecycle¶

The MKE, MSR, and MCR platform subscription provides software, support, and certification to enterprise development and IT teams that build and manage critical apps in production at scale. It provides a trusted platform for all apps which supply integrated management and security across the app lifecycle, comprised primarily of Mirantis Kubernetes Engine, Mirantis Secure Registry (MSR), and Mirantis Container Runtime (MCR).

Mirantis validates the MKE, MSR, and MCR platform for the operating system environments specified in the MCR compatibility matrix, adherring to the maintenance lifecycle detailed here. Support for the MKE, MSR, and MCR platform is defined in the Mirantis Cloud Native Platform Subscription Services agreement.

Detailed here are all currently supported product versions, as well as the product versions most recently deprecated. It can be assumed that all earlier product versions are at End of Life (EOL).

Important Definitions

“Major Releases” (X.y.z): Vehicles for delivering major and minor feature development and enhancements to existing features. They incorporate all applicable Error corrections made in prior Major Releases, Minor Releases, and Maintenance Releases.
“Minor Releases” (x.Y.z): Vehicles for delivering minor feature developments, enhancements to existing features, and defect corrections. They incorporate all applicable Error corrections made in prior Minor Releases, and Maintenance Releases.
“Maintenance Releases” (x.y.Z): Vehicles for delivering Error corrections that are severely affecting a number of customers and cannot wait for the next major or minor release. They incorporate all applicable defect corrections made in prior Maintenance Releases.
“End of Life” (EOL): Versions are no longer supported by Mirantis, updating to a later version is recommended.

Support lifecycle¶
GA to 12 months	12 to 18 months	18 to 24 months
Full support	Full support ¹	Limited Support for existing installations ²

¹ Software patches for critical bugs and security issues only; no feature enablement.

² Software patches for critical security issues only.

Mirantis Kubernetes Engine (MKE)¶

	3.7.z	3.8.z
General Availability (GA)	2023-AUG-30 (3.7.0)	2024-DEC-4 (3.8.0)
End of Life (EOL)	2025-AUG-29	2026-DEC-4
Release frequency	x.y.Z every 6 weeks	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MKE Versions¶

MKE Version	EOL date
2.0.z	2017-AUG-16
2.1.z	2018-FEB-07
2.2.z	2019-NOV-01
3.0.z	2020-APR-16
3.1.z	2020-NOV-06
3.2.z	2021-JUL-21
3.3.z	2022-MAY-27
3.4.z	2023-APR-11
3.5.z	2023-NOV-22
3.6.z	2023-OCT-13

Mirantis Secure Registry (MSR)¶

	2.9.z	3.1.z
General Availability (GA)	2021-APR-12 (2.9.0)	2023-SEP-28 (3.1.0)
End of Life (EOL)	2025-SEP-27	2025-SEP-27
Release frequency	x.y.Z every 6 weeks	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MSR Versions¶

MSR Version	EOL date
2.1.z	2017-AUG-16
2.2.z	2018-FEB-07
2.3.z	2019-FEB-15
2.4.z	2019-NOV-01
2.5.z	2020-APR-16
2.6.z	2020-NOV-06
2.7.z	2021-JUL-21
2.8.z	2022-MAY-27
3.0.z	2024-APR-20

Mirantis Container Runtime (MCR)¶

	Enterprise 23.0	Enterprise 25.0
General Availability (GA)	2023-FEB-23 (23.0.1)	2024-DEC-04 (25.0.7)
End of Life (EOL)	2025-JUNE-04	2026-DEC-04
Release frequency	x.y.Z every 6 weeks	x.y.Z every 6 weeks
Patch release content	As needed: Maintenance releases Security patches Custom hotfixes	As needed: Maintenance releases Security patches Custom hotfixes
Supported lifespan	2 years ¹	2 years ¹

¹ Refer to the Support lifecycle table for details.

EOL MCR Versions¶

MCR Version	EOL date
CSE 1.11.z	2017-MAR-02
CSE 1.12.z	2017-NOV-14
CSE 1.13.z	2018-FEB-07
EE 17.03.z	2018-MAR-01
Docker Engine - Enterprise v17.06	2020-APR-16
Docker Engine - Enterprise 18.03	2020-JUN-16
Docker Engine - Enterprise 18.09	2020-NOV-06
Docker Engine - Enterprise 19.03	2021-JUL-21
MCR 19.03.8+	2022-MAY-27
MCR 20.10.0+	2023-DEC-10

Release Cadence and Support Lifecycle¶

With the intent of improving the customer experience, Mirantis strives to offer maintenance releases for the Mirantis Container Runtime (MCR) software every six to eight weeks. Primarily, these maintenance releases will aim to resolve known issues and issues reported by customers, quash CVEs, and reduce technical debt. The version of each MCR maintenance release is reflected in the third digit position of the version number (as an example, for MCR 23.0 the most current maintenance release is MCR 25.0.7).

Regarding major releases, MCR is dependent on Docker Engine major releases upstream. Following such a release, the Mirantis support lifespan of the resulting major version of MCR will adhere to our legacy two year standard.

End of Life Date

For information on MCR version lifecycles, refer to the MKE, MSR, and MCR Maintenance Lifecycle.

As necessary, Mirantis may produce an MCR release between upstream releases. These so-called dash releases can contain hotfixes, packaging changes or depenency changes. In such cases, these dash releases replace the previous release of the same version (as an example, MCR 23.0.9-1 replaces MCR 23.0.9).

Note

In general, MCR dash releases for a particular patch version share the same OS and kernel compatibility.

The MCR team will make every effort to hold to the release cadence stated here. Customers should be aware, though, that development and release cycles can change, and without advance notice.

Technology Preview features¶

A Technology Preview feature provides early access to upcoming product innovations, allowing customers to experiment with the functionality and provide feedback.

Technology Preview features may be privately or publicly available and neither are intended for production use. While Mirantis will provide assistance with such features through official channels, normal Service Level Agreements do not apply.

As Mirantis considers making future iterations of Technology Preview features generally available, we will do our best to resolve any issues that customers experience when using these features.

During the development of a Technology Preview feature, additional components may become available to the public for evaluation. Mirantis cannot guarantee the stability of such features. As a result, if you are using Technology Preview features, you may not be able to seamlessly upgrade to subsequent product releases.

Mirantis makes no guarantees that Technology Preview features will graduate to generally available features.

QuickStart: MCR on Ubuntu¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Ubuntu systems from the repository.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on Ubuntu:

Set up the repository¶

To install MCR using the Mirantis repository you must first set up the repository on the host machine.

Note

MCR only supports x86_64/amd64.

Install the packages:

$ sudo apt update && sudo apt install curl gnupg

Add the official Docker GPG key:

$ sudo gpg --batch --yes \
  --output /usr/share/keyrings/mirantis-archive-keyring.pgp --dearmor \
  <<< $(curl -fsSL https://repos.mirantis.com/ubuntu/gpg)

Verify that the GPG key has the fingerprint DD91 1E99 5A64 A202 E859 07D6 BC14 F10B 6D08 5F96:

$ gpg --show-keys --with-fingerprint --keyid-format=short \
  /usr/share/keyrings/mirantis-archive-keyring.pgp

Expected output:

pub   rsa4096/6D085F96 2017-02-22 [SCEA]
     Key fingerprint = DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96
uid                    Docker Release (EE deb) <docker@docker.com>
sub   rsa4096/91A29FA3 2017-02-22 [S]

Add the repository to your sources.list. To do this, create a text file in /etc/apt/sources.list.d/mirantis.sources:

Types: deb
URIs: https://repos.mirantis.com/ubuntu
Suites: <value-depends-on-Ubuntu-version>
Architectures: amd64
Components: stable-25.0
Signed-by: /usr/share/keyrings/mirantis-archive-keyring.pgp

Note

The Suites parameter setting is jammy for Ubuntu 22.04 and focal for Ubuntu 20.04.

Install MCR¶

Install the latest version of MCR:
```
$ sudo apt update && sudo apt install docker-ee
```
The Docker daemon will start.

Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:

$ sudo docker run hello-world

Expected output:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs
    the executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which
    sent it to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.

Verify the installation:

sudo docker info --format '{{.ProductLicense}}'

What’s next¶

Refer to Install Mirantis Container Runtime for Ubuntu to learn about these additional installation topics:
- ubuntu-package-install
- ubuntu-upgrade
- Uninstall Mirantis Container Runtime (including old versions)
Begin using Docker Hub to find and share images.
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR).
Learn about all the components of Mirantis Cloud Native Platform.

QuickStart: MCR on Oracle Linux¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Oracle Linux systems from the repository.

Note

The documentation herein applies only to Oracle Linux 7. Mirantis does not support Oracle 8.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on Oracle Linux:

Set up the repository¶

To install MCR using the Mirantis repository you must first set up the repository on the host machine.

Note

MCR supports Oracle Linux on the x86_64 platform with Red Hat Compatible Kernel (RHCK).

Next, create or modify the /etc/yum.repos.d/docker-ee.repo file to contain the following:

[mirantis]
name=Mirantis Container Runtime
baseurl=https://repos.mirantis.com/oraclelinux/$releasever/$basearch/stable-25.0
enabled=1
gpgcheck=1
gpgkey=https://repos.mirantis.com/oraclelinux/gpg
module_hotfixes=true

Note

$releasever and $basearch are repo variables that must be placed into the /etc/yum.repos.d/docker-ee.repo file exactly as written.

Install MCR¶

Run the following command to install the latest verison of MCR from the repository:
```
$ sudo dnf install docker-ee
```
If you are prompted to accept the GPG key, first verify that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9.
Start Docker:
```
$ sudo systemctl start docker.service
```

Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:

$ sudo docker run hello-world

Expected output:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs
    the executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which
    sent it to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.

Verify the installation:

sudo docker info --format '{{.ProductLicense}}'

What’s next¶

Refer to Install Mirantis Container Runtime for Oracle Linux to learn about these additional installation topics:
- oracle-package-install
- oracle-upgrade-repo
- oracle-upgrade-package
- uninstall-mcr
Begin using Docker Hub to find and share images
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR)
Learn about other components of Mirantis Cloud Native Platform

QuickStart: MCR on RHEL¶

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Red Hat Enterprise Linux (RHEL) systems from the repository.

Introduction¶

MCR installations includes the following components:

MCR engine
MCR CLI
containerd
runc

After installing MCR, you will be able to:

Use Dockerfiles to build and run images as containers.
Share images using Docker Hub.
Run applications using Docker Compose.

The following diagram illustrates the workflow for installing MCR on RHEL:

Set up the repository¶

To install MCR using the Mirantis repository, you must first set up the repository on the host machine.

Note

MCR supports Red Hat Enterprise Linux (RHEL) on the x86_64 platform.

Create or modify the /etc/yum.repos.d/docker-ee.repo file to contain the following:

[mirantis]
name=Mirantis Container Runtime
baseurl=https://repos.mirantis.com/rhel/$releasever/$basearch/stable-25.0
enabled=1
gpgcheck=1
gpgkey=https://repos.mirantis.com/rhel/gpg
module_hotfixes=true

Note

$releasever and $basearch are repo variables that must be placed into the /etc/yum.repos.d/docker-ee.repo file exactly as written.

Install MCR¶

Run the following command to install the latest version of MCR from the repository:
```
$ sudo dnf install docker-ee
```
If you are prompted to accept the GPG key, first verify that the key has the fingerprint 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9.
Start Docker:
```
$ sudo systemctl start docker.service
```

Run the hello-world image to verify that MCR is correctly installed. This command downloads a test image, runs it in a container, prints an informational message, and exits:

$ sudo docker run hello-world

Expected output:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs
    the executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which
    sent it to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Install the license¶

An MCR license gives the user access to Mirantis Support. You can complete this guide and start using MCR right away, and install the license later.

To install the MCR license:

Purchase an MCR subscription or contact Mirantis for more information.
Follow the link to download your MCR license file found in the confirmation email you received after purchasing MCR from the Mirantis web store. If you cannot access your confirmation email, contact Mirantis.
Copy the file to the data root directory and name it docker.lic. The default data root directory is /var/lib/docker.

Verify the installation:

sudo docker info --format '{{.ProductLicense}}'

What’s next¶

Refer to Install Mirantis Container Runtime for Red Hat Enterprise Linux to learn about these additional installation topics:
- FIPS 140-2-support
- rhel-package-install
- rhel-repo-upgrade
- rhel-package-upgrade
- Uninstall Mirantis Container Runtime
Begin using Docker Hub to find and share images
Install Mirantis Kubernetes Engine (MKE) and Mirantis Secure Registry (MSR).
Learn about other components of Mirantis Cloud Native Platform.