|
1 | 1 | # GitLab CI Demo |
2 | 2 |
|
3 | | -In this demo we will use GitLab pipelines. We will need to split this pipeline into three different jobs |
| 3 | +In this demo we will use GitLab CI/CD pipelines. We will need to split this pipeline into three different jobs: |
| 4 | + |
4 | 5 | 1. Kaniko: Tool used to build docker image |
5 | 6 | 2. Sysdig-cli-scanner: Scan docker images for vulnerabilities using the new scan engine developed by Sysding in 2022 |
6 | 7 | 3. Crane: Push container image to a remote registry |
7 | 8 |
|
8 | | -## Setup |
9 | | -In GitLab repo settings add variables |
10 | | -`CI_REGISTRY_USER`: Docker username |
11 | | -`CI_REGISTRY_PASSWORD`: Docker user password |
12 | | -`SYSDIG_SECURE_TOKEN`: Sysdig Token |
| 9 | +The pipeline leverages the GitLab's container registry to store the container image once the scan has been successfully completed. There are a few special CI/CD variables to use the Container registry (`CI_REGISTRY*`) that are populated automatically by GitLab so there is no need to specify them in our pipeline if we want to use it, cool! |
| 10 | + |
| 11 | +The [official documentation](https://docs.gitlab.com/ee/user/packages/container_registry/index.html#authenticate-by-using-gitlab-cicd) explains this in more detail but the following is an example of the variables' content once they are [automatically populated](https://docs.gitlab.com/ee/ci/variables/#list-all-environment-variables): |
13 | 12 |
|
14 | | -Modify the gitlab-ci.yml file to build the image |
15 | 13 | ``` |
16 | | - CI_REGISTRY_HOST: "docker.io" |
17 | | - CI_REGISTRY_NAME: my-registry |
18 | | - CI_IMAGE_NAME: "my-image" |
19 | | - CI_IMAGE_TAG: "latest" |
| 14 | +CI_REGISTRY="registry.example.com" |
| 15 | +CI_REGISTRY_IMAGE="registry.example.com/gitlab-org/gitlab-foss" |
| 16 | +CI_REGISTRY_USER="gitlab-ci-token" |
| 17 | +CI_REGISTRY_PASSWORD="[masked]" |
20 | 18 | ``` |
21 | 19 |
|
22 | | -The variables are to build the full image url |
23 | | -`$CI_REGISTRY_HOST/$CI_REGISTRY_NAME/$CI_IMAGE_NAME:$CI_IMAGE_TAG` |
24 | | -We would expect |
25 | | -`docker.io/my-registry/my-image:latest` |
| 20 | +## Setup |
26 | 21 |
|
27 | | -## Understanding the stages |
28 | | -In order to get around using Docker in docker, these additional stages are necessary |
| 22 | +In the GitLab repo settings add the `SYSDIG_SECURE_TOKEN` variable to store the Sysdig Token. |
29 | 23 |
|
30 | | -There are three pipeline stages |
31 | | -1. Build |
32 | | -2. Scan |
33 | | -3. Push |
| 24 | +Modify the `gitlab-ci.yml` file to replace the image tag if needed: |
| 25 | + |
| 26 | +``` |
| 27 | +CI_IMAGE_TAG: "latest" |
| 28 | +``` |
| 29 | + |
| 30 | +## Pipeline stages |
34 | 31 |
|
35 | 32 | ### Build |
36 | | -The build stage is using Kaniko. We use a method to build the container to an oci format tarball, saved to the current working directory in `build/` directory. It is not pushed to a remote registry. |
37 | | -We then save the `build/` directory as an artifact. |
| 33 | + |
| 34 | +The build stage leverages Kaniko. The container is built as an OCI format tarball file in `$(pwd)/build/$CI_IMAGE_TAG.tar` and not pushed to a remote registry (it will be done only if the scan is successful). |
38 | 35 |
|
39 | 36 | ### Scan |
40 | | -The scan stage is using `sysdig-cli-scanner`. This stage uses a the latest Sysdig scanning method documented here [Sysdig Secure - Vulnerabilities](https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/pipeline/) |
41 | | -We then save the `build/` directory as an artifact for the next step as well as the `report/` directory to review the PDF scan results later. |
| 37 | + |
| 38 | +The scan stage leverages `sysdig-cli-scanner`. This stage uses the latest Sysdig scanning method documented here [Sysdig Secure - Vulnerabilities](https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/pipeline/). |
42 | 39 |
|
43 | 40 | ### Push |
44 | | -The push stage is using `crane`. It simply authenticates to your docker registry and pushes the conatiner from the Build stage to the remote registry |
| 41 | + |
| 42 | +The push stage uses `crane` to authenticate to the GitLab registry and to push the container image already built from the Build stage to the remote registry. |
0 commit comments