CircleCI’s machine runner installation with Docker
On This Page
- Supported method for Docker installation (container runner)
- Machine-based approach with Docker
- Runner terms
- Prerequisites
- Additional prerequisites with Docker
- 1. Create namespace and resource class
- 2. Create a Dockerfile that extends the machine runner image
- 3. Build the Docker image
- 4. Start the Docker container
- Start the Docker container on server
- Stopping the Docker container
- Remove the Docker container
This page describes how to install CircleCI’s machine runner with the Docker executor on server. If you are looking to set up self-hosted runners in a private Kubernetes cluster, visit the Container runner page.
Supported method for Docker installation (container runner)
The container runner is the recommended approach for running containerized jobs on self-hosted runners. Container runner offers the ability to seamlessly define, publish, and use custom Docker images during job execution, as well as the ability to easily manage dependencies or libraries through custom Docker images instead of enumerating dependencies as part of steps
in the .circleci/config.yml
file.
Machine-based approach with Docker
The instructions below are not supported for Cloud customers. |
Runner terms
Before you can install self-hosted runners through the web app, you will need to agree to the CircleCI Runner Terms. To be able to gain access to the Self-Hosted Runners section of the CircleCI web app or your CircleCI server app, an admin in your organization needs to navigate to , and agree to the terms.
Once the terms have been accepted, Self-Hosted Runners will appear permanently in the side navigation.
Your role within your org is determined differently depending on how you integrate with your code, as follows:
-
If your code is integrated with CircleCI via the GitHub OAuth App or Bitbucket Cloud, CircleCI mirrors VCS permissions for organizations. If you are an admin on your organization’s VCS, you are an admin on CircleCI. If you are unsure, check the admin permissions on your VCS.
-
If your code is integrated with CircleCI via the GitHub App, GitLab, or Bitbucket Data Center, you can check roles by navigating to Roles and permissions overview.
. Full details on roles and permissions are available in the
To find out which GitHub integration you are using, head to the CircleCI web app, select your org, select Organization Home from the sidebar, and inspect the URL in your browser:
For more information about the differences, see the GitHub docs comparison page. |
Prerequisites
Additional prerequisites with Docker
The host needs to have Docker installed. Once the runner
container is started, the container will immediately attempt to start running jobs. The container will be reused to run more jobs indefinitely until it is stopped.
The number of containers running in parallel on the host is constrained by the host’s available resources and your jobs' performance requirements.
1. Create namespace and resource class
In order to install self-hosted runners, you will need to create a namespace and resource class token. To create resource classes and tokens, you need to be an organization admin in the VCS provider. You can read about namespaces and resource classes on the Concepts page.
You can view your installed runners on the inventory page, by clicking Self-Hosted Runners on the left navigation.
-
On the CircleCI web app, navigate to Self-Hosted Runners and select Create Resource Class.
-
Next, you will create a custom resource class to use when configuring jobs to use your self-hosted runners. If this is your organization’s first time using self-hosted runners. You will need to create or enter a namespace. If your organization already creates orbs, do not create a new namespace, but instead enter the namespace your organization uses for orbs here too. Enter aname for your self-hosted runner resource class.
Each organization can only create a single namespace. While not required, we suggest using a lowercase representation of your CircleCI account name. CircleCI will populate your org name as the suggested namespace by default in the UI. -
Copy and save the resource class token. Self-hosted runners use this token to claim work for the associated resource class.
The token cannot be retrieved again, be sure to store it safely. -
Select the Machine tab and progress on to the platform-specific instructions in the next section of this installation guide.
2. Create a Dockerfile that extends the machine runner image
Create a Dockerfile.runner.extended
file. In this example, Python 3 is installed on top of the base image.
FROM circleci/runner:launch-agent
RUN sudo apt-get update; \
sudo apt-get install --no-install-recommends -y \
python3
3. Build the Docker image
docker build --file ./Dockerfile.runner.extended .
4. Start the Docker container
The environment variable values are not available to the docker command, so these environment variables are not visible in ps output. |
CIRCLECI_RESOURCE_CLASS=<resource-class> CIRCLECI_API_TOKEN=<runner-token> docker run --env CIRCLECI_API_TOKEN --env CIRCLECI_RESOURCE_CLASS --name <container-name> <image-id-from-previous-step>
When the container starts, it will immediately attempt to start running jobs.
Start the Docker container on server
When starting the Docker container on server, the agent_version
and LAUNCH_AGENT_API_URL
environment variables will need to be passed in using the --env
flag.
CIRCLECI_RESOURCE_CLASS=<resource-class> CIRCLECI_API_TOKEN=<runner-token> agent_version=<agent_version_for_server> LAUNCH_AGENT_API_URL=<server_host_name> docker run --env agent_version --env LAUNCH_AGENT_API_URL --env CIRCLECI_API_TOKEN --env CIRCLECI_RESOURCE_CLASS --name <container-name> <image-id-from-previous-step>
Stopping the Docker container
docker stop <container-name>
Remove the Docker container
In some cases you might need to fully remove a stopped machine runner container from the system, such as when recreating a container using the same name.
docker stop <container-name>; docker rm <container-name>;