Lifecycle Job
Before you begin, this documentation assumes the following:
You have created an Environment.
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).
- 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).
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.
Qovery allows you to create and deploy jobs from two different sources: Git Repository or Container Registry
Deploying from a Git Repository
In this configuration, Qovery will pull the code from the chosen repository, build the application and deploy it on your kubernetes cluster.
The list of Git repositories available during the setup is strictly tied to the permissions of your git account (by default Qovery can access all your repositories). If you want to restrict the Qovery access only to a few repositories, user the GitHub Qovery Application (only for Github).
Deploying from a Container Registry
In this configuration, Qovery will pull the chosen container registry an image you have pre-built and deploy it on your kubernetes cluster.
To improve the security and avoid deploying images from non-authorized registries, we have decided to restrict the list of Container Registry you can use during the setup process. Only an administrator with the right permissions can manage it from the Container Registry Management page
Create a Job
Go into the chosen environment and press the "New Service" button and then the "Create Lifecycle job" button
Select the following fields:
- Name: give a name to your application
- Source: Chose between Git Repository or Container Registry, depending on the source location of your application
If you want to deploy a cronjob from a Git Repository you will have to select:
- Git Repository: Select the git provider hosting your code (it can be hosted on GitHub, GitLab or Bitbucket).
- Branch: Select branch that Qovery should use to deploy your code
- Root Application Path: base folder in which the code resides in your repository
- Build Mode: only Docker is supported
If you want to deploy a job from a Container Registry you will have to select:
- Registry: select the container registry storing the image of your job. Note: only pre-configured registry are available in this list, check the Container Registry Management page for more information.
- Image name: the name of the image to be deployed with this job (example: postgres)
- Image tag: the tag of the image to be deployed with this job (example: 12)
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 job (not mandatory). We expect the format to be an array. Example ["rails", "-h", "0.0.0.0", "-p", "8080", "string"]
- 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
- Within this section, you will need to define the resources to be assigned to your job at run time.
- vCPU: the vCPU assigned to each instance of your application. The default is 500m (0.5 vCPU).
- RAM: the amount of RAM assigned to each instance of your application. The default is 512MB.
Define any input variable required by your job to run. Any declared variable will be injected as environment variables based on the selected scope (project, environment, service) Any additional environment variable can be added later from the environment variable section
You will find a recap of your job setup and you can now decide to: 1. Go back to one of the previous steps and change your settings 2. Create your job without deploying it 3. Create and deploy your job
Deployment Management
Have a look at the Deployment Management section for more information.
Force Run
You can force the execution of a job independently its deployment status by:
Select the job that you want to force
click on the
Play
button of the cronjob you want to force and select theForce Run
option. Note: the same option is available on the service list as wellSelect the environment event you want to force.
Once you click, the job will be deployed and executed with the entrypoint and arguments associated to the selected event. You will be able to follow its execution within the application logs
Configuration
Once created, you can access the configuration at any time via the Settings tab available on the service section
You can find below the description of each of the tabs available in this section
General
General settings section allows you to set up your application name and the source code location (git repository or image registry) .
Git Repository
If your job is built and deployed from a git repository, within this section you can:
- Modify the git provider where your code is stored (it can be hosted on GitHub, GitLab or Bitbucket).
- Modify the branch that Qovery should use for deploying your code
- Modify
Root Application Path
- base folder in which the application resides in your repository
Container Registry
If your application is deployed from an image registry, within this section you can modify:
- Registry: select the container registry storing the image of your application. Note: only pre-configured registry are available in this list, check the Container Registry Management page for more information.
- Image name: the name of the image to be deployed with this application (example: postgres)
- Image tag: the tag of the image to be deployed with this application (example: 12)
Build Mode
This option is available only if you have selected "Git Repository" as source. Only Docker is supported
Qovery runs your application within the Container technology. To build and run your application, you need to provide a valid Dockerfile.
FROM node:13-alpineRUN mkdir -p /usr/src/appWORKDIR /usr/src/appCOPY . .RUN npm installEXPOSE 3000CMD node ./bin/www
After creating a Dockerfile, specify the location of your Dockerfile in Dockefile path
field.
Configuration from above will make Qovery look for the Dockerfile in /timescale/Dockerfile
path of your repository (Root Application Path
+ Dockerfile Path
).
JOB Configuration
You can modify here the configuration of your job:
- CRON Schedule: specify a valid CRON expression (see 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)
- CMD Arguments: the arguments to be passed to launch your job (not mandatory). We expect the format to be an array. Example ["rails", "-h", "0.0.0.0", "-p", "8080", "string"]
- 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
To configure the number of CPUs that your job needs, adjust the setting in the Resources
section.
Please note that in this section you configure the CPU allocated by the cluster for your application and that cannot consume more than this value. Even if the application is underused and consume less resources, the cluster will still reserve the selected amount of CPU.
RAM
To configure the amount of RAM that your app needs, adjust the setting in Resources
section.
Please note that in this section you configure the CPU allocated by the cluster for your application and that cannot consume more than this value. Even if the application is underused and consume less resources, the cluster will still reserve the selected amount of CPU. If your application requires more RAM than requested, it will be killed by the kubernetes scheduler.
Environment Variable
To learn how to set up environment variables in your projects and applications, navigate to configuring Environment Variables section.
Secrets
To learn how to set up secrets in your projects and applications, navigate to configuring Secrets section.
Logs
To learn how to display your application logs, navigate to logs section
Job output
Qovery expects the output file to be written in the following path /qovery-output/qovery-output.json
(the output
folder is automatically mounted by Qovery).
The file should follow this format:
{"varname1": {"sensitive": True,"value": "myvalue"},"varname2": {"sensitive": False,"value": "myvalue"}}...
At the end of the job execution, this file will be processed by Qovery and a set of environment variables will be created, one for each element in the json. The information in the json file will be mapped to an environment variables in this way:
- Variable Name:
QOVERY_OUTPUT_JOB_<JOBID>_<VARNAME>
, where<JOBID>
is the id of the Job on Qovery side and<VARNAME>
is the name of the element in the output file. - Variable Value: field "value"
- Secret: field "sensitive"
An alias <VARNAME>
will be automatically created to simplify your setup.
Example
Let's say that the code of our job creates a PostgreSQL RDS on AWS. At the end of its execution, the job should know the connection Once created, the job should know the connection string of the PostgreSQL. The job can now create a file /qovery-output/qovery-output.json
with the following structure:
{"POSTGRES_DB_HOST": {"sensitive": False,"value": "zf138d9c8-postgresql"},"POSTGRES_DB_USER": {"sensitive": False,"value": "root"},"POSTGRES_DB_PASS": {"sensitive": True,"value": "mypassword"},"POSTGRES_DB_TABLE": {"sensitive": False,"value": "MYDB"},"POSTGRES_DB_PORT": {"sensitive": False,"value": "3600"}}
This file will be processed by Qovery and the following environment variables will be created:
Var QOVERY_OUTPUT_JOB_<JOBID>_POSTGRES_DB_HOST
- Value: "zf138d9c8-postgresql"
- Secret: false
- Alias: POSTGRES_DB_HOST
Var QOVERY_OUTPUT_JOB_<JOBID>_POSTGRES_DB_USER
- Value: "root"
- Secret: false
- Alias: POSTGRES_DB_USER
Var QOVERY_OUTPUT_JOB_<JOBID>_POSTGRES_DB_PASS
- Value: "mypassword"
- Secret: true
- Alias: POSTGRES_DB_PASS
Var QOVERY_OUTPUT_JOB_<JOBID>_POSTGRES_DB_TABLE
- Value: "MYDB"
- Secret: false
- Alias: POSTGRES_DB_TABLE
Var QOVERY_OUTPUT_JOB_<JOBID>_DB_PORT
- Value: "3600"
- Secret: false
- Alias: POSTGRES_DB_PORT
Once the execution of the job is terminated and the environment variables are created, any application within the same environment will be able to access those environment variables and thus connect to the postgres instance.
Delete a job
Select the job you want to delete
In the overview, click on the
3 dots
button and remove the job. Note: the same option is available on the service list as well