Creating an Azure DevOps CI & CD pipeline for AKS

i would like to welcome our speaker so in today's session we are joined by itae malca a cloud solutions architect from 2bcloud itae will walk us through the process of setting up a ci cd pipeline on kubernetes this session will run for approximately 60 minutes with time for questions so ittay thank you so much for being a part of today's session um and also to to be cloud for making this all possible please at this time you are welcome to unmute yourself share your screen i am giving you the floor yeah thanks you thanks rebecca thanks for the introduction and hi guys um just i want to share my screen okay so uh hello you guys and welcome to the azure devops for aks webinar uh thanks for coming first of all nice to meet you my name is itae malka i was born in south israel and as you can see i love sea music and especially food who's not and i'm also a cloud solutions architect at 2b cloud um so who is 2b cloud so we are a global microsoft partner we specialized in working with tech companies and isvs we are an azure expert msp with advanced uh specialization in app modernization sql migration and kubernetes on azure and here's the agenda for today so first of all i just want you to know that i will save time for q a between the following parts and at the end of the meeting so what are we going to do today first of all we're going to make a resources brief and we are going to see how to create basic ci cd pipelines in azure devops and how to deploy to aks which means the azure kubernetes service using this pipelines for that i already created the pipelines but we will start to build them together from scratch and for this demo i also created a simple node.js web application which exposed to the internet over port 3000 which means http and since we need to deploy on kubernetes so we will dockerize the application by creating a docker file build the docker image and push it to the container registry and in our case we will use azure container registry and to store images inside the repository and finally we will see the yaml file with um the ml file sorry which contains the kubernetes resources and objects like deployment and external service that will expose our web application to the internet so first of all as i said before i want to start from the resources brief and the aks and the azure container registry i go to the browser and as you can see here i'm logging to the azure portal and i go i also created before and resource group named webinar rg and inside this resource group we can find two resources the first one is named webinar aks which represent the aks cluster the kubernetes cluster that we're going to deploy to our web application and the second one is the container registry named webinar acr or azure container registry so we actually have to create a docker image and put it and push it to this container registry and then we want to deploy our application on kubernetes which means the aks um so that's the reason why um why this visual says i created before um okay so what's next github repository so we will review all the files inside the repository repository that i also created before and push all the files to there and to understand the world flow and now i will show you the repository but a few seconds before i want to share with you this repo is a public repo over the chat so you can find the link to the repository uh on the chat okay so as i said before uh there is a at the end of what we're going to do today like go through all the files inside this repository so first of all i would like to talk about the index js file uh i created this file for simple node.js web application we are not developers and we are a devops engineer so we will not drill down to the code um and it is just starting the web application and write the static content inside it which means if i click on the on the file as you can see i i'm using the express module in node.js and all what when i will start this web application it's actually write this static content welcome to the webinar on the screen and another line with the result of one plus one is equal to calc is a variable that equal to 2 and i want to say that we will see it later but i actually add this line um to the file because i want to test to run unit tests for the app and we will talk about it later next file is the package.json the package.json is a file that holds the metadata relevant to the project like modules dependencies and etc in node.js finally this is the taste the test directory sorry and this directory is used to run the unit tests for the app in many cases we want to test some of methods in our code so today i will show a minimal implementation of unit test and it used to just to understand the concept the base concept of how to deploy and how to manage our ci cd pipelines um in azure devops or in general any ci cd tool what's next so okay now we actually understand that we have an application web application simple one the index.js file with the unit test that includes in the test directory um now as i mentioned before we want to deploy our web application to kubernetes and if you want to deploy to kubernetes it means that we have to dockerize my application to create a docker image so i can deploy it on kubernetes so for that i actually created the docker file so this docker file we must make the application docker as i said and this docker file can build the docker image which expose my web application over port 3000 and we will see how it works later and what else okay and the last one so once we have a web application docker image so all what you have to do is to deploy it on kubernetes so for that you can find the yaml file inside the deployment directory and if i go to it we can find the webinar up dot yaml file that i actually created before and we can find here we find here two objects ronnettis the first one is a deployment that contains one replica it means one pod with one container inside it the name of the container is webinar web up and the image of the container is actually the image that built from the docker file that i showed you uh one minute ago um and what is that url webinar acr.azure cr dot io so it represents the url of my container registry i go back to the azure portal and when i go to the container registry as you can see the login server this is the url that represents my container registry after that the slash this is the repository if i go to repositories in the left menu we can find the repository named webinar web app and inside this repository i can find the multiple multiple tags for multiple images that i push to this registry and okay so we have deployment we have one container that can that can run my web application but in addition i want to be able to expose my web application over the internet and overpower 3000 so for that all that i have to do is to create another object another resource on kubernetes uh and this resource is service type load balancer because i want that this container will be exposed to the internet so anyone can browse to um okay so that's about the github repository and you clone and you can right now cloning it to your local computer um okay so what's next um before i want to before we'll continue and after all the theory uh i will i would like to move forward to a local demo a mini demo on my local computer and i would like to know if there are any questions guys for now and before i will continue and you can feel free to ask now and you can feel free to ask me later at the end of the session um okay good let's check the text in the chat sorry okay it's not a question good okay so okay so before i start the local demo it's really important to say um i just want to show you the concept of cicd especially in azure devops and how to implement it on azure devops and there are a lot of methods how to do it and today i will show you one of them and regarding the local demo now i will show you how to run the web application local and run the unit test by running the npm commands and node commands because we're using node.js framework and so in real cases before we will start our web application we would like or any application we would like to run some tests to check our code methods and i will show you the example and first we will run the unit tests and then we will start the web application so by typing ls l as you can see here i actually already cloned the repository the gita repository to my local computer and as you can see here all the files are exist on my computer [Music] and now i want to show you the test the unit test so if i cut the test js file that is located inside the test directory as we can see here okay i maybe it's preferred that i will show you it from here from the github repository it will be more comfortable good so now as you can see i actually ran one one simple test it's called simple math test which includes two two tests inside it the first test it should return two because i want to check what is the result of one plus one it's supposed to be it's supposed to equal to be two and should and the second test is should return nine because three times three is equal to nine and it's not really a test in the real life when we are developing new feature for our application but it just for this for this case is just for the demo and i want to show you how it works so if i go back to the root directory and i want to run the test i can find how can i run the tests in the package.json file that holds the metadata so if i'm going here you can see that there is a section named scripts and under the scripts we were points to the test that represent the unit tests for our application in ojs and the value is moca mocha is the framework that help us to um to run the unit tests in node.js so let's see the output and let's see how it works locally on my computer let me clean the screen and now by running the npm run test i'm getting the following output moca which is represent the framework of node.js to get a unit test and my two tests under the name simple math test the first one should return two is passing successfully and also they should return nine three times three is actually nine so after i test some methods for example yes in this case uh of my code now i can make sure that i can deploy my application or web application to production for example yeah so i want to start my application by running the command of node with the index js file and which is the root file click enter and if i'm going to the browser because i ran and start the web application on my local computer so i have to browse to my local computer local lost over port 3000 which means http and this is the part that i exposed my web application to the world click enter and as you can see welcome to the webinar and the result of oneplus one is really equal to two um we will take and we will change the file for example i want to edit the index file let add a smile to the file because it's always good to be happy i save the file i want to run the web application again refresh the page and here's the smile and that's exactly what we were going to do with the cicd pipeline today and i will show you how easily it to create so that's the moment we want to delete and remove the changes and we are good okay so after the local demo um i want to start with the real process um of the session of this webinar so we'll talk about two main things the first one is how to create a build pipeline or ci pipeline in azure devops and the second one is how to create a release pipeline or cd pipeline in azure devops and before we'll create the ci pipeline i think that we we need to talk about what is the main purpose of this pipeline so in the most basic way to define this the main purpose of the ci pipeline is to build and prepare the application so that it is ready to be deployed on the relevant infrastructure in our case kubernetes imaging that will develop a new feature to our application now we want to deploy the new version with this feature and in addition in most cases we would like to add some tests for our particular application before we'll deploy it on the production environment for example or any environment even if it's a testing environment development environment and etc so we will create the build pipeline which includes the following components [Music] sorry okay so uh we will as i said we'll create the pipeline uh with the following components yes we are still seeing the powerpoint sorry we're still seeing the powerpoint slide yeah yeah i know okay okay thanks uh i just want to uh to say some theory before we're going to the other to the azure devops um so with the following components the first of the first one is the trigger the pipeline for any from any push or pull request to the main branch in our repository so just to imagine it again once we committed and pushed the new feature to the repository we want to be able to be ready for newer version of our application so this is the first one and i will show you everything don't worry the second one is another task or another part in ci pipeline is to print variables in our pipeline and in most of the pipelines all over the world we are using several variables that are used by us for one or more pipelines for example what is the application version where is the path to the specific files and etc another part or another component is in our case is to install the npm package and ins and run the npm test which means the unit test since we're using node.js in this case we need to install the relevant modules from the package.json by running the by running the npm install command and then uh run the unit test by running the npm run test commands uh next we're going to build the docker file the call and push it to the acr to the azure repo to the azure container registry because we have to deploy it on kubernetes using the docker image and the last component and the last step of any ci pipeline in most cases is to publish an artifact so the last step as i say to publish an artifact that we would like to use in the ci in the cd pipeline which means this is the relevant files to be deployed on their infrastructure so in decay in this case we will publish the deployment tml file because we want to deploy this yaml file on kubernetes to create all the relevant resources so now all the parts that you are guys waiting for now we will go into the azure devops so um okay so in azure devops there is um and a hierarchy for example if you can um see my cursor you can see that i already created an organization in azure devops named itai zero four eight and under the organization i can create a project i also created project named webinar project and i can create multiple projects under one organization and this is in a high level the uh let's say the hierarchy of the azure devops so azure devops have a lot of features uh that you can use starting from birds to manage to our we can use it as platform to manage all of our tasks for example like jira um repos this is the source code management like github we can store and include all of our code here in azure devops directly pipelines we are going to talk and use a lot about with pipeline sorry with ci pipelines which means the build pipeline and the releases pipelines which means the cd pipeline uh test plans and artifact there are another feature but it's not really necessary to this webinar so i will not talk about it so okay so now we are in azure devops by clicking on pipeline i'm going uh i get this page and now i would like to start from scratch i want to build to the to create a new build pipeline so by creating here on new pipeline in the top right corner of the page now i will need to configure some things um first of all is where is my where is my code what is my source code management and in this example my source code management is actually in github so i will choose github okay um next select repository i will choose the webinar repo this is the repository that i created for this webinar and one thing that we have to understand that we must link our repo to the pipeline because we will use the files inside the repository and we want that the pipeline will be triggered for any push or pull request to the main branch or any branch of our repository so it's really important to understand why we're linking our source code management to the build pipeline um next what's next so configure your pipeline so azure devops is very uh convenient to use because there are a lot of building templates which may help which will help us easily to create our pipeline we will start with an empty pipeline and build the pipeline from scratch in this case so i will scroll down and click on starter pipeline so now um as you can see once i chose the starter pipeline it automatically created a yaml file in my repository named azure pipelines dash one dot yammer so from one side you have to be familiar with yaml syntax but from the other side you will see how easily you can create your pipeline with building tasks list in the next few seconds when i go to the pipeline that i actually created before so now we can see that our we can start to uh to write our pipeline and there are a lot of methods and combination of how to create a pipeline there are there is a hierarchy in azure devops for the pipeline for the pipeline structure yes for example some stages which include multiple jobs and the jobs which include multiple steps and steps which include multiple tasks and i will show you how it works in the next few seconds and you can treat each of them in the way that is the best for your organization in this case i will show how i chose to implement the basic ci pipeline and you see and it is not necessarily the best way that i want you to do i want you to know sorry and okay so before i will um explain for any um line or command or command like the trigger main like the pull i will show you the i want to show you the hierarchy of the structure of the azure devops pipeline uh ci pipeline and i want to show you what i uh what i'm talking about so for example i want to start to build my pipeline by this hierarchy so first of all let's as i say stages for example this is the top level in this hierarchy under stages i can create my stage for example my stage under the stage i can create multiple jobs and this is my job for example and under the jobs i can create multiple tasks um steps and tasks so this is a basic uh yaml syntax for how to create ci pipeline in azure and now if i want to create a task for example for example i want to run any bash script or something like that i can just uh write bash and with an amazing autocomplete of azure by click enter i can um to to configure this task and as you can see here it also created a settings button for me so if i'll click on the settings button then i can work with a convenient ui so by clicking on inline i just for example want to i don't know echo two um two sentences to the to the user so i can hello webinar people and hello world for example by clicking on add of course they can configure a lot of another settings here and i can execute any script from any path that placed and located in my repository but in this case i just want to show you a simple um a simple bash script so by clicking on n as you can see that it was really simple to create best script with all of the parameters and settings to be configured and as you can see here in the in the right menu there are the building tasks in azure devops for example let's say that i want another task i don't know i want to publish my artifact for example so i can search for publish artifact and perfect by clicking on publish an artifact you can see that easily i can configure what is the path to publish and what is the artifact name and all the parameters that is necessary to be configured to define this task clicking on add and here is another task so the ui is really really really familiar to the user um and that's it so all what i want to to show you here the hierarchy of the structure of azure devops ci pipeline and it's really important to understand it the stages and other stages the jobs and the steps and the tasks and i can for example i can i don't know um divide my stages by let's say by environments for example i want to uh execute some jobs for my testing environment then i would like to create another another stage for example and this stage is represent my develop meant environment and i can maybe implement some conditions for example if the testing stage uh was failed for example i don't know don't execute the development stage and that's and this is uh really important and really necessary in uh in the devops engineer life so now i want to show you and to work about the pipeline the same pipeline that i created before so by clicking on it i will click on edit sorry okay so um what we can see here in this pipeline let's talk about all of the commands the first command here uh trigger main this is the first line it means that this pipeline will be triggered whenever any push or pull request will will happen to uh to the main branch i can change the the name of instead of main to the relevant branch for example next as we can see here we see the section of variables this is the way to define variables in a ci pipeline in azure this way i can use these variables along the entire length of the pipeline and even pass them to another pipelines and that's a really cool feature and really cool option to use in azure devops for example i can as you can see here i create also created um variable named docker registry service connection and this name this value is represent the service connection that allows me to push docker images to the azure container registry uh i will in the next few minutes i will talk about the service connection because it is a really uh important object uh in azure devops because that's the way how we can uh grant the permissions on azure services or azure resources or external services that are not included in the azure devops um image repository for the name of the repository inside the container registry what is the url of the container registry what is the docker file path for example um as you can see here um we actually i actually use um building environment variable this environment variable is a building in azure devops and it represents my uh the path that i'm working on while the pipeline is executed so this variable will points to the path of the docker file and this is the directory which means the root directory of my repository if you remember i linked my repository with this ci pipeline so i actually use this path slash docker file so if you go back to the repository we can find here in the root directory the docker file uh in the directory so this is why we're using the slash docker file um another important variable is the tag actually here the value is a built-in variable for any execution of ci pipeline or build pipeline there is a unique identifier which called build id so i want to use this tag later when i will push the uh the docker image to the container registry as you can see here all of the numbers so these numbers represent the build id of the pipeline of the ci pipeline uh they comes from um okay and the last name via vm image name uh i will talk about it later this is the operating system of my agent so what else um okay so here we can see sorry so here we can see um that we are starting as i said before with the hierarchy in the stage in the stages line and in this case i treated the stage as an environment for example multiple stages for multiple environment testing depth production as i said before and there are really several approaches regarding how to treat it and you can choose your own um your own prefer and whatever you want it's okay so in this case i really represent it as my environment for example testing um display name this is the name um for for the this is the name of the ci pipeline that i will see when i watch the logs while the ci pipeline runs so this is just just represent the name it's not really matter next uh this is the jobs so here i'm going to define all my tasks all my actually jobs that they want that this ci pipeline will make um so first of all i as i mentioned as i mentioned before the first job is print parameters or print variables and why is that because just i want just to verify and validate all of my parameters or all of my variables that i define uh in the up of this pipeline uh i and i can view later on the pipeline executions uh history so it's really uh it's really helpful and if we're if we're going next to the pull section now azure devops allocates for us an agent an agent it's it means a machine or server on which all of the following commands will run so once i mentioned the pool i can choose which agent i want that azure devops will allocate for me so in this case i chose to use ubuntu latest because to run all of the following commands i need to use a linux operating system so now we see the print parameters job that i defined but i want to uh now i have to um to append at tasks for that to act to be executed so as you can see here this is a simple bash tasks that all what it does it actually print all of the variables um above the first one is the service connection the second image repository and so on and so on and again why should i need it because it's really a classic ci pipeline in this case we have really not a lot of variables but in really pipeline in a big organization we can find more than 100 variables so if we want to research the pipeline and view the history so i can go back to the uh to the run to the runtime of the exit of the ci pipeline and just view all of these parameters so that's the reason why this um this job or this task is really simple but it's really important and helpful uh to research the next issues of our application so next job is to run the application test um if you remember and as i show you in the local demo before we we build our application and before we want to deploy our application we want to check and test some methods in our code so the application tests um is to install the node modules from the package.json file and then run the unit tests so if you can see before i go into the tasks there are again display name and the display on parameter display display sorry deep depends on parameter and depends on parameter represent that and it says until the print parameters didn't finish you will not start and it's really important because sometimes we want to make things in order we want to execute the first task and then the second task and then the third task and not in parallel so that's the reason why i append this parameter here and there are a lot of more a lot of features in azure devops but really it's the basics um so as i said before we want to run the npm install command which is a which is also a built-in um task in azure devops and and you can see here i want to find npm by clicking on npm i can add this task as well and okay and once i run npm install [Music] the command npn install is required any packet json file because it must know which modules and which dependencies should i install so that's the reason why you can find here the working deer the working directory so my rocking directory it means where is the package.json file exists and where is it located so this package.json file is actually works in the root directory and as you remember before this is how can i uh a building environment variable that helps me to locate the uh the root directory next npm after i run the npm install to install all the relevant modules for the tests now i can run the command of npm custom command not [Music] this is just a custom command npm run test because i want to run my test so once this task will be done i'm expecting to get the output of sorry this output of the testing simple math test that two tests are passing successfully and next next job is maybe the most important job in the ci pipeline in many cases i can say in any ci pipeline and why because in this job um or this job build and publish build and push sorry um is is actually to build the docker image from the docker file and push it to the azure container registry um and this job and this and this tasks will build my application so we have to be very carefully about it and we have to take it really really seriously as the other jobs here but especially this job and what can we see here so we can see two steps which means two tasks the first one is the command of it's one task a building task in azure devops that includes two tasks actually the first one is the docker build that will build the docker image from the docker file and the second one is the docker push because i want to push my image with a specific tag to the container registry so what's the parameter that i have or the settings that i have to set here in this task let's think about it so build and push this is a building command that represents the build task and the push push task repository why it's important because and now you can see that i use my variable from the start of the pipeline image repository and if i go scroll up i can see that image repository represent the name of my image of my repository in the container registry so repository uh which means that what is the name of the image repository the docker file what is the path to the docker file exactly as the last setting and the last parameter the repository actually here i also use the variable from the start of the pipeline um what's next container registry so now there is an interesting question i want to specify my container registry so this is the this is my container registry but how azure devops have the permissions to push any docker image to my private container registry on azure um so for that we will answer in the next few minutes because i want to talk about it separately um and it's really important things and the last parameter is the tags so which means i want to before i want to push um the docker image to the container registry i want to specify what is the tag and the tag specified what is the version of my application so i chose to tag my docker image with two uh with two tags actually the first one is the environment variable named tag which represents the build id of the ci pipeline and the second one is the latest and why i did it because i want that no matter who is the latest who is the last image that pushed to the container registry it must be the latest image so it actually holds the latest version of my web application so that's the reason and i just want to wanted to show you that you can configure more than one tag and more than and you can do it multiple times so this is the task of the docker building push what's next publish artifact as i mentioned before any ci slash build pipeline finished with publish artifact task for step and why because this artifact will be [Music] will be used it in the cd pipeline and the published artifact is to publish the deployment file for the cd pipeline as i said to be deployed on aks so if we understand we want to publish the yaml file which includes the kubernetes objects or resources so what is the parameters here path to publish which means the root directory slash deployment y slash deployment because if i go back to the repository click on deployment directory here i can find the webinar up yaml which represents my uh the objects of kubernetes that should be deployed on and the artifact name would just named our artifact in specific name and publish location container not really necessary so um how how do azure devops and this is the really sorry this is the really um important thing in azure devops get permissions on the resources in my azure environment in my private azure environment so i can configure it here by clicking on project settings and scroll down to service account service connections sorry now can i um define all of the connections to my external resources so what is the service connection this is an object in azure devops that enable to connect to external and remote services to execute tasks in a specific job that which exactly what we are need to do and as we can see here i actually have three service connections the first one [Music] is github and why because we linked my we linked our github repository to the pipeline and the pipeline need permission to pull the code from the github repository from the private not private sorry from the github repository next we can see here the webinar acr connection which represents the permission to the azure container registry and the last one is we want to be able to that azure devops cd pipeline will be we will be the will be able to deploy on the kubernetes on the ats cluster so we actually have to create a service connection how we can create service connection when we click on new service connection here we have three we have multiple [Music] how can i say that end points or options to create the service connection on which or in specific for specific resource but for example in my case in our case i want to allow this azure devops to get permissions to my azure resources so i will i will check the azure resource resource manager and i have multiple um multiple options how i want to grant the permissions there is another way to do it if i'll go through the the ci pipeline and let's check for example the task of the build and push docker so now wait a minute not this one where should i have to use the service connection okay okay so let's do it here build and push for example if i want to create a new task now it will ask me to okay it will ask me to a container registry a service connection and if i want to create a service connection i can do it i will show you what is the second option in the cd pipeline because uh there is a more comfortable gui to do it um okay so that's the step of the ci pipeline guys i would like to know if there are any questions or if you want to write until all of the process and all of the word process with the cincd pipeline will be shown to you and at the end of the session of course that i will show you how all of this flow actually works so don't worry about it but i would like to know if for now there are any questions quick questions i think we have a few questions here in the chat window oh sorry oh god we have a question from muhammad he's asking why is there a tick in line 36 line 36 sorry thanks ilanit um edited 36 what is the question why is there tick in line 36 tech in line 36 yeah you have a back uh there just before image before image yeah ah okay so yeah so thanks for the attention it's wrong syntax it's not really necessary here thanks for the attention uh any other questions you'll need or we will wait until the to the end let's do another question and see kevin has a question then we continue kevin you can take yourself out of mute sure thank you um just a quick question about using environments with deploying kubernetes images or what has been your experience deploying into environments with kubernetes and containers sorry i didn't hear you as well i don't know if it's me oh i'm sorry can you hear me now or no yes yes yes can i hear you okay um just a quick question about using environments with kubernetes deployments um adding those into your pipelines um have you had good experience using those um is it something you haven't adopted yet or just trying to find out more about integrating environments into that pipeline ah okay so that's a good question uh thanksgiving um i would like to uh to talk about the the importance of different environment in kubernetes when we are deploying to kubernetes especially in the cd pipeline because here in the ci pipeline there is a really meaning for the environment as if i want to for example use multiple stages for multiple environments but actually the differences between the environment uh tasks in the ci pipeline there is no so much uh differences as we can find the differences in in the real life in the cd pipelines and i would like to talk about it in the in the next step but thanks for the question okay let's go ahead let's go ahead for cd yes so cd um okay so cd ci continuous integration cd continuous deployment or continuous delivery and before we will create the cd slash release pipeline so i think that we should understand what is the main purpose of this pipeline also so cd is about the processes that have to happen after code is integrated for app changes to be delivered to users or in simple words this is the pipeline which responsible for deployed our code on the infrastructure after all the code tests and validations which means that sorry again which means the tests and validations represent the ci pipeline so in this case we will see how it works and which tasks can uh we will use to deploy um we just deployed the web application on aks cluster so we'll create a release pipeline which includes the following components and i will show you that to get the cd pipeline i go into the releases here and i also created um a pipeline but i would like to start to start from scratch as we did for the ci pipeline and then i will talk about the pipeline and this pipeline so how can i create a new release pipeline by clicking on your new near this pipeline and here i would like to start from scratch as i said again even on the cd also on the cd pipeline release pipelines you can find a lot of building features and a lot of building tasks to deploy without any code to a specific infrastructure especially on azure but also outside azure i will start with an empty job here okay and let me call this stage deploy on to aks not qa webinar test for example and now once i clicked on release new release pipeline and i can change the name to my release pipeline um we can see here two components the left one is the artifacts and this is very important to understand because as i mentioned before we must to the ci and the cd words are always not always part but in the most cases it comes together and what is the connection between the ci and the cd this is the artifact the last step in the ci pipeline was to publish in any artifact and the first step in the cd pipeline is to take this artifact from the ci pipeline so that's the this is the left uh component which called artifacts what is the right component named stages as we know from the ci pipelines stage stages in the stages i can create multiple stages and i can define here multiple variables so all what i want to do now is i want to start with the artifact i want to show you um how can i configure the and and push a pull sorry the artifact that i also push and publish in the ci pipeline by clicking on add an artifact i will choose the build source type because i want to take it from any build pipeline next i want to choose my build pipeline and under my project default version uh for this for now it will be latest we can specify um which version of the artifact we would like to take in this case and is really important to us i would like to to use the latest and the source alias it just an alias that created and represent my artifact from the build pipeline but as you can see here in my cursor this line actually say that i have an artifact from this build pipeline named webinar artifact and if you remember as well i actually named the published artifact in the ci pipeline i named it as webinar artifact so that's good and by clicking on add i can add my artifact to my cd pipeline now next question that we can ask ourselves is how okay now whenever any ci pipeline executed i would like that the cd pipeline will automatically start to to execute so how can i do it easily i can click on the continuous deployment trigger and by enabling the continuous deployment trigger here all what they say that any time that there is a new artifact that created trigger the the related stages trigger the cd pipeline and now i'm good because i actually have an artifact and now the question is what i wanted to do with this artifact so by clicking on the job and tasks here now i can starting to work on the cd uh pipeline um so okay uh where is my mouse sorry okay so here you can see and you can find as the first job is the agent job and this agent job represents the same uh is the same as the pull parameter in the ci pipeline as i said before azure devops allocates for us an agent a machine a server that all the commands will run on so now we can [Music] define one agent we can define multiple agents and we can define our server from azure for example and not any just any um random agent from azure devops that i can all what i'm interested in is the asian specification which represent which operating system i want that we this agent [Music] will host so windows server is fine for me uh because i don't need any more linux for the cd pipeline and let's think why so here as you can see we have again a lot of building tasks and this is not ci pipeline um this is a cd pipeline so in this release pipeline i would like to perform tasks that can helps me that can help me to deploy my artifact on my infrastructure so in this case let's let's say that i would like to take the artifact with the deployment eml file and deploy it on my kubernetes cluster so how can i deploy on kubernetes i have two mainly options okay the first one is to use the cubectl command the client of kubernetes so if i want to use cubesteel first i have to install cubectl on the agent so i can add this task and install cubectl with a specific version or with the latest version not really matter for now next once i have cubectl on my computer or in this agent i would like to take the file the yaml file and deploy using cubectl for example so again i will search for cubectl command by clicking on add now as you can see here some settings need attention and of course the time some settings need attention because cube ctl there are a lot of flags that i can execute with this command for example cube ctl cubes tl apply cube ctrl create get set login and so on um and let's let's take it as i said before that there is another option here to create a service connection to greater production sorry on the producers thanks um and now as i said before the second option to create a service connection is from here from the gui actually here it the azure devops this task asked me okay give me permissions to deploy on kubernetes currently i have no permissions and i don't know your cluster so all that i have to do is to choose any service connection if i already created and if not i can click on new and here there are three options for example in this task in cube ctl kubernetes task that i can create a service connection the first one is to use the cube config cubeconfig file that represent all my credentials here and then i can get permissions uh to deploy on my aks cluster this is first option service account this is another option that is not really relevant and we are not will use this option in the most of the cases and the last option and the easiest option is to use the azure subscription currently now is loading subscriptions and because it takes my user and loading all of the subscription that i have permissions and then i can easily choose the subscription choose the resource groups in that here the resource group in azure and then i can choose the cluster and when i will choose the cluster it will ask me okay now you choose the cluster choose please which namespace would you like that i will deploy to for example in my case i have to be cloud this is my subscription cluster webinar aks in the webinar orgs this is the resource group and now namespace okay this is the namespace that you actually have in your cluster which one of them so it must to know that even if i will choose the default namespace i will not be able to deploy on other namespace so it's really important to know and that's it so next what else so as i said before i can deploy on kubernetes using the cube ctl and i can deploy on kubernetes for example using helm charts um for example again in the case of the cube ctl i had to install the cube ctl on the agent so here again i had to install hell with a specific version as you can see here you can specify the version and what's next that i can help chart can deploy my uh and run helm commands that deploy my health chart on kubernetes so if i go back to the cube ctl now you can understand that if we want to to um how can i say that if you want to deploy to kubernetes so i must to choose the namespace for example default put an attention please pay attention that the namespace here must must be the same namespace as we defined in the service connection next which command would we like to use cube ctl create cube ctl apply cube ctl for in this case cube ctl apply and what would we like to do oh now we have the deployment yaml file that we published as an artifact so i can check the use configuration and here it will ask me for what is the file path to the yaml file or what is the inline for example here i can define that aml file api version v1 what is the kind for example pod and metadata and so on and so on and so on but i don't have to create it from scratch so i've already published an artifact from the ci pipeline so by click on the browse file path i can see the linked artifacts i actually viewed this build pipeline and this is the name of my artifact if you remember webinar artifact and then finally i find my webinar app dot yaml file so by clicking on ok all what that this task will execute is to run the command cube ctl apply i can append the flag dash f or dash dash force for example to override the changes in kubernetes and what it will be deploy the yaml files so i'm happy and now after we talked about it i would like to show you the pipeline that i created before and then i will show you how all the workflow actually works um okay so here i added the artifact and here i have one job with four tasks and i didn't uh forget you kevin i will answer the environment question after that um so what's next the as you can see here i actually have four tasks and i will explain the first one is just a bash script simple best script that echo that print environment variable where i can define environment variable here in their variables section so all what i did i actually defined and initiate environment variable named image tag and the value of this environment variable is the build id that comes from the ci pipeline and why i'm using it in the cd pipeline this is a good question but i'm using it because i need to know what is the version of my app because if you remember i tagged my docker image with the build id so i need that the cd pipeline will know this build id this actually image tag which represents the version of my web application and then i know which version i have to deploy on my cluster so okay so the first is just simple bash to echo and print the image tag and why because i just want to um to see that i actually going to deploy the the right version next i want to install the cube ctl latest version next i want to to apply to q to deploy my yaml file so that's exactly what i did here i actually deployed the yaml file that's the what this task is perform and the last command is the cube ctl set so all of you guys who are who is familiar with kubernetes and especially with cubectl uh client so it will be very easy to understand so cube ctl set command i use it to change the current deployment image to the last build id and i remember tag or build id is equal to version and in my case like y cube ctl is really necessary because i'm always deploying the same yaml file with the same image reference latest tag if i'm going to the back to the repository and you can see here this is a static string it always will be deployed using the latest there is a methods how to change it but in this case in really this simple and basic case i use a static string so if i will continue if i will try to deploy the same yaml file again no changes will be made because it i did i did not change any value of the kubernetes resources so if you were using helm charts so you're right it would solve the problem since there is a very easy way to deal with this issue for example dash dash reset values who is familiar with health charts know this command but in this case i'm using cube ctl so i have to deal with this situation um so now i would like to show you uh how it works after we go through all the cincd pipelines and not only theory and we will follow the logs and watch the logs online and i will show you the kubernetes uh pods deployment and services so before i will do it i just want to show you something i'll go back to the terminal i actually connected and log in logged in to the aks cluster that i showed you on azure so by running the let me clean the screen by running the cube ctl get pods now as you can see i actually have one pod in a running state what else i actually deployed at deployment so this deployment is actually holds this pod so the deployment is here as expected as well and i want to that this web application will be exposed to the internet over port 3000 so cube ctl get service and here is my service here is the external public ip external ip sorry and if i'll go to the browser and put this public ip and as you can see here is my web application however we have to remember why i didn't mention here the 3000 port because it's some about kubernetes some words about kubernetes the service which exposed the uh which which will be exposed the container to the internet get all the traffic overboard http which is the default http port so we don't have to to say that or to initiate it and it will get all the traffic over port 80 and move the traffic to the port over port 3000 so that's the reason why i can access this public ap just by pass it in the browser and click enter and now to the interesting um let's say part in this webinar so now i would like to make some changes push them to the repository and then i would like to know and figure out what what will happen so let's say that i want to change my [Music] my index.js file i want to change my application so i will edit the index.js file welcome to webinar create read people and thanks for taking part in this video dot now i will save now i actually develop a new feature and it's not really feature but i changed the static content of my web application now i want to push all the changes to my git to my github repository commit and push so git status okay modified git add git commit update index gs and git push it seems like it's done let's go to the repository let's go to the root directory click on index.js okay welcome to webinar great people and thanks for taking part in this video great now i want to go to the azure devops click on pipelines ci pipeline and up we can see that actually it automatically executed why because if you remember i have the trigger from the main branch for any push or pull request so by clicking on the specific execution i can see the logs and before i will see the logs you can see here the name of the jobs print parameters npm install npm test build so that's the reason why i told you that i can view the history of any execution of this pipeline so print parameters i'll click on bash because i want to see the bash output and print all parameters service connection here is the output image repository here is the output build id this is the most important this this is our uh newer version of the application 33 and if we will go online to see here i actually have not yet the 33 number here so i know that the image has not been pushed to the repository yet with this image tag so next is the npm so npm install so okay it's installed all the relevant packages that's looked good um and what's next good and pm test run test so if you remember the output of the unit test simple math test this is exactly was my output in my local computer so i'm good and now i can go to build my docker file to be a docker image and push to the container registry but let's see and follow there [Music] we can see the output now it will start from the from step one in the docker file and then until the end of the docker file okay so it seems like it pushed as you can see here the output pushed if i go to the uh to my container registry click on refresh and i actually can see here the 33 image type okay so now what by run the cube ctl um get pots i can cube run the command cube ctl describe pod and i want to see what is the image so i will grab only the image and actually the current version is 32. you can see the image of the pod i'll go back to the releases because as we said for any published artifact there is automatically triggered for the city pipeline and we can see that in this time here is an euro list 17 in this number and it actually in progress by clicking on it you can see all the outputs so let's move through the outputs the first initialize job this is the step that azure devops allocates us the agent next download artifact because the cd pipeline need to push to pull sorry all of the files in this case only one file yaml file from the ci pipeline so it's called it calls uh download artifact second print image tag we want to see that we are using the the the right version so 33 that's good what's next install cubectl just because i know cubectl i know that it actually passed successfully cubectl apply cubectl set and finalize job so if i go now cube ctl get pods i actually still see here only one pod but as you can see the last pod was running for more than 30 hours and this new pod is running only 44 seconds so if i will run the command again cube ctl describe pod with this pod id her name grab only the image sorry why did they wrong ah describe as you can see guys now actually have a new the newer version which represent the 33 and all of that starts and started only for from my uh git push command i committed the changes i pushed the changes i pushed the changes and from there everything happened automatically um so thank you guys thank you so much for the listening and now i'm here and i would like to know if you have any question for anything feel free to write in the q a chat and feel free to open your microphone and one by one and ask me and again thanks so thanks so much any questions guys i will go to the teams feel free to unmute as well and ask any questions if you oh um can you explain what it is um okay i can see here a question can you explain what are the various metrics that can be monitored in aks deployments so yes this question is actually more relevant uh to drill down and hurt kubernetes and not a specialist for aks but let me you know what let me go to the um to my aks cluster it maybe it can helps you by clicking on metrics and it's only here from the portal so there are a lot of metrics that i can expose and a lot of methods that i can monitor my aks cluster maybe even if it's an azure portal or even if it's in a third-party tools like prometheus and like elasticsearch and like other data tools yeah that can help me monitor and data dog to monitor my nodes and my cluster and my pods and you know all of that all of that tools is actually related to the uh to to the hpa the horizontal pod auto scaler we can link it easily so once we want to monitor our deployment um is to understand why or what not why but um when do i need to scale up my uh pod or to scale up the pods or even if when i need to scale up my nodes and regarding your questions cloud cluster auto scaler no i can regarding the deployments okay so there is no any building metric for deployments in azure but again if you will use the third-party tool for monitoring you can get i think all almost any metric that you want even if it's custom metric another question is there any way to configure email addresses to send email for ci cd status that is billed or deployed failed or succeed very good question so the answer is absolutely yes if i'm going to the cd so i can um just a moment maybe ah my mail is actually um closed but for any failed pipeline even ci pipeline we can we will get an email and we can define all of the settings all of and not define and put all of the emails and only the administrator email of the organization or something like that we can uh define an image that we want in the project under the project settings here but i want to show you another thing that it's maybe will be relevant to your questions that let's say that i would like to add another stage okay so let's call it and let's change it i would like to deploy to aks cluster this is my qa environment for example and here i would like to deploy to aks cluster but this is my uh production environment for example until the deployment to the to the qa environment didn't happen so i don't want that the cla the it will be deployed on the production and i have a really good feature um pre-deployment condition it's one of them i can define here um pre-deployment approval that i can insert my name for example itaimalka at 2bcloud.io and for any any time that sorry any time that this qa stage will be done so there is not automatically deployed to the production only when i will approve [Music] over the mail the the deployment and i can append here and add multiple uh for example ilaneet and so on um [Music] yes so for your question is actually it possible can we deploy to other third-party cloud servers using azure devops pipeline yes uh we can we can use the external services uh this is question this question is to be supposed to be asked with a specific third resource or name or whatever infrastructure that you want to deploy on because not all of them you can deploy but you can deploy to external services thank you everyone thank you itai hope you guys enjoyed that's it thank you all that's it that's it [Laughter] thank you all if you are um sticking around if you step through to the very end we dropped a lot of information into the chat lots of great links resources a survey some feedback we'd love to have to be cloud back again for another session for those of you that responded to the poll we'll take that into account and hopefully we'll have something up on the calendar soon enough we'd love to have them back thank you tay and um elenian for helping out and and your contributions for today's reactor session this was really great had a wonderful turnout lots of uh chat interaction and everything as well if you are not familiar with the microsoft reactor program um we are on meetup we have our own website microsoftreactor.com feel free to check that out we have lots of content always coming up um we're located in 11 physical spaces around the world so you know depending on your time zone there may be a session for everyone that's joining so do check that out we're also on twitter and we have a monthly um email mailing list that we send around just with highlights for the following months um like events and sessions and things so aka dot ms slash reactor email sign up so do feel free to do that as well if you'd like to see more content that uh the reactor is putting out all right thank you all again everyone have thanks rest thank you everyone thank you take care all bye everyone thank you bye-bye

Channel: Microsoft Reactor

Views: 1,597

Keywords:

Id: U6n6NzGKyRI

Length: 95min 8sec (5708 seconds)

Published: Fri Jul 09 2021