@@ -80,3 +95,48 @@ This default assignment is maintained as long as you do not delete or rename the
You can access and modify the pipeline configuration from the environment settings. Have a look at [this section][docs.using-qovery.configuration.environment#deployment-pipeline] to know more.
+## Best practices to speed up build time
+
+Here you can find some best practices you can follow to ensure you benefit from all the caching system and reduce the build time.
+
+### Review your Dockerfile structure
+
+Review the content of your Dockerfile to find performance improvements. There's a list of suggestion on the [Docker website](https://docs.docker.com/build/building/best-practices), feel free to ask for help on [our forum](https://discuss.qovery.com/)
+
+### Benefit from the build and deployment parallelism
+
+Try to put on the same deployment stage as many apps as you can, making sure there is no dependency between them. It will allow you to benefit from the parallel build and deployment.
+
+### Update your Qovery configuration based on your application repository structure
+
+#### 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:
+
+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
+
+
+#### Managing Preview environments
+
+No real configuration change is required here to speed up your deployment. Ensure to avoid as much as you can to use environment specific variables as ARGS within your Dockerfile (such as `QOVERY_ENVIRONMENT_ID`) since this will force a new build on each environment.
+
+
+#### Cross-environment deploy with auto-deploy enabled
+
+When the auto-deploy feature is enabled and you deploy the same application across multiple environments, the applications will be built separately on each environment and you can't benefit from the caching mechanism available for the already built images.
+
+A small diagram to explain it:
+
+
+
+
+
+Example: two apps A and B are configured on Qovery pointing to a repo X.
+
+Flow:
+1. A commit is pushed on the repo X. Git(hub/lab) inform Qovery about the new commit
+2. Qovery starts the deployment of the two apps separately and checks the existence of the image. At this moment, the image does not exist and thus both deployments move forward with the build phase.
+3. Qovery starts building the image for each application and pushes it onto the repository.
+
+As you can see, every deployment is independent and the build choice is only based on the existence or not of the image on the container registry at the very beginning.
\ No newline at end of file
diff --git a/website/docs/using-qovery/deployment/image-mirroring.md b/website/docs/using-qovery/deployment/image-mirroring.md
index d8641970f0..146f6dbad7 100644
--- a/website/docs/using-qovery/deployment/image-mirroring.md
+++ b/website/docs/using-qovery/deployment/image-mirroring.md
@@ -1,5 +1,5 @@
---
-last_modified_on: "2024-10-09"
+last_modified_on: "2024-10-15"
title: "Image Mirroring"
description: "Learn how images are mirrored within your cloud account"
---
@@ -9,7 +9,7 @@ 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.
-This `mirroring registry` is available and configurable within the Qovery interface
+This `mirroring registry` is available and configurable within the Qovery interface within the `Image registry` section of your cluster.
@@ -17,7 +17,7 @@ This `mirroring registry` is available and configurable within the Qovery interf
# How does it work
-Every time an application needs to be deployed on your cluster, the application image is mirrored on the mirroring registry.
+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.
-## Application built via the Qovery pipeline
+## Application built via the Qovery Deployment Pipeline
-Images in the mirroring registry are organized by Git repository. Each service, with identical build context parameters (commit ID, repository root path, Dockerfile path, Dockerfile content, and environment variables), is assigned its own repository, named z-git_repo_name (or namespace, depending on the cloud provider). This ensures that each service's build and mirroring process is completely isolated from others.
+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-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.
Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the build context parameters (commit id, repository root path, dockerfile path, dockerfile content and environment variables) within the same cluster.
-If the image already exists, the built is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
+If the image already exists, the build is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
-Otherwise, the image is built by the Qovery pipeline the resulting image is pushed on the mirroring registry at the repository of the application A1, deleting any previous image.
+Otherwise, the image is built by the Qovery pipeline the resulting image is pushed on the mirroring registry at the repository of the application A1.
-In order to speed up the image build, we are using remote caches (available in AWS, GCP and Scaleway). It will avoid building the image from scratch, only the layers that changed will be built.
+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.
+
+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.
-Given this isolation mechanism, if the same application is cloned (via the [clone][docs.using-qovery.configuration.environment#clone-environment] or [preview environment][docs.using-qovery.configuration.environment#preview-environment] feature), Qovery will re-build the application since the environment variables have changed (the ones at environment level).
## Application deployed from a container registry
@@ -127,5 +132,3 @@ You can push this image on the mirroring registry within the repository `nginx`,
[docs.using-qovery.configuration.cluster-advanced-settings#image-registry]: /docs/using-qovery/configuration/cluster-advanced-settings/#image-registry
-[docs.using-qovery.configuration.environment#clone-environment]: /docs/using-qovery/configuration/environment/#clone-environment
-[docs.using-qovery.configuration.environment#preview-environment]: /docs/using-qovery/configuration/environment/#preview-environment
diff --git a/website/docs/using-qovery/deployment/image-mirroring.md.erb b/website/docs/using-qovery/deployment/image-mirroring.md.erb
index d7dc2b43a6..2a57b6f7b2 100644
--- a/website/docs/using-qovery/deployment/image-mirroring.md.erb
+++ b/website/docs/using-qovery/deployment/image-mirroring.md.erb
@@ -8,7 +8,7 @@ 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.
-This `mirroring registry` is available and configurable within the Qovery interface
+This `mirroring registry` is available and configurable within the Qovery interface within the `Image registry` section of your cluster.
@@ -16,25 +16,30 @@ This `mirroring registry` is available and configurable within the Qovery interf
# How does it work
-Every time an application needs to be deployed on your cluster, the application image is mirrored on the mirroring registry.
+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.
-## Application built via the Qovery pipeline
+## Application built via the Qovery Deployment Pipeline
-Images in the mirroring registry are organized by Git repository. Each service, with identical build context parameters (commit ID, repository root path, Dockerfile path, Dockerfile content, and environment variables), is assigned its own repository, named z-git_repo_name (or namespace, depending on the cloud provider). This ensures that each service's build and mirroring process is completely isolated from others.
+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-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.
Before building the application A1, Qovery checks within mirroring registry at the repository of the application A1 if an image has already being built with the build context parameters (commit id, repository root path, dockerfile path, dockerfile content and environment variables) within the same cluster.
-If the image already exists, the built is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
+If the image already exists, the build is skipped and Qovery starts the deployment of that image on the Kubernetes cluster.
-Otherwise, the image is built by the Qovery pipeline the resulting image is pushed on the mirroring registry at the repository of the application A1, deleting any previous image.
+Otherwise, the image is built by the Qovery pipeline the resulting image is pushed on the mirroring registry at the repository of the application A1.
-In order to speed up the image build, we are using remote caches (available in AWS, GCP and Scaleway). It will avoid building the image from scratch, only the layers that changed will be built.
+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.
+
+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.
-Given this isolation mechanism, if the same application is cloned (via the [clone][docs.using-qovery.configuration.environment#clone-environment] or [preview environment][docs.using-qovery.configuration.environment#preview-environment] feature), Qovery will re-build the application since the environment variables have changed (the ones at environment level).
## Application deployed from a container registry
@@ -114,4 +119,4 @@ Push the images in a image registry `repository` having the same name of the ima
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
\ No newline at end of file
+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
diff --git a/website/static/img/deployment/autodeploy_build.png b/website/static/img/deployment/autodeploy_build.png
new file mode 100644
index 0000000000..a8f7e0f60e
Binary files /dev/null and b/website/static/img/deployment/autodeploy_build.png differ