#10 Gitlab CI CD Pipeline Tutorial | Build and Push Docker Image

what's up get love and docker people so today i'm back with another brand new video of our gitlab series this is a very interesting topic to talk about so in this video we will be talking about gitlab cicd pipeline so mainly we'll be covering two things so one of the thing that we're gonna do is that we are going to build docker images um by the gitlab ci pipeline and we're gonna push the particular image to gitlab container industry this video is highly interlinked uh one for previous video which was about gitlab container history right so on that video we actually showed you how to write the docker file build an image out of the tucker file and push that image to gitlab content registry so today we are gonna do the same thing but instead of doing it manually we are going to do it all via the gitlab pipeline so everything is kind of like automated so whenever you push you make changes and you push and this will automatically build the docker docker images on your behalf so we do not have we do not have to do any more manual interaction so in this video i will walk you through with examples so first of all let me create a new branch by the way if you are new to the channel and if you are interested in devops and cloud related content you could subscribe to our channel so that you get notified before everyone else when i upload new video in this video i will explain each and every line that i write in eml file so that you understand the concept so in the previous video we had a docker file right so now we're gonna create a docker file in this branch and we're gonna copy the content from the previous video as you see on the screen if you are new to docker file you do not have much knowledge so this is the video i would recommend to watch because here i explain how to write docker file build image right so you're gonna watch the video and then you come back to this video so what we did in the in the previous video we pushed this image apache web server out of the docker image right that we have built so what we're gonna do here we will write a dockerfile and along with that we'll write uh index.html so we are set to write our gitlab.yaml file once we have prepared our dockerfile and index.html file so here i'm just showing you what we have done previously so i'm just copying the content and pasting it here in index.html file all right so we have dockerfile we have index.html file now we need to start with gitlab ci dot ml file first of all we will instead of pulling a docker image from github in one of our previous github cicd pipeline video i already explained this section pretty much line number one to four so default keyword means in this case i'm kind of like repeating this again so default keyword means i'm telling gitlab hey pull docker image which is um docker i stable image with the tags table pull this image and run my pipeline using this image all my jobs basically should be using this image as you can see i'm using the tag mac because that's what we have configured in one of our previous video when we installed the private runner so we are going to run this particular pipeline jobs on that particular um on the particular machine so basically this mac tag is used on my personal working computer right so that's where the job will be running when we when we push our changes to gitlab repository so we are going to use some variables in our pipeline and in this video i'm going to show you different way different ways using variables in github there are many ways to do it and i'm gonna kind of like show you in this video how to do it so our container is to url registry.github.com right so that's the that's the url so we can actually for this particular url we could use predefined variables or we could declare our own variables here or we could declare variables on the group level or on the project level so there are at least four different ways defining this particular variable so if you look at the groups you can see our group is youtube and then the project name is gate gitlab tutorial right so here if you look at the url that's how the url is composed of or consist of whatever you say it so in the variable section i'm going to show you how you could use predefined variables right predefined variables in gitlab so if you use predefined variables you do not have to define your own variables in the project section so i will take you to the gitlab predefined variables this is the official link so if you click on there you can search for ci underscore registry so in this page you can just press ctrl f or command f and search for any particular predefined variable that you are after so say underscore registry is actually the address of the gitlab content registry is only available if the container is stressed and a voltage so in our case in our in our project container container registry is done about right because we have pushed the images before so instead of defining our own variable we could directly use this predefined variable as i'm using here this is one way if you use pre-defined variable you could also declare it like this so i call it container registry and you could paste the container register url right within the double quotation so register.gitlab.com this is the option number two so option number three so in here you need to use the dollar sign right so to declare a variable you need to this is the syntax for a variable so you need to use the dollar sign and right after you need to put the name so let's delete this one so i'm not gonna use this one i just showed you so another way you could do also from the project level so if you follow me along in the video you could write the name of the variable and you can put the very value of the variable right so in our case register.gitlab.com you could also mask variable but we are not going to use product variable because that is for the protected branches and tags so in my case i'm not going to use protected ones rather than i would just uncheck that option for the time being for this for this demo so that's also another option so you could um just copy this value and use the dollar sign right and then put it there in the variable section so this is number three the same way you could do also from the group level which is uh what i didn't show you but you could also do that this is a similar process you need to go to your groups and then you follow the same process the way i did for the project level so we gonna have two stages in this pipeline so one uh is going to be build docker image the other one is going to be push docker image so build docker image is responsible responsible for building the docker image push docker image is is responsible for pushing the docker image so i showed you in the previous video as a side note i would also like to pay your attention so if you assign a variable in the group level so all the projects under that group can inherit your variables once you have defined so this is a good way of defining variables for example if you have some common variables that should be inherited to many projects then you do not want to define on the project level because project level only accessible on that particular project so you cannot access project level defined variable from another project so in build docker image stage we have a script that script is basically to run some shell command right so in here we want to build the image right and for that image when we build the image the image should have some particular tag right so the in our case if we do not define any tag is going to be latest we don't want to to be latest rather we want to have some unique identifiers so in this case we choose ci underscore commit under short underscore sha so which you'll get which will give you the commit hash so it's going to be eight characters so in here the commit hash is going to be the committees from your docker push right when you push you have a commit right so that commit is going to be the tag of your docker image i also wanted to show you how you could utilize ci lint that is kind of like built in with gitlab so you just get your yaml file and paste it here and build it so if you look at the value section when on underscore success so in this case it's a default one so you do not have to define same goes with the um only policies hold on i'm not gonna create two jobs here i will continue with one job because i just wanted to show you one thing here maybe this is very useful to you as well so let's push let's keep docker push as well in the same um job where we have build as well so we are going to build and push on the same um job so we update the job name a bit so build and push instead of build so when we do the docker push what we have to do we need to get the um tag right so docker repo and the tag that we have already defined in the previous line so we're going to copy and paste we are good to push right so push command is ready so in the only section i want to mention that whenever i create a merge request i want to do this so this is going to be only applied to merge request so only colon wraps colon line you see on 21 they are actually the same thing so you could omit reps if you want to but i just wanted to show you there are two ways you could write it so probably the latter option was more easy because you need to write uh less all right so we wanted to push but we did not log in so are we gonna be able to push docker images without login to our registry absolutely not i have showed you this stuff in the previous video so what we want to do now you want to utilize before you script this is what also uh we described in the previous video so before the script is going to be executed before we actually execute the script section online number 17 so what we want to do before we execute line number 19 and 20 docker build and docker push we want to actually log in so in this case if we want to log in we need to pass some parameter right so we need to pass in the username so here again i'm going to use the predefined variables because these are the recommended variables you should be using so i'm gonna pick up a registry user and i'm gonna pick up also the password here i did not show you actually docker auth config that is something you would be using in real project instead of typing in your password right password is not a good way of doing it but since the demo i just wanted to show you if you are working in a production stuff go with the docker as config variable that is also a predefined variable excellent now you're kind of like ready with the login command and in this ui register password if you read more you can get a little bit more information and if you're wondering when i type dollar ci underscore that why does it give me those automated pops up is because i have the plugin installed in vs code so if you're interested is very useful you could also install it and use it so let's add our changes to gitlab um index so his status actually is an alias so it means git status instead i'm writing status because i use ideas for it so give it a comment message and then we are ready to push right so this is the first time we are going to push our changes to gitlab project in our repository so when we push it our idea now to create a merge request because in our jobs we talked about a merge request condition to run this pipeline right so now we have created a merge request so now this should trigger the pipeline and when we trigger this pipeline it should do two things one build the image and then push the image and in the skipped section line number 18 and 19 that's what we talked about right and in the predefined variables we have done the login and docker info docker info it just to give show you some information about version i have installed on my on my mac computer so that is not required this is just for demo purposes but the login is required as you can see the output it seems like job is succeeded we should be able to see our image as you can see we can see the image has been pushed just a minute ago and it has the eight character uh comment hash right so this is used as a tag if you merge these changes this merge request to master master would not actually build and push the images because this condition is applied to merge request so not for this particular branch like master branch so now we are gonna make some changes so we will create another stage we call it push docker image my voice got a little bit broken so i needed to drink some water now i will show you a little bit modified versions of this job so we are going to create two jobs now instead of one so docker build will have on its own docker build job and dr push will have its own dagger push job right so in the build image job we will build docker images and this is going to be part of build docker image stage and push docker image job is going to be part of push docker image stage and in this stage we are going to add a condition and condition is going to be only for master before we were doing for merge requests right instead we will push the docker image when we merge our changes into master so before what we did we were actually building and pushing docker images in the merge request you do not want to push a docker image right until it is in master in the build stage it will build the image where you will get the comet hash right for that particular image and then you can test your image but when it goes to master we only want to push our docker image let's look into this linting part again so now if you look at there once you click on validate you will see very nice overview so docker login actually goes before each job as we talked about before script should be executed before the manuscript right so in this case manuscript is the docker build in in that particular job right so i'm going to show you after some time about hawaiian and only policies so for the time being you do not have to struggle about those particular thing that you see on the screen right now so just remember before script runs before a job is actually executed so in this case as we can see in the preview we had two jobs and before you skipped where kind of like executed or it will be executed before the actual job runs right so in the hawaiian section i'm gonna show you by default on success so you do not have to mention it meaning that if this docker build command runs successfully right this is gonna move forward do not worry at all because i will also paste you the links in the video description so you can find all the links from there as well so now what i'm gonna do i will approve this merge request right so once we approve the merge request pipeline will trigger pipeline has triggered and now we will see that since we have the manual step it means that the push docker image is not going to be automatically triggered until we manually click there right so once we manually click the job is going to be triggered so let's go to the lint thing again so i'm going to show you something about the before script so as i said yaml is kind of like ascending order it goes line by line the before you script is not always true because before you script if you put anywhere let's say after push docker image job it's still going to be executed before a job is executed as you can see here so this is a very nice tool that you should be using in your in your daily job whenever you write some yaml stuff always check it so as we talked about the build was automated but push docker image it requires manual trigger because we put the condition one manual so this is why we need to trigger to run the pipeline you could also delete this if you wanted to there are a couple of options right that is in the documentation mentioned so you can play around because of the time constraint i cannot show you all of them in this video because this is going to be a really long video in this case so i will try to escape this but i just wanted to give you some heads up that there are such things that is existed and you could utilize in your pipeline all right nice so we are going to do we are going to switch to master now because our change is already in our master branch so i'm using aliases so do not get confused master means get checkout master here cheaple means get pull because that's what i'm using as as elias going to remove um manual option that i had in the docker push and after that i'm going to push i'm not going to create a merge request because it will slow down the process so i will refactor a bit so let's remove hawaiian manual so uh we are not gonna trigger the pipeline manually all right so i'm gonna add my changes to kit index and i'm gonna put a comment message and after that we are going to push to our master branch so now we are pushing to our master branch so it should automatically trigger the build job and then the push job as well so bail job has taken kind of like 10 or 13 seconds so it's been done so now push job is already done right so um so what has happened here so when we pushed our changes to master it has triggered the build job and after that it has triggered the push job so push job only happens in master branch as we have seen before it doesn't happen in the merge request or any other branch because we have the only condition right i hope you get the idea this is really cool right so this is how you can utilize the power of gitlab in your ci city pipeline so i hope that you found this video useful if you find this video useful do not forget to like comment share and subscribe to our channel and in the next video i will be bringing a lot more useful pipeline tricks i'm currently also working on docker videos so i'll be also working on um dagger best practices uh docker compose in intellij and entry point versus cmd in docker after that i'm gonna publish some videos on google cloud platform so if you find this video useful stay tuned and see you in the next one

Channel: Tech With Foyzur

Views: 3,955

Keywords: gitlab, gitlab ci cd tutorial, gitlab pipeline tutorial, gitlab pipeline, gitlab demo, gitlab ci, gitlab merge request, gitlab runner tutorial

Id: GdY_haXvgXw

Length: 21min 9sec (1269 seconds)

Published: Thu Aug 05 2021