Deployment Actions
Qovery allows you to manage the deployment lifecycle of your services and environments via a set of Deployment actions
(example: deploy, redeploy, restart, stop etc..). These actions can be triggered via the Qovery web console, via the Qovery API, via the Qovery CLI or from your CI/CD depending on your integration type.
You can imagine the deployment lifecycle of a service or environment like a state machine:
- each state is identified by a
Deployment Status
- the execution of a deployment action will modify the state of the service/environment until it reaches a final status (ok or error)
- the list of allowed
Deployment action
depends on the currentDeployment Status
. Example: if the deployment status isDeployment Ok
, you can trigger only the actionStop
. This will stop the execution of the service (deployment statusStopped
).
Example:
When a new application is created within Qovery, the application will have the deployment status Ready
. Once the action Deploy
is executed on the service, the service will go through the statuses Queued
, Building
, Deploying
and then finally on the status Deployed
(meaning that the application is correctly deployed). At this point, you can trigger only the action Stop
(This will stop the execution of the service, moving the application to the deployment status Stopped
).
You can find the status of the last deployment directly in the Qovery console in the service or environment list:
Note that the deployment status of the environment is built based on the deployment statuses of each service within it.
You can decide to execute a deployment action on:
1. an environment: via the Play
button at environment level, the action will be executed on each service within the environment. To know more about the deployment order of your services, have a look at the Deployment Pipeline
2. a single service: via the Play
button at service level, the action will be executed only on the selected service.
3. a subset of services: selecting one or more services from the service list and using the floating action button.
Note that all the deployment actions are available via any interface described within this section.
Deployment Actions
You can find below a description of each deployment action, including its purpose and the deployment status your environment and/or service will go through.
Deploy
The Deploy
action allows you to create the resource necessary to run your code on your Kubernetes cluster. This action is available only if the service or environment have never been deployed.
Based on the configuration of your services within, a certain number of Pods will be created in a dedicated Namespace of the target Kubernetes cluster.
Once triggered, the deployment of a service goes through the following deployment statuses:
- QUEUED : the deployment has been queued and it is waiting for the necessary resources to be allocated to manage your request
- BUILDING : the Qovery engine is downloading the git repository and building your code. At the end of this step an image is built and pushed to a registry available on your cloud account. The status will become BUILD ERROR in case of issues on building your code
- DEPLOYING : the pods are being created on your cluster based on the image built on the previous step. The status will become DEPLOYMENT ERROR in case of issues on deploying your service. A service is considered un-healthy if the Kubernetes readiness probe check is never OK (more info on readiness probe).
- DEPLOYMENT OK : all the requested pods have been created and the service is correctly running (liveness and readiness probes are ok).
If the deployment was triggered on the entire environment, the environment will go through the following deployment statuses:
- QUEUED : at least one service is in status QUEUED
- BUILDING : at least one service is in status BUILDING
- DEPLOYING : at least one service is in status DEPLOYING
- DEPLOYMENT OK : at least one service is in status DEPLOYMENT OK but none of them is in error (BUILD ERROR or DEPLOYMENT ERROR)
- DEPLOYMENT ERROR : at least one service is in status DEPLOYMENT ERROR
Redeploy
The Redeploy
action allows you to update the remote configuration of your services based on their configuration on Qovery side. If any difference exists (vCPU, number of instances, code version etc..), a new set of pod will be created with the new configuration and replace the existing ones. If there are no configuration differences, nothing will happen on the pods running on your cluster (not even a restart, please use the Restart Service feature).
This action is available only if the Deploy
action has been triggered at least once on the service or environment.
When replacing the pods of your application, Qovery uses the rolling-restart deployment logic:
1) Deploy new version of instance #1.
2) New version of instance #1 is running => kill previous version of instance #1.
3) Deploy new version of instance #2.
4) New version of instance #2 is running => kill previous version of instance #2.
And so on...
You can trigger the re-deployment of a service or of the entire environment. The service or environment goes through the same deployment statuses described in the deployment section.
Stop
The Stop
action allows you to stop the execution on the cluster of the selected service or environment (deployment status = Stopped). This action is available only if the current deployment status is Deployment OK
or Deployment Error
.
The effect on your cluster of the stop operation is different depending on the type of service:
- Application, Container, Container DB : Pods of those services are stopped. Any attached storage is preserved
- Cloud provider Managed DB: the database is paused (only for AWS, not working on Redis)
Restart Service
The Restart Service
action allows you to restart the pods of your service without applying any configuration change. This action is available only if the current deployment status is Deployment OK
and only for a single service.
Once triggered, the deployment status service goes through the following statuses:
- RESTARTING : the request to restart has been received
- RESTARTED : all the pods of the service have been restarted
- RESTART ERROR : Qovery couldn't process the restart request
Cancel Deployment
The Cancel Deployment
action allows you to abort any Deploy
or Redeploy
action and stop the execution of the deployment pipeline. This action is available only if the current deployment status is Queued
or Building
or Deploying
.
If a deployment of a service A is already ongoing, the cancel operation will stop the deployment execution and rollback the service A to the previous version. Any service already deployed during the pipeline execution will not rollback to the previous version.
For Lifecycle Jobs, the cancel operation is not taken into account unless it is forced
via the checkbox available in the "Deployment cancel" modal.
Deploy other version
The Deploy other version
action allows you to deploy a different version for your service. This action is available no matter the deployment status of the service.
Once you click on the action, this panel will appear, and you will be able to choose the version you wish to update/rollback (either git commit or image Tag).
By pressing on the Deploy button, a deployment of the service will be triggered using the selected version.
Deploy latest version
The Deploy latest version
action allows you to deploy the latest version for any of your services within the environment. This action is available no matter the deployment status of the service and only at environment level
Once you click on the action, this panel will appear, and you will be able to choose the services you wish to update to the latest version (only for services with source = git repository).
By pressing on the Deploy button, a deployment of the service will be triggered using the selected version.