 I'm Vishnu Bhatani from Verizon India. So today I'm going to talk about GitLab CI CD. So how many of you are using GitLab as a source code management tool? So I think you're aware of the features provided by GitLab. So before that, I just want to give you an overhead about CI CD in general. So as you guys know, every organizational is moving towards CI CD and optimizing the tools, and as well as driving CI CD with various DevOps tools. So every day a new tool gets into picture and we try venturing out. And all this chaos is to achieve one common goal, which is to how fast a team can deliver the results. So that is the one common goal. So in general, I'd like to talk about the CI CD workflow. So consider I have a team and we have a locally implemented feature. So when I locally committed to my source code management tool, say any kind of a Git or a Stash or a Bitbucket, any kind of a Atlasian tool, so it must automatically trigger a CI CD pipeline. And that should be triggered based upon various rules. Say if there's a merge request and then there is a commit or any kind of trigger that trigger should actually trigger a pipeline. And the pipeline is generally going to have a set of automated rules like build, scan, test and so on. So once the feature is okay and the review is completed, it is moved to the higher environments like Prod. And if something goes wrong in the Vaskar scenario, it should be rolled back to the previous working state. So all these things should be happening in an automated fashion. So in order to do this, we generally pick up tools from the market or our favorite tools like say GitHub or Jenkins CI, Travis CI or for Artifactory Management, we pick up Nexus or JFrog and for Jira as an issue tracking. So the sky is the limit. We have so many tools in market. And as well as for deployment, we do the AWS deploy or any kind of deployment tool which is favorable for the application, right? So in order to avoid all this, GitLab came up with an application lifecycle management. So in GitLab, it is a powerful tool built to perform the entire CI CD in single place without much of a third party intervention. So the goal is to do the entire CI CD pipeline in a single place. GitLab is also called as a single suite for the DevOps pipeline or the lifecycle. So what are the features provided by GitLab? So GitLab provides, as you all know, it's a distributed system and we use it as a source code management tool. The other features is GitLab CI CD and the other features of GitLab are GitLab Wiki, GitLab issues, which is for issue tracking like Jira and GitLab Wiki is very much similar to the Confluence pages and it also provides registry management which is a replacement for like artifact management. So all these are provided by GitLab and the most favorite and the current bus word is the GitLab CI CD. Since we're like, it is much better than actually maintaining a lot of tools in the market, right? So we do not need the licenses of many tools or we do not need people to maintain various tools, say for DevOps person who would only do the CI using the Jenkins and we need the infra team to maintain the infra or the deployment activity and we need the dev team in order to create a merge request or review the merge request. So all these teams are, despite their own activities, they need to concentrate on these as well. So GitLab CI CD results this. So it's a kind of replacement for many kinds of CI servers like Jenkins. GitLab also, GitLab does CI using the GitLab runners. So runners are very much similar to the Jenkins build nodes or the build slave. So these are the, this runner can be created using a shell or as well as a Kubernetes or a Docker executor. Another important feature of GitLab CI CD is it's a, in Jenkins we need to maintain all the plugins and we need to concentrate on the updates of the plugins but whereas in GitLab CI CD that is not required since it has another feature called the auto DevOps. So in auto DevOps, you need not maintain a list of tools like for doing the quality gateway using Sonar or say if you need to communicate with the, if there isn't any vulnerability, you need to create an issue using, say, Jira. We need not go to external tools. And inside GitLab itself, we are having a tab called the GitLab issues and we'll be able to create it. Let's consider a scenario. So I am from a dev, say I'm from a dev team and when I create a merge request, the merge request is created in GitLab, right? So the person who's created it has a cometer name. So once a snippet or a code is committed, if that particular code is having a say a vulnerability, that has to be notified to the dev team and a correspondent person should be assigned to it. So this is completely achievable in GitLab. We not go about creating external hook to Jenkins or you need not need a plugin to create a ticket in Jira. So what you can do is you can just create a CI CD pipeline file. So it's an YAML file which is going to have the steps to execute or instructions which you need to perform. It's very much similar to the pipeline as a code but it is written in YML. So how it can be done is, so when I create a merge request, the GitLab is going to trigger the pipeline, right? So inside the pipeline file, I'm going to say that, see if this particular snippet is having a vulnerability, create an issue in GitLab issues and assign the cometer name to it. So this creates accountability within the dev team and we need not go about looking for random people and asking them to fix for the current, there's a release, we did not ask for people to fix that. So this is one of the benefit of having a source code management and the CI together. So and in Verizon, we actually concentrate on the security a lot and we do not promote or release the code to the release environments or higher environments if it doesn't pass the security rules. So this particular use case was hugely used in our organization. And another thing about GitLab is that it is natively supporting Docker. You need not go about looking for plugins or you need not go about looking for any kind of external documentation to achieve that. So if you guys have your own Docker images safe in your organization, you're going to do Sonar quality gateway, you need not go about looking for plugins. So if you have a Docker image in place and that can be automatically plugged in or called in your CI file and you can readily use it. So while using this, so this was a very interesting story happened for us. So when, let me give an example with Jenkins itself since it's a very much familiar tool. So consider you're running Jenkins as a container and on top of that you're having a build node or a build slave which is also running as a container. On top of it, for say XYZ application, you need to do a CI CD pipeline. So consider it has a main one build which is also running as a, you have a main image and it is also running as a main one container. So as you see, there are three content, three level of containers in your, this scenario. So when you have three containers, obviously you're going to have three demons and communicating between them is going to be a little, a lower or higher level performance issue. Or there's a high chance that your host demon might be crashed or you're going to lose all the three images. Say if you're an organization, you're going to practice reusability and you guys have a Docker images which is in a reusable fashion. So in that case, if you crash the Docker images, that's going to be an overhead for you in creating it again. So to resolve that, we actually found out that Docker is providing a service called the dint. So dint is nothing but Docker inside Docker. So the advantage of this is that you can have multiple containers pinned up on top of that using dint. So how it is happening is that you're going to, at the end of the day, you're going to have a host mission with demon. But the container which is pinned on top of it would not be having its own demon, but it would be communicating with the host demon. So in this scenario, what would happen is you would get an encapsulated environment. So this means that you're going to, there will be no performance leak or any kind of image crash because your host images or Docker images are not getting tampered. So we believe in reusability and we have a set of reusable images and we do not want to lose them. So while we tried out this, so as the example quoted in Jenkins, please try to replicate that in GitLab. So GitLab is actually running as a container. So it supports native containers because GitLab runs on top of a container. So you have a GitLab runner which is also a container and on top of that, if you guys have a container-based application deployment, it is going to be useful by using the dint as a service. So this was a success story for us. Hope you guys use GitLab and figure out whether it's useful for you guys as well. Thank you.