Terraform Provider Enhancements, Performance Analysis Tool, Deployment Restrictions...
Romaric Philogène
CEO and co-founder of Qovery. Romaric has 10+ years of experience in R&D. From the Ad-Tech to the financial industry, he has deep expertise in highly-reliable and performant systems.
See all articlesIt's changelog #38, and I'm thrilled to bring you a plethora of updates that have been under the works for the past two weeks. These enhancements aim to make your experience with Qovery smoother, more secure, and more efficient.
#Terraform Provider Enhancements
We know how crucial Infrastructure as Code (IaC) is for managing and provisioning your tech stack, so we’ve made some key additions to our Terraform provider. You can now add aliases and overrides directly to your Terraform configurations. This means greater flexibility and more control in defining your resources.
...
environment_variable_aliases = [
{
key = "ENV_VAR_KEY_ALIAS"
# the value of the alias must be the name of the aliased variable
# e.g here it is an alias to the above declared environment variable "ENV_VAR_KEY"
value = "ENV_VAR_KEY"
}
]
environment_variable_overrides = [
{
# the key of the override must be the name of the overridden variable
# e.g here it is an override on a variable declared at project scope "SOME_PROJECT_VARIABLE"
key = "SOME_PROJECT_VARIABLE"
value = "OVERRIDDEN_VALUE"
}
]
secret_aliases = [
{
key = "SECRET_KEY_ALIAS"
# the value of the alias must be the name of the aliased secret
# e.g here it is an alias to the above declared secret "SECRET_KEY"
value = "SECRET_KEY"
}
]
secret_overrides = [
{
# the key of the override must be the name of the overridden secret
# e.g here it is an override on a secret declared at project scope "SOME_PROJECT_SECRET"
key = "SOME_PROJECT_SECRET"
value = "OVERRIDDEN_VALUE"
}
]
...Additionally, we've added the ability to assign custom domains to your containers.
...
custom_domains = [
{
domain = "example.com"
}
]
...Perhaps the most exciting update here is the auto-trigger for cluster re-deployment. Now, whenever you change cluster settings, the system will automatically initiate a re-deploy, saving you the manual effort and ensuring your configurations are always up-to-date.
#New User Settings Section
In response to growing demand, we've introduced a new User Settings section. Located under the organization navigation, this feature currently allows you to change your "communication email."
We highly recommend setting up your communication email (no spam) - to receive Qovery latest updates and product notifications.
#Deployment Restrictions Now in UI
Previously, you could only configure deployment restrictions through our API. Now, you can conveniently set them right from the User Interface under your app settings.
This feature is extremely beneficial when you are using mono-repositories only to retrigger your app on specific changes. Or even for conventional apps - let's say you don't want to redeploy your app if your README has changed - you can add a rule to exclude the file from deployment. Watch my quick demo video for more details.
#Websockets in Front-End
We've listened to your feedback about the performance issues caused by the repetitive pulling of information. To address this, most of our front-end code has now been migrated to use WebSockets. This is a crucial step toward real-time data transmission, reducing latency, and improving the overall performance of your apps on Qovery.
#Enhanced Service Status Information
The service status endpoint now offers additional valuable information, including the last container error and the status of your certificates. This enhancement will soon be reflected in the front-end, giving you a more comprehensive view of your service status and helping you troubleshoot more efficiently.
#RBAC-Compliant Audit Logs
Security is a top priority for us, and in line with this, we have updated our audit logs to be Role-Based Access Control (RBAC) compliant. Now, you will only see events in the audit logs for resources you have read rights to. This not only enhances security but also makes the logs more relevant to each user.
#Deployment Performance Analysis
Last but certainly not least, you can now analyze your deployment performance using the qovery environment deployment explain command.
~ $ qovery environment deployment explain --level step --id fae5c3aa-ae74-4560-b988-9f029a726533-1 --environment pr-234-preview-env
.
└── Environment: pr-234-preview-env [duration: 14 minutes and 58 seconds]
├── Stage 1: Databases [duration: 5 minutes and 31 seconds]
│ ├── Terraform RDS [duration: 4 minutes and 55 seconds]
│ │ ├── Step 1: Build [duration: 37 seconds]
│ │ └── Step 2: Deploy [duration: 4 minutes and 6 seconds]
│ ├── DB [duration: 1 minute and 13 seconds]
│ │ └── Step 1: Deploy [duration: 1 minute and 11 seconds]
│ ├── Redis [duration: 1 minute and 22 seconds]
│ │ └── Step 1: Deploy [duration: 1 minute and 22 seconds]
│ ├── My DB [duration: 1 minute and 22 seconds]
│ │ └── Step 1: Deploy [duration: 1 minute and 22 seconds]
│ └── SQS [duration: 3 minutes and 11 seconds]
│ ├── Step 1: Deploy [duration: 3 minutes and 11 seconds]
│ └── Step 2: Deployed [duration: 1 minute and 44 seconds]
├── Stage 2: Migration and Seed [duration: 1 minute and 18 seconds]
│ └── DB Seed Script [duration: 1 minute and 13 seconds]
│ ├── Step 1: Build [duration: 30 seconds]
│ └── Step 2: Deploy [duration: 21 seconds]
├── Stage 3: Backends [duration: 4 minutes and 42 seconds]
│ ├── DB Sync Cron [duration: 1 minute and 42 seconds]
│ │ ├── Step 1: Build [duration: 22 seconds]
│ │ └── Step 2: Deploy [duration: 10 seconds]
│ ├── Core Backend [duration: 4 minutes and 37 seconds]
│ │ ├── Step 1: Build [duration: 1 minute and 12 seconds]
│ │ ├── Step 2: Deploy [duration: 3 minutes and 18 seconds]
│ │ └── Step 3: Deployed [duration: 2 minutes and 21 seconds]
│ ├── Lambda [duration: 4 minutes and 23 seconds]
│ │ ├── Step 1: Build [duration: 1 minute and 2 seconds]
│ │ └── Step 2: Deploy [duration: 2 minutes and 46 seconds]
│ └── Backend [duration: 4 minutes and 37 seconds]
│ ├── Step 1: Build [duration: 1 minute and 15 seconds]
│ ├── Step 2: Deploy [duration: 3 minutes and 18 seconds]
│ └── Step 3: Deployed [duration: 1 minute and 52 seconds]
├── Stage 4: Gateways [duration: 53 seconds]
│ └── API Gateway [duration: 50 seconds]
│ ├── Step 1: Build [duration: 22 seconds]
│ ├── Step 2: Deploy [duration: 25 seconds]
│ └── Step 3: Deployed [duration: 9 seconds]
└── Stage 5: Frontends [duration: 2 minutes and 18 seconds]
├── Frontend [duration: 2 minutes and 13 seconds]
│ ├── Step 1: Build [duration: 1 minute and 16 seconds]
│ └── Step 2: Deploy [duration: 52 seconds]
└── Dashboard [duration: 0 seconds]
└── Step 1: Deploy [duration: 0 seconds]This is invaluable for identifying bottlenecks in your deployment pipeline and optimizing accordingly. Knowing where your deployment is taking most of its time means you can make targeted improvements, thereby speeding up your delivery process.
#Minor Updates
While the major changes steal the spotlight, we've also made some smaller yet significant tweaks. Audit logs now have clickable targets, and we've fine-tuned the behavior of the nginx button in the live logs.
Thank you for being an invaluable part of our journey to make cloud application deployment as seamless as possible. Your feedback drives us, so please keep it coming.