Module 2 Lesson 1: GitLab Runners
·DevOps

Module 2 Lesson 1: GitLab Runners

The muscle behind the code. Learn how GitLab Runners execute your jobs, and the critical difference between using GitLab's cloud runners and hosting your own.

Module 2 Lesson 1: GitLab Runners

GitLab itself is the "Web Interface" and "Storage." But GitLab doesn't actually Run your code. That is the job of the GitLab Runner.

1. What is a Runner?

A runner is a lightweight application (written in Go) that installs on a server. It "Polls" GitLab and asks: "Is there any work for me to do?"

If there is a new "Build" job:

  1. The Runner downloads your code.
  2. The Runner creates an environment (usually a Docker container).
  3. The Runner executes your scripts.
  4. The Runner sends the result (logs/artifacts) back to GitLab.

2. Shared vs. Specific Runners

A. Shared Runners

  • Provided by: GitLab.com.
  • Pros: Zero maintenance. You don't have to setup anything.
  • Cons: You share them with everyone else. During busy times, your build might wait in a "Queue." There is usually a limit on "CI Minutes" per month.

B. Specific (Private) Runners

  • Provided by: You (running on your laptop, an AWS instance, or an old server in your closet).
  • Pros: Infinite free minutes. You control the hardware (e.g., you can give it a GPU for AI builds). High security (your code never leaves your server).
  • Cons: You have to install, update, and secure them yourself.

3. Executors: How the Runner runs code

When you setup a runner, you choose an Executor:

  • Docker (Recommended): Runs every job in a fresh container. Ensures no "Leftover" files break the next build.
  • Shell: Runs directly on the server's terminal. Faster, but dangerous because one job can accidentally delete files needed by another job.
  • Kubernetes: Starts a temporary Pod for every job. Best for massive scale.

4. Using Tags

If you have 5 runners, how does GitLab know which one to use? Tags.

  • You can tag a runner with high-ram.
  • In your job description, you specify tags: [high-ram].
  • GitLab will only send that job to runners with that specific tag.

Exercise: The Runner Hunt

  1. Go to your GitLab project -> Settings -> CI/CD -> Runners.
  2. How many "Shared Runners" are available to you?
  3. What are the "Tags" associated with the shared runners? (Usually docker, shared, linux).
  4. Why would a company with 1,000 developers move away from Shared Runners and build their own "Runner Farm" in the cloud?
  5. Research: Can you run a GitLab Runner on your own laptop? (Hint: Yes! It's a great way to save CI minutes).

Summary

Runners are the "Workhorses" of the DevOps world. By understanding how to manage shared and specific runners, you can control the speed, cost, and security of your automated pipelines.

Next Lesson: The blueprint: The .gitlab-ci.yml structure.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn