 Hi Red Hat Developers, this is Jason with the Red Hat Developers Program back at Summit 2017 here in the Dev Zone with Jorge Morales with Red Hat who's going to show us how to enhance our builds in OpenShift by chaining. And I'm going to talk to you about chaining builds in OpenShift. So there is, usually in OpenShift there is 3 ways to get your application into OpenShift. It's louder, yeah. So there is 3 ways of getting your applications into OpenShift. You can deploy your application source code using source to image. OpenShift will build your application source code and will layer that on top of a Docker image. Then the other option that we have is usually, if you want to build that application out of OpenShift, you just build it with Maven and you maybe push that artifact into an external repository, artifact or artifact or whatever, so you can just stream that artifact down into a Docker image and then build that image into an OpenShift. And then the third option that we have to build or get applications in the OpenShift is just by deploying your complete image, Docker image that you have built somewhere else. Okay, so this is the process of source to image. In source to image, what we do is just we get a source repository, usually a git repository. Then you stream your source code, you pull down the source code into a Docker builder and that image will build your application source code using Maven with our supported images and then it will layer that on top of a Docker container. That container will be pushed into an application registry and will be ready to deploy. But there is always a but. So what if we want to deploy or use a vanilla Docker image? So right now the process that I shown is just to use source to image enabled image. So they have to be ready to be used in OpenShift. You may not want to use those images because you may have an application server that is provided by a third party or an ISP, so you may want to use those. Or maybe you want to use a different building technology. So our source to images, they are using Maven to build your artifacts. You maybe want to use Gradle if you are talking about Java. So you may want to use a different build of technology. Then the third option we have is just to have the smallest possible image. Usually when we talk about our source to images because they are building and running your applications, they have a lot of dependencies in it. You may want to have a small image to run in production. So you may want to create the smallest possible image to be able to run it in production. But we still want to use source to image. So the answer is chaining builds. So chaining builds is a process where we have, still, we get your source code from Git and we build your application artifact using an image that is just created to build. Not to run your application but just to build. So you can have a different set of images like Maven, Gradle, whatever languages go, whatever language you want to build. But the sole purpose of that image is just to build your artifact. And that artifact, the binary artifact that you have will be streamed into a second builder image. That what it will do is just put that artifact in a specific location in your Ranta image. It will use not source to image, the second build. It will use Docker strategy, Docker build. So it will use the Docker build. It will get your artifact. It will put it in a location and then it will create an image that will be pushed into a registry and it will be used then to run your application. So this first image will be a builder image. The second image will be a Ranta image. And this can be specialized images that you can create and you can combine it in a more flexible way. So there are some examples that I'm going to show you today. And as an example to run your vanilla image as Ranta, we may not want to make an S2I-enabled image or maybe we can use an image from anywhere. We want to use it for running our application, an image that somebody has provided to us, an USB or maybe a Docker hat. Or we want to have a smaller room. So as an example, we have a Maven builder that we will use with our stock, known as S2I-Wildfly image. So in this example, what we do is create the first build. And we are going to be using, because this image is built with Maven, we will leverage the Maven capabilities that are on the Wildfly image. So we're just using a regular Wildfly build, but we will not use that image too as runtime. We give that name as a name of builder and we just build it. Once we have that and we know that the build process will be put in the artifact in a specific location, what we will do is second build that will get the artifact from that specific location. And it will just put it as a new layer on top of an existing image. In this case, we are going to use the official project Yevos Wildfly, which is a non-S2I type of image. Another different sample is using Gradle to build your application. So if you just don't want to leverage whatever it will provide, because you have already a lot of expertise and a big investment in building things with Gradle, then this is a different way of doing it. So with this, you can achieve a bigger combination or possibilities of image creation. And the same way as we did before, I'm going to use an image that has Gradle capabilities. So this example is building with Gradle. It's using one of my own images that is not supported, of course, and it will just build a Gradle application. Once I have the application and I know where the image is put in that artifact, I will stream that into a second build, and I will just layer the application on top of an existing image. In this case, the official JDK image, which has building capabilities, but the building capabilities that it has is using Maven, not Gradle. And then the third example that I'm going to show you is just getting the smallest possible final image. With Go, you can create a binary that just has all the dependencies statically linked. So with this, what we are doing is just build using a source to image, Go source to image enable. So we will use Go to build the application, but then that application will just stream it on top of a scratch-based image, which will reduce the footprint of the image from 200 or 300 megs to only 8, which is really awesome. I'm going to show you some examples of this in action. So here, as you can see, what you will see is that we have two different builds. One is the builder and the other one is the runtime. The builder is the one that will pull down my code and will build the application, will put it in a specific location and then I will create a second build that will get that artifact and will stream it on top of an existing scratch image. The good thing is that we can also leverage the capabilities of OpenShift in the sense of once my application is being created, my first application is being created, this application, this build application, this build will be pushed into a registry. We see that it's been pushed into a registry. Once we see that it's pushed into a registry, we will see that we get a second build here that just happened, should happen right now, that is the second build because there is a trigger that knows whenever I have built the first image, it will notify the second build and it will automatically build. So I just need to care the same way as with regular S2I to update my code. I can have a web, again, have trigger to just trigger the first build. The second build will be triggered once the first build has finished. And in this way, I can reduce the footprint. I can use different builders. I can use different images to runtime. So I can have a bigger combination of possibilities and capabilities in OpenShift. Questions? Not build config because it's build config that defines one single build. But what you can do is once you have prototyped this type of build, you know that you are going to be using go S2I builder and then runtime on top of scratch. What you can do is create a template that will simplify your life. So yes, that will have to build configs. But the configuration that you will expose to the developers can be as minimal as just the source of where is your source code or can be as complete as with a regular template. So from a developer's perspective, if you are using templates, you will see no difference that there is two builds happening below. Of course, it will take a little more time and there is some other considerations to think about. But from a developer's perspective, it will be as easy as it used to be. Yes, but the thing is that if you don't build, if you execute the runtime process multiple times, it will be the same image always created. Yeah, yeah, yeah, yeah. And you can integrate this. This is usually integratable into Jenkins. So in continuous delivery in pipelines, this is the same process you will do probably in Jenkins. But if you don't want to invest in Jenkins, you don't want to integrate Jenkins in your build process, you can just leverage this. Yeah, of course. So whenever, like every other build, what you need to specify is that the image stream where you are pushing can be local or can be remote. So if you just use what is called pull through and push through, you will specify that the image should go to a remote registry and the build will go to a different. But if you want to go to both, no, you cannot do that. Yeah, so you can have one registry external to OpenShift and you can just build and push to the external Docker registry, but you cannot push to two different registry at the same time. You can do it with any version. Yeah, so you can do it. This is a process that can be done from OpenShift 3.0.0. Well, probably not 3.0.0, but 3.0.2 for sure, and onwards. Because the only requirement that you have is that it allows you to do what is called binary builds. So inject the binary into a Docker image and while you do a Docker build.