Deployment Pipeline, Update on our Single EC2 K3s offer (AKA Qovery EC2), Cluster Advanced Settings - Interface V3...

Hi 👋🏻 and welcome to Changelog 29 where we have exciting updates to share with you!

We're thrilled to announce that our Deployment Pipeline feature is now available globally, giving you more control over your deployment order. We've also been working hard to improve the stability of our Single EC2 K3s offer, and we're happy to announce that a new version is now available. We've introduced Cluster Advanced Settings through the V3 interface, which allows you to fine-tune your Qovery infrastructure even further. Want to know more? Keep reading!

#Deployment Pipeline

I am excited to announce that our Deployment Pipeline feature is available globally now!

When an environment’s deployment is triggered, Qovery executes what we call the Deployment Pipeline. It defines which operation shall be performed to properly deploy every service defined within your environment (build, deploy, etc.)

A pipeline is composed of an ordered list of Deployment Stages. Each Stage has an execution order assigned within the pipeline: If stage A has an execution order lower than stage B, then B can be executed only if the execution of stage A is completed.

To learn more about it, check out our documentation!

Below you can find a visual example of how the pipeline looks like:

#Manage your Deployment Order with Qovery Deployment Pipeline

The Deployment Pipeline feature opens the door to many exciting news as we also make it possible to manage your deployment orders. In this forum thread, we went through every step of the process, and if you want to see how it looks in the interface, here is a sneak peek.

#Update on our Single EC2 K3s offer (AKA Qovery EC2)

As you may know, we have been offering the choice to use two types of Kubernetes clusters to deploy your applications on AWS:

• a fully managed EKS cluster
• a single EC2 running a K3s cluster (also known as Qovery Single EC2)

The “Single EC2” has been in beta for a few months, and we have been recently working on a few fixes to make it stable and get it out of the Beta program.

The new version, available on any new “Single EC2” created since 24/02/2023, avoids any data loss while upgrading/updating the cluster configuration, making it easier to maintain the cluster in the future.

What will happen to the existing Qovery EC2 instances:

The new version is NOT retro-compatible, and a migration is required; here are the steps you will need to follow alongside extra information about it.

#Cluster Advanced Settings - Interface V3

In the previous changelog, I announced that the Cluster Advanced Settings were available through the Qovery API endpoint. If that’s not your thing, I have the pleasure of announcing that it’s also available straight from the V3 interface so that you can fine-tune your Qovery infrastructure further! Here is the documentation for the Cluster Advanced Settings.

#Cluster Advanced Settings Additions - Database

Because releasing the Cluster Advanced Settings on the interface was not enough, we also have some brand new additions that are useful for SOC2 compliance. For example, it allows for restricting database availability to specific subnets and/or the public at a higher level (cluster).

Here is the documentation about it

#Migration of 1.23 Cluster

Each cloud provider has a limited number of supported Kubernetes versions, if you were to use Kubernetes without Qovery, you would have to do the upgrades yourself, but one of the benefits of using Qovery is that we manage it for you!

A few months ago, I told you about our migration to 1.22, and it was now time to move to 1.23; if you want to know the whole timeline, here is the forum thread about it.

#Smaller Improvements and Fixes

• Support Git LFS (up to 5Gb of data)
• [Terraform] Fix container documentation