Web Ear
Simple webhook listener written in go. Executes pre-configured shell scripts upon receiving custom web hook requests. hook
Problem Statement
If it is necessary to to a server side action based as a part of deployment pipeline, it is often required to ssh into the server by the pipeline and execute the commands in the server. However, if web hook based signalling is possible, we can tell the server to to the action by triggering the web hook. However, for this setup, server needs to have a custom listener. Often times, this listener is written as part of the application, but this is redundant if we have a common easily use and configure web hook listener.
Project Description
This is an open source project written in Go. The project was developed to cater a need I had back then for a deployment pipeline in a web project.
The daemon listens on port 8080 for web hook requests. Users can configure WebEar to do different actions based on the endpoint web hook request was received. What actions to do is configured by writing a shell script and providing that shell script in the WebEar configuration. If the application is executed as root, it has the ability to switch to any user as necessary to execute the shell script corresponding to triggered end point.
Shell scripts are executed as child processes of Web Ear. Go routines are being used to spawn them without blocking the main thread. Also, a go routine runs continuously to check for zombie processes (as a result of the child process finishing its task) and to reap them.
Challenges & Learning Experience
This is the first Go application I developed for a real world requirement. Therefore, the application was developed end-to-end covering all aspects including configuration files and an installer.
With this, I was able to explore the concepts of daemon processes since web ear essentially runs as a daemon. I dig deep into how new processes, a.k.a child processes are created in linux based systems since each action corresponding to a web-hook trigger is done in its own sub-process. Also, this during this project I faced a challenge where the application creating zombie processes. Before this project I had no idea what zombie processes mean. Once a child process finishes execution, unless the parent kills it, the now dead process stays around, hence referred to as a zombie. If we do a double fork to daemonize the process, it becomes a direct child of Systemd and hence systemd takes care of reaping. However for Web Ear, to keep it clean, we don't daemonize child processes. Hence, a separate go routine polls for zombies to reap them.
Hence with this project I was able to explore the operating system behavior and how it manages processes as well.