Merge pull request #528 from Qovery/chore_add_info_registry

chore: add more info on mirroring registry behaviour and TTL

website/docs/using-qovery/configuration/clusters.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2025-02-22"
+last_modified_on: "2025-02-25"
 title: "Clusters"
 description: "Learn how to configure your Kubernetes clusters on Qovery"
 sidebar_label: hidden
@@ -385,12 +385,18 @@ Security is our main concern. When a vulnerability is found, here are the action
 3. We transparently communicate with our customers about the vulnerability to help them take the right actions.
 
 
+### What is a mirroring registry?
+
+It's the registry used by Qovery to push the image built by the Qovery CI or mirror the images that you want to deploy from your own registry. Check [this documentation][docs.using-qovery.deployment.image-mirroring] for more information
+
+
 [docs.getting-started.basic-concepts#cluster]: /docs/getting-started/basic-concepts/#cluster
 [docs.getting-started.install-qovery.kubernetes]: /docs/getting-started/install-qovery/kubernetes/
 [docs.using-qovery.configuration.clusters#deleting-a-cluster]: /docs/using-qovery/configuration/clusters/#deleting-a-cluster
 [docs.using-qovery.configuration.clusters#logs]: /docs/using-qovery/configuration/clusters/#logs
 [docs.using-qovery.configuration.clusters#restarting-a-cluster]: /docs/using-qovery/configuration/clusters/#restarting-a-cluster
 [docs.using-qovery.configuration.clusters#stopping-a-cluster]: /docs/using-qovery/configuration/clusters/#stopping-a-cluster
 [docs.using-qovery.configuration.clusters#updating-a-cluster]: /docs/using-qovery/configuration/clusters/#updating-a-cluster
+[docs.using-qovery.deployment.image-mirroring]: /docs/using-qovery/deployment/image-mirroring/
 [docs.using-qovery.troubleshoot.cluster-troubleshoot]: /docs/using-qovery/troubleshoot/cluster-troubleshoot/
 [urls.qovery_console]: https://console.qovery.com

website/docs/using-qovery/configuration/clusters.md.erb

@@ -372,3 +372,8 @@ Security is our main concern. When a vulnerability is found, here are the action
 1. We quickly identify how significant is the impact of the vulnerability.
 2. We look at how we can solve or mitigate the vulnerability.
 3. We transparently communicate with our customers about the vulnerability to help them take the right actions.
+
+
+### What is a mirroring registry?
+
+It's the registry used by Qovery to push the image built by the Qovery CI or mirror the images that you want to deploy from your own registry. Check [this documentation][docs.using-qovery.deployment.image-mirroring] for more information

website/docs/using-qovery/deployment/deployment-pipeline.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-10-15"
+last_modified_on: "2025-02-25"
 title: "Deployment Pipeline"
 description: "Learn how to the Environment Deployment Pipeline works"
 ---
@@ -48,7 +48,7 @@ The Building process is managed by the Qovery CI which downloads your repository
 
 The build operation of each service within a deployment stage is executed in parallel with a parallism of 7. 
 
-Once the operation is completed, the built image is pushed in the `mirroring registry` for deployment ([check here][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-deployment-pipeline] for more information).
+Once the operation is completed, the built image is pushed in the `mirroring registry` for deployment ([check here][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-ci] for more information).
 
 Check [this section](#best-practices-to-speed-up-build-time) to know more on how to reduce the build time of your application.
 
@@ -120,7 +120,7 @@ Try to put on the same deployment stage as many apps as you can, making sure the
 
 #### Multi-stage deployment on the same environment
 
-If within the same environment you have multiple applications using the same git repository and build context, you can benefit from the image caching mechanism provided by the [mirriring registry][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-deployment-pipeline] by:
+If within the same environment you have multiple applications using the same git repository and build context, you can benefit from the image caching mechanism provided by the [mirriring registry][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-ci] by:
 
 1. having one application X on a stage A. This is the one that will be built each time
 2. having all the other application on other stages as long as they are after the stage A. For all these applications the build phase will be skipped since the image has already been built from application X
@@ -153,6 +153,6 @@ As you can see, every deployment is independent and the build choice is only bas
 
 [docs.using-qovery.configuration.environment#deployment-pipeline]: /docs/using-qovery/configuration/environment/#deployment-pipeline
 [docs.using-qovery.configuration.environment]: /docs/using-qovery/configuration/environment/
-[docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-deployment-pipeline]: /docs/using-qovery/deployment/image-mirroring/#application-built-via-the-qovery-deployment-pipeline
+[docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-ci]: /docs/using-qovery/deployment/image-mirroring/#application-built-via-the-qovery-ci
 [docs.using-qovery.deployment.image-mirroring]: /docs/using-qovery/deployment/image-mirroring/
 [docs.using-qovery.integration.continuous-integration]: /docs/using-qovery/integration/continuous-integration/

website/docs/using-qovery/deployment/deployment-pipeline.md.erb

@@ -39,7 +39,7 @@ The Building process is managed by the Qovery CI which downloads your repository
 
 The build operation of each service within a deployment stage is executed in parallel with a parallism of 7. 
 
-Once the operation is completed, the built image is pushed in the `mirroring registry` for deployment ([check here][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-deployment-pipeline] for more information).
+Once the operation is completed, the built image is pushed in the `mirroring registry` for deployment ([check here][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-ci] for more information).
 
 Check [this section](#best-practices-to-speed-up-build-time) to know more on how to reduce the build time of your application.
 
@@ -111,7 +111,7 @@ Try to put on the same deployment stage as many apps as you can, making sure the
 
 #### Multi-stage deployment on the same environment
 
-If within the same environment you have multiple applications using the same git repository and build context, you can benefit from the image caching mechanism provided by the [mirriring registry][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-deployment-pipeline] by:
+If within the same environment you have multiple applications using the same git repository and build context, you can benefit from the image caching mechanism provided by the [mirriring registry][docs.using-qovery.deployment.image-mirroring#application-built-via-the-qovery-ci] by:
 
 1. having one application X on a stage A. This is the one that will be built each time
 2. having all the other application on other stages as long as they are after the stage A. For all these applications the build phase will be skipped since the image has already been built from application X

website/docs/using-qovery/deployment/image-mirroring.md

@@ -1,23 +1,27 @@
 ---
-last_modified_on: "2025-01-15"
+last_modified_on: "2025-02-25"
 title: "Image Mirroring"
 description: "Learn how images are mirrored within your cloud account"
 ---
 import Jump from '@site/src/components/Jump';
 import Alert from '@site/src/components/Alert';
 import Assumptions from '@site/src/components/Assumptions';
 
-When Qovery is running on your infrastructure, it requires an image registry to store the images built via the Qovery CI and to mirror the images deployed from a 3rd party container registry.
+When Qovery is running on your infrastructure, it requires an image registry on your cloud account to store the images built via the Qovery CI or to mirror the images deployed from a 3rd party container registry.
 
-This `mirroring registry` is available and configurable within the Qovery interface within the `Image registry` section of your cluster.
+This process allows to:
+1. speed up the deployment process by avoiding to re-build every time the application image from scratch
+2. speed up and secure the scale up operation of your application since it doesn't need to pull the image from the source registry every time a new instance of the application is needed.
+
+This `mirroring registry` is available and configurable within the Qovery interface within the `Mirroring registry` section of your cluster.
 
 <p align="center">
   <img src="/img/deployment/mirror-registry.png" alt="Mirroring Repository" />
 </p>
 
 # How does it work
 
-Every time an application needs to be deployed on your cluster, the deployed image is picked from the `mirroring registry`. How the image is pushed on the `mirroring registry` it depends if you build the application with the Qovery Deployment Pipeline or not.
+Every time an application needs to be deployed on your cluster, the deployed image is picked from the `mirroring registry`. How the image is pushed on the `mirroring registry` it depends if you build the application with the Qovery CI or not.
 
 <!--
      THIS FILE IS AUTOGENERATED!
@@ -27,9 +31,9 @@ Every time an application needs to be deployed on your cluster, the deployed ima
      website/docs/using-qovery/deployment/image-mirroring.md.erb
 -->
 
-## Application built via the Qovery Deployment Pipeline
+## Application built via the Qovery CI
 
-Images built by Qovery are organized in the mirroring registry by "Git repository", meaning that the image built on services having the same git repsitory will be pushed in the same repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider).
+At the end of the build process, the Qovery CI push the generated image into your mirroring registry. The images pushed here are organized by "Git repository", meaning that the image built on services having the same git repsitory will be pushed in the same repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider).
 
 The tag assigned to the built image is based on the following elements (build context): commit ID, repository root path, Dockerfile path, Dockerfile content, and ARGS environment variables (present in the dockerfile). This ensures that each service's build and mirroring process is completely isolated from others.
 
@@ -43,11 +47,11 @@ Otherwise, the image is built by the Qovery pipeline the resulting image is push
   <img src="/img/deployment/build-mirror.png" alt="Mirroring built image" />
 </p>
 
-Once an application is deleted, if no other application is using the same image name and tag, the image is deleted from the mirroring registry.
+Once an application is deleted, if no other application is using the same image name and tag, the image is deleted from the mirroring registry. If the image is still used by another application, it will not be deleted until the lifecycle TTL is reached (see [this section][#image-retention-policy]).
 
 In order to speed up the image build, we are using the mirroring registry as a remote cache (available in AWS, GCP and Scaleway). It will avoid building the image from scratch, only the layers that changed will be built.
 
-Check out the Best practices section below to know some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.
+Check out the best practices section below to know some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.
 
 
 ## Application deployed from a container registry
@@ -71,7 +75,7 @@ Otherwise, the image is pulled from the source registry and pushed on the mirror
 
 
 Pro:
-- Images are automatically deleted when not needede anymore
+- Images are automatically deleted when not needed anymore
 
 Cons:
 - If the same image is used across environments or service, Qovery will mirror multiple time the same image, reducing the deployment speed
@@ -134,4 +138,11 @@ Let's say you have a container image called `nginx` that you build on your CI an
 You can push this image on the mirroring registry within the repository `nginx`, avoiding the mirroring operation: https://32432542.dkr.ecr.eu-west-3.amazonaws.com/nginx
 
 
+## Image retention policy
+
+Depending on the cloud provider, you can define how long an image should be kept in your registry via a TTL (Time To Live). You can configure the TTL via the advanced settings [image_retention_time][docs.using-qovery.configuration.cluster-advanced-settings#image-registry]
+
+Please keep in mind that changing this settings will only affect new ECR repositories created after the change. Existing repositories will not be affected.
+
+
 [docs.using-qovery.configuration.cluster-advanced-settings#image-registry]: /docs/using-qovery/configuration/cluster-advanced-settings/#image-registry

website/docs/using-qovery/deployment/image-mirroring.md.erb

@@ -6,21 +6,25 @@ import Jump from '@site/src/components/Jump';
 import Alert from '@site/src/components/Alert';
 import Assumptions from '@site/src/components/Assumptions';
 
-When Qovery is running on your infrastructure, it requires an image registry to store the images built via the Qovery CI and to mirror the images deployed from a 3rd party container registry.
+When Qovery is running on your infrastructure, it requires an image registry on your cloud account to store the images built via the Qovery CI or to mirror the images deployed from a 3rd party container registry.
 
-This `mirroring registry` is available and configurable within the Qovery interface within the `Image registry` section of your cluster.
+This process allows to:
+1. speed up the deployment process by avoiding to re-build every time the application image from scratch
+2. speed up and secure the scale up operation of your application since it doesn't need to pull the image from the source registry every time a new instance of the application is needed.
+
+This `mirroring registry` is available and configurable within the Qovery interface within the `Mirroring registry` section of your cluster.
 
 <p align="center">
   <img src="/img/deployment/mirror-registry.png" alt="Mirroring Repository" />
 </p>
 
 # How does it work
 
-Every time an application needs to be deployed on your cluster, the deployed image is picked from the `mirroring registry`. How the image is pushed on the `mirroring registry` it depends if you build the application with the Qovery Deployment Pipeline or not.
+Every time an application needs to be deployed on your cluster, the deployed image is picked from the `mirroring registry`. How the image is pushed on the `mirroring registry` it depends if you build the application with the Qovery CI or not.
 
-## Application built via the Qovery Deployment Pipeline
+## Application built via the Qovery CI
 
-Images built by Qovery are organized in the mirroring registry by "Git repository", meaning that the image built on services having the same git repsitory will be pushed in the same repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider).
+At the end of the build process, the Qovery CI push the generated image into your mirroring registry. The images pushed here are organized by "Git repository", meaning that the image built on services having the same git repsitory will be pushed in the same repository, named z<short_cluster_id>-git_repo_name (or namespace, depending on the cloud provider).
 
 The tag assigned to the built image is based on the following elements (build context): commit ID, repository root path, Dockerfile path, Dockerfile content, and ARGS environment variables (present in the dockerfile). This ensures that each service's build and mirroring process is completely isolated from others.
 
@@ -34,11 +38,11 @@ Otherwise, the image is built by the Qovery pipeline the resulting image is push
   <img src="/img/deployment/build-mirror.png" alt="Mirroring built image" />
 </p>
 
-Once an application is deleted, if no other application is using the same image name and tag, the image is deleted from the mirroring registry.
+Once an application is deleted, if no other application is using the same image name and tag, the image is deleted from the mirroring registry. If the image is still used by another application, it will not be deleted until the lifecycle TTL is reached (see [this section][#image-retention-policy]).
 
 In order to speed up the image build, we are using the mirroring registry as a remote cache (available in AWS, GCP and Scaleway). It will avoid building the image from scratch, only the layers that changed will be built.
 
-Check out the Best practices section below to know some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.
+Check out the best practices section below to know some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.
 
 
 ## Application deployed from a container registry
@@ -62,7 +66,7 @@ Otherwise, the image is pulled from the source registry and pushed on the mirror
 
 
 Pro:
-- Images are automatically deleted when not needede anymore
+- Images are automatically deleted when not needed anymore
 
 Cons:
 - If the same image is used across environments or service, Qovery will mirror multiple time the same image, reducing the deployment speed
@@ -123,3 +127,10 @@ Example: if the source registry is `https://xxx.dkr.ecr.us-west-2.amazonaws.com`
 Let's say you have a container image called `nginx` that you build on your CI and the container registry associated with your cluster is https://32432542.dkr.ecr.eu-west-3.amazonaws.com. 
 
 You can push this image on the mirroring registry within the repository `nginx`, avoiding the mirroring operation: https://32432542.dkr.ecr.eu-west-3.amazonaws.com/nginx
+
+
+## Image retention policy
+
+Depending on the cloud provider, you can define how long an image should be kept in your registry via a TTL (Time To Live). You can configure the TTL via the advanced settings [image_retention_time][docs.using-qovery.configuration.cluster-advanced-settings#image-registry]
+
+Please keep in mind that changing this settings will only affect new ECR repositories created after the change. Existing repositories will not be affected.