We’re on the run up to our 2-year anniversary of taking over the development of WISP, and we’ve been hard at work behind the scenes on a long overdue major update 🌴
Recently, we’ve been on a war path of optimizing backend infrastructure & improving reliability, ripping out (far too many) legacy systems & replacing tech debt, and formulating a new vision going forwards for how the administrative process and user experience of a game panel should work.
We’ve decided that it’s time to shake things up and make some necessary breaking changes to pave our path forward. There’s a lot of features we’d be unable to ship without a major update and some breaking changes. For a TL;DR on what happens next, what’s breaking and what you need to do, feel free to scroll to the end.
Nests were always a fun little way to organize… eggs. Ha-ha. But that’s kind of all there was to it. Nests were merely a way to group eggs, and didn’t really fit into the wider ecosystem of games we have today: what nest should I put Hytale under? Windrose? DayZ? There’s a lot of games now that don’t really fit into any particular nest, and it stood out to us that this feature is mostly redundant.
We rarely used nests to activate specific features, outside of mainly just knowing how to query the number of players on the server, which was unclear, and hacky. More on that later.
We decided Nests need to go. We discussed what would be a useful replacement, and decided it’s time to introduce a Tags system.
For a game panel built to be automated and talk to a billing system, the node deployment system as it stands is… incomplete, and a lot of what was implemented felt like an afterthought, with some poor design decisions and rushed, redundant functionality implemented in all those years ago. From the WHMCS module to the panel itself, this functionality needed some critical rethinking.
🏷️ Firstly, tags have opened up a lot of new functionality here, and closed a lot of missing gaps. Moving forward, tags are going to be the first-class strategy for how we handle automatic node deployments.
By attaching tags to nodes, you can specify what kinds of eggs are allowed to be automatically deployed to each of your nodes. That means you can have game-specific nodes, whereas previously the idiomatic way of doing this was by making a “Location” for each of these groups. This was semantically wrong, and when building the Egg Switcher, we realized this was going to bite us in the butt; the Egg Switcher relies heavily on automatic node deployment rules and policies, so Tags were a must for shipping the Egg Switcher.
The concept of “allocations” in relation to eggs is entirely disjoint as it stands, despite them actually being deeply intertwined. Let’s take Rust as an example. Rust uses a whopping four ports, which must be passed down to the game’s config to define: the game port, the query port (for Steam A2S queries), the RCON port, and the Rust+ companion app WebSocket port. This highlighted some high-friction issues with our current concept of eggs:
These gaps in what an egg can express led to some complicated and fragile setups in terms of automation, e.g. WHMCS. It also meant that we could not faithfully ship the Egg Switcher without shipping something that would just lead to tickets from customers who need a specific number of ports, and worse yet, where to even put those ports in their respective configs.
We have closed this gap entirely by moving the responsibility of port allocations to eggs. Eggs are now able to express, “I need this many ports, and I need these startup/environment variables populated with those port numbers when I boot up.”
We’ve also made it so that allocating a port to the QUERY_PORT environment variable automatically tells Gamedig which port to query on.
The egg switcher is here!
We put a lot of effort into getting egg switching right for everyone’s needs. The egg switcher is definitely the most feature rich implementation of this out there:
TODO
Welcome to Server Templates!
This is our vision for what billing → panel deployment of servers should look like from now on.
Instead of defining tons of plans, defining port allocations & ranges, target nodes, etc, all in WHMCS, and therefore likely being completely unable to change the specs of a plan after the fact without mass API calls, and general WHMCS shenanigans, why not let us handle all the bull💩!
Server templates allow you to specify a template for server creation. Who would’ve thought? The fun part comes in divergence, resyncs, port configuration, and even egg variable configuration - all things most billing platforms, and especially WHMCS, either make it extremely difficult to do, or is completely unable to do at all!
Instead of filling in all the fields on a new WHMCS product for each plan, you’d simply fill in the new “Server Template Identifier” field in v3 of the WISP WHMCS module (please update!), to associate the product with a server template.
Then, you can define everything such as CPU %, disk space limit, backup limits, etc, as part of a server template.
That way, if you ever want to make changes to a plan, just go into its server template, make the change, and click “Resync” to push it to all attached servers!
Now, in order to help facilitate migration to this new system, we’ve added a clever button called “Import from WHMCS” to the Server Templates index page.
With no extra configuration in regards to API keys, permissions, etc, we securely pull all your WHMCS products that have a Server Template Identifier set, and create or update an existing Server Template for you!
Then, once templates are all synced in, you can then sync in server assocations too. The whole process should take no more than 15 minutes 😉
TODO