You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/cross-platform/gitlab-managed-runners/_index.md
+19-10Lines changed: 19 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,24 @@
1
1
---
2
-
title: Build a Simple CI/CD pipeline with GitLab-Hosted Runners
2
+
title: Build a CI/CD pipeline using GitLab-hosted Arm runners
3
3
4
4
draft: true
5
5
cascade:
6
6
draft: true
7
7
8
8
9
-
minutes_to_complete: 40
9
+
minutes_to_complete: 30
10
10
11
-
who_is_this_for: This is an Introductory topic for DevOps professionals who are looking to build a CI/CD pipeline with GitLab on Google using GitLab-Hosted runners.
11
+
who_is_this_for: This is an introductory topic for DevOps engineers who want to build CI/CD pipelines on Arm-based infrastructure using GitLab-hosted runners.
12
12
13
13
learning_objectives:
14
-
- Create a GitLab Project
15
-
- Understand basic pipeline script structure and how to use it
16
-
- Build and test a simple CI/CD pipeline using Gitlab-hosted runners which will build and produce a tiny docker image from a simple "Hello world" "C" language program. The image will be built to run on Arm64 machines and will be saved in Gitlab Registery to be used later.
14
+
- Create a GitLab project with CI/CD configuration
15
+
- Configure pipeline stages to use Arm64 runners
16
+
- Build and containerize applications for Arm64 architecture
17
+
- Store container images in GitLab Container Registry
17
18
18
19
19
20
prerequisites:
20
-
- A valid GitLab account
21
+
- A GitLab account (free tier includes Arm64 runner access)
A GitLab Runner works with GitLab CI/CD to run jobs in a pipeline. It acts as an agent and executes the jobs you define in your GitLab CI/CD configuration. Some key points to note about GitLab Runner:
11
10
12
-
1. GitLab offers multiple types of runners - You can use GitLab-hosted runners, self-managed runners, or a combination of both. GitLab manages GitLab-hosted runners, while you install and manage self-managed runners on your own infrastructure.
11
+
A GitLab Runner is an agent that executes CI/CD jobs defined in your pipeline configuration. GitLab offers two types:
13
12
14
-
2. Each runner is configured as an Executor - When you register a runner, you choose an executor, which determines the environment in which the job runs. Executors can be Docker, Shell, Kubernetes, etc.
13
+
-**GitLab-hosted runners**: Managed by GitLab, no setup required
14
+
-**Self-managed runners**: You install and manage on your own infrastructure
15
15
16
-
3. Multi-architecture support: GitLab runners support multiple architectures including - **`x86/amd64`** and **`arm64`**.
16
+
When you register a runner, you choose an executor that determines the job environment (Docker, Shell, Kubernetes, etc.).
17
17
18
+
### Arm64 runner support
19
+
20
+
GitLab-hosted runners support both x86-64 and arm64 architectures. For developers targeting Arm platforms (servers, edge devices, or embedded systems), using Arm64 runners provides:
21
+
22
+
- Native compilation for Arm architecture without cross-compilation
- Access to Arm-specific instructions and optimizations
25
+
- Faster builds when targeting Arm64 platforms
18
26
19
27
{{% notice Note %}}
20
-
All The information provided in the next section are from GitLab official Pages and it's provided here for convenience and can be changed by Gitlab at anytime. Please refer to the [Gitlab Documentation](https://docs.gitlab.com/ci/runners/hosted_runners/) for more details and for the latest updates. This section is optional.
28
+
GitLab-hosted runner specifications are subject to change. See the [GitLab documentation](https://docs.gitlab.com/ci/runners/hosted_runners/) for current details.
21
29
{{% /notice %}}
22
30
23
-
## GitLab-Hosted Runners Facts
24
-
25
-
1. Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
31
+
## GitLab-hosted runners
26
32
27
-
2. The storage is shared by the operating system, the container image with pre-installed software, and a copy of your cloned repository. This means that the available free disk space for your jobs to use is reduced.
33
+
### Execution environment
28
34
29
-
3. Untagged jobs run on the **`small`** Linux x86-64 runner.
35
+
Each job runs in a newly provisioned virtual machine dedicated to that job. The VM is deleted immediately after job completion.
30
36
31
-
4. Jobs handled by hosted runners on GitLab.com time out after 3 hours, regardless of the timeout configured in a project.
37
+
- Untagged jobs default to the small Linux x86-64 runner
38
+
- Jobs time out after three hours
39
+
- The VM has sudo access without password
40
+
- Storage is shared between OS, container image, and repository clone
32
41
33
-
5. The virtual machine where your job runs has **`sudo`** access with no password.
42
+
### Network isolation
34
43
35
-
6. Firewall rules only allow outbound communication from the ephemeral VM to the public internet.
44
+
- Outbound communication to the public internet is allowed
45
+
- Inbound communication from the public internet is blocked
46
+
- Communication between VMs is not permitted
47
+
- Only the runner manager can communicate with ephemeral VMs
36
48
37
-
7. Inbound communication from the public internet to the ephemeral VM is not allowed.
49
+
### Available Arm64 runners
38
50
39
-
8. Firewall rules do not permit communication between VMs.
51
+
GitLab provides three tiers of Linux Arm64 runners:
40
52
41
-
9. The only internal communication allowed to the ephemeral VMs is from the runner manager.
53
+
-`saas-linux-small-arm64` (free tier)
54
+
-`saas-linux-medium-arm64` (paid tier)
55
+
-`saas-linux-large-arm64` (paid tier)
42
56
43
-
10. Ephemeral runner VMs serve a single job and are deleted right after the job execution.
57
+
For complete specifications, see [GitLab-hosted runners](https://docs.gitlab.com/ci/runners/hosted_runners/linux/).
44
58
45
-
11. In addition to isolating runners on the network, each ephemeral runner VM only serves a single job and is deleted straight after the job execution. In the following example, three jobs are executed in a project’s pipeline. Each of these jobs runs in a dedicated ephemeral VM.
59
+
### VM lifecycle
46
60
47
-
12. GitLab sends the command to remove the ephemeral runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) takes over the task of securely deleting the virtual machine and associated data.
61
+
Each job executes in complete isolation:
48
62
49
-
13. The hosted runners share a distributed cache stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle). The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive.
63
+
1. GitLab provisions a new VM for your job
64
+
2. The job executes in this dedicated environment
65
+
3. GitLab sends deletion command to Google Compute API immediately after completion
66
+
4. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext) securely deletes the VM and data
title: "Create and Test a New Simple CI/CD Pipeline"
3
-
weight: 15
2
+
title: Configure CI/CD pipeline for Arm64
3
+
weight: 4
4
4
5
5
### FIXED, DO NOT MODIFY
6
6
layout: learningpathall
7
7
---
8
8
9
-
## How to Create a CI/CD Pipeline with Gitlab-hosted Runners?
9
+
GitLab-hosted runners are available for any project without additional setup. To use Arm64 runners, create a `.gitlab-ci.yml` file in your project root and specify the Arm64 runner tag.
10
10
11
-
To create the pipeline you only need to create a new **`.gitlab-ci.yml`** file in your Project and define it's stages. Nothing else is needed since Gtilab-hosted runners are readily avilable to any Project and doesn't need to be created or instantiated by the Gitlab users.
11
+
## Build an Arm64 container image
12
12
13
-
Once you run your pipeline with the correct **`tags`** Gitlab will create everything that you need and yep it is as simple as that.
13
+
You will create a simple C application, containerize it for Arm64 architecture, and push it to GitLab Container Registry.
14
14
15
-
## How are you going to test your pipeline functionality?
16
-
17
-
You will test the pipeline by building a Docker image from a simple C language "Hello World" program which can run on Arm64 instances/machines and to do that you will need to create the following files:
18
-
19
-
1)**`main.c`** File: which is the main program that will get executed when we will run your Docker image later. I only provided a simple example but please feel free to use any program that you like. Although, I advise to start with this simple program to test that everything is working then use anything later after by changing the **`main.c`** file.
15
+
Create `main.c` with a simple test program:
20
16
21
17
```c
22
18
//main.c
@@ -28,9 +24,11 @@ int main(void) {
28
24
}
29
25
```
30
26
31
-
2) **`DockerFile`** File: This file has a set of instruction for Docker on how to create a Docker image. It simply instructs the Docker on your runner on how to build and package your **``hello``** app into a Docker image. This produces a tiny image and will run on Arm64 hosts as long as the binary is Arm64 (which it will be, since we’re building on an Arm runner).
27
+
This example provides a minimal starting point to verify your pipeline works correctly.
32
28
33
-
```DockerFile
29
+
Create a `Dockerfile` with build instructions:
30
+
31
+
```Dockerfile
34
32
# DockerFile
35
33
# syntax=docker/dockerfile:1
36
34
@@ -46,58 +44,56 @@ ENTRYPOINT ["/hello"]
46
44
47
45
```
48
46
49
-
3) Optionally **`.dockerignore`** file: This file instructs Docker to ignor certain files that has nothing to do with the image that it will create.
47
+
This multi-stage build compiles your C program with GCC on Alpine Linux, then copies only the statically-linked Arm64 binary to a minimal scratch image.
48
+
49
+
Optionally, create `.dockerignore` to exclude files from the build context:
50
50
51
51
```.dockerignore
52
52
.git
53
53
.gitlab-ci.yml
54
54
```
55
55
56
-
4) You will also need to create a YML file as I mentioned before which I will explain in more details in the next section.
56
+
To create these files in GitLab, use the **+** button in your project and select **New File**. Name each file appropriately (`main.c`, `Dockerfile`, `.dockerignore`).
57
57
58
-
To Create any of those files simply follow the same steps in the next section but instead of choosing **`.gitlab-ci.yml`** file just change the name to each of the corresponding file names above. It is very important to create the 3 files from this section first because once you create and commit/save the **`.gitlab-ci.yml`** file, it will simply run the pipeline. If the other 3 files don't exist at that time then the pipeline will fail.
58
+
{{% notice Note %}}
59
+
Create these three files before adding the pipeline configuration. Once you commit the `.gitlab-ci.yml` file, the pipeline runs automatically. If the application files don't exist, the pipeline will fail.
60
+
{{% /notice %}}
59
61
60
-
## How to Create .gitlab-ci.yml file in a Gitlab Project?
62
+
## Create pipeline configuration
61
63
62
-
1. Start by going to the main project page where you will need to Create the CI/CD pipeline.
64
+
From your project page, select **Set up CI/CD** or use the **+** button to create a new file:
63
65
64
-
2. You can choose to create **`.gitlab-ci.yml`** file by using one of the 2 options circled in red in the image below.
65
66
66
67
67
-
Option1: You can Click on **`Set up CI/CD`** button/link and follow the wizad to create an empty **`.gitlab-ci.yml`** file.
68
+
Name the file `.gitlab-ci.yml`:
68
69
69
-
Option2: Click on the "+" button. From the popup menu click on **`New File`** option and name the file **`.gitlab-ci.yml`** and then click on **`Commit Changes`** button on the top right hand side like in the image below (Add any message as your commit message).
70
70
71
71
72
-
3. A page like the one in the image below will be visible with your **`.gitlab-ci.yml`** file. From here, you will need to Click on the **`Edit`** button. A menu will pop up, you will click on **`Edit in pipeline Editor`** which will allow you to add your CD/CD script.
72
+
Select **Edit** > **Edit in pipeline editor**:
73
+
73
74
74
75
75
-
4. In the pipeline editor, just copy and paste the following YML script and click on commit changes (Add any relevent message as your commit update message).
76
-
```YML
77
-
#First Section
76
+
Add the following pipeline configuration. This defines three stages that build, test, and publish your Arm64 container image:
# Talk to docker:dind over TLS (default behavior for docker:dind)
85
83
DOCKER_HOST: "tcp://docker:2376"
86
84
DOCKER_TLS_CERTDIR: "/certs"
87
85
DOCKER_CERT_PATH: "/certs/client"
88
86
DOCKER_TLS_VERIFY: "1"
89
87
90
-
#Second Section
91
88
build_test_push:
92
89
stage: build
93
-
tags:# This tag is used to specify the size of the runner for each stage but it can be defined on the top of the file if you want to use the same exact runner size for all the stages in your pipeline
94
-
- saas-linux-small-arm64
90
+
tags:
91
+
- saas-linux-small-arm64
95
92
image: docker:27
96
93
services:
97
94
- name: docker:27-dind
98
95
before_script:
99
96
- uname -m
100
-
# install lscpu (provided by util-linux) which is used to identify the CPU used for this stage runner
101
97
- apk add --no-cache util-linux
102
98
- lscpu
103
99
- docker version
@@ -107,7 +103,6 @@ build_test_push:
107
103
- docker run --rm "$IMAGE_TAG"
108
104
- docker push "$IMAGE_TAG"
109
105
110
-
#Third Section
111
106
push_latest:
112
107
stage: push
113
108
tags:
@@ -116,7 +111,7 @@ push_latest:
116
111
services:
117
112
- name: docker:27-dind
118
113
before_script:
119
-
- apk add --no-cache util-linux#since each stage is using a different runner then we need to check this CPU as well
5. Once you commit the file updates, Gitlab will check the scripts for errors and will try to execute the pipeline directly.
124
+
125
+
### Understanding the pipeline configuration
126
+
127
+
**Runner selection:**
128
+
The `tags: saas-linux-small-arm64` directive selects GitLab's Arm64 runner. This ensures your build runs on Arm architecture, producing native Arm64 binaries.
129
+
130
+
**Build stage:**
131
+
The `build_test_push` job compiles your C program on the Arm64 runner. The `uname -m` and `lscpu` commands verify you're running on aarch64 architecture. The Docker build produces an Arm64 container image because the compilation happens on Arm64 hardware.
132
+
133
+
**Push stage:**
134
+
The `push_latest` job runs only on the default branch (typically `main`). It tags the successfully built image as `latest` and pushes it to GitLab Container Registry.
135
+
136
+
**Authentication:**
137
+
GitLab automatically provides `$CI_REGISTRY_PASSWORD` and `$CI_REGISTRY_USER` variables for authenticating to the container registry.
138
+
139
+
Commit the configuration. GitLab validates the syntax and starts the pipeline automatically.
Before you begin, log in to your [GitLab account](https://gitlab.com/) or create a new one.
10
10
11
-
Start by logging into your GitLab account or create a new one in the [Gitlab](https://gitlab.com/) main page.
11
+
You need a GitLab project to store your application code and CI/CD configuration. You can either create a new project or use an existing one.
12
12
13
-
You will need to a new project/repo that will contain all your project files including your **`CI/CD`** pipeline configuration file.
14
-
15
-
You can also choose to use any previously created projects in your Gitlab account. Simply open your previously created project, If that is the case then skip the rest of the steps in the current page and move to the next steps in this tutorial.
13
+
{{% notice Note %}}
14
+
If you're using an existing project, skip to the next section.
15
+
{{% /notice %}}
16
16
17
-
## Create a New Project in Gitlab
17
+
## Create a new project
18
18
19
-
1. From the Home page, Click on the **`Projects`**icon from the menu on the left hand side panel as the image below.
19
+
Navigate to **Projects**in the left sidebar and select **New Project**:
20
20
21
-
2. Click on the **`New Project`** button on the top right hand side as the image below.
3. You will get a new screen like the image below with multiple options. You can choose any of the 2 options highlighted in red from the image below.
25
-
26
-
{{% notice Note %}}
27
-
If you chose option 2 then you will need to choose the **`GitLab CI/CD components`** option from the list of templates.
28
-
{{%/notice%}}
23
+
Choose **Create blank project** or **Create from template** (select **GitLab CI/CD components** if using a template):
29
24
30
25
31
26
32
-
4. Regardles of which option you choose, you will get a screen like the image below where you will need to fill-in the fields highlighted in red. The first field is the **`Project Name`** which you can name it **`CI-CD Runner`**. In the second field you need to choose any option from the **`Project Url`** list then click on the **`Create Project`** button at the end of the page.
33
-
27
+
Provide a project name (for example, `arm-runner-demo`) and select your preferred project URL. Select **Create Project**:
28
+
29
+
30
+
31
+
Your new project is ready:
34
32
35
-
##### **If you did everything correctly then you should get a screen like the one in the image below.**
36
33
37
34
35
+
With your project created, you can now add application files and configure the CI/CD pipeline to use Arm64 runners.
0 commit comments