Drone — CI Pipeline Engine

Drone a Continuous Integration platform helps the DevOps engineer a lot in building the pipelines for application easily. As stated it empowers the developers in many ways.

Drone by Harness™ is a modern Continuous Integration platform that empowers busy teams to automate their build, test and release workflows using a powerful, cloud native pipeline engine.

A DevOps pipeline is a set of steps that are executed in sequence or parallel to validate the basic functionality of the project is not broken. The primary steps can be to run the test cases or to build the output binary. For a cloud-native-based application, we can also have additional steps which include building the docker image, pushing it to the Docker registry, and then deploying it for integration testing. Whenever a new commit or change is pushed to a project in Source Control Management(SCM) the pipeline is triggered to validate that the new change wouldn’t break any existing functionality.

In this blog, we will explore Drone to build a basic pipeline for a sample golang application. The Drone platform primarily contains a drone server and a runner.

The drone server runs as a docker container that integrates with Github or Gitlab or Gitea or other supported SCM providers. Once integrated using the drone UI we can sync any one of the existing projects in the SCM with the drone to build a pipeline. A drone runner runs as a daemon that integrates with the drone server to execute the pipeline. It supports different types of runners like Docker, Kubernetes, ssh, exec, and others. Based on the user’s requirement, the runner would be selected and configured.

Once we have the drone server and runner in place, we define a configuration(usually .drone.yml) file which lists various steps that would be part of the pipeline. This YAML file should be part of the same repository or project for which the pipeline is built for. It would then be used by the drone server to execute the pipeline with the help of the drone runner.

The current blog outlines the steps to install a drone server with a private Gitlab SCM and then configure a drone runner with Kubernetes. Next, we will sync and build a pipeline for a sample go-lang project from Gitlab with the drone. The pipeline would define a sequence of steps that involve the execution of test-cases, building binary, building a docker image, and publish it to a private repository and finally, it also deploys the application on the Kubernetes cluster.

The use case is being executed on the linux platform with the following specifications:

  • Ubuntu 20.04
  • Docker 20.10.2
  • Kubernetes v1.21.2 — kubeadm single node cluster with calico CNI
  • GitLab Community Edition 13.12.3 — Private Gitlab running on the same host

Please note: As this is a testing environment so there is no DNS server to resolve DNS entries, hence all the configuration is done based on the IPs. And also all the applications — Gitlab, drone, Kubernetes are running on the same host, so some port re-configurations are done respectively.

Below are some commands which help installation of gitlab-ce on ubuntu server. Detailed steps are available here.

$ sudo apt install curl openssh-server ca-certificates postfix
$ curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
$ sudo apt install gitlab-ce
$ vim /etc/gitlab/gitlab.rb == change external_url 'http://<ip>'
$ sudo gitlab-ctl reconfigure

In this setup, we are using a private SCM, but a similar use case can be extended to other SCM hosted publicly provided the drone server has connectivity to it. This would require running the drone platform on a public cloud.

Install Drone

The following steps illustrate the installation of drone server and drone runner in integration with private gitlab-ce.

Here we will discuss the installation of the drone server as a docker container. More info can be found here.

Step 1: Create an application entry of the drone server in Gitlab. Login to Gitlab server and navigate to user-> preferences-> applications and configure drone server as shown below. In this setup, we would be running the drone server at correspondingly configure where you would be running your drone server in your setup. Also, allow API and read user access to the server.

Application creation in Gitlab

Step 2: Once created, it generates an application-id and secret-key. Copy these ids to use when launching the drone server.

Application created in Gitlab

Step 3: Generate shared secret to be used by drone server and drone runner.

$ openssl rand -hex 16 

Step 4: Create a drone server using the ids from step 2 and step 3. Configure DRONE_SERVER_HOST with the IP and Port on which the server will be running, here it would be <> the same details provided in step 1. Also, configure the host port mapping in the publish argument, it is 8081 in this case.

$ docker run \
--volume=/var/lib/drone:/data \
--env=DRONE_GITLAB_CLIENT_ID=<application_id_from_step_2> \
--env=DRONE_GITLAB_CLIENT_SECRET=<secret_from_step_2> \
--env=DRONE_RPC_SECRET=servet_from_step_3 \
--env=DRONE_SERVER_HOST=<Ip_and_port_for_the_server_to_run> \
--env=DRONE_USER_CREATE=username:root,admin:true \
--env=DRONE_LOGS_TRACE=true \
--env=DRONE_LOGS_DEBUG=true \
--env=DRONE_LOGS_PRETTY=true \
--publish=<port_of_drone_server>:80 \
--publish=443:443 \
--restart=always \
--detach=true \
--name=drone \
# Check logs to see if drone server is running$ docker logs drone
{"interval":"30m0s","level":"info","msg":"starting the cron scheduler","time":"2021-06-24T08:37:39Z"}
{"interval":"24h0m0s","level":"info","msg":"starting the zombie build reaper","time":"2021-06-24T08:37:39Z"}
{"acme":false,"host":"","level":"info","msg":"starting the http server","port":":80","proto":"http","time":"2021-06-24T08:37:39Z","url":""}

Step 5: Configure the drone server with Gitlab. Access the drone server on browser and then follow the below steps

Welcome page

Click continue to redirect to Gitlab page.

Authorize drone to have api access to Gitlab

Click on authorize. After authorization, you will be again redirected to drone server page.

Register yourself
Project details page

After registering you would be redirected to the drone server dashboard which would list the projects available in Gitlab. This completes the drone server setup.

Next, we move to the installation of the drone runner with the Kubernetes plugin. More info can be found here.

Drone runner will be running as a kind deployment in the Kubernetes cluster and integrate with drone server to launch the pipeline on the Kubernetes cluster. It helps in executing the steps defined in the pipeline. We will create the deployment in the default namespace.

Before creating the drone runner, edit the yaml file with the drone server details according to your setup. The following environment fields have to be updated in the deploy.yaml file.

  • DRONE_RPC_HOST — Drone server hostname and port
  • DRONE_RPC_PROTO — Drone server protocol — http/https
  • DRONE_RPC_SECRET — openssl secret created from step 3 above.
# deploy.yamlapiVersion: apps/v1
kind: Deployment
name: drone
app.kubernetes.io/name: drone
replicas: 1
app.kubernetes.io/name: drone
app.kubernetes.io/name: drone
- name: runner
image: drone/drone-runner-kube:latest
- containerPort: 3000
value: http
value: 887a80e28b7183912e788173dbd5d07f
$ kubectl apply -f deploy.yaml
deployment.apps/drone created

After creating the deployment, check the pod logs to see if the connection is established successfully with drone server.

$ kubectl get pods
drone-5bdf497677-srhkw 1/1 Running 0 36s
$ kubectl logs drone-5bdf497677-srhkw
time="2021-06-28T10:38:54Z" level=info msg="starting the server" addr=":3000"
time="2021-06-28T10:38:54Z" level=info msg="successfully pinged the remote server"
time="2021-06-28T10:38:54Z" level=info msg="polling the remote server" capacity=100 endpoint="" kind=pipeline type=kubernetes

This completes the installation of drone platform. Next steps would be to define pipeline for the project which require testing, building and deploying the application.

Here we will discuss the creation of a sample project in Gitlab and integrating it with drone.

Login to Gitlab and create a sample project.

Sample project creation

Next open the drone dashboard and click on sync button on top right to sync the projects.

Drone server dashboard

Click on the golang-app project to activate the repository.

Activate repository
After activating the repository

This completes the project sync between Gitlab and drone server

Pipeline Creation

We will now discuss how to enable the pipeline for the created sample project. The pipeline definition for a project is done in a .yml file which is committed as a file and is part of the same repository.

As we are building a sample golang application that can be deployed as a microservice below are the steps we will execute as part of the pipeline

  • Test & build — to run golang test and to build golang binary
  • Publish — builds docker image for the application and push it to quay repository
  • Deploy — Finally deploys the application with the latest built image

Here we are using a part of the commit id to tag the image while pushing it to quay and it is later used for deployment.

If you are not deploying or pushing the application to any private repository ignore the below steps.

From the above listed steps, we can see that there are some parameters required by the drone server before executing the pipeline. These include docker username and password to publish the image to quay and Kubernetes endpoint, API server key, and cert for deploying the application as microservice in the Kubernetes. These configurations can be specified as secrets in the drone server as shown below and are later used in the pipeline .yml file.

Navigate to project Settings->Secrets ->New Secret

Create a secret

Similarly create k8s_cert, k8s_token, docker_username, and docker_password secrets in the drone CI.

To retrieve the k8s server, cert, and token details for the server on which the application will be deployed using the below commands.

# To retrieve k8s server details
$ kubectl config view -o jsonpath="{.clusters[?(@.name==\"kubernetes\")].cluster.server}"
# To get cert and token, first retrieve the secret associated with the service account desired. Here we are using the default sa in the default namespace.
$ kubectl get secret
default-token-4mc89 kubernetes.io/service-account-token 3 2d21h
# Get token and cert
$ kubectl get secret default-token-4mc89 -o jsonpath='{.data.token}' | base64 --decode && echo
$ kubectl get secret default-token-4mc89 -o jsonpath='{.data.ca\.crt}' && echo

Using the above details create secrets in the drone, also create the private image repository credentials as secrets in the drone UI.

As we are using the default service account from the default namespace to deploy the application as a microservice in Kubernetes, we should also take care that the service account has proper RBAC policies associated with it so that the application can be deployed. Here we create role, cluster role, role binding, and cluster role binding for the default service account to enable it with proper RBAC permissions. Here is the yaml file used.

$ kubectl apply -f rbac.yaml
role.rbac.authorization.k8s.io/drone created
rolebinding.rbac.authorization.k8s.io/drone created
clusterrole.rbac.authorization.k8s.io/drone created
clusterrolebinding.rbac.authorization.k8s.io/drone created

In this section, we will discuss how to define and commit the pipeline .yml file for the sample project repository.

First clone the repository. And add the golang files related to our project. In this application, we are running an http server that has 2 endpoints with some sample responses. The application go code and related files used are available here.

$ git clone https://github.com/SirishaGopigiri/drone-example.git$ git clone
Cloning into 'golang-app'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
$ cd golang-app# Copy files from github sample project
$ cp -r ../drone-example/golang/* .

Next, create the sample pipeline .yml file with the steps discussed.

# .drone.ymlkind: pipeline
type: kubernetes
name: test-go
- name: test
image: golang:alpine
- "apk add build-base"
- "go mod download"
- "go build -o app ."
- "go test -v"
- name: publish
image: plugins/docker
registry: quay.io
repo: quay.io/sirishagopigiri/golang-app
tags: [ "${DRONE_COMMIT_SHA:0:7}","latest" ]
from_secret: docker_username
from_secret: docker_password
- name: deliver
image: sinlead/drone-kubectl
from_secret: k8s_server
from_secret: k8s_cert
from_secret: k8s_token
- sed -i "s|golang-app:v1|golang-app:${DRONE_COMMIT_SHA:0:7}|g" deployment.yaml
- kubectl apply -f deployment.yaml

Below are some definitions for the keys in the pipeline .yml file

  • type — defines the drone type runner for the pipeline, here as we are using Kubernetes
  • steps — list of contains that would be created in the drone type runner, each executing the commands defined in that step
  • Some steps have pre-defined logic built for them, example plugins/docker automatically builds and pushes the image
  • settings — are the environment variables passed to the container when launched.

Copy the drone.yml file defined above to the repository and then commit the repository. Please note that the file name should match the configuration file name defined in the settings page for the project in the drone server.

Check configuration file name
# Copy the .drone.yml file to the repo
$ cp ../drone-example/golang-app/.drone.yml

We will now commit and push the changes, which will automatically trigger the pipeline in drone which in turn will execute the steps in the pipeline.

$ ls -al
total 48
drwxrwxr-x 3 sirisha sirisha 4096 Jun 28 16:20 .
drwxrwxr-x 6 sirisha sirisha 4096 Jun 28 16:18 ..
-rw-rw-r-- 1 sirisha sirisha 434 Jun 28 16:18 app.go
-rw-rw-r-- 1 sirisha sirisha 1282 Jun 28 16:18 app_test.go
-rw-rw-r-- 1 sirisha sirisha 720 Jun 28 16:18 deployment.yaml
-rw-rw-r-- 1 sirisha sirisha 287 Jun 28 16:18 Dockerfile
-rw-rw-r-- 1 sirisha sirisha 819 Jun 28 16:20 .drone.yml
drwxrwxr-x 8 sirisha sirisha 4096 Jun 28 16:30 .git
-rw-rw-r-- 1 sirisha sirisha 69 Jun 28 16:18 go.mod
-rw-rw-r-- 1 sirisha sirisha 4285 Jun 28 16:18 go.sum
-rw-rw-r-- 1 sirisha sirisha 214 Jun 28 16:18 README.md
$ git add .$ git commit -m "Initial commit"
[master e3292a4] Initial commit
8 files changed, 231 insertions(+), 2 deletions(-)
create mode 100644 .drone.yml
create mode 100644 Dockerfile
create mode 100644 app.go
create mode 100644 app_test.go
create mode 100644 deployment.yaml
create mode 100644 go.mod
create mode 100644 go.sum
$ git push origin master
Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 4.30 KiB | 4.30 MiB/s, done.
Total 10 (delta 0), reused 0 (delta 0)
85d2248..e3292a4 master -> master

After pushing the changes, check the drone UI to see if the pipeline is triggered.

Pipeline status
Click on the build to see the details

Alternatively, we can also see that there would be a pod created in Kubernetes default cluster namespace, which is managed by the drone runner running in the same namespace.

$ kubectl get pod --show-labels
drone-1rxlonglx22qecnz1sii 1/4 NotReady 4 4m35s io.drone.build.event=push,io.drone.build.number=1,io.drone.name=drone-1rxlonglx22qecnz1sii,io.drone.repo.name=golang-app,io.drone.repo.namespace=root,io.drone=true
drone-5bdf497677-srhkw 1/1 Running 0 29m app.kubernetes.io/name=drone,pod-template-hash=5bdf497677

After the execution of the pipeline, we can access the logs for each step and verify that the execution has been successful or not. Below are the screenshots of logs for each step. Please note that clone is a default step added by drone to pull the latest commit changes.

Clone step logs
Test case execution and build output
Build and publish image to private repo
Application deployment in the kubernetes cluster

From the final logs we can observe that the application has been deployed successfully as a microservice in the Kubernetes cluster. Checking the same using kubectl.

$ kubectl get deploy -n test
golangapp-deploy 1/1 1 1 85s
$ kubectl get pods -n test
golangapp-deploy-6689fdc49b-9gcgd 1/1 Running 0 77s
$ kubectl get svc -n test
golangapp-service ClusterIP <none> 5000/TCP 88s

We will now try to access the application and observe the responses.

$ kubectl -n test run -i -t nginx --rm=true --image=nginx -- bash
If you don't see a command prompt, try pressing enter.
root@nginx:/# curl -X GET http://golangapp-service:5000
{"message":"hello world!!"}root@nginx:/#
root@nginx:/# curl -X GET http://golangapp-service:5000/app_version
{"message":"Sample golang app version 1.0 !!"}

This verifies that the pipeline execution and the application deployment have been successful.

Now that we have the pipeline built, we will now push another commit with some golang changes and see if how the pipeline executes. Below are the changes done to the golang application, we have added another API endpoint and its corresponding test cases.

--- a/app.go
+++ b/app.go
@@ -14,6 +14,11 @@ func RunServer() *gin.Engine {
"message": "Sample golang app version 1.0 !!",
+ r.GET("/testing", func(c *gin.Context) {
+ c.JSON(200, gin.H{
+ "message": "New api added to the application !!",
+ })
+ })
return r

diff --git a/app_test.go b/app_test.go
index 3beb302..a729119 100644
--- a/app_test.go
+++ b/app_test.go
@@ -51,3 +51,25 @@ func TestServeHTTPVersion(t *testing.T) {

+func TestServeHTTPNewAPI(t *testing.T) {
+ server := httptest.NewServer(RunServer())
+ defer server.Close()
+ resp, err := http.Get(server.URL+"/testing")
+ if err != nil {
+ t.Fatal(err)
+ }
+ if resp.StatusCode != 200 {
+ t.Fatalf("Received non-200 response: %d\n", resp.StatusCode)
+ }
+ expected := `{"message":"New api added to the application !!"}`
+ actual, err := ioutil.ReadAll(resp.Body)
+ if err != nil {
+ t.Fatal(err)
+ }
+ if expected != string(actual) {
+ t.Errorf("Expected the message '%s' but got '%s'\n", expected,actual)
+ }

We will now commit the code to trigger the pipeline.

$ git add .
$ git commit -m "Update go code"
[master 3d3aef0] Update go code
2files changed, 28 insertions(+), 4 deletions(-)
$ git push origin master
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 596 bytes | 596.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
e3292a4..3d3aef0 master -> master

We can see that the pipeline has been triggered.

Pipeline execution

The clone, build and publish steps have the same logs as seen before, but in the deliver step we will see that the application will now be configured with the latest image. The namespace and the service object remains the same.

Deployment of the application

Checking the application using kubectl

$ kubectl get pods -n test
golangapp-deploy-54c89c7d56-7hnj6 1/1 Running 0 2m20s
$ kubectl get deploy -n test
golangapp-deploy 1/1 1 1 22m
$ kubectl -n test run -i -t nginx --rm=true --image=nginx -- bash
If you don't see a command prompt, try pressing enter.
root@nginx:/# curl -X GET http://golangapp-service:5000
{"message":"hello world!!"}root@nginx:/#
root@nginx:/# curl -X GET http://golangapp-service:5000/testing
{"message":"New api added to the application !!"}root@nginx:/#
root@nginx:/# curl -X GET http://golangapp-service:5000/app_version
{"message":"Sample golang app version 1.0 !!"}

We can observe that a new pod has been created for the existing deployment with the latest tag. This new image supports the new API that has been added.

Here we will try to push a commit which has failed test cases and observe the pipeline behaviour. Below are the changes listed.

diff --git a/app_test.go b/app_test.go
index a729119..dde377d 100644
--- a/app_test.go
+++ b/app_test.go
@@ -63,7 +63,7 @@ func TestServeHTTPNewAPI(t *testing.T) {
if resp.StatusCode != 200 {
t.Fatalf("Received non-200 response: %d\n", resp.StatusCode)
- expected := `{"message":"New api added to the application !!"}`
+ expected := `{"message":"New api added to the application"}`

actual, err := ioutil.ReadAll(resp.Body)
if err != nil {

Commit and push the changes

Test cases fail commit pipeline
Pipeline failure
Pipeline failure in graph view

We can observe that since the test case execution failed the pipeline is marked as failed and is not deployed in the cluster.


The drone CI platform helps in building an effective pipeline to help identify issues before deployment. Drone has support to integrate with different types of SCM like Gitea, Github, Gitlab, bitbucket, etc. It also has various runners support to run like exec, docker, Kubernetes, ssh etc. And since the drone pipeline steps are simple which involves specifying the docker container we can build various custom plugins according to our requirements.

Integrating the project with Drone helps in easy maintenance of the projects. It also makes debugging the problems and issues easy in case if something fails. As the drone pipeline is built using simple YAML file configuration it helps the DevOps engineer in an effortless configuration.

  1. https://docs.drone.io/
  2. https://www.magalix.com/blog/building-a-cd-pipeline-with-drone-ci-and-kubernetes



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

Engineer by profession. Chef by passion (applicable only for some dishes :-P). Trying to become a blogger.