24. 12. 2023
Development, DevOps, Log-SIEM, NetEye
24. 10. 2023
Valentina Da Rold
Development, NetEye
The Configurator: Moving from a Monolithic to a Modular Approach in NetEye Upgrade
Over the last few months, I’ve had the chance to work on a number of issues that involved many NetEye modules. In all these situations, we had to face the same problem: how to release a new module version without impacting the automated NetEye upgrade procedure.
Nothing new for us, but we’d like to improve the way we usually handle these situations.
What we did in the past for migration of custom module configurations or settings was blocking the upgrade procedure, and giving the users time to apply their customization to the new module version. Once files like .rpmnew or rpmsave were manually migrated, the upgrade procedure could proceed.
These interruptions during the upgrade are definitely annoying. For this reason, we’d like to avoid stopping the NetEye upgrade procedure and forcing the user to manually intervene to migrate files. We’d like to automate the migration as much as possible, in order to give the best possible user experience.
Starting from this idea, a couple of releases ago we started working on the concept of the configurator.
The configurator has the sole responsibility to provide (if needed) the necessary automation procedure for correctly moving to the new module version. We will then slowly move from the idea of a “global” NetEye upgrade to the concept of a dedicated upgrade procedure for each module.
As you can see from this schema, the old upgrade procedure expected that all modules are updated before launching the setup script called NetEye Secure Install (that in this case can be seen as monolithic).
With the configurator, this approach changes in the sense that first of all we download the new version for all the modules that need a custom upgrade procedure (one by one), and for each one of these modules we execute the dedicated upgrade procedure.
This will lead to an updated system that won’t generate files like .rpmnew or .rpmsave that will have to then be manually migrated. Once all the modules are updated, the global Secure Install will then be executed, with the main goal of subsequently breaking it down so that all the modules manage the necessary configuration by themselves.
Moving to this modular approach should help us in managing modules that are simpler to create and deploy, improving their functionality and stability.
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.
Valentina Da Rold
Hi, I'm Valentina and I'm a Frontend Developer at Wuerth Phoenix. I started out my career applying my Cryptography skills to coding, but really quickly fell in love with the web. I have been making websites and applications since 2012 and I still can't get enough of it. Along the way I found a passion for front-end development, and I use this passion to create interfaces that solve problems. When I'm not creating beautiful solutions, I enjoy cooking or doing sport, while listening to beautiful music.
Author
Latest posts by Valentina Da Rold
19. 12. 2023
Development, Events, NetEye
We spent a (Vue)day in Verona