Jenkins X 3.x Getting Started Demo

welcome to this short demonstration of jenkins x version 3. so let's show you how to install it uh if you click on the docs and click on the version 3 website and the getting started guide the first thing to do is pick a git repository based on the kind of cluster you want to create whether it's google amazon or mini cube right now we hope to have a zero fairly soon and a bunch of other example quick starts i'll click on the gke one we're going to start off using gke and google cloud with terraform and vault so we click on this url which opens a little wizard on github.com and we're going to create a brand new git repository for our cluster we'll call it terraform three i'll make it a private repository just in case i accidentally check in any secrets or anything and i'll create a repository so now we've got a new git repository on github and i'll talk about the source code inside this git repository a little bit later but let's get going on the demo um now we need to get clone the repository so i'm going to git clone this new repository and then cd into jx3 terraform demo3 so here's the cloned stuff and now we read the docs on how to create your infrastructure which in this case is using um terraform i've already installed the terraform binary so i'm going to create the environment variable for which google project i wish to create this inside and then we're going to run the terraform i'm going to configure the project which is going to modify the terraform file to specify the project id and now we're going to run the apply this is going to download all the various terraform modules um initialize and verify the terraform stuff we then get a chance to approve at the end so now we enter yes to continue to create the kubernetes cluster and buckets and service accounts and so forth click yes and now terraform is going to set up all the infrastructure for us okay we've created the cluster now if i do cubectl get name spaces i'll see there's no jx namespace yet there's a certain manager namespace and the default and cubesystem and stuff so we've got an empty kubernetes cluster now what we need to do is commit any uh change files um do git status we'll see that we've modified uh the terraform file git status git diff we'll see we've added the project id so we're gonna do a git commit commit run the same on this end good push okay and now we're going to run the operator the git operator which is going to install jenkins x into this cluster so i type jx admin operator it's going to ask me for my github username and token to run the pipeline and all the pipelines all the cicd pipelines i can use my personal username um i'm going to copy in a token i've created already now you can click on this url here to create a new token and click that now it's going to um refresh the helm uh the locally queried helm chart repositories i'm gonna install the jx git operator chart you see that line there it's gonna install the jxket operator this is basically the line that is just executed it's running helm version 3.2.4 it's installing a chart it's passing in the url of my git repository my username my token into the jx namespace and that's the chart name so it's going to install that chart the track contains the git operator which is a thing that installs jenkins x in a job inside the kubernetes cluster so it looks like this is all running on my laptop but really everything's running in a pod inside kubernetes from now on so this is the pod for the git operator that's starting it's ready it's running that's great now the git operator is going to create a job to install jenkins x this jake's boot job here um the job has started um a pod should start soonish and then the whole installation process will continue so it's nice and simple you create the git repository um you configure it with your cluster-specific details um you commit the changes then you just run jx admin operator so it's one simple command from a git repository and while that's running we can open octant let's open update there we go i just ran octane to the shell and here's the octane front end where we can now look at what's happening in the cluster so it's looking at the jx namespace and if i look at the pods you'll see these are all the running pods so we've got the git operator running and the git operator is the thing that periodically pulls the git repository to look for changes it's seen a change so now it's around this jx boot pod and that pods now running and we can see in the console here's the output of the installation job um so this is going to take a few minutes to run and fairly soon we should see some new pods appear okay boots finished we've now got a jenkins x install complete if i look inside the repositories tab we'll see we just have a single repository which is the repository that contains the git repository configuration for the terraform so that's the term form file and it's got the helm file which defines all the chats we're deploying so there's uh kubernetes external secrets there's nginx there's tekton there's lighthouse nexus chat museum and so forth full operator and something called push away so we've defined we've got a definition of all the charts to install in this helm file and we've got the requirements file which defines things like what's the gcp project what's the name of the vault what name space to use and so forth right so let's let's try use jenkins x if i look in the pipelines tab we'll see we've run a pipeline on uh the cluster repository to set up all the name spaces in the jenkins x deployments and so on and you'll see here's all the apps we've installed so far in the jx namespace so we've got the git operator build and roll controller falcon controller and keeper are part of lighthouse and webpack web focuses to nexus and tectum okay right so let's keep this open on the pipelines tab uh let's create a brand new quick start so with jenkins x3 we use the project command so project quickstart this will create a new project quickstart um i've not downloaded the most recent project plugin so it's just downloading that for me once it's done that it won't ask you again for the latest version it's asking me which kind of quick start do i want to do and i'm going to use a node quick start i'm going to use my get user i'm going to use that my personal organization to create this uh think of a really good uh project name let's call it uh awesome node uh initialize the git repository and commit the quick start source code gonna use the default build pack and we're going to use a javascript build pack in the library it's now going to create a git repository on github and here's the git repository let me open that in a new terminal new browser so here's the gate repository if you've seen the jenkins x demonstration before this all probably looks very similar it's a very simple node.js application with a very lovely home page that just says jenkins x um what's interesting about jenkins x3 is we've now created a poll request on the cluster repository and if i open that pull request i'll show you what it looks like so this is the pull request that's been generated to to import this new quick start and if you look at the files that have been changed we'll see we're keeping this depending matrix which is a little bit of metadata that keeps track of all the different dependencies of a repository that helps us understand the uh the flow of versions across repositories and we've created this new file here and let's view that file file so there's a new file called source config in jk3 so this is in the dot jx github source config file and this is basically a single simple config file that keeps track of all the different git repositories you you import into the cluster so there's one or more groups each group has an owner or an organization or a user in the git provider this one's for github.com at the provider github.com the owner is my personal user name and then here's all the repositories that are going to be imported from that user so if you want a quick way of importing lots of different projects you can just create a pull request on this text file and junkies x3 will automatically import all of those projects you mentioned in this file so it's nice and easy to just use pure githubs to import repositories now we also have a couple of commands in the jx githubs plugin which helps export projects from other clusters um let me show you this one repository let me go here this is the jx githubs command line and under repository we have repository export so there's this new command jx github's repository export which if you connect to a version 2 cluster and this will export all of the source repositories in that cluster and generate this file for you so it's a way of connecting to an existing you know version 1 or version 2 jenkins x installation exporting all the source repositories creating that one file and then just checking that file into git and hey pesto you've imported all the social procedures into your new cluster now let me show you this pull request again um you see we're running a pipeline on this pull request and look at the pull request one more time so if you remember the very first file it changed was that source config file so this one now because the the pull request pipeline is detected you've changed the source config it's also generated the source repository custom resource in the config root namespaces jx folder so we have a source repository resource that's going to be applied into kubernetes and it's also updated you see these files here these files are the lighthouse configuration files so it's also generated the pull request on the lighthouse configuration files to add pre-submit and post submit pipelines for this git repository so what we've basically done is automatically generate a whole bunch of resources in the pull request and what's nice about this is you can just look at each pull request and see exactly what's actually going to happen so these are all the actual changes to kubernetes resources that are going to be applied when this pull request merges so the very first the very first commit if we go back and look at the pull request the very first commit was a fairly modest it just added the dependency yaml and the source repository then another pull request another commit has been generated which generates all the other stuff so the source repository the lighthouse config files and those kind of things so we get again a double commit on each pull request so fairly soon this pull request should go green and then it should merge and we can watch the pull requests executing in in the ui so we can see we've got the poor request number one on uh the cluster good repository currently in general six version three the very first input process is a little bit slower we haven't quite optimized it for speed yet so it can take kind of five minutes to do your very first import once you've imported in your repository it's pretty quick from then on but the very first import is a little bit slow it ends up running the pipeline three times which is suboptimal it runs it the first time to do the code generation it runs a second time and then the third time it basically checks that nothing's changed since the last commit so we can hopefully make this a little bit quicker soon and you can see the import is finished um here's the commands we can use the command line to watch the pipeline running the classic jsk activity so we can watch the pipeline running on the command line you'll also notice that the pipeline for this new quick start has started in octane as well so we can look at it in octane and we can watch the pipeline flow here and so this new quick start is going to be built uh the container image pushed to the container registry it's then going to create a pull request on the cluster gate repository to deploy this quick start into the staging name space with djangos x3 we use a single did repository to represent all of the local namespaces in the cluster so we don't have a separate staging git repository right now because staging by default is in the same cluster as dev um so we're going to use the same git repository for dev and staging so this pipeline will took a long and we'll promote to staging while that's running let's look at the repositories page we'll see now we have two repositories we've got the cluster good repository and we've got this quick start if i let me close these other tabs a second if i open this good repository for this awesome quick start i'm going to make a pull request so i'm going to edit this file i'm going to say awesome x jenkins awesome x and i'm going to create a pull request we propose a change and create a pull request there we go there's the pull request created and you'll notice the chat ops has kicked in and the pipeline has started if i go back to octant and look at the pipelines page we'll see there's a pull request started for the pipe there's a pull request there's a pipeline starting for the pull request and in addition to the release pipeline that's running we can filter out just the olsen node uh pipelines to make it a bit more simple so we're running a pull request pipeline and the release pipeline at the same time so we'll be able to see the effect of the pull request and the effect for promoter staging very shortly if we look at the pipeline for the promotion you'll see we've created a pull request and if i click on that pull request is the pull request to promote version 1 0 1 to the staging environment if i look at the files changed you can see the pull request changes the helm file and it's adding a new chart the awesome node version 101. it's going to use the namespace jx staging and because we've never used the local chart museum yet it's going to add a new chat museum url into the requirements file so if i view this as a complete file you'll see we have all the different repositories here the helm chart repositories so we see we've added a new repository called dev which has got our local chat museum and towards the bottom of these chart releases we'll see here's the new um awesome node chart in the dev chart repository with 1 0 1. so you can see that we can have many different chart repositories here different teams can have their own chart repository and you can deploy any chart from any repository in any name space and if you didn't want this to be in the j extending their space you could pick another namespace and put it somewhere else so using a symbol simple standard yaml file the helm file we can deploy any kind of charts in any namespace in the cluster and it's githubs all the way um so this pipeline will continue it's going to um trigger um a pipeline on let's see we've got the pipeline running on the [Music] it's the pull request has triggered the pipeline on the cluster gate repository and what's interesting about this pull request um if i look at the pull request go back to the pull request this one so just like before we have a fairly modest commit to start with which just adds the new helm file changes there we go and then we're going to get another commit on this pull request which is going to add all of the actual resources that are included in that chart so the deployment resource the ingress resource yeah there we go we've just generated another pull request another commit to the pull request and if we look in here we'll see we've never used the jx staging namespace before so there's a namespace resource being created there's the deployment resource in the jx staging namespace for this app this is the content image that's being used 101 and the various readiness probes and liveness probes this is the ingress that's being created this is where the endpoint is going to be and this is a release crd that includes details about like what's the sha what what was the commit uh where's the git url and those kind of things so we can see from the git pull request exactly what's actually going to happen in kubernetes when we merge this we don't have to do magic or mentally guess we can see exactly what's actually going to be changed in kubernetes so it helps on your your reviews so once this pipeline goes green it should merge and then we'll have this application promoted to the staging namespace meanwhile the pull requests the pipeline for the pull request on the preview has already completed which is awesome if we look at the pull request let me close into the tabs if open the pull request so this is a pull request i made on the also node app we'll see we have the comment uh the pull request is built and available in preview environment that's the name space and here's the app and if i click on the app we'll see here's the running application with hello nerd jenkins awesome x so there's the preview of the code before we've merged it which is awesome we can also go straight to the preview from octant if we click on this preview link and open that it goes straight to the preview so we can link to the preview we can link to the repository and we can link to the pull request all from this handy little page we'll also look at the logs of all these steps or the step definitions and stuff and now if we go back we should see promoter staging is chugging along we're almost there and we should have a release promoted to staging shortly and as you can see the the promotion pipeline is finished so we can switch into the jx staging namespace and look at the apps look at the apps in there so we can see in the jx staging we have awesome node deployed version one zero one is one pod running out of one and if we click on this url we'll see there's the quick start running in the staging environment so we've created a brand new cluster from scratch we've imported the project we've built it released it to staging and we've created a preview environment pretty cool thanks for watching you

Channel: Jenkins X

Views: 8,285

Keywords: kubernetes, CI/CD, jenkins-x, GitOps

Id: RYgKvRpjkoY

Length: 21min 16sec (1276 seconds)

Published: Wed Aug 26 2020