Hello everyone!
Today, I’d like to briefly discuss an improvement to the update and upgrade procedures that we’ve started to adopt with NetEye 4.39!
One aspect that made quite an impact was that whenever the update or upgrade procedure stopped, even for legitimate reasons such as rpmnew
or rpmsave
files, it took a certain amount of time to reach the same step upon relaunching.
And yes, it’s true that our procedure is based on Ansible and hence targets the maximum possible idempotence, but the evaluation of the each step (to understand if it needs to be performed or not) still requires some time, and especially in large environments, this may be a slowdown during the update and upgrade procedure.
Okay, so how could we improve on this?
Well, the first aspect that we need to consider is that our procedure is generally divided into blocks, especially for those services that have a dedicated upgrade procedure. Simplifying a bit, we can summarize both procedures into something similar to the diagram below, where each block can be assumed to be a set of Ansible tasks:
Now, NetEye 4.39 brings the architecture to a point where potentially upon the successful conclusion of a block, we can set a checkpoint! What do we mean by a checkpoint?
Well, it’s just a way to signal that, for that particular procedure (round of update or upgrade to a specific version), a specific step has already been performed successfully.
Why does this help? Because if the procedure stops at a later point, relaunching it will then allow us to skip all those blocks up to the last successful checkpoint, without having to “enter the block” and evaluate the conditions of all single Ansible tasks that made up that block, leading to quite a significant speed-up!
Okay, so that’s the general idea. Now, what does NetEye 4.39 bring?
First of all it updates the architecture, allowing us to set, retrieve and evaluate the checkpoints.
Further, it already applies some checkpoints, which can already play a role in the upgrade from NetEye 4.38 to NetEye 4.39, to the update and upgrade procedures of the Elastic Stack components (yes, all of them!) and to the secure install stages, as shown below:
Of course, we look forward to an expansion of the checkpoints to all “blocks” of our procedures to ensure a smoother and faster experience during updates and upgrades.
See you at the next blog post and… happy holidays 🎅❄️
Did you find this article interesting? Are you an “under the hood” kind of person? We’re really big on automation and we’re always looking for people in a similar vein to fill roles like this one as well as other roles here at Würth Phoenix.