Continuing with the multiarch and Kubernetes narratives that I have been writing about for awhile now, in this post I will be showing off some of the capabilities of the Drone.io continuous integration tool running on my arm64 Kubernetes homelab cluster.
As arm64 continues to gain popularity, more and more projects are adding support for it, including Drone.io. With its semi recent announcement, Drone can now run on a variety of different architectures now. Likewise, the Drone maintainers have also been working towards a 1.0 release, which brings first class support for Kubernetes, among other things.
I won’t touch on too many of the specifics of Drone, but if you’re interested in learning more, you can check out the website. I will mostly be focusing on how to get things running in Kubernetes, which turns out to be exactly the same for both amd64 and arm64 architectures. There were a few things I discovered along the way to get the Kubernetes integrations working but for the most part things “just work”.
I started off by grabbing the Helm chart and modifying it to suit my needs. I find it easiest to template the chart and then save it off locally so I can play around with it.
Note: the below example assumes you already have helm installed locally.
git clone [email protected]:helm/charts.git && cd charts
helm template --name drone --namespace cicd \
--set 'sourceControl.provider=github' \
--set 'sourceControl.github.clientID=XXXXXXXX' \
--set 'sourceControl.secret=drone-server-secrets' \
--set 'server.host=drone.example.com' \
--set 'server.kubernetes.enabled=false' \
stable/drone > /tmp/manifest.yamlObviously you will want to set the configurations to match your own settings, like domain name and oauth settings (I used Github).
After saving out the manifest, the first issue I ran into is that port 9000 is still referenced in the Helm chart, which was used for communication between the client and server in the older releases, but is no longer used. So I just completely removed the references to the port in my Frankenstein configuration. If you are just using the Kubernetes configuration mentioned below, you won’t run into these problems connecting the server and agent, but if you use the agent you will.
There is some server config that will need to adjusted as well to get things working. For example, the oauth settings will need to be created on the Github side first in order for any of this to work. Also, the drone server host will need to be accessible from the internet so any firewall rules will need to be added or adjusted to allow traffic.
env:
# Webhook setings
- name: DRONE_ALWAYS_AUTH
value: "false"
- name: DRONE_SERVER_HOST
value: "drone.example.com"
- name: DRONE_SERVER_PROTO
#value: http
value: https
# Agent config
- name: DRONE_RPC_SECRET
valueFrom:
secretKeyRef:
name: drone
key: secret
# Server config
- name: DRONE_DATABASE_DATASOURCE
value: "/var/lib/drone/drone.sqlite"
- name: DRONE_DATABASE_DRIVER
value: "sqlite3"
- name: DRONE_LOGS_DEBUG
value: "true"
- name: DRONE_LOGS_PRETTY
value: "true"
- name: DRONE_USER_CREATE
value: "username:<github_user>,machine:false,admin:true,token:abc123"
# Github config
- name: DRONE_GITHUB_CLIENT_ID
value: abcd
- name: DRONE_GITHUB_SERVER
value: https://github.com
- name: DRONE_GITHUB_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: client-secret-drone
key: secretAdd the DRONE_USER_CREATE env var to bootstrap an admin account when starting the Drone server. This will allow your user to do all of the admin things using the CLI tool.
The secrets so should get generated when you dump the Helm chart, so feel free to update those with any values you may need.
Note: if you have double checked all of your settings but builds aren’r being triggered, there is a good chance that the webhook is the problem. There is a really good post about how to troubleshoot these settings here.
Running Drone with the Kubernetes integration
This option turned out to be the easier approach. Just add the following configuration to the drone server deployment environment variables, updating according to your environment. For example, the namespace I am deploying to is called “cicd”, which will need to be updated if you choose a different namespace.
- name: DRONE_KUBERNETES_ENABLED
value: "true"
- name: DRONE_KUBERNETES_NAMESPACE
value: cicd
- name: DRONE_KUBERNETES_SERVICE_ACCOUNT
value: drone-pipelineThe main downside to this method is that it creates Kubernetes jobs for each build. By default, once these builds are done, the will exit and not clean themselves up, so if you do a lot of builds then your namespace will get clogged up. There is a way to set TTLs on finished to clean themselves up in newer versions of Kubernetes via the TTLAfterFinished flag but this functionality isn’t default in Kubernetes yet and is a little bit out of the scope of this post.
Running Drone with the agent configuration
The agent uses the sidecar pattern to run a Docker in Docker (dind) container to connect to the Docker socket in order to allow the Drone agent to do its builds.
The main downside of using this approach is that there seems to be an issue (sometimes) where the Drone components can’t talk to the Docker socket, you can find a better description of this problem and more details here. The problem seems to be a race condition where the docker socket is not being able to be mounted before the agent comes up, but I still haven’t totally solved the problem there yet. The advice for getting around this is to run the agent on a dedicated stand alone host to avoid race conditions and other pitfalls.
That being said, if you still want to use this method you will need to add an additional deployment to the config for the drone agent. If you use the agent you can disregard the above Kubernetes environment variable configurations and instead set appropriate environment variables in the agent. Below is the working snipped I used for deploying the agent to my test cluster.
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: drone-agent
labels:
app: drone
component: agent
spec:
replicas: 1
template:
metadata:
labels:
app: drone
component: agent
spec:
serviceAccountName: drone
containers:
- name: agent
image: "docker.io/drone/agent:1.0.0-rc.6"
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 3000
protocol: TCP
env:
# This value should point to the Drone server service
- name: DRONE_RPC_SERVER
value: http://drone.cicd
- name: DRONE_RPC_SECRET
valueFrom:
secretKeyRef:
name: drone
key: secret
- name: DOCKER_HOST
value: tcp://localhost:2375
- name: DRONE_LOGS_DEBUG
value: "true"
# Uncomment this for additional trace logs
#- name: DRONE_LOGS_TRACE
# value: "true"
- name: DRONE_LOGS_PRETTY
value: "true"
- name: dind
image: "docker.io/library/docker:18.06-dind"
imagePullPolicy: IfNotPresent
env:
- name: DOCKER_DRIVER
value: overlay2
securityContext:
privileged: true
volumeMounts:
- name: docker-graph-storage
mountPath: /var/lib/docker
volumes:
- name: docker-graph-storage
emptyDir: {}
I have gotten the agent to work, I just haven’t had very much success getting it working consistently. I would avoid using this method unless you have to or as mentioned above, get a dedicated host for running builds on.
Testing it out
After wiring everything up, the rest is easy. Add a file called .drone.yml to a repository that you would like to automate builds for. You can find out more about the various capabilities here.
For my use case I wanted to tell drone to build and publish an arm64 based Docker image whenever a change to master occurs. You can look at my drone configuration here to get a better idea of the multiarch options as well as authenticating to a Docker registry.
After adding the .drone.yml to your repo and triggering a build you should see something similar in your local Drone instance.
If everything worked correctly and is green then you should be good to go. Obviously there is a lot of overhead that Kubernetes brings but the actual Drone setup if really straight forward. Just set stuff up on the Github side, translate it into Kubernetes configurations and add some other Drone specific config options and you should have a nice CI/CD environment ready to go.
Conclusion
I am very excited to see Drone grow and mature and use it more in the future. It is simple yet flexible and it fits nicely into the new paradigm of using containers for everything.
The new 1.0 YAML syntax is really nice as well, as it basically maps to the conventions that Kubernetes has chosen, so if you are familiar with that syntax you should feel at home. You can check out the available plugins here, which cover about 90% of the use cases you would see in the wild.
One downside is that YAML syntax errors are really hard to debug, and there isn’t much in the way of output to figure out where your problems are. The best approach I have found is to run the .drone.yml file through the Drone CLI lint/fmt tool before committing and building.
The Drone CLI tool is really powerful and could probably be its own post. There are some links in the references that show off some of its other features.
References
There are a few cool Drone resources I would definitely recommend checking out if you are interested running Drone in your own environment. The docs reference is a great place to start and is great for finding information about how to configure and tweak various Drone settings.
https://docs.drone.io/reference/
Here is a link to the CLI reference.
https://github.com/drone/awesome-drone
I also definitely recommend checking out the jsonnet extension docs, which can be used to help improve automation workflows. The second link show an good example of how it works and the third link shows some practical applications of using jsonnet to help manage complicated CI pipelines.
https://docs.drone.io/extend/config/jsonnet/
https://github.com/drone/drone/blob/master/.drone.jsonnet
https://medium.com/dazn-tech/simplify-your-ci-pipeline-configuration-with-jsonnet-5a96cd9ccc51
Here is a link for various cool drone stuff, including blog posts and tools.
