The idea of having installers for applications comes from looking for a generic way that all products have an installer to avoid multiple manual steps that were used when installing it.
For example, an installer may contain:
- Component: a generic way of referring to a library or application.
- Base software: any software we use that is external to us, such as the operating system, database, a service.
- Packages: This is a software package that has programs and data. In other words, you can have an application with all the necessary dependencies so that it runs correctly.
Installer Features:
- It is executed by a command line that gives us a user interface when the installation is done in an attended way. (It also offers the possibility of doing so unattended).
- A generic solution, that is, technology does not matter, etc.
- Internally, it uses Puppet, and in turn, Puppet is based on a Yum repository containing all the packages generated in the continuous integration environment.
- Made in Python.
- Allows selecting the application to install and set the necessary parameters (they are obtained from a YAML file).
Puppet
Puppet is a tool that facilitates the configuration of a server or computer, which abstracts us from knowing how to do an action in a specific environment. It has its own language that internally performs the necessary execution or actions in the destination environment (for example, Debian uses apt internally, or RedHat uses yum).
Puppet allows you to organize the execution/installation process through recipes.
These recipes contain a series of steps to execute. They can provide a template for a configuration file, etc.
Puppet modules are generated in the installer creation process, in general, for each component of the final application to be installed.
Each module will be responsible for managing the deployment and configuration.
Evolution:
This process of the installers began to be more complex. They are larger, and, above all, they keep the production servers concerning their configuration is complicated, so it was sought to find a way to facilitate this process.
The new generation of the installer provides a web environment for this management with the following components:
1) Installers modules
Here you can upload all the installers, with their versions and platforms, including all their artifacts and being able to manage the default configuration of all of them.
2) Artifacts repository
A centralized repository is provided for all artifacts in the installers.
This applies to RPM, Puppet forge and non-RPM files (such as .tar.gz)
3) Server configuration management
Here you can manage the configuration of a server, what modules and version to install. At the end of this configuration, a command line is obtained to apply to the destination server, which will be an unattended execution, but that will leave a history of the installation process (failed, successful) that can be consulted in the installer’s creative environment.
Below are some screenshots of the new classic and web installer
Module selection in the classic installer
Configuration of a module in the classic installer
Module selection and configuration of a module in the web installer
Module installation from the web installer.
