Cirrus CI supports
arm_container instances in order to run your CI workloads on
platforms respectively. Cirrus CI uses Kubernetes clusters running in different clouds that are the most suitable for
running each platform:
containerinstances Cirrus CI uses a GKE cluster of compute-optimized instances running in Google Cloud.
arm_containerinstances Cirrus CI uses a EKS cluster of Graviton2 instances running in AWS.
Community Clusters are configured the same way as anyone can configure a private Kubernetes cluster for their own repository. Cirrus CI supports connecting managed Kubernetes clusters from most of the cloud providers. Please check out all the supported computing services Cirrus CI can integrate with.
By default, a container is given 2 CPUs and 4 GB of memory, but it can be configured in
Containers on Community Cluster can use maximum 8.0 CPUs and up to 32 GB of memory. Memory limit is tied to the amount of CPUs requested. For each CPU you can't get more than 4G of memory.
Tasks using Compute Credits has higher limits and can use up to 28.0 CPUs and 112G of memory respectively.
Scheduling Times on Community Cluster
Since Community Cluster is shared, scheduling times for containers can vary from time to time. Also, the smaller a container require resources the faster it will be scheduled.
If you have a popular project and experiencing long scheduling times, don't hesitate to reach out to support and we can whitelist your repository for use of extra resources.
Using in-memory disks
Some I/O intensive tasks may benefit from using a
tmpfs disk mounted as a working directory. Set
to enable in-memory disk for a container:
Note: any files you write including cloned repository will count against your task's memory limit.
If you need to run privileged docker containers, take a look at the docker builder.
Greedy instances can potentially use more CPU resources if available. Please check this blog post for more details.
KVM-enabled Privileged Containers¶
It is possible to run containers with KVM enabled. Some types of CI tasks can tremendously benefit from native virtualization. For example, Android related tasks can benefit from running hardware accelerated emulators instead of software emulated ARM emulators.
In order to enable KVM module for your
kvm: true to your
container declaration. Here is an
example of a task that runs hardware accelerated Android emulators:
Limitations of KVM-enabled Containers
Because of the additional virtualization layer, it takes about a minute to acquire the necessary resources to start such tasks.
KVM-enabled containers are backed by dedicated VMs which restrict the amount of CPU resources that can be used.
The value of
cpu must be
1 or an even integer. Values like
3 are not supported for KVM-enabled containers
Working with Private Registries¶
It is possible to use private Docker registries with Cirrus CI to pull containers. To provide an access to a private registry of your choice you'll need to obtain a JSON Docker config file for your registry and create an encrypted variable for Cirrus CI to use.
Let's check an example of setting up Oracle Container Registry in order to use Oracle Database in tests.
First, you'll need to login with the registry by running the following command:
After a successful login, Docker config file located in
~/.docker/config.json will look something like this:
If you don't see
auth for your registry, it means your Docker installation is using a credentials store. In this case
you can manually auth using a Base64 encoded string of your username and your PAT (Personal Access Token).
Here's how to generate that:
Create an encrypted variable from the Docker config and put in
Now Cirrus CI will be able to pull images from Oracle Container Registry: