Gitlab CI & Kaniko to build Docker Images

Rizwan Khan — Thu, 10 Sep 2020 11:44:16 +0000

Introduction

You can build container images from a Dockerfile inside a container or a Kubernetes cluster, though Jérôme Petazzoni strongly discourages from doing so. He wrote a detailed blog that can be read here on why not to build container images using Dockerfile inside a container or a Kubernetes cluster.

Context

You will get N number of blogs on how to use the CI/CD of GitLab; here we will see an easy reference point to extend a file and create CI/CD for Docker Image to be built and stored in the same GitLab registry using kaniko. This file needs to be created in the individual project in the GitLab using the template available with the name .gitlab-ci.yml.

What is Kaniko?

Note: Kaniko is not an officially supported Google product

It is a tool to build container images from a Dockerfile inside a container or a Kubernetes cluster. It doesn't depend on the Docker daemon to run each Dockerfile command.

It comes with its own limitations, but we don't run the risk of using Docker-in-Docker

Prerequisites

Access to GitLab (either private self-hosted or managed)
GitLab project with a Dockerfile

CI YAML for auto-devops

# .gitlab-ci.yml
variables:
    GIT_SSL_NO_VERIFY: "true"

before_script:
  - echo "Random image creation, user = $GITLABUSER"

stages:
  - build

build_image:
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: build
  script:
    - ls
    - pwd
    - export CI_REGISTRY_IMAGE=mygitlab.com/base-project/subproject/project
    - echo "{\"auths\":{\"mygitlab.com\":{\"username\":\"gitlab-ci-token\",\"password\":\"$CI_BUILD_TOKEN\"},\"repository.xyz-company.io\":{\"username\":\"user\",\"password\":\"123random\"}}}" > /kaniko/.docker/config.json
    - wget https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem | xargs cat lets-encrypt-x3-cross-signed.pem >> /kaniko/ssl/certs/ca-certificates.crt
    - /kaniko/executor --skip-tls-verify --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_BUILD_REF_NAME

variables: These are static values which aren't going to change and is used at multiple locations in the gitlab-ci.yml file

before_script: Set(s) of commands or echo statement we want to print

stages: Stages are the block of code for an identical job or set of jobs viz. build, test, clean up, delete, deploy, etc. This executes in the order it's defined in the YAML. A dot(.) in front of any job(block of code) disables it and it won't be executed or available neither as an automatic or manual job.

Jobs (Each block of code): Each block of individual stage contains key-value pair or set of commands to it. We can define each block of code to point to a particular stage and all the set of commands it requires to perform that function in the script block. It can be made to run automatically and also manual (start the job manually by clicking a button). The variables like password, access/secret key can be defined in the CI/CD settings under the secret variables section so it's not available in plain text format.

Note: If you want to use the GitLab docker registry and store docker images in the GitLab project; this by default is disabled and needs to be enabled in the General setting section.

How to use service accounts for Kubernetes imagePullSecrets

Rizwan Khan — Wed, 12 Aug 2020 13:16:38 +0000

What are Service Accounts in Kubernetes?

As per Kubernetes.io - A service account provides an identity for processes that run in a Pod.

One can think of service accounts as service users for pods. They help pods authenticate with the api-server and interact with it.

Many times, we come across a situation where our organization uses a private Docker registry to store the Docker images and to make this available we need to create a docker-registry kubernetes secret and pass as imagePullSecrets in the deployment manifest.

kubectl create secret docker-registry registry-cred \
 --docker-server=my.private-registry.com \
 --docker-username=my_username \
 --docker-password="my_superr_strong_password" \
 --docker-email=my.email@mycompany.com -n my-namespace

Then, we pass this secret in the deployment manifest as below.

...
      imagePullSecrets:
      - name: registry-cred
...

The problem with this approach?

Not many that I can think of, except below ones:

The deployment yaml are generally developed by Developers who doesn't need to know about this credentials
If there are a large number of pods in the namespace, then each manifest needs to be updated, whenever the password is rotated

The solution

serviceAccounts - your Kubernetes administrator can just patch serviceAccounts with the registry credential secret and you don't need to worry about replacing or adding it in your manifest yaml each time.

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "registry-cred"}]}' -n my-namespace

DEV Community: Rizwan Khan