 Hi everyone, I hope you're having a great Kubicon. My name is John Jane Shade from Morantis. In this video I'll be demonstrating Morantis Container Cloud, a tool for delivering consistent container orchestration clusters across one, more, or many different infrastructures. As many are aware, Morantis acquired Docker Enterprise from Docker about a year ago. We've had two releases since that time, the first being an upgrade to the core cluster model, now called Morantis Cluster Engine, which provides Kubernetes and swarm orchestration over multiple node types, in which now includes Istio Ingress as well as Calco Networking as defaults. The second release, about six weeks ago, was the thing I'll be focusing on mostly in this demo. It's called Morantis Container Cloud. Its goal is to help solve cloud journey problems for developers, IT operators, and organizations. Today, a lot of organizations are coming to terms with Kubernetes, or maybe somewhat simpler kinds of container orchestration like swarm, at the same time as they're exploring and sort of trying to refine hybrid cloud or multi-cloud. So they have DOI clusters in-house, maybe several types, they have more types maybe in public cloud flavors. And this model is fun for a while, so long as stakes are low and nobody asks hard or scary questions, like, okay, how do we keep all these clusters updated? How do we easily provide clusters via self-service over in environments? Or how do we monitor all these things in one place? Or how do we build out any kind of deep CI that works more or less the same way everywhere and helps us enforce enterprise-y policies like preventing unscanned, unsigned, unpromoted images from getting executed in production? And clearly, this becomes unscale-friendly quickly. So then, folks sometimes fear in the other direction and go all in on one provider. But depending on how you do that, this may lock you into very deep and expensive stack. It may limit the way you design workflows and workloads. It may limit how you build out into multi-cloud and into edge and other places, so it constrains choice in meaningful ways. So Moranus wanted to solve this problem. We wanted to let people deploy ready-for-work clusters configured, okay, within some limits, pretty much however people wanted, anywhere they liked, on private clouds, public clouds, or bare metal. We wanted to do a good job of integrating them with services provided by their host infrastructures and clouds, so folks would get state-of-the-art production-ready clusters that perform great and were cost-optimized to their environments. We wanted to deliver them already telematrized for metrics and analytics, so operators and developers could drill in from wherever they are, while also providing a single point of integration for stuff like notifications. And we wanted operators to be able to life-cycle, manage scale clusters up and down, update, upgrade, or retire child clusters easily with no downtime for applications or control plane functionality. So that's what Moranus Container Cloud is. It's a Kubernetes cluster running management in LCM and observability, usually integrated with corporate directory, so it has a single source of truth for IAM everywhere. You can put it anywhere convenient. For example, on an internal infrastructure as a service cloud, it can then manage local and remote infrastructures and deploy and LCM work-a-day clusters configured, however. You can build self-service portals that talk directly to the Container Cloud instance API and give developers, teams, and operators clusters as they need them wherever that might happen to be. And all the clusters are consistent, so you get dead simple to relatively easy workload portability among them, and you can use whatever tools you'd like to automate around all of them. So what I'm going to do now is a demo that's pretty much the same as you might experience yourself if you went to our website, went to the download page, downloaded the product and its license and install it yourself. I'm going to deploy this instance of Container Cloud on AWS. Then I'm going to use it to deploy a child cluster, then access that cluster several different ways on the way, exploring observability and other features. It's not a flashy demo. We're looking for a simple, painless, secure consistency so that you can ship software faster. Note that throughout the demo, the flow of time will be altered to avoid boredom. Here's Christopher Plummer from the 1978 movie Star Crash with more. Imperial battleship, halt the flow of time. To begin installing an instance of Container Cloud, you download a starter shell script and a license file from maranthus.com and put them in a convenient place. Then you make the script executable and run it. Then copy the license file into that subdirectory. Next, since we're deploying this instance of Container Cloud on AWS, we need to open up a template file in the template slash aws subdirectory and copy in the AMI ID of an appropriate host OS image. In this case, I'm using an AMI for Ubuntu 1804 LTS in an SSD configuration. Now we export credential variables for the administrative account that will be used to define resources to host the instance. This is the only time and administrative role of high privileges is required. And then we run the preliminary deployer, which creates a CloudFormation template to create resources for the cluster. This creates a Bootstrap user for us with more limited permissions used to actually deploy software under the machines. We retrieve the Bootstrap user's AWS ID and secret key and use them to replace the values for the administrative account. That's all the configuration required for deployment. So now we run the main Bootstrap script. Imperial battleship accelerate the flow of time. And there we are. Boom. Easy peasy. So then we should save all that useful information and we should look on our CAS Bootstrap directory where the deployer has thoughtfully left us a kube config file for the Container Cloud host and a passwords YAML file containing important system passwords. We're going to grab the password for the keycloak security system and use it to change all the passwords for the three default account roles called operator, writer, and reader to something harder to guess than password. Of course, there is a simple way of injecting passwords prior to deployment, but I didn't do it because I'm lazy. Now I can log into the Container Cloud instance itself. Creating a child cluster is very simple. Start by clicking Create Cluster and give your cluster a name. Then add machines, at least three manager nodes and two workers. Adjust enough to permit a zero downtime rolling update with some headroom free to stop and drain nodes of each type neatly under normal loading. Again, we alter the flow of time. And now we have a child cluster. We can visit the cluster's web UI using the keycloak-based single sign-on. The web UI lets us examine nodes, explore objects in the cluster, and edit and change their definitions. We can see the Stacklight namespace, for example, in which telemetry deployments and related lifecycle management reside. We can also see how the deployer has configured persistent volume claims on AWS Block Storage, just one example of how Container Cloud pursues optimal deployment strategies for the different host infrastructures it manages. We can also download a client bundle for our user. Back in our laptop, we can unzip it and source the ENV-SH file to enable kubectl connectivity. We also have a kube.yaml file defining our new cluster, and the most convenient way to use that is to fire up Lens, the Kubernetes IDE, and add the new cluster with a single click. As you'll notice, Lens immediately finds the cluster's existing Prometheus and can show us simple metrics helpful for programming and forensics. Lens can also show us logs, let us sign into container shells, and provide smart context-aware terminals to automate common transactions, like those performed with kubectl edit and permit direct use of kubectl with automatic credential management. Jumping back into Container Cloud, we can view operational metrics for the child cluster by clicking on its Grafana button. As you'd expect, this opens a pretty comprehensive survey dashboard, of course, entirely customizable, one of a very large hierarchy of included dashboards that lets operators quickly survey and explore the health of the Container Cloud instance itself and the distributed region managers and the entire collective of child clusters at any desired level of detail. So that's the quick start. Without all the alterations in the flow of time and end-to-end proof of concept deployment if Container Cloud takes about 52 minutes, which isn't a huge investment for a solution that can help you simplify, secure, create consistency, manage from the top, and ship software faster. We hope you'll stop by morandus.com, download Container Cloud, and take it for a test drive soon. If you have any questions, reach out to me on email. Thank you.