I manage a “DigitalOcean Droplet” to host a website for a nonprofit. We have a private repo on GitHub for source control. Since we built it, we had to manually deploy each time, even for simple tasks like publishing a new article. As GitHub offers Actions to automate deployment, naturally we want to benefit from that.
In short, we need to write a config file, in YAML, so that when we push new code to GitHub, GitHub can read the config file, orchestrate the DigitalOcean droplet based on the config, so that the site can be rebuilt, redeployed(via a few Docker commands) on the DO droplet.
My hunch was, there should be easily an existing solution working perfectly fine, what I needed to do was discover it(likely on GitHub) and use it.
The failed attempt
With some quick Googling, it seems that DigitalOcean has some official recommended way to talk to DigitalOcean via GitHub Actions: GitHub Actions for DigitalOcean. This looks promising: I could find bunch of examples using this. It requirs me to create a personal token to invoke their public APIs, so I did. From a glance at the documentations I found APIs for “Droplets” and “Droplet Actions”. I first played around some APIs locally to simply query my account info, invoice. They worked perfectly as I expected, so far so good.
As I kept going, I realized a gap: “Droplet” is the most basic feature of Digital Ocean, costs $5 a month. The public APIs around droplet are about querying/creating/updating/deleting droplet. The example action I could find also assumes I use Digital Ocean’s Kubernetes feature and the “early availability” Container Registry feature, both costs extra money. Is it the only aviable way to do so?
Took a step back and looked again at the commands I had to run on the Droplet: pretty straightforward and simple:
ssh to the droplet git pull # from our repo docker build # and other docker commands
- name: Pull from GitHub uses: appleboy/ssh-action@master with: host: $ username: $ password: $ script: cd ~/path/to/project && git pull email@example.com:project/home.git
Then the other steps got super easy: just define more Workflow steps, invoke multiple commands via SSH, to run the docker commands. Putting them together, I got a straightforward workflow running like this.
No, I didn’t discover an existing solution perfectly fit my requirement. But yes, it was easy to leverage a few building blocks, to build a solution simple enough to perfectly fulfill my own requirement.