The purpose of this post series is to guide you to configure GitLab CI/CD pipelines for effective operation with SAS Viya. The first step on this journey is to register a GitLab runner and define an executor. What is the role of the GitLab runner, what is an executor and why do you need one for triggering SAS Viya workloads? Read the post to find out more.
In this post series you will learn how to:
Before diving in the details, let’s answer the following question:
Implementing GitLab CI/CD pipelines brings numerous benefits to SAS Viya operations. These include automating processes, code versioning, fostering collaboration in development, facilitating content transfer across various environments, storing as well as archiving artifacts.
GitLab CI/CD pipelines empower you to:
Take a look at the following video, in which a GitLab Kubernetes runner is registered and tested.
After the video, let's familiarize ourselves with some GitLab concepts:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
GitLab Job: This is the smallest component of a pipeline, which contains one or more commands that need to be executed, such as to run a SAS program in SAS Viya. The jobs and the commands are defined inside a file .gitlab-ci.yml.
GitLab Runner: This is an agent installed on a server different from the GitLab server. The GitLab runner receives instructions from the GitLab server on which jobs to run. Each runner must be registered with the GitLab server.
Executor: Each runner requires at least one executor. An executor is the environment where the job will be executed.
Thus, the crucial distinction is: The GitLab Kubernetes runner acts as the agent that oversees and delegates the tasks, whereas the Kubernetes executor is the environment where these tasks are actually carried out.
GitLab offers various executors that you can use depending on your needs. These include Shell, Kubernetes, Docker, SSH, VirtualBox, Parallels, and Docker Machine.
In this post we will focus on a Kubernetes executor. Why Kubernetes?
We utilize a Kubernetes runner and executor since SAS Viya is deployed within a Kubernetes cluster. The Kubernetes executor pod is temporary, existing only for the duration of the job execution. Utilizing a Kubernetes executor is advantageous in this context. The runner spawns an executor pod using a Docker image, which can be sourced from a private container registry linked to your GitLab project or a public one like Docker Hub.
There are five simple steps to create the GitLab runner:
In your GitLab repository, perform the following steps:
Copy the value of the runner authentication token and save it somewhere safe.
GITLABTOKEN=glrt-....
For clear workload separation, the runner will be deployed in a fresh Kubernetes namespace. Executors will operate as pods within this specifically assigned workspace.
kubectl create namespace gitlab
A values.yaml file allows you to customize some of the runner pod settings, such as pods resources, number of replicas. You can find the full list of variables values.yaml.
cd ~
tee values.yaml > /dev/null << EOF
## Configure resource requests and limits for the runner pods
resources:
limits:
memory: 1024Mi
cpu: 750m
requests:
memory: 512Mi
cpu: 500m
## How many runner pods to launch
replicas: 2
EOF
The official way of deploying a GitLab runner instance into your Kubernetes cluster is by using the gitlab-runner Helm chart. This chart configures a GitLab runner to run using the Kubernetes executor. For each new job it receives from GitLab CI/CD, it provisions a new pod within the specified namespace to run it.
GITLABTOKEN=glrt-....
helm repo add gitlab https://charts.gitlab.io
helm install \
-f values.yaml \
--namespace gitlab gitlab-sasviya-008 \
--set gitlabUrl=https://gitlab.com/,runnerRegistrationToken=$GITLABTOKEN \
--set rbac.create=true \
--set runners.privileged=true \
--set checkInterval=5 \
--set nodeSelector."kubernetes\.io/role"=agent \
gitlab/gitlab-runner
Explanation of the options:
For more general information about Helm, see Helm basics.
To verify the registered runners, navigate to Settings -> CI/CD and click on 'Expand' in the runners section.
Create a new file .gitlab-ci.yml in your GitLab repository, and paste the following inside:
show-hello:
script:
- echo "hello world"
Commit the changes with a comment. Go to Build -> Pipelines and check the status.
In this post, we've walked through the process of setting up a GitLab runner for your GitLab repository in a Kubernetes cluster. This is an essential first step towards seamless CI/CD operations with SAS Viya.
In the following steps, you'll construct a Docker image that your Kubernetes executor will use to send commands to SAS Viya and write a few SAS Viya CI/CD pipelines.
Thank you for your time!
Many thanks to @JanKostrubiec, @katarzynazuk, @larsarne, and Neil Griffin from whom I learned the most about DevOps with SAS Viya and GitLab.
Thank you for your time reading this post. If you liked the post, give it a thumbs up! Please comment and tell us what you think about having conversations with your data. If you wish to get more information, please write me an email.
Find more articles from SAS Global Enablement and Learning here.
Available on demand!
Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.