Clone Services, Audit Logs Addition, Terraform Exporter...
Hi everyone, and welcome to Changelog 36! 🌞 With two new additions to the teams, Camille in frontend and Pierre in the backend, our team velocity is now even faster during those summer months; we will talk Terraform and Audit Logs additions, Clone services, Kube upgrade, and much more, so let’s get started!
We've enhanced the environment duplication feature to allow you to duplicate individual services to other environments. This will allow you to copy the configuration of a service and avoid rewriting everything from scratch while you just need to change the repository (especially on mono-repository setups).
Check our documentation for more information.
Following the last changelog, where we introduced Audit Logs, allowing you to monitor all actions within your organization, we've added more capabilities. Now, you can filter the logs by target, giving you more granular control over monitoring and auditing. Additionally, we've introduced a quick filter option directly from the service and environment pages, making it easier to access relevant information.
We've been working hard on our Terraform Provider to match the interface's quality. Good news! You can now export your configuration as a Terraform file using the Qovery provider. Set up your entire configuration on the Qovery console and then export everything to manage your setup via Terraform. This powerful feature simplifies infrastructure management and provides a ClickOps approach to speed up the provisioning of infrastructure via IAC and avoid the tedious writing of long HCL files.
Here is a small demo showing you how you can export your Qovery configuration into Terraform:
We have included the ability to manage advanced settings directly from our Terraform provider. With the latest version (0.18.0) of the provider, you can fine-tune various aspects of your applications, gaining more control over the deployment process and much more.
As shared in our product roadmap, we have been working on improving the naming of resources deployed on your Kubernetes cluster, adding the environment and service name in the naming convention instead of just our own internal IDs.
As an example, the namespace name will change from:
- z<qovery_project_id-z<qovery_environment_id> (Example: zfd999c59-z31bd7e07)to:
- env-z<qovery_environment_id>-<sanitizied_env_name> Where <sanitizied_env_name> is a cleaned version of the environment name that you chose on the Qovery platform (Example: env-z2843c942-front-end)
This change brings greater clarity and consistency to your Kubernetes resources, making them easier to manage.
Please note that this naming convention applies only to new environments or services created on your Qovery organization. Existing environments and services will retain their current naming to avoid any disruption to ongoing services. This approach ensures a seamless transition while still benefiting from the new naming convention in future deployments.
We are excited to announce the release of support for gRPC, TCP and UDP protocols. You can now use these protocols to expose your applications publicly, providing more flexibility in how you handle network communication. This update enables you to support a wider range of networking scenarios, such as real-time applications and multiplayer games, making Qovery even more versatile for your needs. Here is the link to the documentation for more information.
As mentioned in our roadmap, we have been diligently preparing the necessary updates to migrate your Kubernetes cluster from the current version (1.23) to version 1.26. We are pleased to inform you that the team has completed the upgrades to version 1.26!
If you have any questions, please feel free to comment directly within this thread!
We've added the capability to change the database version. Please note that while you can select a lower DB version, it is intended primarily for edge cases to roll back failed upgrades.
For more information, check out our documentation!