Linux Containers
Linux Containers¶
Linux Community Cluster is a Kubernetes cluster running on Google Kubernetes Engine that is available free of charge for Open Source community. Paying customers can also use Community Cluster for personal private repositories or buy CPU time with compute credits for their private organization repositories.
Community Cluster is configured the same way as anyone can configure a personal GKE cluster as described here.
By default a container is given 2 CPUs and 4 GB of memory but it can be configured in .cirrus.yml
:
container:
image: openjdk:8-jdk
cpu: 4
memory: 12G
task:
script: ...
Containers on Community Cluster can use maximum 8.0 CPUs and up to 24 GB of memory.
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.
Using in-memory disks
Some I/O intensive tasks may benefit from using a tmpfs
disk mounted as a working directory. Set use_in_memory_disk
flag
to enable in-memory disk for a container:
task:
name: Much I/O
container:
image: alpine:latest
use_in_memory_disk: true
Note: any files you write including cloned repository will count against your task's memory limit.
Privileged Access
If you need to run privileged docker containers, take a look at the docker builder.
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 container
s, simply add kvm: true
to your container
declaration. Here is an
example of how to configure a task capable of running hardware accelerated Android emulators:
task:
name: Integration Tests (x86)
container:
image: cirrusci/android-sdk:29
kvm: true
accel_check_script: emulator -accel-check
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 such tasks can use: the value of cpu
must be 1
or an even integer. Values like 0.5
or 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:
docker login container-registry.oracle.com
After a successful login, Docker config file located in ~/.docker/config.json
will look something like this:
{
"auths": {
"container-registry.oracle.com": {
"auth": "...."
}
}
}
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, it's simply a Base64 encoded string of your username and your PAT (Personal Access Token):
echo $USERNAME:$PAT | base64
Create an encrypted variable from the Docker config and put in .cirrus.yml
:
registry_config: ENCRYPTED[...]
Now Cirrus CI will be able to pull images from Oracle Container Registry:
registry_config: ENCRYPTED[...]
test_task:
container:
image: bigtruedata/sbt:latest
additional_containers:
- name: oracle
image: container-registry.oracle.com/database/standard:latest
port: 1521
cpu: 1
memory: 8G
build_script: ./build/build.sh