MCP Deployment Guide version q4-18 Mirantis Cloud Platform Deployment Guide Copyright notice 2021 Mirantis, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. No part of this publication may be reproduced in any written, electronic, recording, or photocopying form without written permission of Mirantis, Inc. Mirantis, Inc. reserves the right to modify the content of this document at any time without prior notice. Functionality described in the document may not be available at the moment. The document contains the latest information at the time of publication. Mirantis, Inc. and the Mirantis Logo are trademarks of Mirantis, Inc. and/or its affiliates in the United States an other countries. Third party trademarks, service marks, and names mentioned in this document are the properties of their respective owners. ©2021, Mirantis Inc. Page 2 Mirantis Cloud Platform Deployment Guide Preface This documentation provides information on how to use Mirantis products to deploy cloud environments. The information is for reference purposes and is subject to change. Intended audience This documentation is intended for deployment engineers, system administrators, and developers; it assumes that the reader is already familiar with network and cloud concepts. Documentation history The following table lists the released revisions of this documentation: Revision date Description February 8, 2019 Q4`18 GA ©2021, Mirantis Inc. Page 3 Mirantis Cloud Platform Deployment Guide Introduction MCP enables you to deploy and manage cloud platforms and their dependencies. These include OpenStack and Kubernetes based clusters. The deployment can be performed automatically through MCP DriveTrain or using the manual deployment procedures. The MCP DriveTrain deployment approach is based on the bootstrap automation of the Salt Master node that contains MAAS hardware nodes provisioner as well as on the automation of an MCP cluster deployment using the Jenkins pipelines. This approach significantly reduces your time and eliminates possible human errors. The manual deployment approach provides the ability to deploy all the components of the cloud solution in a very granular fashion. The guide also covers the deployment procedures for additional MCP components including OpenContrail, Ceph, StackLight, NFV features. Seealso Minimum hardware requirements ©2021, Mirantis Inc. Page 4 Mirantis Cloud Platform Deployment Guide Plan the deployment The configuration of your MCP installation depends on the individual requirements that should be met by the cloud environments. The detailed plan of any MCP deployment is determined on a per-cloud basis. For the MCP reference architecture and design overview, see: MCP Reference Architecture: Plan an OpenStack environment or MCP Reference Architecture: Plan a Kubernetes cluster depending on the type of your deployment. Caution! Kubernetes support termination notice Starting with the MCP 2019.2.5 update, the Kubernetes component is no longer supported as a part of the MCP product. This implies that Kubernetes is not tested and not shipped as an MCP component. Although the Kubernetes Salt formula is available in the community driven SaltStack formulas ecosystem, Mirantis takes no responsibility for its maintenance. Customers looking for a Kubernetes distribution and Kubernetes lifecycle management tools are encouraged to evaluate the Mirantis Kubernetes-as-a-Service (KaaS) and Docker Enterprise products. At the same time, MCP provides a flexible reduced prebuilt mirror image that you can customize depending on the needs of your MCP deployment after the initial bootstrap is performed. The usage of the prebuilt mirror image is essential in case of an offline MCP deployment scenario. The prebuilt mirror image contains the Debian package mirror (Aptly or flat deb repositories), Docker images mirror (Registry), Git repositories mirror, and mirror of the Mirantis Ubuntu VM cloud images (VCP). This guide includes the steps required for the case with the additional prebuilt VM deployment on the Foundation node. ©2021, Mirantis Inc. Page 5 Mirantis Cloud Platform Deployment Guide Prepare for the deployment Create a project repository An MCP cluster deployment configuration is stored in a Git repository created on a per-customer basis. This section instructs you on how to manually create and prepare your project repository for an MCP deployment. Before you start this procedure, create a Git repository in your version control system, such as GitHub. To create a project repository manually: 1. Log in to any computer. 2. Create an empty directory and change to that directory. In the example below, it is mcpdoc. 3. Initialize your project repository: git init Example of system response: Initialized empty Git repository in /Users/crh/Dev/mcpdoc/.git/ 4. Add your repository to the directory you have created: git remote add origin <YOUR-GIT-REPO-URL> 5. Verify that Git and your local repository are set up correctly by creating and pushing a test file to your project repository. Run the following example commands: Note The example commands below require the Git and GitHub credentials to be created and configured for your project repository. git remote add origin https://github.com/example_account/mcpdoc.git git config --local user.email "[email protected]" git config --local user.name "example_gituser" git config -l echo "#. mcpdoc" >> README.md git add README.md git commit -m "first commit" git push -u origin master ©2021, Mirantis Inc. Page 6 Mirantis Cloud Platform Deployment Guide 6. Create the following directories for your deployment metadata model: mkdir -p classes/cluster mkdir nodes 7. Add the Reclass variable to your bash profile by verifying your current directory using pwd and adding the string that exports the Reclass variable with the output value of the pwd command: pwd vim ~/.bash_profile export RECLASS_REPO=<PATH_TO_YOUR_DEV_DIRECTORY> Example of system response: /Users/crh/Dev/mcpdoc/ "~/.bash_profile" 13L, 450C export RECLASS_REPO="/Users/crh/Dev/mcpdoc/" 8. Log out and log back in. 9. Verify that your ~/.bash_profile is sourced: echo $RECLASS_REPO The command must show the value of your RECLASS_REPO variable. Example of system response: /Users/crh/Dev/mcpdoc/ 10 Add the Mirantis Reclass module to your repository as a submodule: . git submodule add https://github.com/Mirantis/reclass-system-salt-model ./classes/system/ Example of system response: Cloning into '<PATH_TO_YOUR_DEV_DIRECTORY>/classes/system'... remote: Counting objects: 8923, done. remote: Compressing objects: 100% (214/214), done. remote: Total 8923 (delta 126), reused 229 (delta 82), pack-reused 8613 Receiving objects: 100% (8923/8923), 1.15 MiB | 826.00 KiB/s, done. Resolving deltas: 100% (4482/4482), done. Checking connectivity... done. ©2021, Mirantis Inc. Page 7 Mirantis Cloud Platform Deployment Guide 11 Update the submodule: . git submodule sync git submodule update --init --recursive --remote 12 Add your changes to a new commit: . git add -A 13 Commit your changes: . git commit 14 Add your commit message. Example of system response: [master (root-commit) 9466ada] Initial Commit 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 160000 classes/system 15 Push your changes: . git push 16 Proceed to Create a deployment metadata model. ©2021, Mirantis Inc. Page 8 Mirantis Cloud Platform Deployment Guide Create a deployment metadata model In a Reclass metadata infrastructural model, the data is stored as a set of several layers of objects, where objects of a higher layer are combined with objects of a lower layer, that allows for as flexible configuration as required. The MCP metadata model has the following levels: • Service level includes metadata fragments for individual services that are stored in Salt formulas and can be reused in multiple contexts. • System level includes sets of services combined in a such way that the installation of these services results in a ready-to-use system. • Cluster level is a set of models that combine already created system objects into different solutions. The cluster module settings override any settings of service and system levels and are specific for each deployment. The model layers are firmly isolated from each other. They can be aggregated on a south-north direction using service interface agreements for objects on the same level. Such approach allows reusing of the already created objects both on service and system levels. This section describes how to generate the cluster level metadata model for your MCP cluster deployment using the Model Designer web UI. The tool used to generate the model is Cookiecutter, a command-line utility that creates projects from templates. While generating a metadata model, you can enable automated encryption of all secrets for the Salt Master node .iso file. Note The Model Designer web UI is only available within Mirantis. The Mirantis deployment engineers can access the Model Designer web UI using their Mirantis corporate username and password. The workflow of a model creation includes the following stages: 1. Defining the model through the Model Designer web UI. 2. Optional. Tracking the execution of the model creation pipeline in the Jenkins web UI. 3. Obtaining the generated model to your email address or getting it published to the project repository directly. Note If you prefer publishing to the project repository, verify that the dedicated repository is configured correctly and Jenkins