Published: 23.05.2021 | Edited: 23.05.2021 | Tags: 100daystooffload,gitea

Understanding single Drone per VPS limitation

Being occupied by many other higher priority tasks lately, my goal to set up Drone instance on the Contabo VPS was put on hold. I wanted to set-up Drone to create a pipeline for building the posts for this blog. The blog is statically generated site, meaning posts need to be generated on some machine, before they can be published as an actual blog.

Currently, I am building this blog on the laptop, but having the build and publish process set up on the server would enable me to write from other devices as well, because the build would be performed on the server, not the laptop itself. The laptop would be used only for the writing part.

The theory would be that Drone would track the blog's repository main branch and if any commit appears there, it would build and publish. Most of my work is hosted at my Gitea server, the blog included. Gitea already has a markdown editor integrated, so if I can login into Gitea, I can publish a blog post.

Gitea and Drone integration

Drone is capable of working with Gitea and the set up for such integration is also available in the official Drone docs. However, there is a scary part for the Drone version 1.0 at the beginning:

Please note we strongly recommend installing Drone on a dedicated instance. We do not recommend installing Drone and Gitea on the same machine due to network complications, and we definitely do not recommend installing Drone and Gitea on the same machine using docker-compose.

I have been trying to understand what does it mean for some time. The response I received at the Gitter Drone channel was that it is possible to have Gitea and Drone on the same VPS but it is complicated and no official documentation is offered.

There are a few guides available that offer some guidance, but I was not following either of them, so no links here. The only link I would like to discuss regarding the topic is this one.

Drone behind Nginx

The reason I am referring to that link is twofold. First, it is the latest link I could find on the topic and also relatively well written, but I did not test it yet. But I plan to as I could understand the steps outlined there. The second reason is however more important. The actual problem with installing Drone on the host with Gitea lies in the fact that Drone should not be installed behind Nginx at all!

There is a page in old docs regarding Drone version 0.8 instructing about Nginx configuration. But there is no such page mentioning Nginx in the recent docs! I suspect other reverse-proxy tools are omitted as well.

The official documentation for running Drone sever container is the following:

docker run \
  --volume=/var/lib/drone:/data \
  --env=DRONE_GITEA_SERVER={{DRONE_GITEA_SERVER}} \
  --env=DRONE_GITEA_CLIENT_ID={{DRONE_GITEA_CLIENT_ID}} \
  --env=DRONE_GITEA_CLIENT_SECRET={{DRONE_GITEA_CLIENT_SECRET}} \
  --env=DRONE_RPC_SECRET={{DRONE_RPC_SECRET}} \
  --env=DRONE_SERVER_HOST={{DRONE_SERVER_HOST}} \
  --env=DRONE_SERVER_PROTO={{DRONE_SERVER_PROTO}} \
  --publish=80:80 \
  --publish=443:443 \
  --restart=always \
  --detach=true \
  --name=drone \
  drone/drone:1

Note the --publish option, specifying precisely the 80 and 443 ports. How to setup TLS without the reverse proxy like Nginx? Well Drone has https functionality built in.

The easiest way is to add --env=DRONE_TLS_AUTOCERT=true to the above command and call it done. The Drone starts. Of course the certs can be specified manually, everything is in the docs. But the point is that it is not problematic to setup Drone with Gitea on the same server, because problems starts a step before, at the missing reverse proxy documentation, which is needed for setting up anything on the server alongside Drone.

Closing words

I am not blaming anyone here, it is just a pity that Drone basically requires it's own VPS. The point of self-hosting is running multiple services on the VPS. Especially when the service is meant to be run once a day for a few seconds till it builds the static blog. Since Drone would not be using resources continuously and its startup time delay would be insignificant (it does not matter if the blog is published 5 minutes later or sooner), it would be much better suited to some serverless environment, but I did not get there yet. For now, I am passing on Drone until I find better place where it can run.

This is a 74th post of #100daystooffload.