The post Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool appeared first on Mirantis | Pure Play Open Cloud.
Try out Docker Enterprise or generate PoC clusters quickly and confidently with our new deployer
Released in Beta with Docker Enterprise 3.1 comes Mirantis Launchpad, a simple-to-use, robust CLI deployer that works out-of-the-box to let you quickly configure, deploy, tear down, and update clusters for trial, PoCs, labs, and development on almost any infrastructure, and integrates with Terraform and other tools for low-level IaaS provisioning.
Right now, Mirantis Launchpad only deploys Docker Enterprise itself, due to (now changing) limits on how Docker Trusted Registry applies license files. In coming weeks, Mirantis will add the ability to deploy DTR alongside Docker Enterprise, and add layers of custom configurability while preserving sensible defaults. The evolving result will remain the easiest way of deploying demo and (eventually) full production Docker Enterprise clusters: readily integrated with other automation you may be using, and complementary to existing deployment solutions.
Using Mirantis Launchpad
Mirantis Launchpad will run on any laptop (Windows, Mac, or Linux) and can deploy to any collection of target bare-metal or virtual machines that it can reach (via IP address or hostnames), and that can see one another. Depending on your requirements, it’s easy to set up various lab configurations, e.g., on AWS, Azure, or your desktop virtualization solution of choice.
Download the binary
Mirantis Launchpad is written in Go and distributed as binaries for direct execution on Windows, Mac, or Linux. To get started, visit our download page and grab the link for the version you need.
The binary should be downloaded to a convenient folder, optionally renamed (we renamed it to ‘launchpad’), and made executable. On (Ubuntu) Linux, we did this as follows:
chmod +x launchpad
We could then test the installation by executing launchpad with the ‘version’ argument:
./launchpad version
The ./ simply directs execution to the local file, since we didn’t add launchpad to our execution path.
This produces the output (example only):
version: 0.10.0
commit: 636ce55
Your version details may vary.
Registering yourself as a user
We’re interested in knowing how people use Mirantis Launchpad, so we ask that you register before using the software. This can be done from the command line:
./launchpad register
This will cause Mirantis Launchpad to ask your name, email, and company name, and transmit these to Mirantis.
Prepare target infrastructure
A small demo deployment can be done on as few as two virtual machines running a supported operating system and configured to comply with Docker Enterprise minimum requirements. Important: Target VMs should be configured for access via .ssh and private key, and login accounts (for Linux nodes) should be part of the sudoers group, with passwordless sudo enabled. This is the default setup for Linux VMs on most public clouds. If you created a new ssh key to use with your deployment, remember to install it on your deployer laptop (on Linux, this would typically be in the .ssh folder in your home directory).
Mirantis Launchpad will deploy Docker Enterprise manager nodes only on Linux (a Docker Enterprise requirement), but can deploy worker nodes optionally on Windows Server, providing these have been set up for access with SSH by the Administrator.
Networking considerations
Target machines must be able to:
Access the internet, so will require public IP addresses or internet access via a configured gateway.
Access one another on several ports to enable Swarm and Kubernetes networking.
Must be accessible on port 22 (SSH) to the machine Mirantis Launchpad is running on, enabling configuration.
Additional ports must also be open between the deployer laptop and target machines to use docker, kubectl and related clients with your new cluster. And ports 80 and 443 (at minimum) will be required to be open on target machines for access to applications running on the cluster.
For the sake of simplicity, it may be easiest to set up a single security group for all target machines with rules as follows:
Security group “my_security_group”
Inbound rules (IPv4 only):
Port Rule
80 Allow from anywhere
443 Allow from anywhere
All traffic Allow from security group my_security_group
All traffic Allow from <launchpad laptop IP (if laptop is not on same subnet as cluster) or jumpbox IP>
Additionally, on AWS (and perhaps other public clouds), depending on your configuration, it may be necessary to explicitly allow machine to machine communications on private IP addresses. Do this by selecting the machines, then, Actions -> Networking -> Source/destination IP checks -> Disable.
Create a config.yaml file
Next step is to create a config.yaml file for launchpad, representing your cluster’s desired configuration. The command:
./launchpad init > cluster.yaml
… will generate a basic cluster.yaml file for you to modify. Meanwhile, here’s a sample cluster.yaml for deploying a cluster on two Linux nodes, creating a manager and a worker:
apiVersion: launchpad.mirantis.com/v1beta1
kind: UCP
metadata:
name: ucp-kube
spec:
ucp:
installFlags:
– –admin-username=<username>
– –admin-password=<password>
– –default-node-orchestrator=<kubernetes_or_swarm>
hosts:
– address: <IP_or_hostname_of_manager_node>
role: manager
sshKeyPath: <path_and_name_of_private_keyfile>
user: ubuntu
– address: <IP_or_hostname_of_worker_node>
role: worker
sshKeyPath: <path_and_name_of_private_keyfile>
user: ubuntu
As with Kubernetes object definition files, the important stuff begins in the spec: stanza, where (in the ucp: stanza) you specify the cluster administrator’s username and password, and the cluster’s default orchestrator (the orchestration mode to which newly-joined nodes are assigned).
Following the ucp: stanza is an array of maps describing cluster nodes and roles. Mirantis Launchpad requires (at this point) at least one node designated as ‘manager’ and one as ‘worker.’ It can provision multiple manager nodes in a highly-available configuration, and as many workers as you like.
Mirantis Launchpad will default to accessing target nodes as ‘root.’ If this isn’t practical (e.g., on Ubuntu targets, which by default don’t permit root login, preferring instead of designate an administrative user with sudo privileges) you can use the user: parameter to specify a username.
The sshKeyPath: key, as you might expect, takes as its value the full path and filename of the private key it will use to access target servers (e.g., ~/.ssh/id_rsa).
Save cluster.yaml after making changes.
Avoiding complexity
Mirantis Launchpad seeks to avoid unnecessary complexity, so by default, for example, component versions are left unspecified, and Mirantis Launchpad will select automatically among latest compatible versions of Docker Engine – Enterprise and other artifacts. Ability to specify versions and many other details, however, is built in (see documentation). For example, you can specify the Docker Engine – Enterprise version by adding an engine: sub-stanza to the ucp: stanza:
engine:
version: 19.03.8-rc2
Note that the most recent compatible version of Docker Engine – Enterprise, at time of writing is 19.03.8-rc3, which Mirantis Launchpad would deploy unless instructed otherwise.
Full documentation of the Mirantis Launchpad YAML specification is here.
Running launchpad to deploy a cluster
At this point, you can deploy your cluster by cd’ing to the directory in which you saved launchpad, and entering:
./launchpad apply
Mirantis Launchpad finds cluster.yaml and begins by testing SSH connectivity to your target machines. As it executes, Mirantis Launchpad tests before performing operations or implementing changes, exposing errors and stopping before anything gets broken. Assuming no configuration, networking, or other errors, it will implement your configuration and terminate execution, telling you the IP address/hostname of your manager node, enabling browser connection using your admin username and password.
Mirantis Launchpad can also tear down your cluster, using the command:
./launchpad reset
… in the process, uninstalling all installed components. This will typically only be used when you no longer need the cluster, however (see below).
Idempotency and updates
More generally, like other mature deployment tools (and Kubernetes itself) Launchpad tries to function idempotently: making changes only in cases where a target system’s actual configuration differs from the configuration requested. You can thus apply (and change, and reapply) cluster.yaml to converge your cluster on a desired state, without repeating steps unnecessarily, or breaking the cluster in the process. For example, if you want to add additional servers, you can add them to the cluster.yaml file.
You can thus perform ‘launchpad apply’ as many times as needed (to fix basic configuration errors such as the wrong path to a private key), add or remove nodes, or update components.
Integrating Mirantis Launchpad with other tools
Users of Terraform will appreciate that Mirantis Launchpad can consume Terraform infrastructure description files to deploy clusters on infrastructure provisioned with this tool. The files need to be converted from JSON to YAML (trivial, using a tool like ‘yq’ or equivalent). An upcoming tutorial will address ways of integrating Mirantis Launchpad with Terraform and other automation.
Now that you have a working cluster, check out this tutorial showing how to use it, and join us for a webinar on the new features in Docker Enterprise 3.1.
The post Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis
Published by