Architecture
Architecture
DeployHub Pro includes an agentless internal deployment engine that can be used to run deployments. The deployment engine is installed locally or from the SaaS offering via a reverse proxy. The internal engine connects to repositories, Continuous Delivery (CI/CD) pipelines, DevOps tools, data sources, transfer protocols and notification tools. With our open architecture, you plug-in the tool-set you use to define your release configurations.
For deploying Application versions, an agentless architecture supports both a decoupled architecture of containers as well as legacy systems. If you use solutions like Helm to update your cluster, great, we can call those external solutions to perform the updates and provide all the deployment configuration mapping and version information. DeployHub Pro also has plug-ins to continuous delivery pipelines that supports continuous configuration management as part of your release process.
Reverse Proxy and SaaS
As a SaaS customer, a ‘one-way’ reverse proxy is used on your side of the firewall. The proxy send requests for deployments every 60 seconds.
Deployments with Custom Actions
DeployHub Pro integrates with external deployment solutions such as Helm to perform the actual movement of containers to a cluster. When a Custom Action is used, the internal deployment engine is bypassed. This is the easiest way to perform an update to your cluster.
DeployHub Pro performs all deployments in an Agentless mode. No remote agents need be installed on the target Endpoint to execute deployments.
A DropZone is created for each Component during a deployment. Files from the Component are placed into the DropZone. After the Component has been processed, the files within the DropZone are deployed to the Endpoints within the selected Environment. The DropZone is then deleted. Another DropZone is created for the next Component, until all Components have been deployed for the Application. The next Application version is deployed, and the process starts all over again.
DeployHub Pro uses ftp, ftps, sftp, or Windows protocol to transfer files. When a deployment is executed, DeployHub Pro performs the following steps:
The first Application is moved onto the stack. Any Pre-Action for the Application will be executed at this point.
| Step | Description |
|---|---|
| 1 | The first Component is moved onto the stack. |
| 2 | A DropZone is created for the Component. |
| 3 | The first Component is processed. It references specific files from the Repository and these are placed into the DropZone. |
| 4 | If needed, A Pre Action for the Component is performed within the DropZone before deployment. |
| 5 | The DropZone files are placed into every Endpoint within the Environment where the Endpoint type is the same as the Component type. Keep in mind that a Component can have only one type and an Endpoint can have many types. |
| 6 | A Post-Action for the Component is performed for cleanup or additional manipulation of files. It is run against every Endpoint with the same Component Type as the Component. |
| 7 | If there are more Components, steps 2 through 7 are performed again after a new DropZone is created. |
| 8 | Pre and Post processing Actions defined in the Application or Release are performed on each of the target Endpoints in the Environments. Any errors found at the delivery level are logged and may fail the deployment. All logs are reported back to DeployHub Pro and recorded in the Logs section for each Application or Release. |
The following diagram shows how the deployment process works:
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.