 In this video, we're going to talk about the requirements for your development environment for this course. So what we want to do is have an operating system that supports Java development, obviously. This is going to be all the major operating systems out there, macOS, Windows, or Linux. I'm saying you probably want at least 8 gig of memory. 16 would be a little more comfortable, a little faster, but you should be able to get by with just 8 gig. And we are going to be using Java 11 or higher. So everything is going to be developed under Java 11. But if you're on a higher version, you should be okay. If you are on a lower version, you may run into issues. So I do recommend if you're lower than Java 11 to update to Java 11. And you do need to have the JDK installed specifically. Now the JRE, the Java runtime, you do need the JDK. As far as the flavor of the JDK oracle or open JDK should be just fine. And then we are going to be getting into Docker. You do want to have Docker engine installed. And I'm saying 20.10.0 or higher. That should be perfectly fine for this course. And then we are going to be building Java. We will be using Maven specifically. And you should have Maven 3.6.0 or higher. And ideally have that installed for command line use. That'll make your life a little bit easier. And if you have any doubts on that, you can read the official Maven, Apache Maven documentation. They do a pretty good job of explaining how to set that up for your specific environment. So you do want to take a moment to verify your environment. And this can be very simply to go verify that Java is installed. So Java version, then we want to make sure that the JDK is also installed. So that's Java C version. That will tell us that the Java compiler is available on the command line. Maven, we can just do Maven minus V. That will show us the Maven version installed. And then we can run a simple Docker command. Make sure that the Docker engine is up and running. And that's simply Docker PS. And that'll show us any running containers. Now I do use, for the source code examples, I do use IntelliJ Ultimate. This is going to be used throughout the course, but it is not a requirement. You do not need IntelliJ Ultimate to go along with code examples in this. I do develop everything to be IDE agnostic, meaning it doesn't matter what IDE or any IDE that you use. Maven is the build tool. We will have a Maven build file and we'll be able to build a project using Maven. So if you're using STS Eclipse or NetBeans or some other IDE, perfectly fine. As long as it supports Maven, you're good to go. And worst case, you can always use Maven from the command line to build through the example. So again, IntelliJ Ultimate is not required to complete the course. It's just my preference of the IDE to use. Now that your environment is properly set up and we've got Docker up and running, everything's happy. We are going to go in and start working with a Spring Boot project. First, I'm going to show you a project that we will be working with in this course. This is an already made Spring Boot project. This course is not specifically on Spring Boot, assuming that you are a Spring developer. So we'll go through a little Spring Boot application that we can work with for the purposes of deploying with Docker. And then we will start looking at a basic Docker build file as to how we build up that Docker image. And we'll go through the step-by-step taking from a Maven project that's producing the good old Spring Boot FATjar and then getting that into a Docker image and running it inside of Docker. So we'll cover that in this course step-by-step. In this video, we are going to do a code review of the Spring Boot application that we are going to be working with. On the screen here, you can see that I have an API definition. So the Spring Boot application that we are going to be working with in this course is a simple Spring MVC Rust type application. Here I have a beer service and you can see that we've implemented endpoints for ListBear, CreateBear, GitBear by ID, UpdateBear by ID, DeleteBear by ID, and then also GitBear by UPC. So a variety of Rustful style operations that we can work with. This API documentation, I will leave a link to it in the course resources. And then the implementation that we are going to be working with in the course is here. It's under KBE Rust Brewery. So this is a Spring Boot project that implements that Rustful API and I will also leave a link to this in the course resources. Now, I do want to prefix this. The course is for people that already know how to develop Spring. So I'm not going to be teaching how to build a Spring Rust API. That's well covered and other content I have and a lot of other people cover that as well. So to proceed, you do need to understand fundamental Spring MVC creating Rustful APIs. But I do want to go through and do a quick code review to get you orientated to the Spring Boot project that we are going to be working with in the course. I'm going to toggle over to IntelliJ where I have the project uploaded. So here I'm in IntelliJ. This is the checked out project from GitHub. And I want to do just a code review on this. So first, let's take a look at the dependencies. So here is the Maven Palm. Let me scroll up to the top here. We are using Spring Boot version 2.4.5. That is the most recent version at the time of recording of Spring Boot. And you can see here in the properties we are using Java 11. I am using MapStrike and Project Lombok on that. More on those in a little bit. I do want to look at the Spring dependencies. We are bringing in Spring Starter for actuator Web. That is going to be Web MVC, not Web Flux. We have the Starter for Spring Data JPA. So that's going to bring in data or JPA and Hibernate. That's the ORM that we will be using. And we are explicitly bringing in validation. There was a recent change to Spring Boot where the Starter validation was previously included in Web. I forget the exact version within the last year or so. That is no longer included. So you do have to bring those in. And if you forget, this is one of those things that might fail silently where the validation is not getting picked up. That can be a problem because you forget that and then your validation silently fails to work. Then you can see on line 50 we are bringing in H2. We will be utilizing the H2 in memory database dev tools. Can we see Project Lombok, MapStrike and then our test dependencies. Here, let's go up to the build plugins. We do have the Spring Boot Maven plugin because I am using a different version of Lombok than was being curated. I am excluding that from the Maven plugin so that doesn't get automatically built in. And here is an important part. If you are not familiar with MapStrike and Project Lombok, you do need to configure Maven like this to add in these annotation processors. I can't remember if the sequence is important but it's important to have these annotation processors there. I would recommend keeping the same sequence here because I know this works. If you have a different sequence, I don't know if that will work. Finally, on line 115 I want to point out this is a compiler argument and this is what tells MapStrike to annotate the generated mappers with a Spring Component annotation so that those mappers get brought in and have Spring Boot components and we can do dependency injection on them. Without that, the project will fail to work properly. So let's come in here. I do want to take a look at the beer loader under Bootstrap. So this is going to be implementing the Spring Boot command line runner. What this does, it initializes our H2M memory database with 30 different beer objects. So you scroll down and you can see the various beers that I am loading up into the database. It just goes with some data so every time we bring up the application, they get initialized into the database. Speaking of the database, we are using traditional JPA here. I'm not going to be covering JPA specifically, but you can go through. We can see that we are using Project Lombok annotations for data. Also, the builder pattern is being implemented as well as a variety of JPA annotations for the yield and whatnot. This is what's getting persisted to the database. Now we do have here, we are using a DTO model. So I do have mapstrike mappers defined to convert from the database entity to a DTO. So the DTOs are kept under the model directly. And all that works pretty, pretty well. Coming from the ground up, we are using Spring Data, Spring Data JPA repositories. We are following the repository pattern. So we do have a repository defined that is utilized in our services. So we do have an interface that we are coding to that does the basic CRUD operations for us. And then here you can see the actual implementation of the service. I close down some of these packages real quick. And then finally, we do have a Spring MVC controller. So this is what's going to be handling the web request that takes in an instance of the beer service to support the CRUD operations. And we can see that we are using basic Spring MVC mapping. So we have request mapping the path parameters are being set up and all that's being handled by Spring MVC. And then we are following through using our service. Our service is going to be handling that. The service takes care of working with the database and then using the mapstark mappers to convert to and from the web-facing DTO objects. So let's go ahead and I'm going to run this application. From IntelliJ, if you're using that, you just come up and say run. Just going to do a stop and rerun there. Sorry, I had it running in the background already. And here you can see the basic initialization. And I do want to point out. Here you can see that there is a council output saying that we've initialized the database. So at this point we are running on port 8080. You can see that a couple lines above. The API documentation, we could utilize that to use Postman or something and exercise those CRUD operations against port 8080 on local host. So we have 30 beers loaded into the H2M memory database and then those RESTful APIs are now exposed and working. And if you want to take a moment on your own and go through and utilize a tool like Postman or Crural to exercise the API just to see that it's working to prove that it does work at this point, go ahead. I encourage you to do so. But I'm not going to be covering that specifically in the course. You should be able to start the application at this point. What this will do is tell you that you checked it out and you have your environment set up properly. It is building and it is coming up and functioning properly. Okay, in this video I'm going to show you how to set up a very basic Docker file for our project. Now one thing I like to do is as I work through these courses, if you're not familiar with taking any of my courses, I will create a new branch. So I'm going to come in here and add in a new branch. I'm just going to call this Docker base. So we were previously on the main branch. Now we are going to Docker base and this gives you the ability to see exactly what was changed in this video. I will be doing that for the remaining videos where I'm actually changing code and you'll be getting a new branch. So you can do a compare of your code to a specific branch and see what was changed or what you're missing. So very handy tool to give you. So now I am on Docker base and let's go ahead and set up a Docker file. Now there's a couple of different ways that you can approach this. I'm going to put things under the main folder for the Maven project structure. Some people when they're doing projects, especially if they're using a build script, they'll put it in the Docker file into the root of the project, which is perfectly fine. That is a valid way of doing that. But here I'm just going to show you a typical setup where I'm going to come in here and I'm going to say a new package. I'm going to call this Docker base. And let's go ahead and create a new Docker file. And by convention that is capitalized. So Docker file all lowercase. And I will be adding that to the branch. And here I'm going to show you just a very basic vanilla Docker file for running our spring boot application. So I'm going to say from open JDK. You can see I'm getting autocomplete there from telj. I'm going to say jre. And I want the slim build. So this is a more efficient. And to be honest, you see I'm getting code complete for Buster, SID, and Stretch. I honestly don't know what those are. So I do know the slim build is a more efficient image. It doesn't have a lot of the tooling in there. So it's a very small lightweight image for us to work with. It does have the jre, the Java runtime. So we are going to be putting in a jar file so that is already compiled so we don't need the JDK. The jre is much smaller. So we have a much smaller image that we're going to be working with. And here we want to set up some environment. I'm going to steal from my working file here to the clipboard. And I'm just going to paste this in from my clipboard. And here I'm setting an environment variable, Java Ops. And I'm setting up some memory limits for the JVM. And then this security from memory that goes through and helps initialize the JVM quicker improves the startup time by setting that. I'm going to say WorkDir application. Now the trick is we need to copy into our file. So we're going to be copying into the image that we're building in our Docker build script. And what we want to do is we don't have it here yet. So if you don't see it, we want to run the package command. So in the lifecycle, we want to run package or verify either one of those or install. But package is the minimal one that we need. So I'm going to go ahead and package that. So now we do, in fact, get the jar built. And that does run our test as well. So we only have, I think, one test out there that brings up the context of pretty lightweight project. So we actually have four tests. I'm a spoke. So now what we want to do is copy. And this copy command is going to be relative to the location of the Docker file. So we need to go up a couple directories. And then we want to say, should be getting a target. It's not seeing it as a project file. And I see what I made, made a mistake. I actually put this here. I want that under main. Let me do that quick refactor. So we have that under main. I mistakenly put under Java, which is our class files. So we did not want that there. Now we're getting target in the auto complete. And we can see that we have these two. So the dot original is the slim jar. We want the fat jar. So that is going to be the executable jar there. So we'll go ahead and take that. And that tells us to copy it. And we are going to copy it into the work directory. So the dot slash is saying copy it into the working directory of application. And then we want to do entry point. Now we're going to pass it a command line. So we're going to say Java. And here we want to give it the name of the jar. So this is a little lengthy and easy to mistype. So I'm going to copy that to the clipboard and we'll paste that in. So this is a very minimal Docker file for running the spring boot application. So at the top we are saying the Docker image that we want to pull from the JRE slim. We are setting environment variable for Java ops. We're just setting some memory limits and then the security. And that helps with our application startup time. We are telling it the working directory called application. We are copying from our local file system. So we are doing a relative path there to target to the generated jar file. We are copying that into our Docker image. And then we are setting the entry point. And this is the command that is going to be running on startup. So this is the Docker file. In the next video I'll show you how we can run this from the command line. In the previous video I showed you how to create this Docker file. And in this video we'll show you how to actually build and run the image. Now I'm going to be staying on the same branch here. You can see down on the bottom of the IDE I'm still on the GitHub branch of Docker base. I'm only going to be doing demonstration here of the runtime application. And I'll be running this right from IntelliJ. IntelliJ does have a terminal that you can bring up and clear that message. And here you can see that I am in the root of the project. Now one very important thing here is the way Docker build command works. It will work from the current directory and down. So you can't go up. That is a security thing. And I actually found that out by the hard way. And it took me a little bit to figure that little bit out. So here in the readme you can see that I've got a couple commands here. So I've got Docker build minus F. I'll be putting this in the readme for your reference that you'll have access to the command. So here let's go ahead and do just make sure Docker is running. So if you do Docker PS you can see that I do have a Postgres image running. That is perfectly fine. That won't bother us. So I'm going to do a Docker build. Now for this to work you can see that I have my target directory exploded and that the jar is there. So you do need to run Maven package before running this. Otherwise it will not work. So I'm going to do Docker build minus F. And I'm going to say from here go source main. And I'm just hitting the tab key for the autocomplete. You can see the Docker file. So that minus F tells the file that we want to build. And because I'm running from the root of the project I'll be able to access that because you can see in the Docker file. Remember I have that relative path. So I'm running from this point in the file system. So this will be able to traverse down and copy that file in. So if I ran from the Docker base folder this would not be happy. So an important aspect there. So that's setting the file. And then I want to do minus T. I'm going to give this a tag on window. And here I am going to do KBE rest like so. Go ahead and tag that. And Docker build. And I see my mistake. I forgot to say current directory there at the end. So now we can see that we went out and we built it. It actually built fairly quick. And the first time you run it I've already built a couple of times. So the open JDK that image is already there. So it's pretty lightweight for this to go ahead and build. So we're saying from I didn't have to download that from the internet. The actual copy and stuff that went fairly quick. Now let's go ahead and run that. You can see I set up the second man here for running it. I want to clear the screen. I can say Docker run. And I'm just going to say minus P8080. That's going to map 8080 to the local host. And we'll do KBE rest. And I'm not going to use the minus D flag. I put the minus D flag there in the command. Because I want to go ahead and observe the startup log. So I'm just going to be starting this up. And we'll go ahead and see that I'm monitoring the logs. And that is now coming up. We can see that we have the normal spring boot startup. So now this application is up and running inside of a Docker context. And a Docker image. And it is running locally on my host. Port 8080 was exposed. So if I wanted to curl from a command line or use postman or something, I would be able to exercise the API at this time. So I'm not going to be demonstrating that in this video. We can see that we are up and running. And I came up in the console mode interactively here. And to shut it down, I just do control C. And that will terminate the JVM. It goes away. If I do a Docker PS. You can see that now I have just Postgres running. And if I went to a second command line while that was running, the Docker PS would have shown that image up and running. Now one thing that's very important about Docker and the way the Docker images work are layers, file system layers. As you get a lot of microservices out there, you want to be very aware of how the layers are working together and interacting together. A very nice feature of Spring that was introduced, I think it was in Spring Boot 2.3 if memory serves me correctly, is being able to do a layered approach. So we're going to break that out. Break out our application into layers. So we'll have a layer for all those common dependencies and the stuff that doesn't change very much. And then another layer for our application, the stuff that does change. The stuff that doesn't change is going to be a big amount of data. Stuff that's changing in our application is going to be much smaller. So when we're doing deployments, the stuff that doesn't change doesn't get deployed again and again and again. Here we are going to be much more efficient. So I'm going to show you how to use Spring Boot layers, how to configure our Docker build file to go ahead and utilize these layers. So this is a really important stuff, especially as we start getting into more production environments where we have applications that are being deployed and devolved and deployed again. So we're doing releases of those applications. This is going to make your life a lot easier, at least your DevOps guys, a lot easier as you produce, move over to containerized environments. Okay, up on the screen you can see that I have Chrome up and I am actually at my blog. So this is an article I wrote about a year ago on using Spring Boot layers. So this is a really cool feature available with Spring Boot. Can you see the article here? I talk about how Docker itself works. So remember, as we build that image, we are going to be building layers in that image. So the JRE base image that we're using, that's going to have a collection of immutable file system layers. And I kind of think of these as effectively as a tar ball with a hash. So every time you add something, it's a new tar ball with a hash that is getting generated. So the Spring Boot layers are actually a fairly clever idea because let's say you have a Docker host that has a bunch of microservices on it. And when you start getting into larger Spring or any Java application, when you start bringing in things like Hibernate and some of the more advanced type stuff, you get a large bundle of dependencies. So you can easily have a 200 meg image, but it's all jar files. And what happens is this big fat jar stuffing into your Docker image, there's no way your application is only going to be a small, teeny part of that. And there's no way for the Docker build system to distinguish from that. So what this does is we build effectively multiple layers in that Spring application. So chances are, as you're doing some type of continuous deployment, your application is going to be changing. Spring dependencies are going to be fairly stable. I mean, it depends on how often you are releasing or updating Spring. I know some organizations that they'll get out on Spring version and because it is so large across their applications, they might only upgrade once a year. So their Spring dependencies are going to be fairly stable for a year. So every deployment that they do, if they broke out to the layers, they wouldn't be redeploying those. So on the Docker host, once a layer is there, it's not going to get downloaded again. So if we break out all the Spring dependencies into its own layer, that layer will get reused over and over and over when we do a new deployment with the application, the application changes, and that is going to be just a small fraction of what's actually changing there. We put that into its own separate layer, then that application is only changing. So if you are running a larger system in production and doing continuous deployment, you can see how this is going to have significant savings coming up. So in this video or in this section of the course, I'm going to show you how to enable it, give you a little preview. We are going to be adding in a Maven configuration, and then we are going to be adding in the dependency. So here you can see that we are setting up layers and the way Spring did it, we have dependencies, Spring Boot Loader, Snapshot dependencies. So if you have any Snapshot versions on dependent projects, those will get put in, and then your application. So chances are these two here, the top two folders, those layers will get converted into layers. Those will be pretty static as far as your deployments, and then the second two, the smaller dependencies, if you have any Snapshot, personally I don't think you should be deploying Snapshot versions to anything, in my opinion. And then you also have the application. That's where your Spring Boot application, the much smaller component, is going to be living. So we will be stepping through that. I'll show you how to set up the Spring Boot Layer tools, as well as we will be doing a multi-stage Docker build. In this video, I want to toggle over to IntelliJ, and what we'll do is we will add in this little piece of configuration right here to our Spring Boot Maven plugin. And you do have to be on Spring Boot 2.3 or higher. This just came out about a year ago. So if you are on a previous version, that Spring Boot Maven plugin will not support this. I think you probably can add in that little bit of configuration and it'll probably just ignore it. But then you might be mystified why it doesn't work. So I'm going to jump over to IntelliJ, and we'll go ahead and add that in. So I'm in IntelliJ. I'm going to go into the Maven POM, and I am on a branch called Layered Maven. And here you can see I have the Spring Boot Maven plugin, the Excludes. I want to come up here, and just grab the configuration, and then Layers. I copied that from my blog. So we are adding in configuration, LayerEnabledTrue, that is going to, by default, is not enabled. And then we are going to be including the Layered tools, and that is going to come up into the build file. We will address the multi-stage build file in the next video. Okay, in this video we're going to go ahead and configure the Docker file for a layered build. I'm going to collapse that down. And what I'm going to do is I'm going to create another folder called Docker. And this will come into play later on in this course where we will be using a build tool with Maven to build Docker. So I'm just going to make that Docker and it will come in and add in a Docker file. Go ahead and add this to get it. And normally you wouldn't have two different folders for Docker. You'd only have one Docker file. But for the purposes of the course I want you to be able to compare and contrast between having a slim regular traditional Docker file and then also a layered Docker file. So now we are actually building the layered Docker file and what I want to do is I want to come in and this is going to be a multi-stage build meaning that we will have two Docker images start up. So one will build and we're going to be using that to run a command to extract out the layers and then the second one is going to be the actual Docker file that we're using for our image and we'll take the layers from the first one and copy those over. So let's take a little closer look as to what we're doing here. Again we just need that and we are going to call this as a builder. So that is we're using this as a builder image. WorkDir is going to be application is just fine. And here I'm going to use the add command. Add and copy are very similar and here I'm going to say target. We're going to get to the directory a little bit different. Again we want to take that jar file and that's going to be kbe. So that is going to add that in and here what we want to do is say run java minus d jar mode equals tools and dot slash there and if I mistyped something we're going to copy it over. So we're going to say minus jar so this is a java command we are saying use the layer tools to extract out the layers. So that's all we want from this first builder. So inside this image it's going to start up as a container and it's going to take in and we'll add in that target the jar file and we are using the layer tools to extract out those layers. Now we're going to say from open JDK we'll use the same one jreslim and we can use application it's just fine and now we're going to say copy and actually I'm going to copy this over from my working notes it's going to speed up. I don't think you guys want to see me type all this out so I'm going to cut and paste this in so now we can see that we're saying copy from builder so that's doing a reference to this image saying from builder from the directory application dependencies and we're going to bring those into our application so this here is the first container that we're starting up and then this is the image that we are building and note here that we have the four layers that we are copying so we have dependencies spring bootloader snapshot dependencies which is typically going to be empty then the application and then the entry point the entry point now we are going to use the spring bootloader the jar launcher so slightly different that's what allows all the class paths and stuff to get reassembled in this and before we actually try to build this remember here we added in that maven configuration to do the layers we want to do a clean on our project now we can say go ahead and do a package step now package things up with the new layers being built and while that's building we want to do this so I'm giving you that docker command and now it's not docker base it's just going to be docker and so it's the same command so I'm going to copy that command and we'll take that into terminal so now rather than docker base we are going docker docker file and we'll tag that to kbe rust again and you can see that we did have everything build properly and you can see here that we are doing the multiple stages of the copy and then writing the image and you can see that's coming up cache and that's because I ran up previously in my testing if anything changed it would have changed there just double checking everything and now if we do docker ps you can see that I still just have Postgres running let's do a spec down this we can do docker history and that will be kbe rust that is our tag and here which you can see this is a history of that image these lines down here that is all from the base image so that is from the jre image so you can see that that's got a number of layers now we have a worker of application and here you can see the actual dependency so our dependencies so that 41 meg that's a good chunk of data that is all our that's the fat jar dependency so all the various jars and that's actually pretty slim for a spring boot project so as you get into larger projects and having more complex applications that can grow significantly then our spring boot loader that is pretty light snapshots and then there's our application you can see that's only 90 kilobytes so if we were deploying this running multiple versions of our application deploying that over and over and over rather than having all this get copied into a single image now these files here are going to be staying the same they'll get reused so if I have four applications running on the jre these are all going to get reused automatically because we're using that jre image if we have the exact same dependencies these will get reused and then only this one is going to be changing so very important this if you start living with Docker on machines you do realize that if you are tight on disk space it can really chew up a lot of disk space and this is a way to really make your disk utilization by Docker a lot more efficient so this is going to be a lot more efficient for building and deploying applications in either a test or some type of production deployment environment so the layers that the Spring Boot team came up with it's a pretty clever way of saving yourself a lot of disk space and a lot of ongoing maintenance and having to go back and clean up the old layers that you may have on your system now there's a number of different ways that we can actually build our Docker images Maven is a very popular build tool for building your Java Java projects such as Spring Boot so it's widely used in the enterprise we can also leverage that in any Docker context as well so we're going to go in and look at adding in a plugin to Maven to help automate our build so if we are getting into a CICD type environment having a common build tool capable of producing our artifacts not only just the Fat Spring Boot Jar but an actual Docker image directly from our build is going to become very important in this section of the course I'm going to show you exactly how to configure Maven to produce Docker images so when it comes to working with Docker and building images from within the Docker context you do have a number of different options one very popular plugin for a long time was the Fabric8 Maven plugin you can see here that I have that on the screen and it's been deprecated and that just happened about six months ago so I'm recording in May of 2021 so this is a fairly recent change at the time of recording that this was a deprecated Fabric8 was a really cool project but that project is no more and so that plugin has been deprecated it's been picked up by Eclipse and it is now called JCube so JCube is a very very robust plugin it was basically a branch of the Fabric8 Maven plugin this is where all the active development is happening JCube works with not only Docker but Kubernetes and OpenShift it has a lot of very robust features and I'm going to not use this one right now everything is very very similar but I'm going to be using a different Fabric8 plugin called the Docker Maven plugin and there's very easy to get confused as to which Fabric8 Maven plugin we're talking about the Docker Maven plugin this at the time of recording is still active it's still in the Fabric8 repository you can see here Fabric8.io Docker Maven plugin we're still getting commits there's just a release done just a month or so ago so on April 4th this is still active the core differences this is a lighter simpler plugin and it only works with Docker so only it utilizes Docker and you can see here we do have a number of options here we can start stop, build images and you can see a number of things here we can even watch for changes and automatically rebuild them so there's a lot that we can do here if you needed to run integration tests bring up a container for an integration test you could utilize this plugin we are not going to be covering all the features here we're primary can be looking at two pieces of this to build images we want to be able to automate our build process using Maven and then push those images up to Docker but I did want to take a moment talk about this plugin the capabilities of it it does give you very nice integration between Maven and Docker so we are interested in building Docker images and what I'm going to do now is going to toggle over to IntelliJ and show you how to start configuring this plugin for use in our project so only jump over to IntelliJ and the first thing we want to do is come in and configure the plugin so I'm going to put it in right here so we want to do plugin group ID this is going to be IO Fabric8 and it brought in the wrong one we actually want the Docker Maven plugin and I'm going to go with 0341 I think that is the current release I'm going to double check that I'm going to toggle over to Chrome real quick it's actually 35 so we'll update this to 35 we'll get the very latest there you can see that is red because I do not have that locally so when I do a build action this will be brought in so I'll go ahead I'm going to click on refresh to tell IntelliJ and you can see that we're downloading that now I'm going to add in some configuration for this the first thing we can do is we can do verbose this will give us some additional information out to the council nice to see what's happening and we can build one or more images so there's a lot of things that you can do with this we are going to use a Dockerfile build you can actually use XML in the palm to declare your build here we are going to I think it's simplest to use the Dockerfile especially since we have a multi-stage Dockerfile here we want that capabilities preserved so we will go ahead and do that and I'm going to say images image we'll give this a name you were calling it kbrest if I remember right now we need to declare a build element and this is how we are actually going to be building our image and what we need to do here is to declare an assembly this works a lot like the maven assembly plugin according to the documentation and we are adding in this line because what we want it to do is it's going to be copying files around and we'll take a look at that closer in the build process so we are saying descriptor ref artifact and by default remember we set up the source main Dockerfile by default and we're going to be looking in that so we are going to say Dockerfile and if I wanted to use a different file name I could declare it like this but I don't need to and then we can also do a tag of our image so let's do tags we can do multiple tags here we'll just declare one for the time being call that latest now one very important thing that we do need to change in our Dockerfile this is going to be copying files around and what we do is come to our Dockerfile and rather than target we want to tell it maven so now the fabricate maven plugin is going to be running the build it's going to be running in that context and the plugin is going to copy files and we'll take a quick look at that so come back over here all that looks correct I'm going to do a refresh here we can see that I'm going to disable our tests right now and we'll go ahead and do a clean that deletes the target directory we'll do a package let me resize some of these we can see that our target directory is back and typical build this is the jar that we want to be including so now I'm going to come over here under plugins we can see Docker and if I was running this from the command line it would be simply maven docker build so I'm going to do the docker build and the way this is working I'm doing it in sequence if we were running from a command line and we didn't have the target directory created we'd have to do maven package docker colon build but right now we've already done the package stuff I'm going to go ahead and run the build stuff you can see that the build did go and complete successfully and let's take a closer look here so now we see under target we have a docker kberus the name of our name of our image and then you can see here under build maven and that's why we had to set that there so here we're running in this context so now we need to tell it's going to be running in the context of the build folder that's where the docker builder is going to be executing from so that's why we need to change that maven because now our docker file is now building from that location so very important so just to recap what we covered in this video this is specifically the fabricate docker maven plugin that we added and intelj hasn't picked that up yet but I'll go ahead and correct that between the videos and here the configuration I did add in verbose to give us a little more chatter in the log so we can see the build steps happening otherwise without the verbose we wouldn't see the image being built like that we are giving the image a name of kberest basically this assembly structure here it tells the plugin to copy this maven artifact over so this is how you copy that into the build directory for us we are specifying the docker file to use and by default the plugin is going to be looking at the source main docker and we are just saying the docker file there and we are applying one tag to the image that we are building of latest and that will get tagged you can see right here in the log output tag with latest and if we wanted to specify multiple tags we could also do so here currently we do have the image being built via maven but there are some things that we can do to make our life a little more easy as far as managing a project now if we take a look at the docker file we are utilizing the name of the artifact so if we do a release we change that version what is going to have to happen is we are going to have to go in and update this so if we did a release to 01 or 02 we would have to go in and edit this file manually and not something that we actually want to do so what we can do is we can utilize maven properties to control this and rather than having the string here we can have it replaced with maven property at runtime so if I come in here like so and I do dollar sign squiggly like that now I can say project.build.final name and this is a maven property that is available at runtime this is the name of the jar so when we run this if we change the version that is going to get changed so I can just take that and copy him right to here like so so that takes care of our build file so there is a couple other things that we can utilize this with also so let's come back to our maven configuration here in the palm and one thing that we are doing here is we are setting it up as kb-rest and a different convention that I like to use so remember the image coordinates if we are pushing up to docker hub we are going to be our name so in my case I have a docker hub account called spring framework guru and then I want to give it a name and the name that I like to use here is from the project itself the artifact ID so the artifact ID which is going to be the kb-rest brewery that will make it a pendant so if I ever have to change the name here that would change I do like to have my repository reflecting that artifact ID name now my docker image as well will reflect that then one additional thing that we can do here is we are tagging it and let's say we are going through a release process or something like that it would be nice to have that version as well so if I were to do a release to 01 or 02 we would like to have an image with that so what we can do here is again using a maven property we will do project and here we are just going to say project version and that will pick up the version property so now when this runs we will get not only tagged to latest but we will also get the tag of version and I don't have to rebuild everything but I can come in here and run the build stuff and demonstrate this so I am just going to come in and do docker build and we will go ahead and expand this window up a little bit so we can see that the build did go through successfully and everything worked properly you can see here this line here the property was properly applied at run time so that got replaced at run time so rather than having that property string it did in fact work properly the way we expected to so now if I change versions and doing a release or something like that that will automatically happen and then here we can see also in the log output that we have the tag of latest and also the 001 snapshot so now we have that image with both tag of latest and snapshot if I were to do a release the tagged images will still be up in docker hub the latest would get replaced and then the 02 would be there but 01 would still also be there so this is a really handy way to version your images as you are doing releases with your java projects so let me minimize this and just recap exactly what I changed here so I came into the docker file and for the file name I am now using a maven property so that will be picked up as the file name changes when we change the versioning information the file name will change and now this will work properly at run time when we are building a project and then also in the palm I changed the name of it so I am now adding in my docker hub directory as well as the I am utilizing the artifact ID for the name and then in our build we are also tagging it with the current version of the build ok in this video we are going to be pushing images up to docker hub so you can see I have docker hub up on the screen here if you want to follow along you are going to need your own docker hub account they are free it is free to register free to use so if you want to follow along obviously you are going to need your own because I am not going to be sharing my credentials with the world here so you can see here I have a number of different images that are already up there in this case we are going to be pushing this up there for the first time once you have your credentials we do need to do a configuration step for the maven plugin to pick things up so here I have the plugin documentation from fabricate and we can see here that there are six different ways of defining the credentials so you can do system properties docker username and password registry username and password you can do an auth config section in the plugin not too thrilled on that one because right on the palm file you would have credentials so that is probably not a very good idea you can use open shift configuration a very common one is using the server tag in your maven under your home directory there are two settings set up a server with docker hub and then the credentials so that is a pretty straightforward way of doing that and then finally you can do a registry you can see here credentials help under a hidden folder called docker config json that one I have not seen used but I am sure it is used out there so to follow along with this video you will need to do both have a docker hub account and use one of these methods to set up the credentials once you have that you will be able to authenticate with docker hub and you will be able to push so with that set I am going to come over to the command line now or at least intelligent and intelligent we do have the ability to bring up a terminal which I am going to do now and what we can do here is say maven docker build docker push so actually if I was running this for the first time if I wanted to run everything all together I could do clean package docker build docker push so that is going to run all those together so let's go ahead and run that and this is going to clean the project rebuild it run our couple tests there you can see the spring boot dialog coming up and in a second here we will get into the build phase you can see here we are building the image and here this is actually the push up to the registry so you can see docker push it is pushing up the various file layers that we created and that last one is going to be a little big let them have somewhat of a speedy internet connection here and you can see here we have set everything thing up so it has pushed up to docker hub now we can see the hash digest here of what was pushed up let's toggle back over to chrome and come back over here to docker hub and go ahead and do a refresh of that and we can see here is the kbe raspberry it wasn't there previously somehow we got three downloads I'm not sure how that happened so but we can see that this is now up inside of docker hub we can see that we have the latest tag and also a snapshot as well so that has now been pushed up to docker hub and is available for anybody that would like to use it