Refacto on lifecycle jobs / TF and cloudformation (#461)

* feat(lifecycle): reorganized doc to introduce templates for Terraform and cloudformation

* chore(lifecyclejob): update action wording to triggers

* fix

* fix

* fix

scripts/generate/templates.rb

@@ -795,6 +795,10 @@ def configure_domains(service)
     render("#{partials_path}/_configure_domains.md", binding).strip
   end
 
+  def template_lifecycle(template)
+    render("#{partials_path}/_template_lifecycle.md", binding).strip
+  end
+
   def qovery_deploy_app_web
     render("#{partials_path}/_qovery_deploy_app_web.md", binding).strip
   end

scripts/generate/templates/_partials/_qovery_continuous_integration_common_scenarios.md.erb

@@ -96,7 +96,7 @@ qovery environment delete \
 
 ### Terraform
 
-Do you want to include Terraform in your CI? Check out our [Terraform documentation][docs.using-qovery.integration.terraform].
+Do you want to include Terraform in your CI? Check out our [Terraform documentation][docs.using-qovery.integration.terraform-provider].
 
 ### Any other examples?
 

scripts/generate/templates/_partials/_template_lifecycle.md.erb

@@ -0,0 +1,67 @@
+You can deploy any <%= template %> manifests/templates with Qovery and manage the lifecycle of your own cloud resources. For example, you can deploy your own databases, lambdas, brokers etc...
+
+Running and deploying your <%= template %> manifest/template is achieved via the Qovery Lifecycle Jobs, have a look at [this section][docs.using-qovery.integration.iac] to know how it works.
+
+To simplify the configuration, Qovery provides a <%= template %> configuration template for your Lifecycle job, allowing you to package your manifest and run it with the <%= template %> CLI directly on your cluster.
+
+Follow these steps to create and deploy your <%= template %> manifest/template:
+
+<Steps headingDepth={3}>
+<ol>
+<li>
+Add a new service
+
+Enter the environment where you want to deploy your <%= template %> manifest and select the "Add Service" button 
+
+</li>
+<li>
+Use the <%= template %> template
+
+Select the "<%= template %>" option in the service creation list and follow the steps.
+
+</li>
+
+<li>
+Manifest location
+
+Provide the location of your manifest within your git repository
+
+</li>
+
+<li>
+Customize your configuration
+
+Qovery provides you with a pre-configuration for your lifecycle job capable to run and deploy your <%= template %>:
+- **Dockerfile**: you will find a Dockerfile capable to package your manifest/template and run the right <%= template %> command depending on the event triggered (Example: the "start" command executes "<%= template %> apply .."). Customize this file to match your needs (backend config, additional configuration etc..)
+- **Triggers**: you will find the default triggers and commands based on the default Dockerfile.
+- **Resources**: you will find a default CPU/Memory values capable to run the <%= template %> CLI on a Kubernetes job
+- **Environment variables**: you will be able to provide the input of your <%= template %> manifest/template as file, which will be stored as an [environment variable as file][docs.using-qovery.configuration.environment-variable#environment-variable-as-file]. You can also add additional environment variables necessary to run the <%= template %> commands (like AWS_SECRET_ACCESS_KEY etc..)
+
+</li>
+
+<li>
+Create & Deploy
+
+Once it is all set, you can Create and Deploy your <%= template %> job. This will trigger the execution and deployment of the <%= template %> manifest/template.
+
+</li>
+
+<li>
+Access the <%= template %> output
+
+If your <%= template %> manifest/template generates an output (see [Lifecycle job output][docs.using-qovery.configuration.lifecycle-job#job-output] for more information), the output will be fetched and injected as environment variable to any service of the same environment. It will allow those services to access the newly created resource.
+
+<p align="center">
+  <img src="/img/configuration/job/job_output.png" alt="Job output" />
+</p>
+
+</li>
+
+</ol>
+</Steps>
+
+### Resources
+
+- [Qovery Lifecycle Job Documentation][docs.using-qovery.configuration.lifecycle-job]
+- [Qovery Lifecycle Job Examples](https://github.com/Qovery/lifecycle-job-examples)
+- [How to deploy any resource with Lifecycle Jobs][guides.tutorial.how-to-use-lifecycle-job-to-deploy-any-kind-of-resources]

website/docs/getting-started.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-06-19"
+last_modified_on: "2024-08-12"
 title: Getting started
 description: "About Qovery, the platform that accelerates and scales application development cycle with zero infrastructure management investment."
 sidebar_label: hidden

website/docs/getting-started/basic-concepts.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2023-12-29"
+last_modified_on: "2024-08-12"
 title: "Basic Concepts"
 description: "Basic Concepts about Qovery"
 ---
@@ -59,14 +59,16 @@ A Preview Environment is an ephemeral environment allowing you to get early feed
 More information about [Preview Environment here][docs.using-qovery.configuration.environment#preview-environment].
 
 ## Service
-A Service is the basic unit that you can add to an environment. Each service has an associated git repository (or registry) and a commit (or image_name:tag) that will be used to deploy the service on the cluster.
+A Service is the basic unit that you can add to an environment, representing one of the elements of your tech stack (front-end, database etc..).
 
-Five types of services exists:
-- Application: it allows you to run your long-running workloads. We usually call them "Containers" when the source code is stored on an image registry. More information about [Applications here][docs.using-qovery.configuration.application]
-- Database: it allows you to deploy a database. Qovery allows you to deploy a container and a cloud provider managed version.  More information about [Databases here][docs.using-qovery.configuration.database]
-- CronJob: it allows you to deploy a cronjob on your cluster and execute it based on the selected schedule. More information about [Cronjob here][docs.using-qovery.configuration.cronjob]
-- Lifecycle: it allows you to execute your code based on the events happening on your environment (Start, Stop, Delete etc..). With the right code, it can be used to seed your database when the environment is created or manage the lifecycle of any external resource (via a terraform file, pulumi code etc..). More information about [Lifecycle here][docs.using-qovery.configuration.cronjob]
-- Helm: it allows you to deploy a helm chart on your cluster. More information about [Helm here][docs.using-qovery.configuration.helm]
+Qovery provides five "basic" services that can be combined together to deploy any tech stack:
+- Application: it allows you to run your long-running workloads on your Kubernetes cluster. It can be deployed from a git repository or as a container from an image registry. More information about [Applications here][docs.using-qovery.configuration.application]
+- Database: it allows you to deploy a database. Qovery allows you to deploy a database as a container on your Kubernetes cluster (for test/dev) and as a cloud provider managed version (RDS AWS etc..).  More information about [Databases here][docs.using-qovery.configuration.database]
+- CronJob: it allows you to deploy a cronjob on your Kuberentes cluster and execute it based on the selected schedule. More information about [Cronjob here][docs.using-qovery.configuration.cronjob]
+- Lifecycle: it allows you to execute code based on the events happening on your environment (Deploy, Stop, Delete etc..). It is enough flexible to cover multiple use cases: seed your database when the environment is created, manage the lifecycle of any external resource (via a terraform file, pulumi code etc..). More information about [Lifecycle here][docs.using-qovery.configuration.lifecycle-job]
+- Helm: it allows you to deploy a helm chart on your Kubernetes cluster. More information about [Helm here][docs.using-qovery.configuration.helm]
+
+On top of these basic services, Qovery provides a pre-set of configuration to simplify the deployment of your tech stack.
 
 ## Deployment
 A Deployment is the operation allowing you to gather your code and make it runs on your cluster. Qovery can pull your repository, generate a docker image and spawn the necessary resources on your clusters to make your application run. You can find more information within [this section][docs.using-qovery.deployment].
@@ -87,6 +89,7 @@ You can monitor the execution of the deployment via the [Deployment Logs][docs.u
 [docs.using-qovery.configuration.environment#preview-environment]: /docs/using-qovery/configuration/environment/#preview-environment
 [docs.using-qovery.configuration.environment]: /docs/using-qovery/configuration/environment/
 [docs.using-qovery.configuration.helm]: /docs/using-qovery/configuration/helm/
+[docs.using-qovery.configuration.lifecycle-job]: /docs/using-qovery/configuration/lifecycle-job/
 [docs.using-qovery.configuration.organization.members-rbac#roles-based-access-control-rbac]: /docs/using-qovery/configuration/organization/members-rbac/#roles-based-access-control-rbac
 [docs.using-qovery.configuration.organization]: /docs/using-qovery/configuration/organization/
 [docs.using-qovery.configuration.project]: /docs/using-qovery/configuration/project/

website/docs/getting-started/basic-concepts.md.erb

@@ -50,14 +50,16 @@ A Preview Environment is an ephemeral environment allowing you to get early feed
 More information about [Preview Environment here][docs.using-qovery.configuration.environment#preview-environment].
 
 ## Service
-A Service is the basic unit that you can add to an environment. Each service has an associated git repository (or registry) and a commit (or image_name:tag) that will be used to deploy the service on the cluster.
-
-Five types of services exists:
-- Application: it allows you to run your long-running workloads. We usually call them "Containers" when the source code is stored on an image registry. More information about [Applications here][docs.using-qovery.configuration.application]
-- Database: it allows you to deploy a database. Qovery allows you to deploy a container and a cloud provider managed version.  More information about [Databases here][docs.using-qovery.configuration.database]
-- CronJob: it allows you to deploy a cronjob on your cluster and execute it based on the selected schedule. More information about [Cronjob here][docs.using-qovery.configuration.cronjob]
-- Lifecycle: it allows you to execute your code based on the events happening on your environment (Start, Stop, Delete etc..). With the right code, it can be used to seed your database when the environment is created or manage the lifecycle of any external resource (via a terraform file, pulumi code etc..). More information about [Lifecycle here][docs.using-qovery.configuration.cronjob]
-- Helm: it allows you to deploy a helm chart on your cluster. More information about [Helm here][docs.using-qovery.configuration.helm]
+A Service is the basic unit that you can add to an environment, representing one of the elements of your tech stack (front-end, database etc..).
+
+Qovery provides five "basic" services that can be combined together to deploy any tech stack:
+- Application: it allows you to run your long-running workloads on your Kubernetes cluster. It can be deployed from a git repository or as a container from an image registry. More information about [Applications here][docs.using-qovery.configuration.application]
+- Database: it allows you to deploy a database. Qovery allows you to deploy a database as a container on your Kubernetes cluster (for test/dev) and as a cloud provider managed version (RDS AWS etc..).  More information about [Databases here][docs.using-qovery.configuration.database]
+- CronJob: it allows you to deploy a cronjob on your Kuberentes cluster and execute it based on the selected schedule. More information about [Cronjob here][docs.using-qovery.configuration.cronjob]
+- Lifecycle: it allows you to execute code based on the events happening on your environment (Deploy, Stop, Delete etc..). It is enough flexible to cover multiple use cases: seed your database when the environment is created, manage the lifecycle of any external resource (via a terraform file, pulumi code etc..). More information about [Lifecycle here][docs.using-qovery.configuration.lifecycle-job]
+- Helm: it allows you to deploy a helm chart on your Kubernetes cluster. More information about [Helm here][docs.using-qovery.configuration.helm]
+
+On top of these basic services, Qovery provides a pre-set of configuration to simplify the deployment of your tech stack.
 
 ## Deployment
 A Deployment is the operation allowing you to gather your code and make it runs on your cluster. Qovery can pull your repository, generate a docker image and spawn the necessary resources on your clusters to make your application run. You can find more information within [this section][docs.using-qovery.deployment].

website/docs/security-and-compliance.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-01-03"
+last_modified_on: "2024-08-12"
 title: Security and Compliance
 description: "Learn more about Security and Compliance in Qovery"
 sidebar_label: hidden

website/docs/using-qovery/configuration/lifecycle-job.md

@@ -1,5 +1,5 @@
 ---
-last_modified_on: "2024-07-03"
+last_modified_on: "2024-08-12"
 title: "Lifecycle Job"
 description: "Learn how to configure your Lifecycle job on Qovery"
 ---
@@ -17,17 +17,30 @@ You have created an [Environment][docs.using-qovery.configuration.environment].
 </Assumptions>
 
 A **Lifecycle Job** is a job that runs on your kubernetes cluster with the following characteristics:
-- it is executed ONLY when the selected environment event occurs (unless its execution is forced, [see the Force execution section](#force-execution)).
+- it is executed ONLY when the selected event (deploy/stop/delete) occurs (unless its execution is forced, [see the Force execution section](#force-run)).
 - any output file created at the end of the execution will be automatically injected as environment variable to any service within the same environment ([see the Job Output section](#job-output)).
 
 Given its characteristics, lifecycle jobs are particularly useful for:
 - Seed your database on your preview environment: you can create a custom job that will seed a database when the preview environment is deployed
 - Create an external resources not natively managed by Qovery: you can create a custom job that will create the external resource. By writing the connection strings in an output file, those information will be injected as environment variables on any service of the environment (so that they can consume this new resource).
 
-A lifecycle job can be executed on the following environment events:
-- **Start**: the job is executed when the environment starts. Note that a start event is generated on both the "Deploy" and "Redeploy" actions so you should take care of managing this in your code to avoid executing it twice (on the first deploy and on the re-deploy).
-- **Stop**: the job is executed when the environment stops.
-- **Delete**: the job is executed when the environment is deleted.
+The execution of this job follows this flow:
+
+<p align="center">
+  <img src="/img/configuration/job/lifecycle_job.png" alt="Lifecycle job schema" />
+</p>
+
+1. You define the repository where the code is located and the Dockerfile to be used to containerize the application (deploying from a container registry is supported as well)
+2. You define the triggers and the command to be executed when your code runs. For example: "on start", execute "start.sh"
+3. When an event happens on your environment or job, if the event matches your trigger condition, the job is deployed and scheduled for execution.
+4. The job is executed on your cluster and can interact with some external services. For example, it can use a Terraform manifest to deploy an RDS instance.
+5. If the job creates an output in a specific format (see [Job output section](#job-output)), this can be retrieved and injected as environment variable for any other service within the environment. For example, you can retrieve the RDS DB URI so that the other applications can use it.
+
+
+A lifecycle job can be executed on the following environment/job events:
+- **Deploy**: the job is executed when the environment/job is deployed. Note that this includes both the "Deploy" and "Redeploy" actions so you should take care of managing this in your code to avoid executing it twice (on the first deploy and on the re-deploy).
+- **Stop**: the job is executed when the environment/job stops.
+- **Delete**: the job is executed when the environment/job is deleted.
 
 <Alert type="success">
 
@@ -107,18 +120,13 @@ See the [Dockerfile section](#dockerfile) for more information.
 
 </li>
 <li>
+Specify the triggers
 
-Specify the configuration of your job:
-- Event: select the environment event which should trigger the execution of the job (Environment start, stop, delete)
-- Image Entrypoint: the entrypoint to be used to launch your job (not mandatory).
-- CMD Arguments: the arguments to be passed to launch your application (not mandatory) separated with a space. Example: `rails -h 0.0.0.0 -p 8080 string "complex arg"`.
-- Number of restarts: Maximum number of restarts allowed in case of job failure (0 means no failure)
-- Max duration time in seconds: Maximum duration allowed for the job to run before killing it and mark it as failed
-- Port: Port used by Kubernetes to run readiness and liveliness probes checks. The port will not be exposed externally
+See the [Triggers section](#triggers) for more information.
 
 <Alert type="info">
 
-Entrypoint and Arguments can be customized for each event. This will allow your job to behave differently depending on the environment status (example: you might want to run a "create" command when the environment starts and a "destroy" command when the environment is deleted)
+Entrypoint and Arguments can be customized for each event. This will allow your job to behave differently depending on the environment status (example: you might want to run a "create" command when the environment is deployed and a "destroy" command when the environment is deleted)
 
 </Alert>
 
@@ -367,15 +375,19 @@ Qovery does not apply any versioning on the provided Dockerfile, we strongly sug
 If you don't have one, you can use the `docker init` command to generate one for your application (check the [documentation here](https://docs.docker.com/reference/cli/docker/init/)).
 
 
-### JOB Configuration
-You can modify here the configuration of your job:
-- CRON Schedule: specify a valid CRON expression (see [Crontab guru](https://crontab.guru/) for help). After being deployed, the job will be executed following the defined schedule.
-- Image Entrypoint: the entrypoint to be used to launch your job (not mandatory)
+### Triggers
+
+This section allows you to define when the lifecycle job should be executed and which command should run. 
+
+In this section you can configure:
+- Event: select the environment/job event which should trigger the execution of the job (deploy, stop, delete)
+- Image Entrypoint: the entrypoint to be used to launch your job (not mandatory).
 - CMD Arguments: the arguments to be passed to launch your application (not mandatory) separated with a space. Example: `rails -h 0.0.0.0 -p 8080 string "complex arg"`.
 - Number of restarts: Maximum number of restarts allowed in case of job failure (0 means no failure)
 - Max duration time in seconds: Maximum duration allowed for the job to run before killing it and mark it as failed
 - Port: Port used by Kubernetes to run readiness and liveliness probes checks. The port will not be exposed externally
 
+
 ### Resources
 
 #### CPU