Enhanced SystemD Service Example

Have you tried running your web app as a SystemD Service? This blog enhances the systemd service example in Run App as SystemD Service Example. The systemd service example written in Run App as SystemD Service Example is probably good for lower environments (e.g. development, preproduction, etc.). For production however, we'll need a few steps more. Chances are your web app sits behind a load balancer.

SystemD Service Example Setup

Here it is. Straight to the point. You can compare it with the one in Run App as SystemD Service Example. I won't be explaining the details, I will leave that to the first blog. I will explain the changes I have made.

[jpllosa@rocky-balboa ~]$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.7 (Blue Onyx)"

...snipped...

[jpllosa@rocky-balboa systemd-stuff]$ cat my-web-app.service
[Unit]
Description=My Web App service
After=network.target
# new additions
Before=my-web-app-curl.service
Wants=my-web-app-curl.service 

StartLimitIntervalSec=0

[Service]
Type=simple
# from always
Restart=on-failure
RestartSec=1
User=codesamples
ExecStart=/usr/bin/java -jar /opt/codesamples/my-web-app/my-web-app.jar --spring.config.location=/etc/codesamples/my-web-app/my-web-app.properties

[Install]
WantedBy=multi-user.target

[jpllosa@rocky-balboa systemd-stuff]$ cat my-web-app-curl.service
[Unit]
Description=Service to LB
Requires=my-web-app.service
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=on-failure
RestartSec=5
TimeoutStartSec=360
User=eh
ExecStart=curl -v --data "{\"status\": \"up\",\"key\": \"1234\"}" --header "Content-Type: application/json" http://localhost:8080/my-web-app/status

[Install]
WantedBy=multi-user.target

What's changed and what's new? Most noticable is the my-web-app-curl.service. What does this service do? It simply sets the status endpoint to up as this is what is checked by the load balancer. When the load balancer sees that it is up (ie. online), it will then add the web app into the pool of available servers and route requests to it.

Let's talk about the my-web-app-curl.service unit file first. The Requires configures dependencies on other units. This unit is not started unless the dependency has been activated. That's common sense really. You can't set the service to online if my-web-app isn't fully ready. The RestartSec is the time in seconds the service will sleep before restarting the service again. The TimeoutStartSec configures the time to wait for start-up in seconds. If a daemon service does not complete start-up within the configured time, the service will be considered failed and will be shut down again. The Restart configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. In this case, on-failure, the service will be restarted when the process exits with a non-zero exit code. Finally the most important bit, ExceStart is the command that is executed when the service is started.

Ok, time for my-web-app.service. This unit file is already explained here, Run App as SystemD Service Example. Here's what changed? The Restart has been changed to on-failure. The Before tells systemd that this service must be ran before my-web-app-curl.service. The Wants is similar to Requries but less strict. It's a weak dependency requirement. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole, and this unit will still be started. This is the recommended way to hook the start-up of one unit to the start-up of another unit. We are doing this weak dependency because our web app might be still loading whilst curl is being ran. We need curl to retry and the web app to completely boot up.

Enhanced SystemD Service Example Wrap Up

There you go. A quick example of chaining systemd services. Aa previously mentioned, if you want more details, jump to Run App as SystemD Service Example. You can now sit back and relax and see your production environment running smoothly. Congratulations, you have automated yourself out of a job.

More Rocky Linux tips here...