rFactor 2 orchestration, week 1e18: Web-based server management
I've been now working almost 2 years, with some breaks, on the APX project. A interim conclusion for a continuous integration/ deployment project for the simracing platform.
Need for compromises
First of all, not all wanted features are actually possible. Some wished features simply have no API to implement them properly in a simple, stable way. But the majority of features are implemented, some of them required some research throught archives, forums and communities. Also a big thanks goes out to people participating in discussions to add troubleshooting ideas.
Especially session control management currently still relies on GUI clicking on the server application window, which is still a open todo to replace with something not relying on the interface of the server.
But in sum, following features are supported and working by now:
- Server update
- Install of workshop items
- Creating rfcmp for liveries
- Creating mod including rfm settings
- Adding numberplates to liveries
- Lifecycle control (start, stop, status, lockfile upload)
- Chatting/ command injection, if supported
I'm quite happy with the current status, to be honest.
Motivation
The motivation? See how far things can work :)
Management
On top of the reciever and the CLI, I added an web-based management interface, powered by Django. The GUI simplifies the usage massively for users without any expierience with shell applications.
The web GUI erradicates the need to move files, mods, handle duplicate folders and so on. You can upload liveries files into the web interface, with clear identification which car is the file is related to.
After that, you just configure your event, choose deployment in the server properties. Then just let the background worker to do it's work and you are ready to go racing.
For interaction with the servers, the GUI uses a frequently running cronjob which will do the actually communication with the server, using the reciever component. The reciever component is basically an "HTTP bridge" and connects CLI and dedicated server.
This all allows you also, to e. g. do daily/ weekly / nightly builds on your server to keep it updated all the time, without the need to move a finger, basically.
Stability and verbosity
Currently, I'm mostly working on stability fixes and increased verbosity. My target here is to offer an transparent expierience what was done with the server in detail.
Also, I'm adding warnings. The purpose of these warnings is to inform the administrator if the configured event may be harmed by issues, e. g. with using wrong or invalid versions of components.
The project will aim to erradicate human-caused errors as long as your initial config is fine. Each build runs the exactly same steps on a fresh, cleaned dedicated server instance. This removes all issues causing by conflicting mods and any other artefacts not really relevant for the newly deployed event. So basically, APX is an continuous integration/ deployment pipeline for rFactor 2.
This all removes a lot of potencial error sources and reduces the human time needed to update the server by a lot. And you can spent the time with more important stuff.
More infos: https://apx.chmr.eu/ and https://discord.gg/qwSkeAM
Other articles about the journey of APX:
More posts
More postsMore posts