- Use Case
- Log in →
- Running Webhook Relay agent with Podman
- New feature announcement: domain-based endpoints
- Static IPs for webhook calls to enable whitelisting
- Responding to API calls using Node-RED Webhook Relay node
- Docker Compose update on Github webhook
- Using Google Firestore for a Golang backend application
- Automated Jenkins builds on GitHub pull request
- Rules-based webhook filtering & routing
- Introducing Cloudflare support for Home Assistant remote access
- Setting up simple, self-hosted & fast CI/CD solution with Drone.io
Docker Compose update on Github webhook
Sep 2, 2019, by Karolis Rusenas
Last year I wrote a blog post about combining several tools to automate simple NodeJS app updates on git push. Many users were solving similar problems by writing local web servers in Ruby, Python or PHP to receive webhooks and then do async processing. I am happy to announce that we finally decided to add this feature to the relay CLI. Now, to execute a bash script, you can:
relay forward --bucket my-bucket-name --relayer exec --command bash update.sh
And to launch a Python app on webhook:
relay forward --bucket my-bucket-name --relayer exec --command python my-app.py
This opens up some interesting posibilities to create pipelines that can react to pretty much anything that emits webhooks. In this article I will show you how to build a GitOps style pipeline that keeps a Docker Compose deployment in sync with a docker-compose.yaml hosted on a git repository.
Repository with scripts that I used for this article can be found here: https://github.com/webhookrelay/docker-compose-update-on-git-push.
First step is to do the initial deployment. We will create a simple dockerized Python application that you can find here that connects to Redis and deploy it:
Since we only want to update on git tags and not just any pushes, let’s configure a webhook and analyse the payload.
To achieve that, let’s first create a bucket with an internal output:
$ relay forward --bucket docker-compose-update-on-git-push http://localhost:4000
Here, bucket will be used later to subscribe to github requests while destination is just a mandatory argument that we don’t have to use in this case.
Grab that https://my.webhookrelay.com/v1/webhooks/*** URL and go to your repository’s settings -> webhooks section. Once there, set:
- Payload URL to your unique https://my.webhookrelay.com/v1/webhooks/*** URL
- Content type to application/json
- Secret to a random secret name, for the sake of this example my secret will be ‘webhooksecret’
Let me select individual events.and select Releases.
Now, go to your repository’s releases page (for example https://github.com/webhookrelay/docker-compose-update-on-git-push/releases) and make a new release
1.0.0. Then, if you visit bucket details page or logs page - you should see webhook from Github. Open it and let’s inspect the payload. It’s quite lengthy but we should be able to see
in the top. To ensure that we only react on these events, create a rule:
If you tag another release, you should see now that only one webhook was forwarder
Our update script is:
It will pull the latest compose file and update containers. Now, let’s update configuration in
relay.yml file (access key & secret can be generated here):
To start the relay, run:
relay run -c relay.yml
This will be running it through your terminal. For production use cases, please use background service mode. It will ensure that the daemon is launched on OS startup.
docker-compose up -d
$ docker ps
Next step would be to build a new image
0.2.0 and push it to the registry. Once it’s available, we can update our github repository
docker-compose.yml and make a new release. For the sake of this example, let’s do this through the Github UI.
In a few seconds you should see a new container running:
$ docker ps
Webhook Relay output rules can also validate Github signature:
This will ensure that only webhooks signed by Github will be processed.
As with any code executed on your machine - you have to be careful when automating tasks. Webhook Relay will provide you with a unidirectional flow of webhooks into the machine. Your script/applications are on your machine and cannot be modified remotely through Webhook Relay. Coupled with authenticated webhook endpoints (you can configure it on a bucket level) or webhook payload checksum validation - you can build a secure update mechanism.