Monat: Mai 2020

Fast, simple Docker Enterprise deployments with the Mirantis Launchpad CLI Tool

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

Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs

The post Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs appeared first on Mirantis | Pure Play Open Cloud.
Docker Enterprise 3.1 is first major release since November’s Docker Enterprise acquisition
Campbell, CA, May 28, 2020 — Mirantis, the open cloud company, today announced the general availability of Docker Enterprise 3.1, the first major release since the company acquired the Docker Enterprise business in November 2019.
Docker Enterprise customers can now further expand their container and Kubernetes adoption to include their most valuable use cases and applications. Now, administrators of a Docker Enterprise cluster can easily join Windows Server 2019 nodes to a Docker Enterprise cluster and enable end users to use Kubernetes to orchestrate Windows containers.
Docker Enterprise 3.1 also adds greater stability and additional features, with an updated version of Kubernetes and Nvidia GPU integration for AI/Machine Learning, IoT, and Big Data applications. It also allows users to easily enable Istio ingress for a Kubernetes cluster with the click of a button.
At the same time, Mirantis is introducing new support options for all Docker Enterprise customers: LabCare, ProdCare, and OpsCare. Previously, the highest level of support available was 24×7 for Severity 1 cases; with Mirantis ProdCare, customers have 24×7 support for all cases. With Mirantis OpsCare, customers get remote managed operations for their environment with enhanced SLAs, a designated customer success manager, proactive monitoring and alerting, and dedicated resources with ongoing health checks and reviews.
“Seven hundred and fifty customers adopted Docker Enterprise as the fastest way to build and run modern apps at enterprise scale,” said Adrian Ionel, co-founder and CEO of Mirantis. “Docker Enterprise 3.1 doubles down on that promise with the only production-ready Kubernetes for Windows capability and SLAs for mission critical applications.”
The latest capabilities of Docker Enterprise 3.1 include:

Certified Kubernetes 1.17

The upstream Kubernetes included in Docker Enterprise has been incremented to the 1.17 release, bringing greater stability and various features introduced after release 1.14, such as Windows support and scheduler improvements.

Kubernetes on Windows
Kubernetes clusters managed by the Universal Control Plane (UCP) in Docker Enterprise can now include nodes running Windows Server. Additionally, pods can interoperate when running on nodes in a mixed cluster consisting of Windows Server and Linux nodes.

GPU Orchestration
Nvidia GPU integration is now included in Docker Enterprise, with a pre-installed device plugin. Users can view GPU nodes inside Docker UCP, request GPUs through standard YAML pod specifications, and create policies for GPUs around access control and shared resources.

Istio Ingress for Kubernetes
Developers can enable Istio Ingress for a Kubernetes cluster with the click of a button. Istio will be automatically added to the cluster with intelligent defaults to get started quickly. Users can additionally configure proxies, add external IPs, and more – all from a simplified, user-friendly interface. Users can also create and review traffic routing rules, with virtual services supported out of the box.

New Mirantis Launchpad CLI Tool for Deployment & Upgrades on any infrastructure (all major public clouds, on-prem operating systems and VMware)
A new Command Line Interface (CLI) tool deploys a cluster in minutes with ready-to-use Docker Engine – Enterprise, Kubernetes, and Universal Control Plane.

“The market leadership of the Docker Enterprise platform combined with Mirantis’ reputation for customer care and technical expertise makes the Docker 3.1 release a compelling fit for our customers in support of their app modernization journey,” said Glen Tindal, Solutions Business unit leader, Capstone IT. “Adding Windows Server support with Kubernetes gives Capstone IT’s customers greater business flexibility and choice based on their use cases.”
Docker Enterprise is the only platform that enables developers to seamlessly build, share and safely run any applications anywhere – from public cloud to hybrid cloud to the edge. One third of Fortune 100 companies use Docker Enterprise as their high-velocity innovation platform.
On June 4th, Mirantis will host a live webinar to walk through the highlights in Docker Enterprise 3.1, and provide a live demonstration of its capabilities. To register for the webinar, sign up here: https://info.mirantis.com/webinar-docker-enterprise-3-1.
 The post Mirantis Launches New Docker Enterprise Release, Adds the only production-ready Kubernetes Clusters on Windows Servers and Industry Leading SLAs appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis

Announcing Docker Enterprise 3.1 General Availability

The post Announcing Docker Enterprise 3.1 General Availability appeared first on Mirantis | Pure Play Open Cloud.
As you may know, last November Mirantis acquired the Docker Enterprise business from Docker, Inc., and since then we’ve been, as you might imagine, quite busy!  The two teams have been integrating their efforts, and combining the best of both worlds into the best products, services, and support we can bring to customers. 
Now, six months later, we are proud to announce the general availability of Docker Enterprise 3.1, with new features that let you up your Kubernetes game even more.  This new release includes lots of new features, including:

K8s on Windows
GPU support
Istio Ingress
A new UCP Installer
Upgrade to K8s 1.17

Let’s look at each of these in turn.
Kubernetes on Windows
From the start, Kubernetes has been an extremely Linux-centric project, which is understandable, as containers themselves evolved from Linux constructs such as cgroups. But what does that mean for Windows developers? After all, Docker runs on Windows, and makes it possible to run Linux containers (albeit using virtualization).
Over the last few Kubernetes releases, the community has been working on the ability to run on Windows, and with Docker Enterprise 3.1, you now have the ability to easily add Windows worker nodes to a Kubernetes cluster and manage them just as you would manage traditional Linux nodes with UCP.
The ability to orchestrate Windows-based container deployments lets organizations leverage the wide availability of components in Windows container formats, both for new application development and app modernization. It provides a relatively easy on-ramp for containerizing and operating mission-critical (even legacy) Windows applications in an environment that helps guarantee availability and facilitates scaling, while also enabling underlying infrastructure management via familiar Windows-oriented policies, tooling, and affordances. Of course, it also frees users to exploit Azure Stack, and/or and other cloud platforms offering Windows Server virtual and bare metal infrastructure.
GPU support
There was a time when Graphic Processing Units (GPUs) were just for gaming, but that time has long since passed; now they are an essential part of efficiently performing the heavy calculations that are becoming more and more a part of enterprise life. Even before Machine Learning and Artificial Intelligence crept onto the enterprise radar, large corporations had data mining operations that have prepared them for the coming onslaught.
Docker Enterprise 3.1 with Kubernetes 1.17 makes it simple to add standard GPU worker node capacity to Kubernetes clusters. A few easily-automated steps configure the (Linux) node, either before or after joining it to Docker Enterprise, and thereafter, Docker Kubernetes Service automatically recognizes the node as GPU-enabled, and deployments requiring or able to use this specialized capacity can be tagged and configured to seek it out. 
This capability complements the ever-wider availability of NVIDIA GPU boards for datacenter (and desktop) computing, as well as rapid expansion of GPU hardware-equipped virtual machine options from public cloud providers. Easy availability of GPU compute capacity and strong support for standard GPUs at the container level (for example, in containerized TensorFlow) is enabling an explosion of new applications and business models, from AI to bioinformatics to gaming. Meanwhile, Kubernetes and containers are making it easier to share still-relatively-expensive GPU capacity, or configure and deploy to cloud-based GPU nodes on an as-needed basis, potentially enabling savings, since billing for GPU nodes tends to be high.
Istio Ingress
When you are using Kubernetes, you don’t want to expose your entire cluster to the outside world. The safe and secure thing to do is to expose only as much of your cluster as necessary to handle incoming traffic. Ideally, you would want to be able to configure this part and have additional handling logic based on routes, headers, and so on. 
You may have heard of Istio, the service mesh application that gives you extremely powerful and granular control of traffic within the parts of a decentralized application.  Part of Istio is Istio Ingress, a drop-in replacement for Kubernetes Ingress, which controls the traffic coming into your cluster.
Docker Enterprise 3.1 includes Istio Ingress, which can be controlled and configured directly from UCP 3.3.0. That means you can easily enable or disable the service directly from the user interface or the CLI.
Mirantis Launchpad CLI Tool for Docker Enterprise
Docker Enterprise is meant to make your life easier by giving you a more straightforward way to perform tasks such as adding servers to your Kubernetes or Swarm clusters, but before you ever get there, you have to install it. Until now, this has been a somewhat manual process, but Docker Enterprise 3.1 includes a new CLI tool, Mirantis Launchpad, that takes the pain and complexity out of deployment and upgrades.
The process is simple. All you need to do is download the installer, tell it where to find your servers, and let it go. (There are a couple of optional intermediate steps depending on your deployment preferences, but we’ve tried to make the process as frictionless as possible.)
For more information on how to get and use Mirantis Launchpad, click here.
Upgrade to K8s 1.17
Finally, Docker Enterprise 3.1 upgrades the included version of Kubernetes to 1.17, which means you now have access to all of the features that come with that release, such as:

IPv4/IPv6 dual stack support and awareness for Kubernetes pods, nodes, and service
The ability to automatically prevent workloads from being scheduled to a node based on conditions such as memory usage or disk space
CSI Topology support, which attempts to ensure that workloads are scheduled to nodes that actually host the volumes they’re going to use, improving speed and performance
Environment variables expansion in SubPath mount and defaulting of CustomResources, which expand capabilities for end user developers
The ability to use RunAsUsername for Windows in addition to Linux

Where to get more information
If you’d like to try out these features, please go ahead and download the Mirantis Launchpad CLI Tool and try out Docker Enterprise 3.1! You can also can see these features in action, at our live webinar on June 4. We look forward to seeing you there!
The post Announcing Docker Enterprise 3.1 General Availability appeared first on Mirantis | Pure Play Open Cloud.
Quelle: Mirantis