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.

MCR 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.

MCR 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.

Install the license

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

Warning

Users are not authorized to run MCR on production workloads without a valid license. Refer to Mirantis Agreements and Terms for more information.

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

  1. Download the license file.

    License files purchased at the Mirantis web store are available using a link in the confirmation email. Otherwise, contact Mirantis Sales and Support to gain access to the file.

  2. Apply the license file.

    Platform

    Applying the license

    Linux distros

    1. Determine the location of the data root directory. This information is available in the daemon.json file associated with MCR. Alternatively, you can specify the data root directory using the --data-root flag at MCR start up. Note that the default data-root directory is var/lib/docker.

    2. Copy the license file to the data root directory and name it docker.lic. It is imperative that the license be readable by the account/user that runs the docker daemon.

    Windows servers

    A license is not currently required for Windows systems, as MCR Windows binaries installed through install.ps1 or MSFT one-get provider are considered to be licensed.

  3. Start MCR (or restart it, if MCR is already running).

Note

MKE, MSR, and Mirantis Container Cloud have implied MCR licenses.

Install MCR on Linux distros

Install Mirantis Container Runtime for CentOS

There are two ways to install and upgrade Mirantis Container Runtime (MCR):

  • YUM repository: Set up a Docker repository and install Mirantis Container Runtime from it. This is the recommended approach because installation and upgrades are managed with YUM and easier to do.

  • RPM package: Download the RPM package, install it manually, and manage upgrades manually. This is useful when installing Mirantis Container Runtime on air-gapped systems with no access to the internet.

Prerequisites

Perform all prerequisites as required prior to installing MCR on CentOS.

Architectures and storage drivers

Mirantis Container Runtime supports CentOS 64-bit, latest version, running on x86_64.

On CentOS, Mirantis Container Runtime supports the overlay2 storage drivers. The following limitations apply:

  • If selinux is enabled, overlay2 is supported on CentOS 7.4 or higher.

  • If selinux is disabled, overlay2 is supported on CentOS 7.2 or higher with kernel version 3.10.0-693 and higher.

Uninstall old Docker versions

The Mirantis Container Runtime package is called docker-ee. Older versions were called docker or docker-engine. Uninstall all older versions and associated dependencies. The contents of /var/lib/docker/ are preserved, including images, containers, volumes, and networks.

sudo yum remove docker \
                docker-client \
                docker-client-latest \
                docker-common \
                docker-latest \
                docker-latest-logrotate \
                docker-logrotate \
                docker-selinux \
                docker-engine-selinux \
                docker-engine
Repo install and upgrade

The advantage of using a repository from which to install Mirantis Container Runtime (or any software) is that it provides a certain level of automation. RPM-based distributions such as CentOS, use a tool called YUM that work with your repositories to manage dependencies and provide automatic updates.

Set up the repository

You only need to set up the repository once, after which you can install Mirantis Container Runtime from the repo and repeatedly upgrade as necessary.

  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Temporarily store http://repos.mirantis.com in an environment variable. This variable assignment does not persist when the session ends:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of the variable, DOCKERURL (from the previous step), in a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/centos" > /etc/yum/vars/dockerurl'
    
  4. Store your OS version string in /etc/yum/vars/dockerosversion:

    sudo sh -c 'echo "7" > /etc/yum/vars/dockerosversion'
    
  5. Install the yum-utils that provides the yum-config-manager utility.

    sudo yum install -y yum-utils
    
  6. Enable the extras RHEL repository. This ensures access to the container-selinux package required by docker-ee.

    The repository can differ per your architecture and cloud provider , so review the options in this step before running one of the following commands.

    For all architectures except IBM Power

    sudo yum-config-manager --enable rhel-7-server-extras-rpms
    

    For IBM Power only (little endian)

    sudo yum-config-manager --enable extras
    sudo subscription-manager repos --enable=rhel-7-for-power-le-extras-rpms
    sudo yum makecache fast
    sudo yum -y install container-selinux
    
  7. Depending on cloud provider, you may also need to enable another repository.

    For AWS (where REGION is a literal, and does not represent the region your machine is running in):

    sudo yum install -y rh-amazon-rhui-client
    sudo yum-config-manager --enable rhui-REGION-rhel-server-extras
    

    For Azure

    sudo yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
    
  8. Add the Mirantis Container Runtime stable repository:

    sudo -E yum-config-manager \
        --add-repo \
        "$DOCKERURL/centos/docker-ee.repo"
    
Install from the repository
  1. Install the latest patch release, or go to the next step to install a specific version:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9, and if so, accept it.

  2. To install a specific version of Mirantis Container Runtime (recommended in production), list versions and install:

    1. List and sort the versions available in your repo. This example sorts results by version number, highest to lowest, and is truncated:

      sudo yum list docker-ee  --showduplicates | sort -r
      
      docker-ee.x86_64      20.10.ee.2-1.el7.centos      docker-ee-stable-19.03
      

      The list returned depends on which repositories you enabled, and is specific to your version of CentOS (indicated by .el7 in this example).

    2. Install a specific version by its fully qualified package name, which is the package name (docker-ee) plus the version string (2nd column) starting at the first colon (:), up to the first hyphen, separated by a hyphen (-). For example, docker-ee-19.03.8.

      sudo yum -y install docker-ee-<VERSION_STRING> docker-ee-cli-<VERSION_STRING> containerd.io
      

      For example, if you want to install the 19.03.8 version run the following:

      sudo yum -y install docker-ee-19.03.8 docker-ee-cli-19.03.8 containerd.io
      

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  3. Start Docker:

    sudo systemctl start docker
    
  4. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is installed and running. Use sudo to run Docker commands.

Package install and upgrade

To manually install MCR, download the .rpm file for your release. You need to download a new file each time you want to upgrade MCR.

Install with a package
  1. Go to repos.mirantis.com in your browser.

  2. Navigate to centos/7/x86_64/stable-<VERSION>/Packages and download the .rpm file for the Docker version you want to install.

  3. Install MCR.

    sudo yum install <path_to_downloaded_centos_package_.rpm>
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  4. Start Docker

    sudo systemctl start docker
    
  5. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is installed and running. Use sudo to run Docker commands.

Upgrade with a package
  1. Download the newer package file.

  2. Repeat the installation procedure, using yum -y upgrade instead of yum -y install, and point to the new file.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall Mirantis Container Runtime
  1. Uninstall the Mirantis Container Runtime package:

    sudo yum -y remove docker-ee
    
  2. Delete all images, containers, and volumes (because these are not automatically removed from your host):

    sudo rm -rf /var/lib/docker
    
  3. Delete other Docker related resources:

    sudo rm -rf /run/docker
    sudo rm -rf /var/run/docker
    sudo rm -rf /etc/docker
    
  4. Delete any edited configuration files manually.

Install Mirantis Container Runtime for Oracle Linux

There are two ways to install and upgrade Mirantis Container Runtime (MCR).

  • YUM repository: Set up a Docker repository and install Mirantis Container Runtime from it. This is the recommended approach because installation and upgrades are managed with YUM and easier to do.

  • RPM package: Download the RPM package, install it manually, and manage upgrades manually. This is useful when installing Mirantis Container Runtime on air-gapped systems with no access to the internet.

Prerequisites

Perform all prerequisites as required prior to installing MCR on Oracle Linux.

Architectures and storage drivers

Mirantis Container Runtime supports Oracle Linux 64-bit, versions 7.3 and higher, running the Red Hat Compatible kernel (RHCK) 3.10.0-514 or higher. Older versions of Oracle Linux are not supported.

On Oracle Linux, Mirantis Container Runtime only supports the devicemapper storage driver. In production, you must use it in direct-lvm mode, which requires one or more dedicated block devices. Fast storage such as solid-state media (SSD) is recommended.

Uninstall old Docker versions

The Mirantis Container Runtime package is called docker-ee. Older versions were called docker or docker-engine. Uninstall all older versions and associated dependencies. The contents of /var/lib/docker/ are preserved, including images, containers, volumes, and networks.

sudo yum remove docker \
                docker-engine \
                docker-engine-selinux
Repo install and upgrade

The advantage of using a repository from which to install Mirantis Container Runtime (or any software) is that it provides a certain level of automation. RPM-based distributions such as Oracle Linux, use a tool called YUM that work with your repositories to manage dependencies and provide automatic updates.

Set up the repository

You only need to set up the repository once, after which you can install Mirantis Container Runtime from the repo and repeatedly upgrade as necessary.

  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Temporarily store http://repos.mirantis.com in an environment variable. This variable assignment does not persist when the session ends:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of the variable, DOCKERURL (from the previous step), in a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/oraclelinux" > /etc/yum/vars/dockerurl'
    
  4. Install required packages: yum-utils provides the yum-config-manager utility, and device-mapper-persistent-data and lvm2 are required by the devicemapper storage driver:

    sudo yum install -y yum-utils \
    device-mapper-persistent-data \
    lvm2
    
  5. Enable the ol7_addons Oracle repository. This ensures access to the container-selinux package required by docker-ee.

    sudo yum-config-manager --enable ol7_addons
    
  6. Add the Mirantis Container Runtime stable repository:

    sudo -E yum-config-manager \
      --add-repo \
      "$DOCKERURL/oraclelinux/docker-ee.repo"
    
Install from the repository
  1. Install the latest patch release, or go to the next step to install a specific version:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9, and if so, accept it.

  2. To install a specific version of Mirantis Container Runtime (recommended in production), list versions and install:

    1. List and sort the versions available in your repo. This example sorts results by version number, highest to lowest, and is truncated:

      sudo yum list docker-ee  --showduplicates | sort -r
      
      docker-ee.x86_64      20.10.ee.2-1.el7.oraclelinux      docker-ee-stable-18.09
      

      The list returned depends on which repositories you enabled, and is specific to your version of Oracle Linux (indicated by .el7 in this example).

    2. Install a specific version by its fully qualified package name, which is the package name (docker-ee) plus the version string (2nd column) starting at the first colon (:), up to the first hyphen, separated by a hyphen (-). For example, docker-ee-18.09.1.

      sudo yum -y install docker-ee-<VERSION_STRING> docker-ee-cli-<VERSION_STRING> containerd.io
      

      For example, if you want to install the 19.03 version run the following:

      sudo yum-config-manager --enable docker-ee-stable-19.03
      

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  3. Start Docker:

    sudo systemctl start docker
    
  4. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is installed and running. Use sudo to run Docker commands.

Upgrade from the repository
  1. Add the new repository.

  2. Follow the installation instructions and install a new version.

Package install and upgrade

To manually install MCR, download the .rpm file for your release. You need to download a new file each time you want to upgrade MCR.

Install with a package
  1. Go to repos.mirantis.com in your browser.

  2. Navigate to oraclelinux/. Choose your Oracle Linux version, architecture, and Docker version. Download the .rpm file from the Packages directory.

  3. Install MCR.

    sudo yum install <path_to_downloaded_oracle_package_.rpm>
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  4. Start Docker:

    sudo systemctl start docker
    
  5. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is installed and running. Use sudo to run Docker commands.

Upgrade with a package
  1. Download the newer package file.

  2. Repeat the installation procedure, using yum -y upgrade instead of yum  -y install, and point to the new file.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall Mirantis Container Runtime
  1. Uninstall the Mirantis Container Runtime package:

    sudo yum -y remove docker-ee
    
  2. Delete all images, containers, and volumes (because these are not automatically removed from your host):

    sudo rm -rf /var/lib/docker
    
  3. Delete other Docker related resources:

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

  4. If desired, remove the devicemapper thin pool and reformat the block devices that were part of it.

You must delete any edited configuration files manually.

Install Mirantis Container Runtime for Red Hat Enterprise Linux

There are two ways to install and upgrade Mirantis Container Runtime (MCR).

  • YUM repository: Set up a Docker repository and install Mirantis Container Runtime from it. This is the recommended approach because installation and upgrades are managed with YUM and easier to do.

  • RPM package: Download the RPM package, install it manually, and manage upgrades manually. This is useful when installing Mirantis Container Runtime on air-gapped systems with no access to the internet.

Prerequisites

Perform all prerequisites as required prior to installing MCR on Red Hat Enterprise Linux.

Architectures and storage drivers

Mirantis Container Runtime supports Red Hat Enterprise Linux 64-bit, versions 7.4 and higher running on x86_64. See the MKE, MSR, and MCR Compatibility Matrix for specific details.

On Red Hat Enterprise Linux, Mirantis Container Runtime supports the overlay2 storage driver. The following limitations apply:

  • OverlayFS: If selinux is enabled, the overlay2 storage driver is supported on RHEL 7.4 or higher.

  • If selinux is disabled, overlay2 is supported on RHEL 7.2 or higher with kernel version 3.10.0-693 and higher.

FIPS 140-2 cryptographic module support

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

With Mirantis Container Runtime license for versions 18.03 and later, Docker provides FIPS 140-2 support in RHEL 7.3, 7.4 and 7.5. This includes a FIPS supported cryptographic module. If the RHEL implementation already has FIPS support enabled, FIPS is also automatically enabled in MCR. If FIPS support is not already enabled in your RHEL implementation, see the Red Hat Product Documentation for instructions on how to enable it.

To verify the FIPS 140-2 module is enabled in the Linux kernel, confirm the file /proc/sys/crypto/fips_enabled contains 1.

cat /proc/sys/crypto/fips_enabled
1

Note

FIPS is only supported in Mirantis Container Runtime. MKE and MSR currently do not have support for FIPS 140-2.

You can override FIPS 140-2 compliance on a system that is not in FIPS 140-2 mode. Note, this does not change FIPS 140-2 mode on the system. To override the FIPS 140-2 mode, follow ths steps below.

Create a file called /etc/systemd/system/docker.service.d/fips-module.conf. Add the following:

[Service]
Environment="DOCKER_FIPS=1"

Reload the Docker configuration to systemd.

sudo systemctl daemon-reload

Restart the Docker service as root.

sudo systemctl restart docker

To confirm Docker is running with FIPS 140-2 enabled, run the docker info command.

Disabling FIPS 140-2

If the system has the FIPS 140-2 cryptographic module installed on the operating system, it is possible to disable FIPS 140-2 compliance.

To disable FIPS 140-2 in Docker but not the operating system, set the value DOCKER_FIPS=0 in the /etc/systemd/system/docker.service.d/fips-module.conf.

Reload the Docker configuration to systemd.

sudo systemctl daemon-reload

Restart the Docker service as root.

sudo systemctl restart docker

Uninstall old Docker versions

The Mirantis Container Runtime package is called docker-ee. Older versions were called docker or docker-engine. Uninstall all older versions and associated dependencies. The contents of /var/lib/docker/ are preserved, including images, containers, volumes, and networks.

sudo yum remove docker \
                docker-client \
                docker-client-latest \
                docker-common \
                docker-latest \
                docker-latest-logrotate \
                docker-logrotate \
                docker-selinux \
                docker-engine-selinux \
                docker-engine
Repo install and upgrade

The advantage of using a repository from which to install Mirantis Container Runtime (or any software) is that it provides a certain level of automation. RPM-based distributions such as Red Hat Enterprise Linux, use a tool called YUM that work with your repositories to manage dependencies and provide automatic updates.

Set up the repository

You only need to set up the repository once, after which you can install Mirantis Container Runtime from the repo and repeatedly upgrade as necessary.

  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Temporarily store http://repos.mirantis.com in an environment variable. This variable assignment does not persist when the session ends:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of the variable, DOCKERURL (from the previous step), in a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'
    

    Also, store your OS version string in /etc/yum/vars/dockerosversion. Most users should use 7 or 8, but you can also use the more specific minor version, starting from 7.2.

    sudo sh -c 'echo "7" > /etc/yum/vars/dockerosversion'
    
  4. Install the yum-utils that provides the yum-config-manager utility.

    sudo yum install -y yum-utils
    
  5. Enable the extras RHEL repository. This ensures access to the container-selinux package required by docker-ee.

    The repository can differ per your architecture and cloud provider, so review the options in this step before running:

    For all architectures except IBM Power:

    sudo yum-config-manager --enable rhel-7-server-extras-rpms
    

    For IBM Power only (little endian):

    sudo yum-config-manager --enable extras
      sudo subscription-manager repos --enable=rhel-7-for-power-le-extras-rpms
      sudo yum makecache fast
      sudo yum -y install container-selinux
    

    Depending on cloud provider, you may also need to enable another repository:

    For AWS (where REGION is a literal, and does not represent the region your machine is running in):

    sudo yum install -y rh-amazon-rhui-client
    
    sudo yum-config-manager --enable rhui-REGION-rhel-server-extras
    

    For Azure:

    sudo yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
    

    Add the Mirantis Container Runtime stable repository:

    sudo -E yum-config-manager \
         --add-repo \
         "$DOCKERURL/rhel/docker-ee.repo"
    
  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Temporarily store http://repos.mirantis.com in an environment variable. This variable assignment does not persist when the session ends:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of the variable, DOCKERURL (from the previous step), in a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'
    

    Also, store your OS version string in /etc/yum/vars/dockerosversion. Most users should use 8, but you can also use the more specific minor version.

    sudo sh -c 'echo "8" > /etc/yum/vars/dockerosversion'
    
  4. Install the yum-utils that provides the yum-config-manager utility.

    sudo yum install -y yum-utils \
      device-mapper-persistent-data \
      lvm2
    
  5. Add the Mirantis Container Runtime stable repository:

    sudo -E yum-config-manager \
      --add-repo \
      "$DOCKERURL/rhel/docker-ee.repo"
    
Install from the repository
  1. Install the latest patch release, or go to the next step to install a specific version:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9, and if so, accept it.

  2. To install a specific version of Mirantis Container Runtime (recommended in production), list versions and install:

    1. List and sort the versions available in your repo. This example sorts results by version number, highest to lowest, and is truncated:

      sudo yum list docker-ee  --showduplicates | sort -r
      
      docker-ee.x86_64      20.10.ee.2-1.el7.rhel      docker-ee-stable-18.09
      

      The list returned depends on which repositories you enabled, and is specific to your version of Red Hat Enterprise Linux (indicated by .el7 in this example).

    2. Install a specific version by its fully qualified package name, which is the package name (docker-ee) plus the version string (2nd column) starting at the first colon (:), up to the first hyphen, separated by a hyphen (-). For example, docker-ee-18.09.1.

      sudo yum -y install docker-ee-<VERSION_STRING> docker-ee-cli-<VERSION_STRING> containerd.io
      

      For example, if you want to install the 19.03 version run the following:

      sudo yum -y install docker-ee-19.03.8 docker-ee-cli-19.03.8 containerd.io
      

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  3. Start Docker:

    sudo systemctl start docker
    
  4. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

Mirantis Container Runtime is installed and running. Use sudo to run Docker commands.

Upgrade from the repository
  1. Add the new repository.

  2. Follow the installation instructions and install a new version.

Package install and upgrade

To manually install Mirantis Container Runtime, download the .rpm file for your release. You need to download a new file each time you want to upgrade.

Install with a package
  1. Enable the extras RHEL repository. This ensures access to the container-selinux package which is required by docker-ee:

    sudo yum-config-manager --enable rhel-7-server-extras-rpms
    

    Alternately, obtain that package manually from Red Hat. There is no way to publicly browse this repository.

  2. Go to repos.mirantis.com in your browser. Navigate to rhel/. Choose your Red Hat Enterprise Linux version, architecture, and Docker version. Download the .rpm file from the Packages directory.

    If you have trouble with selinux using the packages under the 7 directory, try choosing the version-specific directory instead, such as 7.3.

  3. Install MCR, changing the path below to the path where you downloaded the Docker package.

    sudo yum install <path_to_downloaded_rhel_package_.rpm>
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  4. Start Docker:

    sudo systemctl start docker
    
  5. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is now installed and running. Make sure to use sudo to run Docker commands (refer to the Docker documentation for Linux postinstall for information on how to allow non-privileged users to run Docker commands.

  1. Go to repos.mirantis.com in your browser. Navigate to rhel/. Choose your Red Hat Enterprise Linux version, architecture, and Docker version. Download the .rpm file from the Packages directory.

    If you have trouble with selinux using the packages under the 8 directory, try choosing the version-specific directory instead.

  2. Install Mirantis Container Runtime, changing the path below to the path where you downloaded the Docker package.

    sudo yum install <path_to_downloaded_rhel_package_.rpm>
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  3. Start Docker:

    sudo systemctl start docker
    
  4. Verify that Mirantis Container Runtime is installed correctly by running the hello-world image. This command downloads a test image, runs it in a container, prints an informational message, and exits:

    sudo docker run hello-world
    

    Mirantis Container Runtime is now installed and running. Make sure to use sudo to run Docker commands (refer to the Docker documentation for Linux postinstall for information on how to allow non-privileged users to run Docker commands.

Upgrade with a package
  1. Download the newer package file.

  2. Repeat the installation procedure, using ``yum -y upgrade` instead of yum -y install, and point to the new file.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall Mirantis Container Runtime
  1. Uninstall the Mirantis Container Runtime package:

    sudo yum -y remove docker-ee
    
  2. Delete all images, containers, and volumes (because these are not automatically removed from your host):

    sudo rm -rf /var/lib/docker
    
  3. Delete other Docker related resources:

    sudo rm -rf /run/docker
    sudo rm -rf /var/run/docker
    sudo rm -rf /etc/docker
    
  4. You must delete any edited configuration files manually.

Install Mirantis Container Runtime for SLES

Prerequisites

Perform all prerequisites as required prior to installing MCR on SLES.

OS requirements

To install Mirantis Container Runtime, you need the 64-bit version of SLES 12.x, running on the x86_64 architecture. Mirantis Container Runtime is not supported on OpenSUSE.

The only supported storage driver for Mirantis Container Runtime on SLES is Btrfs, which is used by default if the underlying filesystem hosting /var/lib/docker/ is a BTRFS filesystem.

Note

IBM Z (s390x) is supported for Mirantis Container Runtime 17.06.xx only.

Firewall configuration

Docker creates a DOCKER iptables chain when it starts. The SUSE firewall may block access to this chain, which can prevent you from running containers with published ports. You may see errors such as the following:

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 you see errors like this, adjust the start-up script order so that the firewall is started before Docker, and Docker stops before the firewall stops. See the SLES documentation on init script order.

Uninstall old versions

Older versions of Docker were called docker or docker-engine. If you use OS images from a cloud provider, you may need to remove the runc package, which conflicts with Docker. If these are installed, uninstall them, along with associated dependencies.

sudo zypper rm docker docker-engine runc

If removal of the docker-engine package fails, use the following command instead:

sudo rpm -e docker-engine

It’s OK if zypper reports that none of these packages are installed.

The contents of /var/lib/docker/, including images, containers, volumes, and networks, are preserved. The Mirantis Container Runtime package is now called docker-ee.

Configure the Btrfs filesystem

By default, SLES formats the / filesystem using Btrfs, so most people do not not need to do the steps in this section. If you use OS images from a cloud provider, you may need to do this step. If the filesystem that hosts /var/lib/docker/ is not a BTRFS filesystem, you must configure a BTRFS filesystem and mount it on /var/lib/docker/.

  1. Check whether / (or /var/ or /var/lib/ or /var/lib/docker/ if they are separate mount points) are formatted using Btrfs. If you do not have separate mount points for any of these, a duplicate result for / is returned.

    df -T / /var /var/lib /var/lib/docker
    

    You need to complete the rest of these steps only if one of the following is true:

    • You have a separate /var/ filesystem that is not formatted with Btrfs

    • You do not have a separate /var/ or /var/lib/ or /var/lib/docker/ filesystem and / is not formatted with Btrfs

    If /var/lib/docker is already a separate mount point and is not formatted with Btrfs, back up its contents so that you can restore them after step 3.

  2. Format your dedicated block device or devices as a Btrfs filesystem. This example assumes that you are using two block devices called /dev/xvdf and /dev/xvdg. Make sure you are using the right device names.

    Important

    Double-check the block device names because this is a destructive operation.

    sudo mkfs.btrfs -f /dev/xvdf /dev/xvdg
    

    There are many more options for Btrfs, including striping and RAID. See the Btrfs documentation.

  3. Mount the new Btrfs filesystem on the /var/lib/docker/ mount point. You can specify any of the block devices used to create the Btrfs filesystem.

    sudo mount -t btrfs /dev/xvdf /var/lib/docker
    

    Don’t forget to make the change permanent across reboots by adding an entry to /etc/fstab.

  4. If /var/lib/docker previously existed and you backed up its contents during step 1, restore them onto /var/lib/docker.

Install Mirantis Container Runtime

You can install Mirantis Container Runtime in different ways, depending on your needs.

  • Most users set up Docker’s repositories and install from them, for ease of installation and upgrade tasks. This is the recommended approach.

  • Some users download the RPM package and install it manually and manage upgrades completely manually. This is useful in situations such as installing Docker on air-gapped systems with no access to the internet.

Install using the repository

Before you install Mirantis Container Runtime for the first time on a new host machine, you need to set up the Docker repository. Afterward, you can install and update Docker from the repository.

Set up the repository
  1. Temporarily add the $DOCKER_EE_BASE_URL and $DOCKER_EE_URL variables into your environment. This only persists until you log out of the session.

    DOCKER_EE_BASE_URL="http://repos.mirantis.com"
    DOCKER_EE_URL="${DOCKER_EE_BASE_URL}/sles/<SLES_VERSION>/<ARCH>/stable-<DOCKER_VERSION>"
    

    And substitute the following:

    • SLES_VERSION is 15 or 12.3.

    • ARCH is x86_64.

    • DOCKER_VERSION is 19.03 or one of the older releases (18.09, 18.03, 17.06 etc.)

    As an example, your command should look like:

    DOCKER_EE_BASE_URL="https://storebits.docker.com/ee/sles/sub-555-55-555"
    DOCKER_EE_URL="${DOCKER_EE_BASE_URL}/sles/15/x86_64/stable-19.03"
    
  2. Use the following command to set up the stable repository. Use the command as-is. It works because of the variable you set in the previous step.

    sudo zypper addrepo $DOCKER_EE_URL docker-ee-stable
    
  3. Import the GPG key from the repository.

    sudo rpm --import "${DOCKER_EE_BASE_URL}/sles/gpg"
    
Install Mirantis Container Runtime
  1. Update the zypper package index.

    sudo zypper refresh
    

    If this is the first time you have refreshed the package index since adding the Docker repositories, you are prompted to accept the GPG key, and the key’s fingerprint is shown. Verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and if so, accept the key.

  2. Install the latest version of Mirantis Container Runtime and containerd, or go to the next step to install a specific version.

    sudo zypper install docker-ee docker-ee-cli containerd.io
    

    Start Docker.

    sudo service docker start
    
  3. On production systems, you should install a specific version of Mirantis Container Runtime instead of always using the latest. List the available versions. The following example only lists binary packages and is truncated. To also list source packages, omit the -t package flag from the command.

    zypper search -s --match-exact -t package docker-ee
    

    The contents of the list depend upon which repositories you have enabled. Choose a specific version to install. The third column is the version string. The fifth column is the repository name, which indicates which repository the package is from and by extension its stability level. To install a specific version, append the version string to the package name and separate them by a hyphen (-):

    sudo zypper install docker-ee-<VERSION_STRING> docker-ee-cli-<VERSION_STRING> containerd.io
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  4. Configure Docker to use the Btrfs filesystem. This is only required if the ``/`` filesystem is not using BTRFS. However, explicitly specifying the storage-driver has no harmful side effects.

  5. Edit the file /etc/docker/daemon.json (create it if it does not exist) and add the following contents:

    {
      "storage-driver": "btrfs"
    }
    
  6. Save and close the file.

  7. Start Docker.

    sudo service docker start
    
  8. Verify that Docker is installed correctly by running the hello-world image.

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits.

Mirantis Container Runtime is installed and running. You need to use sudo to run Docker commands.

Upgrade Mirantis Container Runtime

To upgrade Mirantis Container Runtime, follow the steps below:

  1. If upgrading to a new major Mirantis Container Runtime version (such as when going from Docker 18.03.x to Docker 18.09.x), add the new repository.

  2. Run sudo zypper refresh.

  3. Follow the installation instructions, choosing the new version you want to install.

Install from a package

If you cannot use the official Docker repository to install Mirantis Container Runtime, you can download the .rpm file for your release and install it manually. You need to download a new file each time you want to upgrade Docker.

  1. Go to repos.mirantis.com in your browser.

  2. Go to sles/12.3/ choose the directory corresponding to your architecture and desired Mirantis Container Runtime version. Download the .rpm file from the Packages directory.

  3. Import Docker’s official GPG key.

    sudo rpm --import http://repos.mirantis.com/sles/gpg
    
  4. Install Docker, changing the path below to the path where you downloaded the Docker package.

    sudo zypper install <path_to_downloaded_sles_package_.rpm>
    

    Docker is installed but not started. The docker group is created, but no users are added to the group.

  5. Configure Docker to use the Btrfs filesystem. This is only required if the ``/`` filesystem is not using Btrfs. However, explicitly specifying the storage-driver has no harmful side effects.

  6. Edit the file /etc/docker/daemon.json (create it if it does not exist) and add the following contents:

    {
      "storage-driver": "btrfs"
    }
    
  7. Save and close the file.

  8. Start Docker.

    sudo service docker start
    
  9. Verify that Docker is installed correctly by running the hello-world image.

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits.

Mirantis Container Runtime is installed and running. You need to use sudo to run Docker commands.

Upgrade Mirantis Container Runtime

To upgrade Mirantis Container Runtime, download the newer package file and repeat the installation procedure, using zypper update instead of zypper install, and pointing to the new file.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall Mirantis Container Runtime
  1. Uninstall the Mirantis Container Runtime package using the command below.

    sudo zypper rm docker-ee
    
  2. Images, containers, volumes, or customized configuration files on your host are not automatically removed. To delete all images, containers, and volumes.

    sudo rm -rf /var/lib/docker/*
    

    If you used a separate BTRFS filesystem to host the contents of /var/lib/docker/, you can unmount and format the Btrfs filesystem.

You must delete any edited configuration files manually.

Install Mirantis Container Runtime for Ubuntu

Prerequisites

Perform all prerequisites as required prior to installing MCR on Ubuntu.

Uninstall old versions

Use the apt-get remove command to uninstall older versions of Mirantis Container Runtime (called docker or docker-engine).

sudo apt-get remove docker docker-engine docker-ce docker-ce-cli docker.io

The apt-get command may report that none of the packages are installed.

Note

The contents of /var/lib/docker/, including images, containers, volumes, and networks, are preserved.

Extra steps for aufs

For Ubuntu 16.04 and higher, the Linux kernel includes support for overlay2, and Mirantis Container Runtime uses it as the default storage driver. If you need to use aufs instead, it must be manually configured.

Install Mirantis Container Runtime

Mirantis Container Runtime can be installed either by using Mirantis repositories, or by downloading and installing the DEB package and thereafter manually managing all upgrades. The Mirantis repository method is recommended, for the ease it lends in terms of both installation and upgrade tasks. The more manual DEB package approach, however, is useful in certain situations, such as installing MCR on air-gapped system that have no access to the Internet.

Install using the repository

To install Mirantis Container Runtime on a new host machine using the Mirantis repository you must first set the repository up on the machine.

Set up the repository
  1. Update the apt package index.

    sudo apt-get update
    
  2. Install packages to allow apt to use a repository over HTTPS.

    sudo apt-get install \
      apt-transport-https \
      ca-certificates \
      curl \
      software-properties-common
    
  3. Temporarily store http://repos.mirantis.com in an environment variable. This variable assignment does not persist when the session ends:

    DOCKER_EE_URL="http://repos.mirantis.com"
    
  4. Temporarily add a $DOCKER_EE_VERSION variable into your environment.

    DOCKER_EE_VERSION=19.03
    
  5. Add Docker’s official GPG key using your customer Mirantis Container Runtime repository URL.

    curl -fsSL "${DOCKER_EE_URL}/ubuntu/gpg" | sudo apt-key add -
    
  6. Verify that you now have the key with the fingerprint DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96, by searching for the last eight characters of the fingerprint. Use the command as-is. It works because of the variable you set earlier.

    sudo apt-key fingerprint 6D085F96
    
    pub   4096R/0EBFCD88 2017-02-22
          Key fingerprint = DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96
    uid                  Docker Release (EE deb) <docker@docker.com>
    sub   4096R/6D085F96 2017-02-22
    
  7. Set up the stable repository, using the following command as-is (which works due to the variable set up earlier in the process).

    sudo add-apt-repository \
      "deb [arch=$(dpkg --print-architecture)] $DOCKER_EE_URL/ubuntu \
      $(lsb_release -cs) \
      stable-$DOCKER_EE_VERSION"
    

    Note

    The included lsb_release -cs sub command returns the name of your Ubuntu distribution, for example, xenial.

Install Mirantis Container Runtime
  1. Update the apt package index.

    sudo apt-get update
    
  2. Install the latest version of Mirantis Container Runtime and containerd, or go to the next step to install a specific version. Any existing installation of MCR is replaced.

    sudo apt-get install docker-ee docker-ee-cli containerd.io
    

    Warning

    If you have multiple Mirantis repositories enabled, installing or updating without specifying a version in the apt-get install or apt-get update command always installs the highest possible version, which may not be appropriate for your stability needs.

  3. On production systems, you should install a specific version of Mirantis Container Runtime instead of always using the latest. The following output is truncated.

    apt-cache madison docker-ee
    
    docker-ee | 19.03~ee-0~ubuntu-xenial | http://repos.mirantis.com/ubuntu xenial/stable amd64 Packages
    

    The contents of the list depend upon which repositories are enabled, and are specific to your version of Ubuntu (indicated by the xenial suffix on the version, in this example). Choose a specific version to install. The second column is the version string. The third column is the repository name, which indicates which repository the package is from and by extension its stability level. To install a specific version, append the version string to the package name and separate them by an equals sign (=).

    sudo apt-get install docker-ee=<VERSION_STRING> docker-ee-cli=<VERSION_STRING> containerd.io
    

    The MCR daemon starts automatically.

  4. Verify that MCR is installed correctly by running the hello-world image.

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits.

Mirantis Container Runtime is installed and running. The docker group is created but no users are added to it. You need to use sudo to run MCR commands.

Upgrade Mirantis Container Runtime
  1. If upgrading to a new major Mirantis Container Runtime version (such as when going from version 18.09 to 19.03), add the new repository.

  2. Run sudo apt-get update.

  3. Follow the installation instructions, choosing the new version you want to install.

Install from a package

If you cannot use the Mirantis repository to install Mirantis Container Runtime, you can download the .deb files for your release and install them manually. You need to download a new file or set of files each time you want to upgrade Mirantis Container Runtime.

  1. Go to repos.mirantis.com in your browser.

  2. Go to /ubuntu/dists/bionic/pool/stable-<VERSION>/amd64/ and download the .deb file for the Ubuntu release and architecture you want to install.

    Note

    Starting with 19.03, you have to download three .deb files. They are docker-ee-cli_<version>.deb, containerd.io_<version>.deb, and docker-ee_<version>.deb.

  3. Install MCR, changing the path below to the path where you downloaded the Mirantis Container Runtime package.

    sudo dpkg -i <path_to_downloaded_ubuntu_package_.deb>
    

    Or, if you downloaded the three .deb files, you must install them in the following order:

    sudo dpkg -i /path/to/docker-ee-cli_<version>.deb
    sudo dpkg -i /path/to/containerd.io_<version>.deb
    sudo dpkg -i /path/to/docker-ee_<version>.deb
    

    The MCR daemon starts automatically.

  4. Verify that MCR is installed correctly by running the hello-world image.

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. When the container runs, it prints an informational message and exits.

Mirantis Container Runtime is installed and running. The docker group is created but no users are added to it. You need to use sudo to run MCR commands.

Upgrade Mirantis Container Runtime

To upgrade Mirantis Container Runtime, download the newer package file and repeat the installation procedure, pointing to the new file.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall Mirantis Container Runtime
  1. Uninstall the Mirantis Container Runtime package.

    sudo apt-get purge docker-ee
    
  2. Images, containers, volumes, or customized configuration files on your host are not automatically removed. Run the following command to delete all images, containers, and volumes.

    sudo rm -rf /var/lib/docker
    

You must delete any edited configuration files manually.

Install MCR on Windows Servers

Mirantis Container Runtime (MCR) enables native Docker containers on Windows Server. Windows Server 2019 and later versions are supported. 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.

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 a helper 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 helper script needs to be executed from an elevated command prompt. If you want to change the default daemon values, make sure to 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.

  1. Download the install.ps1 file.

    Invoke-WebRequest -Uri https://get.mirantis.com/install.ps1 -o install.ps1
    
  2. (Optional): Allow downloaded script files to run in the current session

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;
    
  3. Run the install script.

    .\install.ps1
    

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

  4. 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.

MCR provides FIPS 140-2 support in Windows Server, which includes a FIPS supported cryptographic module. If the Windows implementation already has FIPS support enabled, FIPS is automatically enabled in MCR.

Note

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

To enable FIPS 140-2 compliance on a system that is not in FIPS 140-2 mode, run the following command in PowerShell:

[System.Environment]::SetEnvironmentVariable("DOCKER_FIPS", "1", "Machine")

You can also enable FIPS 140-2 mode using the Windows Registry. To update the pertinent registry key, execute the following PowerShell command as an Administrator:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\" -Name "Enabled" -Value "1"

Restart the Docker service.

Stop-Service docker
Start-Service docker

To confirm Docker is running with FIPS-140-2 enabled, run the docker info.

Labels:
 com.docker.security.fips=enabled

Note

FIPS-140-2 compliance can be disabled if the FIPS-140-2 cryptographic module is installed on the operating system. To disable FIPS-140-2 in Docker but not the operating system, set the value "DOCKER_FIPS","0" in [System.Environment].\

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).

  1. On any Internet connected Powershell terminal: download the install.ps1 file and run it to download the installer .zip files

    Invoke-WebRequest -Uri https://get.mirantis.com/install.ps1 -o install.ps1
    
  2. (Optional): Allow the downloaded script files to run in the current session.

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process;
    
  3. Run the install.ps1 with the DownloadOnly parameter. As per the parameter name, this action only downloads the zip file (no installation is performed).

    .\install.ps1 -DownloadOnly
    
  4. Copy the install.ps1 file and the installation zip file over to the air-gapped machine and run the install with the -Offline parameter.

    .\install.ps1 -Offline
    
  5. If prompted, reboot the installer..

Install a specific version

To install a specific version, you can use the following three parameters separately or in tandem:

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

For example, .\install.ps1 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 install.ps1 script and rerun the installation steps.

  1. Download the install.ps1 file.

    Invoke-WebRequest -Uri https://get.mirantis.com/install.ps1 -o install.ps1
    
  2. (Optional): Allow downloaded script files to run in the current session.

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force -Scope Process
    
  3. Run the install script.

    .\install.ps1
    

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 (examples include stable and test). Default: stable.

.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

  1. In scenarios where you have existing software installed that has its own copies of OpenSSL libraries, you may encounter the following error:

    OpenSSL error: error:0F06D065:common libcrypto
    routines:FIPS_mode_set:fips mode not supported
    

    This is often arises if you have ming/mingw64 as a part of your PATH env variable. As a workaround, ensure that the offending software is not on the PATH and run the script again.

  2. 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, please 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, please 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.

Enable MCR 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 /etc/docker/daemon.json file. Change the setting to true to re-enable telemetry.

{"features":{"telemetry": false}}

Caution

To send the telemetry, verify that dockerd can resolve api.segment.io and create a TCP (HTTPS) connection on port 443.

Uninstall MCR

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

  1. Leave any active Docker Swarms.

    docker swarm leave --force
    
  2. Prune container data.

    docker system prune -all
    
  3. Run the install.ps1 script using the uninstall flag to remove MCR from the system.

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.22 and below or a plugin maintained by Mirantis called cri-docker (included in MCR) for Kubernetes 1.23 and above.

To configure cri-docker:

systemctl enable cri-docker.service

MCR 20.10.x Release Notes

This document describes the latest changes, enhancements, known issues, and fixes for Mirantis Container Runtime (MCR) for versions 20.10.x.

Caution

In developing MCR 20.10.x, Mirantis has been transitioning from legacy Docker Hub-issued licenses to JWT licenses, as detailed below:

  • Versions 20.10.0 to 20.10.6: Docker Hub licenses and JWT licenses

  • Versions 20.10.7 and later: JWT licenses only

Using a JWT license with an MKE instance that manages MCR causes the engine to log error messages, though MCR does not fail. This applies to MKE 3.4.x versions prior to 3.4.6 and MKE 3.3.x versions prior to 3.3.13.

20.10.8

(2021-10-28)

Components

Component

Version

Mirantis Container Runtime

20.10.8

containerd

1.5.8 (from 2021-11-23)

1.5.7 (prior to 2021-11-23)

runc

1.0.2

Deprecation

  • Deprecated support for encrypted TLS private keys. Legacy PEM encryption (as specified in RFC 1423) is insecure by design. Because legacy PEM encryption does not authenticate the ciphertext, it is vulnerable to padding oracle attacks that can allow an attacker to recover the plaintext (docker/cli#3219).

  • Deprecated Kubernetes stack support (docker/cli#3174).

Runtime

  • MCR now prints a warning when using the --platform option to pull a single-arch image that does not match the specified architecture (moby/moby#42633).

  • Fixed an issue wherein the following incorrect warning displayed when running cgroups v2:

    Your kernel does not support swap memory limit.
    

    moby/moby#42479

  • Fixed an issue with MCR on Windows wherein containers were not stopped if HcsShutdownComputeSystem returned an ERROR_PROC_NOT_FOUND error (moby/moby#42613).

  • Fixed an issue wherein using a JWT license with an MKE instance that manages MCR caused MCR to log error messages (FIELD-4201).

  • Fixed an issue wherein the docker info and docker version commands did not properly display the MCR license information on nodes that do not belong to a swarm (FIELD-4180).

Client

  • Fixed an issue with MCR on Windows wherein the following incorrect error displayed when trying to call term.StdStreams():

    Invalid standard handle identifier
    

    docker/cli#3132

Packaging

  • Updated containerd to version 1.5.7 to resolve CVE-2021-41103.

  • Updated the Golang runtime to Go version 1.16.7.

  • Updated the FIPS library with certificate number 3993.

  • Updated the bundled buildx version to 0.6.1 for RPM and DEB packages.

20.10.7

(2021-08-19)

Components

Component

Version

Mirantis Container Runtime

20.10.7

containerd

1.4.8 (prior to 2021-09-13)

1.5.5 (from 2021-09-13)

runc

1.0.0 (prior to 2021-09-13)

1.0.1 (from 2021-09-13)

Swarm

Fixed a SwarmKit bug in the log broker that caused the cluster to stop functioning at times (FIELD-3764).

Runtime

MCR now accepts only JWT licenses. To upgrade MCR, customers using a Docker Hub-issued license must first replace it with the new license version (ENGINE-486).

To request a JWT license, contact support@mirantis.com.

Packaging

Resolved CVE-2021-32760 by updating containerd to version 1.4.8.

Deprecation notes

In correlation with the End of Life date for MKE 3.2.x and MSR 2.7.x, Mirantis stopped maintaining the associated documentation set on 2021-07-21.

20.10.6

(2021-06-29)

Components

Component

Version

Mirantis Container Runtime

20.10.6

containerd

1.4.6

runc

1.0.0-rc95

Client

  • Suppressed warnings for deprecated cgroups (docker/cli#3099).

  • The docker CLI now ignores SIGURG signals, and thus no longer sends them to containers on Linux. Starting with version 1.14, the Go runtime uses SIGURG signals internally as an interrupt to support preemptable syscalls. docker CLI previously forwarded these signals to the containers it was attached to (docker/cli#3107, moby/moby#42421).

Builder

  • Updated BuildKit to version 0.8.3-3-g244e8cde (moby/moby#42448).

    • Transformed relative mountpoints for exec mounts in the executor to work around a breaking change in runc version 1.0.0-rc94 and higher (moby/buildkit#2137).

    • Added retry on push 5xx errors (moby/buildkit#2043).

    • Fixed an issue wherein renaming a file copied using a COPY command with a wildcard did not invalidate the build-cache. This change invalidates existing build caches for copy commands that use a wildcard (moby/buildkit#2018).

    • Fixed an issue wherein the use of mounts did not invalidate the build-cache (moby/buildkit#2076).

  • Fixed an issue wherein MCR did not cache the FROM image when using legacy schema 1 images, resulting in build failures (moby/moby#42382).

Networking

  • Updated libnetwork to fix publishing ports on environments with the kernel boot parameter ipv6.disable=1 and a deadlock that caused internal DNS lookups to fail (moby/moby#42413).

  • Fixed an issue wherein overlapping IP addresses could occur due to nodes failing to clean up their old load balancer IP addresses (FIELD-3915).

Logging

  • Updated the hcsshim SDK to make daemon logs on Windows less verbose (moby/moby#42292).

Packaging

  • Updated containerd to version 1.4.6 and runc to version 1.0.0-rc95 to address CVE-2021-30465 (ENGINE-482).

20.10.5

(2021-05-17)

Components

Component

Version

Mirantis Container Runtime

20.10.5

containerd

1.4.4

runc

1.0.0-rc92

Packaging

  • Added a technical preview for cri-docker (previously known as dockershim).

  • Fixed an issue wherein killing containerd caused systemd to stop docker.

Client

  • Reverted docker/cli#2960 to stop hanging in docker start --attach and removed spurious Unsupported signal: <nil>. Discarding messages (docker/cli#2987).

Builder

  • Fixed an issue wherein the classic builder was silently ignoring unsupported Dockerfile options. It now prompts the user to enable BuildKit instead (moby/moby#42197).

Logging

  • Fixed sporadic and unexpected EOF errors in json-file handling (moby/moby#42174).

Networking

  • Fixed a regression that caused IPv6 addresses not to be bound by default when mapping ports (moby/moby#42205).

  • Fixed implicit IPv6 port-mappings not included in the API response. Prior to version 20.10.0, while published ports were accessible through both IPv4 and IPv6 by default, the API only included information about the IPv4 (0.0.0.0) mapping (moby/moby#42205).

  • Fixed a regression wherein the docker-proxy did not terminate in all cases (moby/moby#42205).

  • Fixed an issue wherein iptables forwarding rules were not cleaned up when containers were removed (moby/moby#42205).

  • Fixed an issue wherein swarm service VIPs timed out from Windows containers, resulting in the following error in dockerd event logs:

    Failed to add ILB policy for service service [] failed during
    hnsCallRawResponse: hnsCall failed in Win32: The specified port already
    exists.
    

    The Windows Operating System update KB4577668 introduced the issue on October 13, 2020, affecting all versions of MCR (FIELD-3310).

Known issues

  • Centos and RHEL 7.x kernels may experience memory exhaustion due to slab cache usage. Because this is a kernel feature, the issue cannot be resolved with MCR code.

    Workarounds:

    • (Recommended) Update to a kernel that supports setting cgroups.memory=nokmem and apply the change (for customers using Centos or RHEL 7.7 and above).

    • Increase the memory available to the machine for slab usage.

    (FIELD-3466)

20.10.4

(2021-04-12)

Components

Component

Version

Mirantis Container Runtime

20.10.4

containerd

1.4.4

runc

1.0.0-rc92

Security

  • Resolved CVE-2021-21285, thereby preventing invalid images from crashing the Docker daemon (ENGINE-438).

  • Resolved CVE-2021-21284, thereby preventing a remapped root from accessing the Docker state by locking down file permissions (ENGINE-438).

  • MCR now confirms that AppArmor and SELinux profiles are applied when building with BuildKit (ENGINE-438).

  • Resolved CVE-2021-21334, and in the process updated containerd to version 1.4.4 (ENGINE-438).

  • Updated syscall list to Linux 5.11 in the seccomp profile (moby/moby#41971).

Builder

  • Fixed the incorrect cache match for inline cache import with empty layers (moby/moby#42061).

  • Updated BuildKit to version 0.8.2 (moby/moby#42061).

    • Avoids error caching on token fetch in resolver.

    • Fixed checksum to contain indexes of inputs in fileop, thus preventing certain cache misses.

    • Fixed reference count issues on typed errors with mount references, addressing invalid mutable ref errors.

    • Set token only for main remote access, thereby allowing submodule cloning with different credentials.

  • Ensures blobs are deleted after pull in /var/lib/docker/buildkit/content/blobs/sha256. Run builder prune to clean up old state (moby/moby#42065).

  • Fixed parallel pull synchronization regression (moby/moby#42049).

  • Ensures libnetwork state files do not leak (moby/moby#41972).

Client

  • Customers who use MCR with Kubernetes directly (without using MKE) need to enable the cri-docker plugin in MCR beginning with Kubernetes version 1.23 (planned for late 2021), at which point Kubernetes will no longer maintain dockershim (MKE-8126).

    Learn more

    cri-docker

  • Fixed an issue wherein docker login resulted in a panic if no config file was present (docker/cli#2959).

  • Fixed an issue wherein MCR erroneously displayed the warning: WARNING: Error loading config file: .dockercfg: $HOME is not defined (docker/cli#2958).

Runtime

  • Silenced docker info warnings that cannot be addressed (moby/moby#41958).

  • Avoids creating parent directories for XGlobalHeader (moby/moby#42017)>

  • Uses 0755 permissions when creating missing directories (moby/moby#42017).

  • Falls back to manifest list when no platform matches in the image config (moby/moby#42045 and moby/moby#41873).

  • Fixed an issue wherein the daemon panicked when an admin specified a custom default runtime (moby/moby#41974).

  • Fixed an issue wherein an empty daemon configuration caused a panic (moby/moby#41976).

  • Fixed an issue wherein the daemon panicked when starting a container with an invalid device cgroup rule (moby/moby#42001).

  • Fixed an issue wherein the userns-remap option did not work when the username and UID matched (moby/moby#42013).

Logger

  • Honors label-regex config even if labels is not set (moby/moby#42046).

  • Handles long log messages correctly, preventing awslogs in non-blocking mode to split events larger than 16 KB (mobymoby#41975).

Swarm

  • Fixed an issue wherein custom Docker heartbeat periods reverted back to the default setting on restart. Thus, previously stalled tasks will no longer be stuck in a pending state (FIELD-3563, moby/moby#42060).

  • Fixed an issue wherein MCR ignored --update-order and --rollback-order flags (docker/cli#2963).

  • Fixed an issue wherein docker service rollback sometimes returned a non-zero exit code (docker/cli#2964).

  • Fixed an issue wherein the direction of the progress bar rendered inconsistently on docker service rollback (docker/cli#2964).

20.10.0

(2021-03-11)

Components

Component

Version

Mirantis Container Runtime

20.10.0

containerd

1.4.3

runc

1.0.0-rc92

What’s new

  • Added support for cgroups v2 which limits process resource usage (such as CPU, memory, and disk). MCR uses cgroups in conjunction with Linux namespaces to isolate processes inside containers. As a result, rootless is now a fully supported feature.

  • Added support for using docker logs to read container logs, regardless of the configured logging driver or plugin. Previously, docker logs did not support the use of many third party logging drivers, and this led to log data gathering issues.

    Learn more

    Refer to the Docker documentation, Configure logging drivers.

  • Added support for Ubuntu 20.04.

  • Added several CLI improvements. Along with the removal of some older and mostly unused commands, various new commands and flags have been added that make it easier to get started and to script using MCR:

    • docker push has been modified to align the default behavior with docker pull. Pushing an image name without a tag now pushes only the :latest rather than all tags, and -a/all-tags can now be used to push all the tags of an image.

    • The --pull flag has been added to the docker run and docker create commands, affording greater control over when users pull images. The option is tristate, offering missing (default), always, and late settings.

    • The -env-file flag has been added to docker exec, allowing use with a file that contains environment variables and subsequent printing or use of any of the variables inside the file.

    Learn more

    For a complete list of the CLI improvements, refer to the Docker release notes.

Deprecated features

  • Making docker pull requests against non-compliant registries that do not support pull-by-digest now results in a warning and deprecation notice (docker/cli#2872).

  • Unauthenticated TCP access now results in a more severe warning and deprecation notice (moby/moby#41285).

  • KernelMemory (docker run --kernel-memory) is deprecated (moby/moby#41254 and docker/cli#2652).

  • The aufs storage driver is deprecated (docker/cli#1484).

  • The --cluster-advertise, --cluster-store, and --cluster-store-opt flags are deprecated from the dockerd CLI (moby/moby#40614 and moby/moby#40510).

  • The legacy Dockerfile ENV name value syntax is deprecated. Use ENV name=value instead (docker/cli#2743).

  • The previously deprecated filter parameter has been removed for API v1.41 and up (moby/moby#40491).

  • The distribution manifest v2 schema 1 is now disabled on push (moby/moby#41295).

  • The MalformedHostHeaderOverride hack has been removed, causing CLI v1.12 and earlier to break. Affected users should upgrade to a more recent client version or set the DOCKER_API_VERSION environment variable to the needed API version (moby/moby#39076).

  • The docker engine subcommands have been removed (docker/cli#2207).

  • The top-level docker deploy command and .dab (“Docker Application Bundle”) file format have both been removed in favor of using docker stack deploy with compose files (docker/cli#2216).

  • The docker search --automated and docker search --stars flags have been removed in favor of using their docker search --filter equivalents (docker/cli#2338).

  • Use of reserved namespaces in engine labels is deprecated (docker/cli#2326).

MKE, MSR, and MCR Compatibility Matrix

MKE, MSR, and MCR Compatibility Matrix

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 (MKE), Mirantis Secure Registry (MSR), and Mirantis Container Runtime (MCR).

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

MKE 3.5/MKE 3.4, MSR 2.9, and MCR 20.10

Note

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.

OS Distribution (x86_64)

MKE

MSR

MCR

Storage Driver

Orchestration

MSR Storage Backend

RHEL 8.4

3.4.4 and higher

2.9.3 and higher

20.10.6 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.3

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.2

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.9

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Enterprise Linux 7.9

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Enterprise Linux 7.8

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP3

3.4.5 and higher 1

2.9.4

20.10.7

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP2

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP1

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP5

3.4.0 and higher 1

2.9.0 and higher

20.10.4 and higher

btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 20.04.3

3.4.5 and higher 1

2.9.4

20.10.7

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 20.04.2

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04.6

3.4.6 1

2.9.4

20.10.7

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04.4

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 8.1.1911

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 7.8.2003

3.4.0 and higher 1

2.9.0 and higher

20.10.0 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server 2019 (10.0.17763)

3.4.0 and higher (worker nodes only) 2

n/a 2

20.10.0 and higher

windowsfilter

Swarm mode, Kubernetes

n/a

1 Users running kernel version 4.15 or earlier on MKE 3.4.2 must either upgrade to kernel version 4.16 (or later) or upgrade to MKE 3.4.4 (or later).

2 MSR does not run on Windows.

Support for aufs storage driver deprecated. EOL in next release.

Support for btrfs storage driver deprecated. EOL in next release.

The MKE, MSR, and MCR platform requires that all manager nodes in a single cluster run on the exact same operating system version.

Oracle Linux 7.8 is supported with Red Hat Compatible kernel (RHCK) 3.10.0-1127 and higher.

Kubernetes Volume Drivers
  • NFS v4 via Kubernetes e2e suite

  • AWS EFS

  • AWS EBS

  • Azure Disk

  • Azure File

MKE 3.3, MSR 2.8, and MCR 19.03 (formerly known as Docker Enterprise 3.1)

Note

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.

OS Distribution (x86_64)

MKE

MSR

MCR

Storage Driver

Orchestration

MSR Storage Backend

RHEL 8.4

3.3.11 and higher

2.8.8 and higher

20.10.6 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.3

3.3.4 and higher 1

2.8.4 and higher

19.03.13 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.2

3.3.0 and higher 1

2.8.0 and higher

19.03.8 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.9

3.3.4 and higher 1

2.8.4 and higher

19.03.13 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Enterprise Linux 7.9

3.3.4 and higher 1

2.8.4 and higher

19.03.13

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Enterprise Linux 7.8

3.3.4 and higher 1

2.8.4 and higher

19.03.13

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP3

3.3.12 and higher 1

2.8.9

19.03.18

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP2

3.3.4 and higher 1

2.8.4 and higher

19.03.13

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15 SP1

3.3.4 and higher 1

2.8.4 and higher

19.03.13

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP5

3.3.8 1

2.8.6

19.03.15

btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 20.04.3

3.3.12 and higher 1

2.8.9 and higher

19.03.18 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 20.04.2

3.3.8 and higher 1

2.8.6 and higher

19.03.15 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04.6

3.3.13 1

2.8.9

19.03.18

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04.4

3.3.0 and higher 1

2.8.0 and higher

19.03.8 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 8.1.1911

3.3.0 and higher 1

2.8.0 and higher

19.03.8 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 7.8.2003

3.3.0 and higher 1

2.8.0 and higher

19.03.8 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server 2019 (10.0.17763)

3.3.0 and higher (worker nodes only) 1

n/a 2

19.03.8 and higher

windowsfilter

Swarm mode, Kubernetes

n/a

1 Users running kernel version 4.15 or earlier on MKE 3.3.9 must either upgrade to kernel version 4.16 (or later) or upgrade to MKE 3.3.11 (or later).

2 MSR does not run on Windows.

Support for aufs storage driver deprecated. EOL in next release.

Support for btrfs storage driver deprecated. EOL in next release.

The MKE, MSR, and MCR platform requires that all manager nodes in a single cluster run on the exact same operating system version.

Oracle Linux 7.8 is supported with Red Hat Compatible kernel (RHCK) 3.10.0-1127 and higher.

Kubernetes Volume Drivers
  • NFS v4 via Kubernetes e2e suite

  • AWS EFS

  • AWS EBS

  • Azure Disk

  • Azure File

MKE 3.2, MSR 2.7, and MCR 19.03 (formerly known as Docker Enterprise 3.0)

OS Distribution (x86_64)

MKE

MSR

MCR

Storage Driver

Orchestration

MSR Storage Backend

RHEL 8.4 1

3.2.15 and higher

2.7.13 and higher

19.03.17 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.3 1

3.2.9 and higher

2.7.9 and higher

19.03.13 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 8.0 1

3.2.4 and higher

2.7.4 and higher

19.03.5 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.9 1

3.2.9 and higher

2.7.9 and higher

19.03.13 and higher

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15

3.2.x

2.7.x

19.03.x

overlay2,btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP5 1

3.2.13

2.7.11

19.03.15

btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP4 1

3.2.x

2.7.x

19.03.x

overlay2,btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 20.04 1

3.2.13

2.7.11

19.03.15

overlay2, aufs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04 1

3.2.x

2.7.x

19.03.x

overlay2, aufs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 16.04 1

3.2.x

2.7.x

19.03.x

overlay2, aufs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 7 1

3.2.x

2.7.x

19.03.x

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Linux 7.6 4

3.2.x

2.7.x

19.03.x

overlay2

Swarm mode, Kubernetes

NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server 2019 LTSC

3.2.2 2

n/a 3

19.03.x

windowsfilter

Swarm mode

n/a

Windows Server 2016 LTSC

3.2.x 2

n/a 3

19.03.x

windowsfilter

Swarm mode

n/a

1 Docker tests and supports Linux vendor kernels from the X.Y.Z branch of the OS vendor’s General Availability of their enterprise OS. Upstream or custom kernels are not supported. For more information on kernel versions, see the following information from your enterprise OS provider: Red Hat, Ubuntu, SUSE.

2 Windows Server 2016 LTSC and Windows Server 2019 LTSC are only supported as worker nodes.

3 MSR does not run on Windows.

4 Oracle Linux 7.6 is supported with Red Hat Compatible kernel (RHCK) 3.10.0-957.1.3.el7 and higher.

Kubernetes Volume Drivers
  • NFS v4 via Kubernetes e2e suite

  • AWS EFS

  • AWS EBS

  • Azure Disk

  • Azure File

MKE 3.1, MSR 2.6, and MCR 18.09 (formerly known as Docker Enterprise 2.1)

OS Distribution (x86_64)

MKE

MSR

MCR

Storage Driver

Orchestration

MSR Storage Backend

RHEL 7.8 1

3.1.14 and higher

2.6.14 and higher

18.09.12

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.4 1

3.1.x

2.6.x

18.09.x

overlay2, devicemapper

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.5 1

3.1.x

2.6.x

18.09.x

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.6 1

3.1.x starting with 3.1.3

2.6.x starting with 2.6.2

18.09.x

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

RHEL 7.7 1

3.1.x starting with 3.1.11

2.6.x starting with 2.6.10

18.09.x starting with 18.09.10

overlay2

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP2 1

3.1.x

2.6.x

18.09.x

overlay2, btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 12 SP3 1

3.1.x

2.6.x

18.09.x

overlay2, btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

SLES 15

3.1.x

2.6.x

18.09.x starting with 18.09.3

overlay2, btrfs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 16.04 1

3.1.x

2.6.x

18.09.x

overlay2, aufs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Ubuntu 18.04 1

3.1.x

2.6.x

18.09.x

overlay2, aufs

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

CentOS 7 1

3.1.x

2.6.x

18.09.x

overlay2, devicemapper

Swarm mode, Kubernetes

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Oracle Linux 7.6 4

3.1.x

2.6.x

18.09.x

overlay2, devicemapper 2

Swarm mode, Kubernetes

NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server 2016

3.1.x 2

n/a 3

18.09.x

windowsfilter

Swarm mode

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server, version 1803

3.1.x 2

n/a 3

18.09.x

windowsfilter

Swarm mode

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

Windows Server, version 2019

3.1.x starting with 3.1.3 2

n/a 3

18.09.x

windowsfilter

Swarm mode

NFSv4, NFSv3, Amazon S3, S3 Compliant Alternatives, Azure Storage (Blob), Google Cloud Storage, OpenStack Swift, Local Filesystem

1 Docker tests and supports Linux vendor kernels from the X.Y.Z branch of the OS vendor’s General Availability of their enterprise OS. Upstream or custom kernels are not supported. For more information on kernel versions, see the following information from your enterprise OS provider: Red Hat, Ubuntu, SUSE.

2 Windows Server 2016, Windows Server version 1803, and Windows Server version 2019 are only supported as worker nodes.

3 MSR does not run on Windows.

4 Oracle Linux 7.6 is supported with Red Hat Compatible kernel (RHCK) 3.10.0-957.1.3.el7 and higher.

Kubernetes Volume Drivers
  • NFS v4 via Kubernetes e2e suite

  • AWS EFS

  • AWS EBS

  • Azure Disk

  • Azure File

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 MKE, MSR, and MCR Compatibility Matrix, adhering 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.

MKE 3.2, MSR 2.7, and MCR 19.03 (formerly known as Docker Enterprise 3.0)

The MKE, MSR, and MCR platform that formerly comprised Docker Enterprise 3.0 will be considered End of Life on 2021-07-21.

  • Mirantis Kubernetes Engine 3.2.z

  • Mirantis Secure Registry 2.7.z

  • Mirantis Container Runtime 19.03.z

MKE 3.3, MSR 2.8, and MCR 19.03 (formerly known as Docker Enterprise 3.1)

The MKE, MSR, and MCR platform that formerly comprised Docker Enterprise 3.1 will be considered End of Life on 2022-05-28.

  • Mirantis Kubernetes Engine 3.3.z

  • Mirantis Secure Registry 2.8.z

  • Mirantis Container Runtime 19.03.z

MKE 3.4, MSR 2.9, and MCR 20.10

End of Life for the MKE, MSR and MCR platform will reach End of Life on different dates. MKE and MSR will reach End of Life on 2023-April-11, while MCR will reach End of Life on 2023-March-10.

  • Mirantis Kubernetes Engine 3.4.z

  • Mirantis Secure Registry 2.9.z

  • Mirantis Container Runtime 20.10.z

Mirantis Kubernetes Engine (MKE)

3.2.z

3.3.z

3.4.z

General Availability (GA)

2019-07-22

2020-05-28 (3.3.0)

2021-04-12 (3.4.0)

End of Life (EOL)

2021-07-21

2022-05-27

2023-04-11

Release Frequency

X.Y Monthly

X.Y Monthly

X.Y Monthly

Supported Lifespan

2 years 1

2 years 1

2 years 1

Patches and Update Frequency

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

1 Refer to the Supported Lifecycle for details.

End of Life (EOL) MKE Versions
  • 2.0.z (EOL 2017-08-16)

  • 2.1.z (EOL 2018-02-07)

  • 2.2.z (EOL 2019-11-01)

  • 3.0.z (EOL 2020-04-16)

  • 3.1.z (EOL 2020-11-06)

Mirantis Secure Registry (MSR)

2.7.z

2.8.z

2.9.z

General Availability (GA)

2019-07-22

2020-05-28 (2.8.0)

2021-04-12 (2.9.0)

End of Life (EOL)

2021-07-21

2022-05-27

2023-04-11

Release Frequency

X.Y Monthly

X.Y Monthly

X.Y Monthly

Supported Lifespan

2 years 1

2 years 1

2 years 1

Patches and Update Frequency

As Needed

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

1 Refer to the Supported Lifecycle for details.

End of Life (EOL) MSR Versions
  • 2.1.z (EOL 2017-08-16)

  • 2.2.z (EOL 2018-02-07)

  • 2.3.z (EOL 2019-02-15)

  • 2.4.z (EOL 2019-11-01)

  • 2.5.z (EOL 2020-04-16)

  • 2.6.z (EOL 2020-11-06)

Mirantis Container Runtime (MCR)

Enterprise 19.03

Enterprise 19.03.8

Enterprise 20.10

General Availability (GA)

2019-07-21 (19.03.0)

2020-05-28 (19.03.8)

2021-03-11 (20.10.0)

End of Life (EOL)

2021-07-21

2022-05-27

2023-03-10

Release Frequency

X.Y Monthly

X.Y Monthly

X.Y Monthly

Supported Lifespan

2 years 1

2 years 1

2 years 1

Patches and Update Frequency

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

As Needed:

  • Maintenance Releases

  • Security Patches

  • Custom hotfixes

1 Refer to the Supported Lifecycle for details.

End of Life (EOL) Mirantis Container Runtime Versions
  • CSE 1.11.z (EOL 2017-03-02)

  • CSE 1.12.z (EOL 2017-11-14)

  • CSE 1.13.z (EOL 2018-02-07)

  • EE 17.03.z (EOL 2018-03-01)

  • Docker Engine - Enterprise v17.06 (EOL 2020-04-16)

  • Docker Engine - Enterprise 18.03 (EOL 2020-06-16)

  • Docker Engine - Enterprise 18.09 (EOL 2020-11-06)

Supported Lifecycle

GA to 12 months

12 to 18 months

18 to 24 months

Full support as outlined in the Docker Scope of Support

Full support as outlined in the Docker Scope of Support 1

Limited Support for existing installations 2

1 Software patches for Urgent bugs only, no feature enablement.

2 Patches for critical security issues only.

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

Subscriptions for MKE, MSR, and MCR provide access to prioritized support for designated contacts from your company, agency, team, or organization. Mirantis service levels for MKE, MSR, and MCR are based on your subscription level and the Cloud (or cluster) you designate in your technical support case. Our support offerings are described here, and if you do not already have a support subscription, you may inquire about one via the contact us form.

Mirantis’ primary means of interacting with customers who have technical issues with MKE, MSR, or MCR is our CloudCare Portal. Access to our CloudCare Portal requires prior authorization by your company, agency, team, or organization, and a brief email verification step. After Mirantis sets up its back end 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 don’t know who is a local designated administrator, or are having problems accessing the CloudCare Portal, you may also send us an email.

Once you have verified your contact details via our verification email, and changed your password as part of your first login, you and all your colleagues will have access to all of the cases and resources purchased. We recommend you retain your ‘Welcome to Mirantis’ email, because it contains information on accessing our CloudCare Portal, guidance on submitting new cases, managing your resources, and so forth. Thus, it can serve as a reference for future visits.

We encourage all customers with technical problems to use the knowledge base, which you can access on the Knowledge tab of our CloudCare Portal. We also encourage you to review the MKE, MSR, and MCR products documentation which includes release notes, solution guides, and reference architectures. These are available in several formats. We encourage use of these resources prior to filing a technical case; we may already have fixed the problem in a later release of software, or provided a solution or technical workaround 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 known as “Clouds” in our portal. Mirantis has pre-populated customer accounts with one or more Clouds based on your subscription(s). Customers may also create and manage their Clouds to better match how you use your subscription.

We also recommend and encourage our 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 Mirantis’ ability 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’s name. Once you’ve verified that Cloud represents the correct MKE cluster and support entitlement, you can create a new case via the New Case button towards the top of the Cloud’s page.

One of the key items required for technical support of most MKE, MSR, and MCR cases is the support dump. This is a compressed archive of configuration data and log files from the cluster. There are several ways to gather a support dump, each described in the paragraphs below. After you have collected a support dump, you can upload the dump to your new technical support case by following this guidance and using the “detail” view of your case.

Use the Web UI to get a support dump

To get the support dump from the web UI:

  1. Log into the MKE web UI with an administrator account.

  2. In the top-left menu, click your username and choose Support Dump.

It may take a few minutes for the download to complete.

To submit the support dump to Mirantis Customer Support:

  1. Click Share support bundle on the success prompt that displays when the support dump finishes downloading.

  2. Fill in the Jira feedback dialog, and click Submit.

Use the CLI to get a support dump

To get the support dump from 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.2.6)|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

Note

The support dump only contains logs for the node where you’re running the command. If your MKE is highly available, you should collect support dumps from all of the manager nodes.

To submit the support dump to Mirantis Customer Support, add the --submit option to the support command. This will send the support dump along with the following information:

  • Cluster ID

  • MKE version

  • MCR version

  • OS/architecture

  • Cluster size

Use PowerShell to get a support dump

On Windows worker nodes, run the following command to generate a local support dump:

docker container run --name windowssupport -v 'C:\ProgramData\docker\daemoncerts:C:\ProgramData\docker\daemoncerts' -v 'C:\Windows\system32\winevt\logs:C:\eventlogs:ro' mirantis/ucp-dsinfo-win:3.2.6; docker cp windowssupport:'C:\dsinfo' .; docker rm -f windowssupport

This command creates a directory named dsinfo in your current directory. If you want an archive file, you need to create it from the dsinfo directory.

QuickStart: MCR on Ubuntu NEW

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:

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

_images/workflow-qs.png

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.

  1. Update the apt package index:

    sudo apt-get update
    
  2. Install packages that allow apt to use a repository over HTTPS:

    sudo apt-get install \
      apt-transport-https \
      ca-certificates \
      curl \
      software-properties-common
    
  3. Store http://repos.mirantis.com in an environment variable:

    DOCKER_EE_URL="http://repos.mirantis.com"
    
  4. Add a $DOCKER_EE_VERSION variable into your environment.

    DOCKER_EE_VERSION=<mcr-version>
    
  5. Add Docker’s official GPG key:

    curl -fsSL "${DOCKER_EE_URL}/ubuntu/gpg" | sudo apt-key add -
    
  6. Verify that you now have the key with the fingerprint DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96 by searching for the last eight characters of the fingerprint:

    sudo apt-key fingerprint 6D085F96
    
    pub   4096R/0EBFCD88 2017-02-22
          Key fingerprint = DD91 1E99 5A64 A202 E859  07D6 BC14 F10B 6D08 5F96
    uid                  Docker Release (EE deb) <docker@docker.com>
    sub   4096R/6D085F96 2017-02-22
    
  7. Use the following command to set up the stable repository:

    sudo add-apt-repository \
      "deb [arch=$(dpkg --print-architecture)] $DOCKER_EE_URL/ubuntu \
      $(lsb_release -cs) \
      stable-$DOCKER_EE_VERSION"
    

Install MCR

  1. Install the latest version of MCR and containerd:

    sudo apt-get install docker-ee docker-ee-cli containerd.io
    

    Note

    To install a specific version of MCR:

    sudo apt-get install docker-ee=<VERSION_STRING> docker-ee-cli=<VERSION_STRING> containerd.io
    
  2. Verify that you installed MCR correctly:

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. If successful, the command prints the following informational message and exits:

    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:

  1. Purchase an MCR subscription or contact Mirantis for more information.

  2. 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.

  3. Copy the file to the data root directory and name it docker.lic. The default data root directory is var/lib/docker.

  4. Start or restart MCR.

What’s next

QuickStart: MCR on CentOS NEW

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to CentOS 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:

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

_images/workflow-qs.png

Set up the repository

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed. MCR supports the latest version of CentOS 64-bit running on x86_64.

Note

MCR supports the overlay2 storage drivers on CentOS. The following limitations apply:

  • If you enable selinux, MCR supports overlay2 on CentoOS 7.4 and higher.

  • If you disable selinux, MCR supports overlay2 on CentOS 7.2 and higher, with kernel version 3.10.0-693 and higher.

  1. Remove any existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Store http://repos.mirantis.com in an environment variable:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

    sudo -E sh -c \
    'echo "$DOCKERURL/centos" > /etc/yum/vars/dockerurl'
    
  4. Store your operating system version string in /etc/yum/vars/dockerosversion:

    sudo sh -c 'echo "<version>" > /etc/yum/vars/dockerosversion'
    
  5. Install the yum-utils that provides the yum-config-manager utility:

    sudo yum install -y yum-utils
    
  6. Enable the extras RHEL repository to ensure access to the container-selinux package that docker-ee requires:

    sudo yum-config-manager --enable rhel-7-server-extras-rpms
    
    sudo yum-config-manager --enable extras
    sudo subscription-manager repos \
    --enable=rhel-7-for-power-le-extras-rpms
    sudo yum makecache fast
    sudo yum -y install container-selinux
    
  7. AWS and Azure require that you enable another repository:

    sudo yum install -y rh-amazon-rhui-client
    sudo yum-config-manager --enable rhui-REGION-rhel-server-extras
    

    Note that REGION is a literal. It does not represent the region your machine is running in.

    sudo yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
    
  8. Add the stable MCR repository:

    sudo -E yum-config-manager \
    --add-repo "$DOCKERURL/centos/docker-ee.repo"
    

Install MCR

  1. Install the latest version of MCR and containerd:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.

    Note

    To install a specific version of MCR:

    sudo yum -y install docker-ee-<version-string> \
    docker-ee-cli-<version-string> containerd.io
    
  2. Start Docker:

    sudo systemctl start docker
    
  3. Verify that you installed MCR correctly:

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

    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:

  1. Purchase an MCR subscription or contact Mirantis for more information.

  2. 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.

  3. Copy the file to the data root directory and name it docker.lic. The default data root directory is var/lib/docker.

  4. Start or restart MCR.

What’s next

QuickStart: MCR on Oracle Linux NEW

Use this QuickStart guide to quickly deploy Mirantis Container Runtime (MCR) to Oracle Linux 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:

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

_images/workflow-qs.png

Set up the repository

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed.

MCR supports Oracle Linux 64-bit version 7.3 or later and Red Hat Compatible Kernel (RHCK) version 3.10.0-514 or later. On Oracle Linux, MCR only supports the devicemapper storage driver.

Note

On production workloads, you must use the devicemapper storage driver in direct-lvm mode, which requires one or more dedicated block devices. Mirantis recommends using fast storage, such as solid-state media.

  1. Remove any existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Store http://repos.mirantis.com in an environment variable:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

    sudo -E sh -c \
    'echo "$DOCKERURL/oraclelinux" > /etc/yum/vars/dockerurl'
    
  4. Install yum-utils to get the yum-config-manager utility, and device-mapper-persistent-data and lvm2, which the device-mapper storage driver requires:

    sudo yum install -y yum-utils \
    device-mapper-persistent-data \
    lvm2
    
  5. Enable the Oracle ol7_addons repository to ensure that you have access to the container-selinux package that docker-ee requires:

    sudo yum-config-manager --enable ol7_addons
    
  6. Add the stable MCR repository:

    sudo -E yum-config-manager \
    --add-repo \
    "$DOCKERURL/oraclelinux/docker-ee.repo"
    

Install MCR

  1. Install the latest version of MCR and containerd:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.

    Note

    To install a specific version of MCR:

    sudo yum -y install docker-ee-<version-string> \
    docker-ee-cli-<version-string> containerd.io
    
  2. Start Docker:

    sudo systemctl start docker
    
  3. Verify that you installed MCR correctly:

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

    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:

  1. Purchase an MCR subscription or contact Mirantis for more information.

  2. 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.

  3. Copy the file to the data root directory and name it docker.lic. The default data root directory is var/lib/docker.

  4. Start or restart MCR.

What’s next

QuickStart: MCR on RHEL NEW

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:

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

_images/workflow-qs.png

Set up the repository

You only need to set up the repository once, after which you can install MCR from the repository and upgrade as needed. MCR supports RHEL 64-bit version 7.4 and higher running on x86_64.

Note

MCR supports the overlay2 storage drivers on RHEL. The following limitations apply:

  • If you enable selinux, MCR supports overlay2 on RHEL 7.4 and higher (OverlayFS).

  • If you disable selinux, MCR supports overlay2 on RHEL 7.2 and higher, with kernel version 3.10.0-693 and higher.


Set up the repository for RHEL 7

  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Store http://repos.mirantis.com in an environment variable:

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'
    
  4. Store your OS version string in /etc/yum/vars/dockerosversion. Use 7 or include the minor version starting with 7.2:

    sudo sh -c 'echo "<version>" > /etc/yum/vars/dockerosversion'
    
  5. Install the yum-utils that provides the yum-config-manager utility:

    sudo yum install -y yum-utils
    
  6. Enable the extras RHEL repository to ensure access to the container-selinux package that docker-ee requires:

    sudo yum-config-manager --enable rhel-7-server-extras-rpms
    
    sudo yum-config-manager --enable extras
    sudo subscription-manager repos \
    --enable=rhel-7-for-power-le-extras-rpms
    sudo yum makecache fast
    sudo yum -y install container-selinux
    
  7. Enable another repository for AWS and Azure:

    sudo yum install -y rh-amazon-rhui-client
    sudo yum-config-manager --enable rhui-REGION-rhel-server-extras
    

    REGION is a literal. It does not represent the region your machine is running in.

    sudo yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms
    
  8. Add the stable MCR repository:

    sudo -E yum-config-manager \
    --add-repo \
    "$DOCKERURL/rhel/docker-ee.repo"
    

Set up the repository for RHEL 8

  1. Remove existing Docker repositories from /etc/yum.repos.d/:

    sudo rm /etc/yum.repos.d/docker*.repo
    
  2. Store http://repos.mirantis.com in an environment variable.

    export DOCKERURL="http://repos.mirantis.com"
    
  3. Store the value of DOCKERURL using a yum variable in /etc/yum/vars/:

    sudo -E sh -c 'echo "$DOCKERURL/rhel" > /etc/yum/vars/dockerurl'
    
  4. Store your OS version string in /etc/yum/vars/dockerosversion. Use 8 or include the minor version (for example, 8.1):

    sudo sh -c 'echo "<version>" > /etc/yum/vars/dockerosversion'
    
  5. Install the yum-utils that provides the yum-config-manager utility:

    sudo yum install -y yum-utils \
    device-mapper-persistent-data \
    lvm2
    
  6. Add the stable MCR repository:

    sudo -E yum-config-manager \
    --add-repo \
    "$DOCKERURL/rhel/docker-ee.repo"
    

Install MCR

  1. Install the latest version of MCR and containerd:

    sudo yum -y install docker-ee docker-ee-cli containerd.io
    

    If prompted to accept the GPG key, verify that the fingerprint matches 77FE DA13 1A83 1D29 A418 D3E8 99E5 FF2E 7668 2BC9 and accept it.

    Note

    To install a specific version of MCR:

    sudo yum -y install docker-ee-<version-string> \
    docker-ee-cli-<version-string> containerd.io
    
  2. Start Docker:

    sudo systemctl start docker
    
  3. Verify that you installed MCR correctly:

    sudo docker run hello-world
    

    This command downloads a test image and runs it in a container. If successful, it prints the following informational message and exits:

    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:

  1. Purchase an MCR subscription or contact Mirantis for more information.

  2. 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.

  3. Copy the file to the data root directory and name it docker.lic. The default data root directory is var/lib/docker.

  4. Start or restart MCR.

What’s next