 Welcome to Automate Container Image Creation and Deploy to Kubernetes Clusters. This session is packed with lots of learning, content, and demos, so let's begin. We'll be showing open-source tools and enterprise-grade solutions that you can use today to automate your container creation, so you can include in your pipeline. Containers are fun to work with when you have a manageable set. Even with hundreds of containers, like on the right, we can still somewhat manage by hand. But when you go to scale, there's a point where you don't have enough hands. Running containers at scale is a logistical nightmare, especially when many enterprises are running thousands and more typically tens of thousands of containers, if not more. How do you fix a bug or a CVE in this situation? How do you fix a virus or even find one? It can be impossible manually and clunky or risky with the wrong tool. This is a 2020 CNCF survey that shows teams are still finding containers complex. They're hard to keep secure. It's difficult to train staff and a plethora of other issues, especially when developers want to focus on writing code and not on something that's more operational, like containers. Taking this single example here out of many possible examples where this can go wrong. Here we have devs that are building their own containers with dependencies downloaded from unknown websites. Suddenly you have multiple teams building containers using different OS versions, different JDK files, different dependencies, etc. You get the idea. Things can get unruly very quick, especially if you have an issue. This is where VMware Tanzu Build Service can help. VMware Tanzu Build Service provides automatic image builds and updates even down to the OS layer, providing complete control over images that are built automatically. There's improved security. It's easy to track and patch containers. There's also included notary signing. There's metadata that can improve audits and you can enforce policy to ensure compliance to what is actually being used. Tanzu Build Service is built from open source projects like Cloud Native Build Packs and K-Pack that produce open container initiative containers that can run on any cloud and are backward compatible with Docker. Quickly, Cloud Native Build Packs are supported by top tech firms. Even GitLab implements Cloud Native Build Packs. Cloud Native Build Packs have been around for a decade since 2011. Cloud Native Build Packs are imperative and can build a container simply with the command pack build and you include your app name. It automatically detects dependencies and packages all of this into an LCI compliant container image. We're going to be using the terminal to build our container with our Java Spring source code. We're going to use pack build, our container GitLab container and a builder that's used for Java. We're going to fast forward. Our container has finished building. We have our GitLab container. If we do Docker images and query that container, we have it here and it can run pretty much anywhere. K-Pack, on the other hand, is another open source tool that's behind Tanzu Build Service and it's declarative in nature. It's a Kubernetes native tool. In the image config here, you can specify a repo and a commit to trigger automatic image builds. Or you can trigger builds across your thousands of containers if you need to patch an image. Let's look at our CI CD pipeline that takes code from a commit and deploys that to a Kubernetes cluster. Quick side note of terms if you're just getting started with GitLab CI CD. A job is a singular task like testing code or running a script in the real world, baking a cake possibly. A runner executes the jobs. So this could be like a chef or cook or a cake machine baking the cakes. A stage is a job or many jobs. For example, for our code, it could be testing the code, could be stage one, stage two could be the build. And each stage could have multiple steps or multiple jobs. Like stage one could do multiple tests of code. Stage two with the build could build several image layers. So it needs several jobs to run that or build several images. And the order matters. You wouldn't want to build until you test or you wouldn't want to bake your cake until you prepare your supplies and mix. So GitLab CI CD is all these concepts working together to form pipelines. And in our real world example, it would be a cake factory that takes raw materials and turns out a cake. Just hand it over the flour and the eggs and then the cakes pop out on the other side. Let's go through the different stages of our pipeline so that we know what's going on once we start the demo. So in the initial stage, we'll have our developer submit their code, which triggers the entire pipeline down to deploying our code to Kubernetes. This code is taken by VMware Tanzu Build Service and converted into an open container initiative container image that can live on any cloud. This container image is then uploaded to our image registry. Then a series of tests are performed and it's deployed to our Kubernetes cluster, which is a VMware Tanzu Kubernetes Grid cluster that can live on any cloud and also on-prem or in a hybrid situation. Here's the main repository for our GitLab pipeline. It's called Spring Music. And it contains different files and directories that have what we need to run our pipeline and different files that we have for our source code for our application for Spring Music. Once the source code gets submitted through the pipeline and deployed to Kubernetes, this is what it looks like. It's a Spring Music and it has a few albums back to our main repository. So we're back in our repository in our IDE here using VS Code. We're going to go into our header class here and change the title for Spring Music from Spring Music to how about just GitLab Connect 2021. Save that. Go to GitHub. Add our changes here. GitLab Connect 2021. Just save that commit. Push and let's look at our pipeline. If you click on CI CD Pipelines, then into this latest commit, GitLab Connect 2021, we can see here a visualization of our pipeline. With each of our stages, set registry creds, build, test, review, all these production, performance, all these different stages correspond to a different stage in your GitLab CI YAML, which we'll be seeing next. So please reference these in those files, build, test, review. We are setting these stages. You can see these different stages that I'm highlighting, test, review, build, and the GitLab CI YAML. That's the .gitlab-ci yaml in your main repository. This is what sets the different stages. There is one little difference as you can see, static testing. That's not in this graphic on the left, but if you go into your ci-test.gitlab-ci yaml, this is where we're creating that static testing stage. This stage, the static testing stage, is very simple. It uses a Java container image from Bitnami and runs a couple of tests on the Spring Music app. Now taking a look at our GitLab CI YAML that we have here, looking into greater detail, we can see that we're running a lightweight Linux image called Alpine. We're also using a lot of environment variables. For example, for our Postgres database, for Docker, etc., within these variables, some of these include the prefix CI underscore, especially in other of our GitLab configuration files. You will see this similar prefix, and that's provided by GitLab, and those environment variables will be populated by GitLab in those files. We do not recommend to use this prefix for environment variables for that reason, especially when using your own custom variables. Please give them a different prefix. It will cause less confusion. Going on to the stages, you might ask yourself, where are all these stages coming from? Where is the Canary stage? Where is the production stage? Where is cleanup? Where are these configured? Are these premade by GitLab? Well, the answer is some of them are and some of them aren't. The include section has all these configurations for our pipeline. Let's take a closer look at the code. Looking at the code, we're taking the same GitLab CI YAML file and just splitting them in two. We're showing the stages section here and the include section on the right. They are just split screen. We're doing this just to show them side by side. This static testing does come from this file, TestGitLab CI YAML. Let's look at that again, even though we did previously. This is our TestGitLab CI YAML, and the stage it creates is static testing. This is one of the files that is creating one of these stages. For example, our setRegisticReds does correspond to this file. Our build stage does get created by this configuration here, the build configuration, and like so for many of these files, but not for all of them. Some of these files, as you can tell from this URL in the notes, are coming from GitLab themselves. These are previous configurations that can be used by anyone that's using GitLab CI CD, and they're common actions that you might want to perform, and it's nice to have them so you don't have to build them yourself. We've broken down the GitLab CI YAML file into the stages and include section, and we've seen that the different stages can correspond to a configuration file on the right, which if you're seeing the CI directory prepended to one of these YAML files, then you know that these YAML files are custom stages that were made. For example, the static testing stage that we've seen previously. Let's take another look at that. Here's the static testing stage under the CI directory that tests the code in our spring music application. Looking at the CI update GLR creds GitLab CI YAML, we can see that this is our set registry creds stage. That's the next stage that was specified here. So what does this configuration file do? This one uses an image of this name that it gets from the GitLab registry and runs a script called kuconfig.sh. It also creates a name for a secret. These right here are environment variables from GitLab that we've referenced before. Then we save the registry password that we are getting for the GitLab registry and we're going to store this to our TBS, our Tanzu Build Service. And again, this would not be a registry password, but in real world you might have something else like a token. Here we have kpack, our open source tool, creating a secret for us. And then it's going to store the secret on the TBS cluster and it's going to use that to authenticate with the image registry, in this case the GitLab registry that we referenced. So we just finished looking at the section that sets our registry credentials for Tanzu Build Service and the container image registry so they can communicate and send things back and forth. Let's look at our next stage, our build stage. In this stage we have an image that we use from our GitLab registry and we use this image for our stage. In that image we create this script right here that creates the kube config and the context that is needed by the Tanzu Build Service. In this next section right here, we're using the kpack CLI to check the status of the image here. If the image exists, then it will patch the image with the latest commit. And if it does not exist, it will create a new image based on that source code. This is completely hands-off and automatic. Even though we are using CLI commands here, this was a design choice for this pipeline, but it's not really needed. It could be completely hands-off and just be kicked off by changes in a commit and TBS is smart enough to recognize that and build a new image and send that through your pipeline. So this pretty much takes us through our whole pipeline. The rest of the stages you see here come from GitLab. They're stages that people use a lot and we've employed them. So pretty much all the stages in this section, almost all of them, come from GitLab's deploy GitLab CI YAML. And we're just reusing those jobs that they have in NetYAML. So as we can see, our pipeline has finished running. All these stages now have check marks that our pipeline finished running. There are no longer any icons that are showing progress and every stage is complete. So our pipeline has taken bra source code, used Tanzu Build Service to build a container and deployed that to our Kubernetes cluster, which is Tanzu Kubernetes Grid. So now it's time to see the change that we made to the title right here in our application by refreshing this page. So just as a reminder, we're going to refresh and look for this title, GitLab Connect 2021, which was from our first commit, but automatically refreshed and it's GitLab Connect 2021, completing our pipeline from bra source code, taking you all the way through the pipeline to a working application using Tanzu Build Service to create your containers automatically in Tanzu Kubernetes Grid to host this application.