 All right, so I'm Matthew Ward. First off, I want to give all of you guys a round of applause. We're staying to the very end, to the last session. I mean, come on, guys. You guys are the true champions here, right? So I was forced to stay. You guys chose to stay. All right, so what we're going to talk about is auto healing databases for administrators and developers. So first, a little bit about me. So I work for Red Hat. I even have the hat. So I'm a husband and father of four. This is my first time in Brno. And unfortunately, my co-presenter, who actually works for Couchbase, is ill. And so he is not going to be here. So that limits some of the QA stuff that we can get into, because I'm not an expert in Couchbase. So let's go ahead and get into it. One of the things that I'm working on, so I'm technical product marketing for partner solutions. I'm sure that means nothing to anyone here. But ultimately, what that means is that I'm working with partners to help them come up with strategies for utilizing Red Hat. Primarily right now, it's all open shift. And how do we take that stuff and actually make it usable? So this is a byproduct of one of those examples. I'm putting together what we're calling partner field kits, which is basically content, collateral, demos, things like that for our partners to use and for internal Red Hat resources to use. We're going to be highlighting Couchbase and the Couchbase operator today. So this was a byproduct of some interest from customers. So customers are coming to us and saying, hey, we really want to see Couchbase running in this automated way. They've chose to partner with Red Hat and run it on open shift. So we are constantly being talked about and constantly talking about this digital transformation and all these things, how apps are changing, how you're moving from monoliths to microservices. This is a pretty common story. And I'm sure since you've heard DevConf and this is the last talk, you've at least heard probably 10 other people talk about it today, let alone this week. So, but basically they come in with the same thing. So we need to have new paradigms when it comes to managing data. So we have this great capability of managing code and compute and moving that around however we like. We need to also take the gravity of data and make sure that we can provide the same high availability, the same automation, the same tooling to that. And so we're doing that using operators. So if you look at the sort of general CNCF ecosystem, Kubernetes is only a small piece of it, right? And this is the day-to-day life of someone who's trying to go kube native or cloud native or microservice application. There's a ton of different things that go here. So the sort of common denominator we're moving everyone towards is the operator framework. So one of the things that makes Couchbase awesome is that they can deploy just like OpenShift, just like Red Hat, just like containers on bare metal VMs in public cloud, private cloud. But ultimately they're helping us with the data story and we're helping them with the automation story around multi-cloud and hybrid cloud. So you can look and design one framework, one set of tooling, that you can then move to any cloud you want, any infrastructure you want when you're running on top of OpenShift or Kubernetes. So everybody here familiar with the operator framework? All right, just a quick overview for those who didn't raise their hand. So the installation, it's basically just a way of orchestrating and automating the deployment of certain tools and certain applications. So it gives us a strict framework to follow, to life cycle and manage all this stuff. So ultimately what this means is that instead of having ops people managing all of the load balancing, rebalancing, managing failures and things like that, we codify that and then they handle it for us. So the CouchBase Autonomous Operator basically does that. It's a great example of how to manage this database and how to deploy and deal with failures and spin up, spin down, things like that. And it is published now on the Red Hat Container Catalog. That is their primary resource for managing this. And what we're gonna do is we're actually gonna spend most of the time doing a no-net live demo on an OpenShift environment to see and discuss what the operator looks like and how we can do some stuff. I'm also going to do something that's probably not very common. I'm gonna ask you at one point to pull out your phone and we're going to tweet anything you like to a certain hashtag. And it would be any of these hashtags down here and I'll come back to it. And what we're gonna do is we're gonna deploy a four-node CouchBase database and then we're gonna deploy three microservices on top of this database. And we're going to have you guys text in and pull in data and while that data is being ingested, we're gonna fail one of the nodes and see what happens. And so we should be able to continue streaming this data. It shouldn't be any problems whatsoever, but hopefully the demo gods are with us. So instead of doing a lot of copying and pasting, I've automated some of this stuff. So hopefully this should be... All right. Can everybody see that? Should I make it bigger? So the first thing we're gonna do is we're gonna deploy a custom resource definition. So a standard resource definition or resource definition as they call it in Kubernetes and OpenShift is basically things like deployments, stateful sets, demon sets. It's certain constructs that we call and can use and the system knows how to operate those. So what we're gonna do is we're gonna deploy a custom resource set that is around CouchBase. And so just a quick look. This is the YAML file for deploying that custom resource definition. And so this custom resource we're gonna be using is called CouchBase cluster. And so the code in the YAML files that we're gonna be deploying are just gonna be calling this resource. And this resource sort of defines the parameters in which it can operate. All right. So this is going to be deploying that CRD. We might get a few errors around user stuff. User already exists because I'm deploying a couple other YAML files in the backend. But that's all normal. We're also deploying secrets. So this secret file that we're deploying is going to basically define what the CouchBase username and password is for the web interface that we're gonna be connecting to. So we're gonna go ahead and take a look at the operator. So here is the YAML file for the operator. So what we're gonna do is we're setting replicas one. The application name is gonna be a CouchBase operator. We're defining the image, which you can see is coming from Red Hat. And we're just defining a few things in here. It's really nothing super complicated, but we need to make sure that the CouchBase operator is running. Awesome. So now we're gonna deploy some secrets and a basic CouchBase cluster. Okay. So now we're deploying a basic cluster and the basic cluster is defined right here. So you can see here that there's different default sets that are set up. We're gonna be creating a bucket called tweets and we're going to be using the CouchBase type. And so all of this is sort of defined. We're defining four servers and let's quickly jump back to the... So one of the things that makes CouchBase a good database to do this with is that CouchBase is designed from the beginning to be microservices. So you're not operating necessarily in a master slave situation. You can scale the database in different ways for different resources that it offers and different services that it offers. So it's not just a NoSQL document database. It's also a caching database. So it actually writes all of the data into memory first before it writes it to disk. It's a document store, key value store. It does full text search. You can do analytics with it and there's some eventing capabilities. They also are offering a mobile version of this. So you can actually, as a developer, run CouchBase on a mobile phone. And so it gives you a lot of different platforms to manage this stuff from. That's about all I know about CouchBase. So, and then we're gonna switch back here and see, all right, we have the first node running. We're gonna wait for the rest of them to get running. So what's happening now is we're basically downloading the image from the Red Hat Registry into each one of the nodes and then starting the execution of those containers on each one of those nodes. So has anyone here used CouchBase before or have heard of CouchBase before? Couple nods. So while this is going, one of the other things that we're working on, I've started working with several different partners on building these partner field kits. And so ultimately, what we're trying to do is we're trying to create these sort of dynamic, livable demos for someone to be able to pull and use and keep them public. So if you have an OpenShift environment, this runs on MiniShift. This runs on any OpenShift environment that you can deploy operators onto. We're getting there, we're getting closer. So one of the other partners that we work with is BlackDuck. So how many of you have heard of Synopsys? BlackDuck, no, looks like the Red Haters might have, but people aren't in Red Hat haven't. So one of the partners that we're working with, they do static code analysis. And so they're looking to us for a platform to help them do static code analysis a little bit better. And it gives them the dynamic capabilities of spinning up nodes, managing nodes. They've written an operator similar to what we, as Couchbase, we're working with CyberArch, who's gonna be providing some security. So it's gonna be people security, identity security, working with several other database partners and other security partners as well. This should be just a few more seconds. So what we're gonna do next is we're gonna go ahead and expose, which means we're gonna make connection here. So we're going to, we throw this in here. This is our Couchbase cluster. And so here is Couchbase. So they use a web interface, they also have a CLI interface for connecting and communicating with the servers. We're gonna click here and we're gonna be able to see that there's four servers that are up and running. The green status over here indicates that they're alive. We're also gonna look at buckets. You can see that we've created a bucket called tweets. And there's some, there's zero items in here right now. Back to servers. All right, so what we're gonna do next, we're going to deploy this microservice application. So we have Couchbase on our backend and we're gonna be deploying three components. A UI web interface written in React.js based on pattern fly. So pattern fly is a Red Hat project that basically standardizes UI and user experience type stuff. We're gonna be deploying a service for analytics. So Couchbase is a NoSQL database, but they also have a SQL-like query language called Nickel. This is actually gonna be using Nickel on the backend to query the database. And then we're going to be deploying a service for Twitter ingester. This ingester is gonna be taking and sucking in all that data from Twitter. Deploy the API service. So we're doing a source to image build. So what this means is that we're taking the code, we're pulling it off of GitHub, we're launching a container, we're taking that code, putting it in the container, building that code, and then we're going to be making artifacts, separating them out, and then running a running container and taking those artifacts and injecting it into the system. As you can see here, we ran the Maven command, so we're sucking down the entire internet. And any questions while this is running build successful, take a look at it. Something else. So the way that I'm deploying is through the CLI, but there is also built-in, and this is OpenShift 3.11. You can see here that we have a cluster console. Under cluster console, there's a catalog service. You can see that this is where we're placing some of the operators that are built in conjunction with Red Hat, or Red Hat has personally built. And you can see Couchbase is one of these operators. So you can deploy it through here, but we're taking the longer way around, all right? Now, something else that's really interesting about OpenShift in Kubernetes is that you can directly deploy an image. So out on docker.io slash ezb, there is a Twitter UI, and so this is gonna be much quicker because we're basically pulling a ready image. So it's gonna download it from Docker and just kick that off. It exposes the UI as well, and then we are going to deploy the Twitter ingester. And so again, this is using sourced image. It's pulling down a Java file. And this is where we're going to, minutes, pull out our phones. All right, so let's see. So we're gonna take it back and we're gonna go to, so here's the hashtags that my Twitter ingester is gonna be looking for. So hashtag devconf, hashtag OpenShift, hashtag live demo, build is successful. So the app should be live. Any minute now. So let me see, nothing yet, come on. Oh, here we go. All right, this is where we pull out our phones and we take a picture.