Mirantis Container Runtime 20.10.13 Released
Docker Engine-compatible, hardened and secure, with Windows Server 2022 support from Mirantis
Mirantis Container Runtime (MCR), now in release 20.10.13, is the open source Docker-compatible enterprise container engine.
Who needs MCR? You might. One reason is if you need to run a secure enterprise container engine on Windows Server 2022 hosts. With this latest release, Mirantis is providing fully-validated support for MCR on Windows Server 2022.
Mirantis Container Runtime supports FIPS 140-2 encryption and enables, in combination with Mirantis Secure Registry, a secure software supply chain with execution prevention for all but properly (i.e., cryptographically) signed container images.
To maintain FIPS compliance, the distro is periodically revalidated by third parties against levels of this standard, as these evolve and come into wide use. Additionally, MCR forms a foundational component of container solutions from Mirantis certified and validated to comply with Federal security standards like the Security Technical Implementation Guide provided by the Defense Information Systems Agency (DISA-STIG).
But there are lots more reasons for using Mirantis Container Runtime, particularly as platforms become larger and more complex, and requirements for support increase.
Docker Engine-compatible, but enterprise-class
Maintaining compatibility with open source Docker Engine is table stakes for those who want to accelerate container software development. Most cloud native coders learn container development using Docker. Over years of exposure, they become deeply familiar with it, and with the ecosystem of development and workflow tools, services, CI/CD, build systems, and options supported by and targeting the Docker runtime. They also become somewhat dependent on the community, and on the massive library of resources, documentation, training, and content explaining how Docker Engine works.
Mirantis Container Runtime keeps all this skill, knowledge, and community support relevant, because MCR is derived and packaged directly from Moby, the Docker component assembly system. MCR is not a fork (potentially with its own quirks and proprietary aspects) but effectively a distro, using Moby assemblies and adding valuable special features and hardening. Like Docker CE, MCR is compatible with the majority of Docker-compatible container development and workflow tools (and platforms, and services) available today.
Mirantis engineers contribute to Docker – we have a long history of becoming importantly-productive contributors to the open source projects we esteem and consume--and in reward for their hard and consistent work, our contributors have earned “maintainer” status on the relevant Docker branch, as well as what Docker calls “upstream rights.”
In practical terms, this means several good things for MCR users:
Regular updates enabling access to community-provided-and-vetted improvements in the Docker Engine core components
Zero concern that MCR will migrate significantly away from the open source Docker Engine standards for command/control
Retention of Docker Engine core features, such as Swarm-mode clustering, that many users value highly
And, not incidentally, the fact that developers using open source Docker Engine can reliably produce workloads and tooling that run on and with Mirantis Container Runtime releases (because the core engines are the same, under the hood - again, MCR is a Moby-based distro).
Says Robert Illing, MCR Product Manager at Mirantis: “We add a ton of value when we package our distro. For example, we add our own security shim that provides encryption enabling FIPS validation, and when dockershim was recently deprecated, we packaged cri-dockerd, enabling interoperation with Kubernetes. But if you removed this and our (hundreds of other) value-adds, we would be 100% the same, and we could cut a release in a matter of minutes to send to testing to review it.”
Having upstream rights also helps MCR users in other ways. For example, Mirantis can write hotfixes for any issues our customers discover, distribute these as patches immediately, and deliver them upstream so the community at large can benefit.
A fully-supported, consistent foundation
Community support and public-accessible documentation may be fine for learning containers and getting up and running with single engines. But the fact that MCR is fully supported plays hugely in making it an optimal foundation for more complicated container infrastructures and application-hosting paradigms.
Out of the box, MCR nodes can be clustered using built-in Swarm technology, making it easy to define and manage (simpler) multi-container applications, gain application resilience, and even support serverless computing and other lower-code platforms at limited scales. But even small-scale Swarms mean you’re adding a layer of complexity – so doing this with fully-supported MCR (vs. community-supported Docker Engine) is fairly easy to justify.
But that’s just the beginning. Maybe your organization needs more sophisticated container orchestration, more platform choices, more operational flexibility. Perhaps you want to:
Build out a large Kubernetes-based datacenter
Deliver and centrally manage dev/test/production Kubernetes or Swarm clusters rapidly on diverse platforms (for example, in an on-premises datacenter – with or without a local infrastructure-as-a-service framework such as OpenStack, hosted bare metal, public virtual private cloud, edge hardware clusters, and so on) in stand-alone or hybrid configurations
Build an OpenStack cluster (or clusters) on arbitrary infrastructure(s), riding on a Kubernetes substrate and hosting a containerized OpenStack backplane for resilience and in-place upgradability …
Or all of the above!
If so, there are clear benefits to running a Docker-compatible, Fed-level-secure, multi-host-OS-capable, and fully/actively-supported container runtime as the foundation for such complex, critical, and growing infrastructure. Which is why Mirantis Container Runtime is the default container engine for Mirantis products that let you do all these cool things – products like Mirantis Container Cloud, Mirantis Kubernetes Engine, and Mirantis OpenStack on Kubernetes.
Using MCR everywhere under complex container infra (vs. possibly-inharmonious versions of open source Docker Engine, for example) gives developers greater assurance that workloads will “just work,” no matter which part of your infrastructure they end up hosted on. Using licensed MCR also gets them support for runtime issues – support that’s also available all the way up the Mirantis product stack, regardless of where you deploy Mirantis solutions.
Indeed, there are benefits to using MCR (in harmony with other Mirantis solutions), even if you don’t want to engineer or operate clouds. Mirantis ZeroOps can do all this for you: build, scale, and operate container clouds of arbitrary complexity under strict SLAs and at predictable costs, so you enjoy “as a service” container orchestration (and/or IaaS) and can focus more attention, headcount, and resources on building and delivering great applications. MCR is just one reason why ZeroOps can work, and scale, and remain affordable – it’s based on open source (like all pivotal Mirantis products), but hardened, made resilient, and made remotely operable on any base infrastructure.
Try MCR free!
Other updates in this MCR release include fixes for several newly-discovered Common Vulnerabilities and Exposures (CVEs), fixes to issues in Dockerfiles, issues arising from port conflicts, and at the packaging level, updating Golang to version 1.17.13.
MCR users and prospective users can learn more about the latest release, and you can download and try MCR free.
