The MCP software is provided as a combination of the following types of artifacts:
The binary packages for Ubuntu Linux operating system. These packages are built and maintained by Mirantis. They are published to package repositories in APT package manager format.
Binary Debian packages provided by a vendors of specific software product integrated into MCP. Typically, those are free open source software projects. These mirror repositories retain the original content and metadata structure provided by vendor of the repository.
Plain text artifacts are usually kept in Git repositories. Examples of such artifact include the Reclass metadata model and Jenkins Pipelines delivered as a source code.
Binary images of containers run by Docker daemon. These images are rebuilt by Mirantis or mirrored as is from their original vendors.
The MCP Release Notes: Release artifacts section describes the repositories and Docker registry sources in detail. The Salt Master node requires access to APT, Docker, and Git repositories, while all other nodes in the environment require access to the APT and Docker repositories only.
Even though it is possible to use the Mirantis and mirrors of the third-party repositories directly with the Internet access, Mirantis recommends using local mirrors for the following reasons:
You can redeploy clouds exactly the same way including all dependencies.
You have control over when and which packages to upgrade. By default,
apt-get dist-upgrade updates the packages to the latest available
version. And with a local mirror, you control when a new update
is available.
This is a good security practice not to download artifacts from the Internet but to control what software gets delivered into the datacenter.
To create the local mirrors and registries, the Internet access is required. Otherwise, you need to ship all artifacts manually through a medium, such as an external hard drive. For more information about the local mirror design, see Local mirror design.