In our previous post, “[CI/CD with Drone 101] 01 Basic Service Setup and GitHub Integration ” there is an example docker-compose.yml file that creates two Docker runners: drone_runner_docker and drone-runner-ssh.
However, in “[CI/CD with Drone 101] 02 Setting Deployment Trigger Conditions (Pipeline) ” only the Docker runner is used.
This post will introduce both runners, along with other runners mentioned on the official website.

All runners can be found on the official runner overview page. The default runner is the Docker runner.

The runners listed during the article edit were:

• Docker Runner
• Kubernetes Runner
• Exec Runner
• SSH Runner
• Digital Ocean Runner
• Macstadium Runner

SSH Runner

Example:

kind: pipeline
type: ssh
name: default

server:
  host:
    from_secret: GCP_IP_HOST
  user:
    from_secret: TESTING_USER
  ssh_key:
    from_secret: TESTING_PRIVATE_SSH_KEY

steps:
  - name: greeting
    commands:
      - echo hello world
      - whoami
      - pwd
      - echo DRONE_REPO = ${DRONE_REPO}
      - echo DRONE_BRANCH = ${DRONE_BRANCH}

Explanation

When the type is set to ssh, it means using the SSH runner.
In the server block, the parameters required for SSH are specified, including the remote host IP location and the username for login. from_secret: SSH_KEY means retrieving the value from the Secrets set in the Drone service backend.

If SSH login to the host is required, the id_rsa for the host needs to be filled in here. Additionally, an authorized_keys file with 600 permissions must be created in the user’s directory for login, inside the .ssh directory.
The file content should be the same as id_rsa.pub so that Drone’s SSH runner can correctly use the specified user’s SSH key to log in to the remote host.

The advantage of this approach is that sensitive information does not need to be known by all project deployers; they just need to know the name of the secrets index being used.
If there are future modifications, they can be done in the Drone backend without needing to modify files for each project.

Secrets Official Documentation

Of course, it is also possible to use a password instead of SSH to log in to the remote host. Further configurations can be found in the official documentation .

Docker Runner

This runner uses a specified image to create a container and executes a specified action within the container.
It is the default runner and is recommended for beginners.

If multiple pipelines need to perform actions on the host’s files, this may not be suitable because Docker pipelines run in Docker containers, isolated from the physical host, and do not directly impact the files on the host.

Example

kind: pipeline
type: docker
name: backend_dev

steps:
  - name: submodules update
    image: alpine/git
    commands:
      - whoami
      - pwd
      - date
      - echo DRONE_REPO = ${DRONE_REPO}
      - echo DRONE_BRANCH = ${DRONE_BRANCH}
      - echo DRONE_COMMIT = ${DRONE_COMMIT}
      - echo DRONE_BUILD_NUMBER = ${DRONE_BUILD_NUMBER}
      - git submodule update --init --recursive

trigger:
  branch:
    - dev
  event:
    - push

Other Runners

Exec Runner

Use Cases

Not suitable for projects that need to run outside containers, for example, MacOS projects.

When Not to Use

Since the Exec runner does not isolate with the host, all operations are directly performed on the service’s constructed host.
If the project and the Drone service are not on the same host, or if dangerous commands are added to the .drone.yml in the project, it can lead to tragedy. Therefore, generally, Docker runners are used by default.
Additionally, the Exec runner is in Beta and is not recommended for use in a production environment.

Example

In the example below, commands are directly executed on the host when the pipeline is triggered!

---
kind: pipeline
type: exec
name: default

steps:
- name: backend
  commands:
  - go build
  - go test

- name: frontend
  commands:
  - npm install
  - npm test

These are the commonly used Drone runners, and it is recommended to use the Docker runner.
Most operations needed have readily available Docker images.
Unless absolutely necessary, avoid using the other two runners to directly manipulate the host file system or execute commands directly on the host.

I haven’t used Kubernetes yet, so it is not covered in this introduction.
If there is an opportunity in the future, I will provide additional information.