 Hi again Red Hat Developers, this is Jason with the Red Hat Developers program. I'm here at, say two of Summit 2017 in the Dev Zone with Andy Rubinger who's going to talk to us about reproducible development to live applications. Good morning everyone, day two I think then, yeah of Red Hat Summit. We're going to try and do something about it as quickly as possible. My name is Andrew Rubinger and I work in the developer experience group over in Middleware so it's our job to make sure that people are getting going as quickly and easily as possible and today we're going to show you what we've brought over to Summit this year. The big question I think that we're all kind of like looking to solve is this particular thing. It works on my machine nonsense, right? You know we are at a point now where we have containers we can lock down into reproducible environments. The question is how do we make it such that we're using these as application developers so that we don't actually have to go and be running things like Docker builds or be dealing with OpenShift templates or any of the stuff that maybe an application developer doesn't want to deal with, right? We don't want to have to go with that. So the challenge for us is to make all of our abstractions like Docker containers, the OpenShift container platform a little bit more transparent. We want to have you focusing on your business logic, we want you to be able to use a known build and deployment environment and we want you to start with continuous delivery from the beginning and evolve from there. Not have to add in your continuous integration environments afterwards and setting up your build hopes, right? We want to get you started with delivery from the cloud from the start. So here's what we've delivered. We've got a site called launch.openship.io. It lets you pick a use case that you want to fulfill. You'll then select your runtime from right now. The newly announced Red Hat OpenShift application run times product that includes entitlements to Vertex, Wildlife Swarm, Spring Boot, and then we're going to launch you. We're going to put you on your way. We will put that new application out for you on GitHub. We'll make a new OpenShift project for you to run it in a pipeline with a reproducible build and then we'll go. So let's take a look at maybe what this all looks like. This right here is launch.openship.io. It's a feature of OpenShift.io, a new end-to-end development platform that we've announced here at Summit just yesterday, okay? And its job is to get you going as quickly as possible in and out. Now, this is now available to the public for an early access registration. You can fill out a quick form. Just let us know your name and your email address and when it comes available, we'll let you know that should be in the coming weeks. For now, we'd like to show you exactly what this means, right? There are two flows that we can start with. There's the continuous delivery flow that I just mentioned and there's also the download and launch manually flow. This is your traditional download as zip that we're familiar with from many other projects, right? I think the real value for us is using OpenShift Online to build and deploy. So we'll select the continuous delivery flow. We'll now ask us just so that we have information to get into your GitHub account and into your OpenShift account just to log in. And we log in through the Red Hat Developer Program. This is a zero cost subscription. It's available to anyone. So I already have an account. I'm already associated in. So I'll just press the login button and it'll take me right through. Here are missions. Missions are preconfigured use cases really, right? So like in the first two missions that we've launched, we've got to we can learn about making a REST API level zero, which is basically just exposing an HTTP endpoint to invokes and business operations. Or we can start to look at some platform features in the form of health check. Health checks are very important. They're real cool. They're the one that we'll do today. Health check is all about letting the platform OpenShift know whether or not your container is running. And if it's not, it'll do things to make sure that it stays up. It's a real feature of OpenShift. It's a real value add. We'll learn about that today. Now we get to pick our runtime. So for anyone in the audience, do we have any fans of Vertex or Wild Ply Swarm? I see Clément over there. He's a core developer for Vertex. So maybe today we'll go with Vertex. So I don't get yelled at a little bit later for showing someone else's stuff, right? We'll pick that up. Yeah. All right. There's really only one thing that we need to fill out here, the OpenShift project name. So I'll just kind of simply do that. We'll call it, I'll give you guys some space here. We'll call this health check, Vertex, ALR for my initials on OpenShift Online at Summit here. And this will validate to make sure that this project name is not taken. We want to make sure that we're not giving you errors a little bit later on. So now we're at a review screen and we're ready to go. All we got to do is hit this launch on OpenShift Online button and it's going to do everything I said. It's going to set up our GitHub repo. It's going to push code into it. We're going to make a new OpenShift project, configure that, make a pipeline, and then we're just kind of going to be on our way. At this point, when I press this button, I have to do nothing else to get a fully built and deployed application out on OpenShift Online. At this point, we're now done with launch. We're in, we're out. We've told it a few things about what we want to build and it's set us up and now we can be on our way. We've got a new GitHub repository right here. This was generated for us by launch.OpenShift.io and we've also got a new project on OpenShift Online. OpenShift Online Starter is a free to use environment and when this is done building, what it's going to do is give us an application that anyone in the world can see, be publicly available. At the moment, you'll see that it's now booting up a Jenkins instance and when this is done booting, we're going to execute our pipeline build. So we'll give this a couple of moments to go through and then what we're going to do in the meantime maybe is we're going to go into our regular development workflows. We don't require you to learn anything else. You can get going with the tools you already know and love. For me, let's maybe use kind of the, maybe the lowest common denominator. We'll start with the command line. I'm a command line guy. So we'll just say we'll, we'll clone this new thing right into our space, into our space, right? And we'll switch into it and because this is a Maven project, I can do stuff like run a simple Maven build, right? Here's the real interesting part of this to me. When we talk about doing reproducible application development, the standard case of just building it on your host as I'm doing right here is not amazingly reproducible. That's, that's the source of this whole it works on my machine problem because my environment may have environment variables set differently, different versions of Maven, different versions of the JDK. There are differences. But this is the quickest way to get the application up and running. And I can very quickly say something like Maven compile. We'll just kind of make sure we do this main, clean, compile, vertex run. And we can use the vertex plugin to kind of like just take this thing and run it for us. And again, in this case we've now built it on our host and we're also going to run it on our host. So if we go to like localhost 8080, this is the application that we've built and it's running on our host environment. Probably the quickest way, the traditional way, we all know how to do this, but still a little bit open to the problems of it works on my machine. But this ends up being nice because we can do like very quick import into our projects. This is the Red Hat Developer Studio for those who haven't seen yet. We can like bring this into our IDE and let's go like make some changes and see what we can do to this thing. How about we maybe change up the index HTML. You know, this is what it looks like. I think what's fun to do is maybe do something pretty obvious. Like add some 2004 style style guides with maybe body tag and I can say background, color. Anyone got a favorite hex code? I'm sorry? Dead beef. That's eight, that's like eight things? Dead beef? Alright. I think our friends in the UX department will say that looks pretty awesome. Right? And now you'll see that I've just, I haven't even had to do anything I'm going to make a commit. I just kind of save it and I see this running in my browser. This is the quickest way that we know to get to see changes, right? And it's because our buddy Clemont over there will make sure that Vertex is monitoring this and can kind of redeploy the vertical for us. That's all fine. But the purpose of this application here, right, is I can say like hello summit and it'll tell me, right? Hello summit. That's fine. This is running on our machine but the purpose of this entire health check application is to use the features of the platform. Remember that microservices are not about making your services smaller. They're about making them composable and coordinated with orchestration through a platform level. So you're not using the application servers in the way that we have before. You're able to like use the features of the platform and in this case we're not running it in the platform. So we need something that's going to be able to run it in the platform for us. Let's shut this down here and we're going to bring this now into this right here. I got one of these. This right here. This is a version of OpenShift that's running on my machine and it's been provisioned for us through the CDK. The CDK is a container development kit and it provides a single node OpenShift cluster running inside a relvm. So I've got basically a cloud on my machine which is going to give me the like stability of a repeatable environment. I know that when I run stuff in here it's going to run very very similarly to how it will in production because we basically get locked down the environment and stripped out only things like environment variables, persistent volume amounts, secrets, right? So what we can do here is now apply a build that uses the Fabricate Maven plugin. If the Fabricate Maven plugin will do, I'll just get this thing going. We're going to run a Fabric, Fabric 8, deploy. We'll give it a profile of OpenShift because that's how this thing is configured and we'll skip the tests just this once for time's sake because I know that they passed and haven't changed anything. The Fabricate Maven plugin is going to take kind of a hybrid approach for us. It's going to build this application locally on our host so the build environment is still non reproducible. But after we've got the binary, the Java binary that we want to deploy, it will then ship this off to OpenShift. That's what the green text is. It's going to ship this off to OpenShift to build it using source to image with binary build content and make the container for us. So at no point are you touching a Docker file, at no point are you running a Docker build, but you're able to do here is just as an application developer run a standard Maven build and have OpenShift build and deploy this application for you. This is going to take maybe another couple seconds as we push this in and you might know that if we go into our console here this is going to start to pop up as a new deployment and we've now got the deployment with the container and it's going to start up and when it starts up this is now going to be running inside of OpenShift inside of our VM in a very production-like environment and that'll mean that we can do things like actually, well we'll take a look in one second, this health check example's job, there's a kill me button and the job of this kill me button is to flag out that this pod is dead. We do this on our local machine, we're going to kill it and that thing is not coming back to life because there's no platform to bring it back to life, but in an OpenShift world, OpenShift and Kubernetes are monitoring that this pod's state, so this one's booting up right now and it knows if it's healthy or not, that's the purpose of the health check. So when this thing comes alive what we can do is kill it and Kubernetes will say like oh my gosh that pod died we get to start up a new one to keep this thing running, right? So now again we've got this thing running on our host, we can kill this, when this kill thing dies nothing is bringing this thing back, right? But we've now got this running here in MiniShift, so what we're going to do is we're going to go to the same application and you'll know that because we've built this with Fabric8 here, we haven't made a commit, we haven't done anything, we've just done our local build, we're going to see the beautiful UX improvements that we've made to it thanks to our dead beef recommendation here, right? So I can say hello summit again and it's going to tell us hello summit and now we're going to kill it, we're going to kill this thing and it tells us this application has been killed and OpenShift will notice that this thing has been killed, that dark blue is going to turn light blue as we notice it, oh my gosh this thing is gone, the health check has now failed and it will automatically reprovision this for us to keep us up and running. In a more production like environment you won't have one pod you may have two three or four or five and what this will do will be great because any one of them can die and you won't lose traffic to your site because it will just bring this back up again, so the container is going to work to boot this up again for us, that should happen in a couple seconds and when it does it's now up again and the application here will notice the recovery took 33 seconds to happen, yep, awesome. So there's one more important step here that we have to go through, we'll wait for the god in the sky talk to kind of finish, I think it's a little rude of him to interrupt us but we're almost done here, right? This application while we've been doing our local stuff this application has built on OpenShift Online Starter, it is deployed and it's now made available to us. If anyone wants to remember that easy to remember URL and type it in your phone that's available to anyone in the world right now, so this is now a public application and then notice that it doesn't have our UX improvements because it was built from source through the pipeline from GitHub, right, so we can do now one more thing, we've shown that we can build it quickly on our local host and deploy it in that environment, the quickest arrangement but also the most unstable, we can also build it kind of locally here and containerize it on MiniShift and deploy it there, a little more stable but a little more time, here's the last thing we can do, we can get at this thing, we can commit it with a message, upgrades in quotes to UX and I can also push this to my Origin Master, when I do this, we're going to trigger off automatically here, a new pipeline build, a stage is going to start on OpenShift and as soon as this build is done, we'll see those changes reflected up in the online application and this is how with the push of a button earlier on, we get you started not only with development of a new application but in a continuous way so you can actually evolve this all the way through into something that you're going to run in production in runtime from the very beginning, that's it, thank you very much all, it's good to see you.