Backups, Restores, Upgrades and Rollbacks
Última actualización
Última actualización
Files for backup involve, on one hand, custom Asterisk configuration files located at /etc/asterisk/custom. On the other hand, a backup of the Postgres Relational Database is performed.Para correr un backup, se debe ejecutar el siguiente script:
The backup is deposited in the Bucket associated with the instance during its deployment process. Remember that the exposed scenarios allow incorporating MinIO as the default bucket, or adding popular solutions from Cloud Providers oriented towards Object Storage, such as Spaces (Digital Ocean) or S3 (Amazon).
Within the bucket, you'll find a backup folder containing a .sql file preceded by the execution timestamp. Additionally, another directory will hold the corresponding Asterisk backups.
In the face of a Disaster scenario, it is possible to proceed with a Fresh Install of a productive instance and perform a data restoration action from a backup (Recovery).
To make this happen effectively, we must modify the last two parameters of the inventory.yml corresponding to our tenants' folder. This is necessary to indicate that the bucket does not handle trusted certificates and to configure the timestamp of the backup to restore:
In this way, by executing the following script with the action "restore", the backup taken in the previous step will be restored onto the newly deployed instance, thereby providing a recovered environment:
The OMniLeads Team builds images for all the components that make up its architecture. They are hosted on Docker Hub at the following link:
It is important to differentiate the main Application Repository (Web) from the rest of the component repositories (asterisk, rtpengine, kamailio, nginx, websockets, and postgres).
The Web App uses a release definition semantic that includes RC (release candidates) and STABLE (releases suitable for production environments), as shown below:
However, the rest of the components use date semantics followed by the version number of that release, for example:
Each time a WebApp release is deployed, it is made available through an image in the Container Registry. Additionally, the Releases-Notes.md file in the root of the repository is updated to reflect a correct mapping between the component versions and the application release version.
Therefore, to apply updates correctly, it is important to "fetch" the latest changes from the stable branch. This is done with the following command:
From there, the next step is to update the inventory.yml file (corresponding to the tenant) with the "target" version. For example, "1.33.0" in the screenshot below:
Finally, we proceed to execute the script with the "upgrade" action in order to update the component(s) in question.
The use of Containers in OMniLeads allows for quick and safe rollback procedures. This way, we can revert to previous versions following an update if the update did not generate satisfactory results.
With the modified inventory.yml, it is then possible to revert to the previous version before the change:
For more information, we suggest visiting the official project repository documentation.
