I wanted to deploy this small website to post small blog posts as the inspiration would come. Because I’m stubborn, I wanted to self-host it, however I also wanted the process to publish to my website to be as stream-lined as it could be. Therefore, I decided to have it continuously delivered so that pushing a new commit to my server would automatically build the changes and serve them.
I had wanted to install Drone CI on my server for a while. I already have a plethora of self-hosted services on my server, and after reading the docs I thought it would be deployed and ready to use in no time.
Instead it took me a few hours over a week before I got it working. I would run
the container in
docker-compose, it would display its logs happily, but
nothing happened if I tried to connect to it.
My service definition looked something like this :
drone-server: image: drone/drone:1 container_name: drone-server restart: unless-stopped env_file: - ./drone/drone.env - ./drone/drone.env.secret volumes: - ./drone:/data ports: - 8080:8080 # Exposed for debugging purposes depends_on: - gitea # My self-hosted Gitea instance user: 1000:1000
I tried everything on port
firefox did not show anything, neither
wget. I even tried to execute
wget inside the
to no avail!
I tried listing the open ports, both outside and inside the container. I tried activating the debug logging, and I could not see anything out of the ordinary.
I then tried launching the container directly on the command line, instead of
docker-compose service. Here’s the command I used:
docker run --rm \ --publish=8080:80 \ --name=drone \ --env-file shipyard/drone/drone.env \ -v `pwd`/drone/:/data \ drone/drone:1
Navigating to port
8080 now redirected me to my
Gitea login page, as it
I was puzzled, as I could not see any difference between my service definition and the command line I was launching.
The keen-eyed among you might have already seen the difference between those
two container instances… A single option was missing in my
command which, had I included it, would have kept it from working too.
Have you found it yet? It’s the
user: ... line. I felt like a fool when
I finally spotted the difference. I removed it, and my service was now up and
The logs showed no difference, nothing was complaining about the rights on disk, the SQLite database was still created either way. But this line was the difference between a working instance and a non-working one.