Getting Started

The CI Runners service by Puzl makes it easy to run and manage your GitLab runners and run the pipeline jobs. Whether you're a new user or have existing pipelines, this guide will help you get started.

Concepts

CI Runners operate using several foundational entities. In this section, we'll touch on each at a general level. Below is an overview illustrating the relationships and interactions among these entities:

GitLab Pipelines Integration

The Integration is designed to connect your GitLab instance with Puzl. One integration scopes one team or department within your organization and enables its owner or maintainer to set up and manage runners for executing their pipeline jobs. The secure isolation ensures that each team's runners and their pipeline jobs operate independently, providing a safe and efficient environment. It allows teams to concentrate on building and running pipelines without worrying about security or interference with other teams.

GitLab Runner Claim

The Runner Claim is your way of requesting a GitLab runner within the isolated namespace created by the Integration. You specify a few requirements, and the platform takes care of the rest. It takes less than a minute to set up and run a new ready-to-use runner.

Pipeline Job

A Pipeline Job is the unit of work executed by a GitLab runner within your GitLab pipeline. At Puzl, each job runs in a light-weight virtual machine that boots in seconds, offering an added layer of isolation for enhanced security.

Each Pipeline Job is allocated vast CPU and memory limits, however you are only billed for the actual resources utilized. This means you're charged based on cpu-seconds and memory GB-seconds consumed during the real usage, not during idle times.

We call it Burstable Resources.

Example

Imagine your pipeline job is cloning a repository; during this period, CPU consumption is often negligible. But when the heavy lifting starts later in this job, like compiling or executing tests, the job can seamlessly scale up its CPU usage up to many cores.

Using Burstable Resources on Puzl

This is where Puzl offers an advantage. Even though there's a cost associated with this higher usage period, the total cost of such a job is far less compared to consistently paying for all the allocated CPU cores throughout the job's entire duration.

Using Regular Cloud Instances

In contrast, when using cloud instances to run your pipeline jobs, you'd still be billed for all the allocated CPU and memory even during the idle moments of the job. Furthermore, during peak job activities, the allocated CPU cores might not suffice, slowing down your job.

Access

Cloud Dashboard

You can see all your pipeline jobs and manage all your integrations and runners through the user-friendly cloud dashboard once you authorized to your Puzl account.

Declarative API

For those who administrate a large organization or prefer a more hands-on approach, Puzl offers access via Kubernetes API, which means that you can use kubectl command or any other Kubernetes tools. This access not only provides the flexibility of a command-line interface but also embraces the declarative Operations-as-Code approach.

By defining the GitLabPipelinesIntegration resources for your organization's team structure, and managing individual runners through the GitLabRunnerClaim resource, all expressed in yaml format, you create a clear and consistent mapping of your operations. It allows for seamless integration into existing workflows, automation of routine tasks, and fine-tuned control over your GitLab pipelines.

An instruction on how to quickly access an API via kubectl is available in our separate user manual on integrations page of your CI Runners dashboard.