Following on from my previous article “Build and containerize an Angular application with GitLab CI/CD“, it’s now time to deploy this application.

In this article, I will deploy the application on a Kubernetes cluster using Helm.

Prerequisites

Before starting, you need to:

Preparing the project

To prepare the project for deployment, I added a very basic Helm chart with only one deployment and one service.

Now, on the root folder of my project, I have a charts folder with the classic content of a chart. See the Helm documentation

Create a new deployment stage in the .gitlab-ci.yaml

Add the name of your new stage in the list od stages (For example, deploy_dev) :

stages:
- build
- deploy_dev

Add a new stage in the main part of the page:

deploy_dev:
  stage: deploy_dev
  image: dtzar/helm-kubectl
  before_script:
  - kubectl config use-context dbiservices/gitlab-testing/ci-project:test-cluster
  - sed -i "s/#TAG#/${CI_COMMIT_SHORT_SHA}/g" ./charts/values.yaml
  script:
  - helm upgrade --install --values=charts/values.yaml --namespace ${K8S_NS} ci-project ./charts
  environment:
    name: "application-test"
  rules:
    - if: $CI_COMMIT_BRANCH
      exists:
        - Dockerfile

Important parameters in the deployment stage:

  • The image parameter: “image: dtzar/helm-kubectl”, a job in GitLab CI/CD run in a container. Consequently, the image need the right tools to execute the task. For a deployment using Helm, you’ll need an image containing kubectl and Helm. I use the dtzar/helm-kubectl image from the community, this image is frequently updated and commonly used.
  • The before_script (kubectl): this step prepare the context for the main task. The “kubectl config use-context” command defines which kubernetes context will be used. GitLab can provision Kubernetes contexts from the configured clusters in the project. The context name is defined as follows: [GitLab project path]:[cluster name] (see my article about cluster in GitLab)
  • The before_script (sed): replace the tag of the image to deploy by the CI_COMMIT_SHORT_SHA in the chart’s values.yaml file.
  • The environment parameter : defines the name of the environment where the application will be deployed. Important : don’t forget to specify the environment, many behaviors are linked to it, such as environment related variables, deployment approval and the deployment tracking

The Helm command

The main task (the script section) of this stage contains only one command:

helm upgrade --install --values=charts/values.yaml --namespace ${K8S_NS} ci-project ./charts

The command Helm upgrade update an existing Helm deployment, in addition, the –install option allow Helm to create the deployment if not exists.

The following option –values=charts/values.yaml, specify the location of the values for the templates in the Helm chart.

The option –namespace, indicates the target namespace in cluster for the application deployment. In addition, the value ${K8S_NS} is an environment-specific variable. See the article about environments.

The two last values in the command correspond to the name of the Helm deployment and the location of the chart.

Conclusion

Now my pipeline could build and deploy my application !

In addition, it’s possible to add more deployment task, such as another for the production environment.

Deploying an application with GitLab CI/CD is really simple, takes little time and meets real business needs.