Declarative Container Configuration¶
jobq allows you to define your container image in a declarative YAML format instead of writing a Dockerfile.
YAML Structure¶
The YAML structure, for the most part, mirrors the structure of a Dockerfile. We only provide an abstraction around the dependencies map. Hence, the official Dockerfile reference may be helpful to understand the meaning of different options.
A full example of a declarative YAML looks like this:
build:
base_image: <base_image>
dependencies:
apt: [<apt_packages>]
pip: [<pip_packages>]
volumes:
- <container_path>
user:
name: <username>
config:
env:
<env_var>: <value>
arg:
<build_arg>: <value>
stopsignal: <signal>
shell: <shell>
meta:
labels:
<label_key>: <label_value>
workdir: <working_directory>
filesystem:
copy:
<src>: <dest>
add:
<src>: <dest>
The YAML file uses a build key as the root, under which various aspects of the Docker image are defined.
First, you have to first specify the base image of the Dockerfile, for example:
Then, you can define system level and Python dependencies.
The system level dependencies require a Debian or Ubuntu derived base image to ensure the availability of apt.
The Python dependencies can be regular package dependencies, but you can also supply requirements files by prefixing them with -r or --requirement as well as wheel, .whl, files in the build context and editable local installs with -e.
The latter require that the source directory contains a pyproject.toml.
build:
dependencies:
apt: [curl, git]
pip: [attrs, pyyaml, test.whl, marker-package, -e ., -r requirements.txt]
Or as a list
To control the execution environment in the container and during the build process, configure the working directory and filesystem. They can be submitted as a dictionary:
Or as a list of strings:Lastly, you can add metadata as per your convenience. You can again supply them either as a dict:
Or as a list of key value pairsTo use the container image, you have to add it in your @job decorator as a spec.