Client
A large telecom software and hardware provider used Elinext to build an application for deploying its software in its clients' systems.
Challenge
The client supplies software to telecommunication companies. Those companies need to install this software, and they used to have to do so manually, which was an extremely challenging task.
Customers would have to deploy a set of YML files and config files describing which docker images needed to be used and in which order, alongside some other parameters. To simplify the task for customers, our client set out to develop an installer program.
“Installing the software had to be done manually, and was a challenging process for customers.
Our client set out to build an installer app to simplify it.”
The company started by putting together a set of shell scripts, which eventually transformed into a Java application. And that’s when they sought out help. At that point, Elinext had already worked with the company on other projects, and they liked our work. So, we turned out to be a natural choice when selecting a developer.
Process
We started by studying the application the client had already been developing for some time. Its very nature posed a few challenges, the main two being working hand-in-hand with end customers’ DevOps and limiting cluster access.
Pairing Programming with DevOps
The installer asks the user a question and validates the answer. However, when the essential data is available, the installer skips the step of asking the user for information and enters the inputs automatically. The installer can also offer the user a choice of possible values.
The user answer validation requires communication with a Kubernetes or Openshift cluster. These clusters are part of end customers’ systems, so we have to work tightly with customers’ DevOps. We provide them instructions and make sure they understand how to follow those.
Limiting Cluster Access
The original idea of the installer was a cluster admin program, an application that would have full access to end customers’ clusters. However, telecom companies had their security concerns. They had had other applications installed in the same clusters and worried those could be affected in case of a breach.
Therefore, we had to limit the installer’s access to clusters, which complicated the development. We changed the code and, in product documentation, described a scenario for installing the software as a namespace administrator without cluster level access.
Users with limited permissions have fewer capabilities to validate inputs or fill them automatically. We also described the steps that require cluster level access (otherwise done by privileged pods) as prerequisites for this scenario in the documentation. For example, the cluster administrator must prepare Persistent Volumes, create folders on NFS and set correct user/group permissions to these folders.
''We guide end customers’ DevOps to ensure the installer works with their systems.''
Implementation and Testing
Quality assurance has also been part of our job on this project. We are using JUnit tests accompanied by automated testing.
Product
The installer is a complex piece of software from the inside — and a very basic app from the user’s perspective. We haven’t designed or built a specific interface or any elements pertaining to user experience for that matter.
Silent and Interactive Modes
The application has two modes: silent mode and interactive mode.
In the interactive mode, the program asks you questions about your environment and the products you want to install.
In the silent mode, you upload YML files with inputs either from a previous installation or filled in manually in the interactive mode. You can also prepare YML files with custom inputs to automate parts of how the software works and upload them in the silent mode.
Input Validation and Deployment
Once inputs have been entered, the installer checks with the Kubernetes or OpenShift cluster to validate those inputs and match them with cluster parameters. After that, the script either fills in user answers, or puts defaults in their place.
At the next stage, the installer downloads docker images from a file or registry and pushes them to the registry used by the cluster. Finally, YML files are applied to create objects corresponding to the essential elements of the software being installed.
Results
The application we helped the client build has simplified the installation of their software for end customers. However, it requires a lot of work on our side and is considered as an interim step on the path toward improving the process. We are now helping the client come up with a better solution.
