Only global administrators, promotion administrators and promotion users can deploy revisions. More information is available in the Authorization section.
Authentication against servers during a deployment are performed using Denodo Security Token. Automated mode cloud servers are configured by default to use token, so no additional configuration is required.
A deployment process in cloud environments is slightly different than deployments in standard mode environments. The behaviour depends on the deployment configuration. We recommend reading this section for a better understanding of the different options.
When the deployment type is Perform changes directly in the servers, Solution Manager performs the changes in the current servers of the cluster. Changes will be performed in:
All the Denodo Virtual DataPort servers if the servers do not have a shared metadata database according to the deployment configuration. You can check the basic steps of this deployment here.
Only the first Denodo Virtual DataPort server if the option VDP Servers use a shared metadata database is enabled. You can check the basic steps of this deployment here.
In cloud environments, when shared metadata database option is disabled and the deployment type is Update the image and recreate the cluster, the changes are not performed in the current servers of the cluster. Instead, the changes are performed in a new server and then the cluster is recreated. The main steps of this cloud deployment type are the following:
If at least one of the deployed revisions contains VQL changes, the deployment process consists in the following:
Solution Manager launches a new instance using the latest image for the Virtual DataPort cluster.
Once the new Virtual DataPort server is up and running, the VQL of the revisions is executed.
The Virtual DataPort cluster is recreated using the new Virtual DataPort server as reference, minimizing downtime or not according to environment configuration.
If a revision includes Scheduler jobs:
Solution Manager launches a new instance using the latest image for the Scheduler cluster.
Once the new Scheduler server is up and running, the included jobs will be created (for CREATE revisions) or removed (for DROP revisions). When deploying CREATE revisions, the Scheduler jobs are executed if they were marked for execution in the revision.
The Scheduler cluster is recreated using the new Scheduler server as reference, minimizing downtime or not according to environment configuration.
If any of the deployed revisions contained VQL changes and the environment has Data Catalog server synchronization configured, the corresponding Data Catalog servers metadata will be synchronized according to the provided configuration.
If the execution of VQL or the import of Scheduler tasks fails, the deployment fails. If this happens, the corresponding product cluster is not modified and the new cloud server where the changes were performed is terminated.
The next picture summarizes the basic steps of a generic deployment process in a cloud environment with all the types of servers involved:
Remember that in order to deploy one or more revisions you have to use the or buttons from the Revisions table.
The deployment preconditions are the same as in standard environments.
Cloud Deployments Options¶
The Solution Manager offers the option to minimize downtime while performing a deployment process in cloud environments in the deployments configuration of the environment. This option affects to the way the cluster is recreated after performing the revisions changes. The differences are explained in the following sections.
Perform Changes Directly in Servers Deployment¶
The following diagram summarizes the main steps of a Perform changes directly in the servers deployment.
This option is usually the fastest one but the capacity of the cluster may be affected during the deployment and changes may need to be rolled back manually if something goes wrong (automatic rollbacks are only available with this option since the update 8.0u20230301).
Without Minimizing Downtime¶
The following diagram summarizes the main steps in the cluster recreation process in a deployment process with minimize downtime option disabled.
With this approach there is no service since old servers are terminated until new servers are ready and they fullfill the load balancer health checks.
The following diagram summarizes the main steps of a minimum downtime cluster recreation process in a deployment process.
Using this option the application service is available during the deployment process, with minimum downtime. However, there may be some inconsistencies during the cluster recreation, since servers with old and new versions of the metadata can provide service at the same time. This can happen once new servers are ready for service, while old servers are terminated and they might be processing some requests.
We recommend to use this option for deployments.
Check the cache considerations in the considerations for deployments section.