Update 9/22/2016: This blog post was eventually used to create a drone-on-kubernetes demo repository. Check that out for more up-to-date examples.
I've been evaluating Drone, with the goal to get it running on Kubernetes. I figured I'd share some very preliminary manifests, for anyone who else may be tinkering. How to use these is outside of the scope of this article, but Google Container Engine is an easy way to get going.
The first order of business is to create a service to serve as an entrypoint. The end result of this on Google Cloud is a Network Load Balancer with a public IP. The creation of the load balancer is handled by Kubernetes. Here's the manifest I used (HTTPS-only, in my case).
apiVersion: v1 kind: Service metadata: name: droneio labels: name: droneio spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: name: droneio type: LoadBalancer
After setting a DNS entry up to point at the load balancer's public IP, the next step was to get a replication controller set up.
apiVersion: v1 kind: ReplicationController metadata: name: droneio labels: name: droneio spec: replicas: 1 selector: name: droneio template: metadata: labels: name: droneio spec: containers: - image: drone/drone:0.4 name: droneio env: # HTTP Listen Address - name: SERVER_ADDR value: ":443" # HTTPS private key - name: SERVER_KEY value: /etc/secrets/proxykey - name: SERVER_CERT value: /etc/secrets/proxycert # DB stuff - name: DATABASE_DRIVER value: sqlite3 # This ends up being a mounted Google Cloud Disk. - name: DATABASE_CONFIG value: /var/lib/drone/drone.sqlite # RCS stuff - name: REMOTE_DRIVER value: bitbucket # TODO: Move these into secrets. - name: REMOTE_CONFIG value: https://bitbucket.org?client_id=YOUR_CLIENT_ID_HERE&client_secret=YOUR_CLIENT_SECRET_HERE&open=true ports: - containerPort: 443 protocol: TCP volumeMounts: # Contains our SSL certs/keys - mountPath: /etc/secrets name: aclima-io-ssl readOnly: true # Persist our configs in an SQLite DB in here - mountPath: /var/lib/drone name: droneio-sqlite-db # Enables Docker in Docker - mountPath: /var/run/docker.sock name: docker-socket - mountPath: /var/lib/docker name: docker-lib volumes: - name: aclima-io-ssl secret: secretName: aclima-io-ssl - name: droneio-sqlite-db gcePersistentDisk: pdName: droneio-sqlite-db fsType: ext4 - name: docker-socket hostPath: path: /var/run/docker.sock - name: docker-lib hostPath: path: /var/lib/docker
A bit lengthy, but we're using the Kubernetes Secrets API to store our SSL certs/keys. Our data store is SQLite, persisted with Kubernetes gcePersistentDisk. You can replace this with something else if you aren't on Google Cloud, or switch to one of the other DBs that Drone supports.
While I have glossed over a lot of details, this was enough to get us up and running well enough to start evaluating Drone.
Here are a few ideas for future improvements:
- The keys in REMOTE_CONFIG should be stored in the Secrets API. There is currently (Kubernetes 1.0) no direct way to pull a secret directly into an environment variable in the manifest. The current workaround seems to be to create a shell script to use as the Docker container's entrypoint, pulling the values from the mounted secrets volume and stuffing them in environment variables.
- HTTP -> HTTPS redirect (if you please).
- X.509 auth might be a good idea, depending on your usage case.
- DB persistence in something other than SQLite for any more active installs.