Wednesday 21 April 2021
Continuous desployment is one of the tools provided by DevOps where, as the developers, we want to control the deployment process of the APP that we are deploying. Therefore, in this example we start from the point where we already have an application (or it is under development) and we want it to be able to be deployed by ourselves and automatically.
When we talk about CD in a DevOps environment, it has two possible meanings:
- Continuous Delivery: the package is built and is about to be deployed, but deployment is done manually.
- Continuous Deployment: deployment is also done in an automated way.
Before starting with the configuration, we need to place ourselves in the environment that we have to be able to do the deployment. In this case, the environment we have is gitlbab + kubernetes. This environment consists of a PRE environment and a PRO environment. In this article we want to explain how to deploy automatically in the PRE environment.
The first thing that is necessary is to request the registration of the service and, once the pertinent procedures have been carried out, we receive a series of configuration parameters that we must add to gitlab. For this we will enter gitlab and, in the left bar, we will go to SETTINGS -> CI / CD.
Now we "expand" the variables and do "add value" and add the values that we received.
These values configure where our "artifactory" is located (where we will leave the images of our application) and with what username and password we will log in.
We also configure the API and the RUNDECK TOKEN (console for the automation of tasks that are accessed via API).
At this point, we already have an environment ready to start with the CD. In the case of gitlab, everything related to CI / CD goes through the configuration file called .gitlab-ci.yml.
A first version of this file will be the following:
Notice how we define 3 stages (test, build_pre and deploy_pre).
In this article, we will not refer to the test stage, since it is about executing everything that is necessary to verify that our app works.
What build_pre does is build the docker images of our app (we need to have a DOCKERFILE file in our repository where we specify how each of the project images should be built).
In the case of this example, our APP was made up of BD + API + UI. The database, as it was a Docker image by default, we did not need to build it, so what we will do is:
- We build the images that we do need (API and UI).
- We authenticate against the artifactory.
- We push the images we have created.
Before continuing, let me give a brief explanation of how the .gitlab-ci.yml works.
As developers, we suddenly do: git push origin master to upload the code to the repository, and if we have the .gitlab-ci.yml file well configured in each push, the test stage will be executed, but the other stages will not be executed (so that we don’t make a CD every time we make a push).
When we decide that we want to make a new image of our app, we will have to execute the following commands:
- git push origin master (we check that we have not broken anything)
- git tag <num_versió>
- git push –tags
This behavior of the build_pre and deploy_pre stages, which are only done when we make a tag, is configured with the following lines within the stages of build_pre and deploy_pre:
If we finished the article here, what we would have done is Continuous Delivery: we have the images about to be deployed, but the deployment would be done manually.
However, we want to go further, we want to deploy, so we add in our .gitlab-ci.yml in the variable section, all the following variables:
In addition, below the build_pre stage we add the deploy_pre stage:
What we do with these lines is to take the images from the artefactory and copy them into the RUNDECK through API, the TOKEN and the JOB_ID that we have defined (some things are in the Settings of gitlab and the job is in the variables of the .gitlab file- ci.yml)
If everything has gone well, at this point, we can access our APP (at the URL and Port where we have defined it) and we can see the logs of the APP through the kibana.