A runtime image configuration identifies a container image that Elyra can utilize to run pipeline nodes on container-based platforms, such as Kubeflow Pipelines or Apache Airflow.
A runtime image configuration is associated with a container image that must meet these prerequisites:
Python 3
version pre-installed and python3
in the search path.curl
pre-installed and in the search path.Refer to Creating a custom runtime container image for details.
You can manage runtime image configurations using the JupyterLab UI or the Elyra CLI.
Runtime image configurations can be added, modified, duplicated, and removed in the Runtime Images panel.
To access the panel in JupyterLab:
Open Runtime Images
button in the pipeline editor toolbar.OR
Runtime Images
panel from the JupyterLab sidebar.OR
Cmd/Ctrl + Shift + C
) and search for Manage Runtime Images
.To add a runtime image configuration:
Runtime Images
panel.+
to add a runtime image.To edit a runtime image configuration:
Runtime Images
panel.edit
icon next to the runtime image name.To duplicate a runtime image configuration:
Runtime Images
panel.To delete a runtime image configuration:
Runtime Images
panel.delete
icon next to the runtime image name.Runtime image configurations can be added, replaced, and removed with the elyra-metadata
command line interface.
To list runtime image configurations:
$ elyra-metadata list runtime-images
Available metadata instances for runtime-images (includes invalid):
Schema Instance Resource
------ -------- --------
runtime-image anaconda /Users/jdoe/.../jupyter/metadata/runtime-images/anaconda.json
...
To add a runtime image configuration for the public jdoe/my-image:1.0.0
container image:
$ elyra-metadata create runtime-images \
--name "my_image_name" \
--display_name "My runtime image" \
--description "My custom runtime container image" \
--image_name "jdoe/my-image:1.0.0"
To replace a runtime image configuration use the update
command:
$ elyra-metadata update runtime-images \
--name "my_image_name" \
--display_name "My runtime image" \
--description "My other custom runtime container image" \
--image_name "jdoe/my-other-image:1.0.1"
To export runtime image configurations:
$ elyra-metadata export runtime-images \
--directory "/tmp/foo"
The above example will export all runtime image configurations to the "/tmp/foo/runtime-images" directory.
Note that you must specify the --directory
option.
There are two flags that can be specified when exporting runtime image configurations:
--include-invalid
flag.--clean
flag. Using the --clean
flag in the above example will empty the "/tmp/foo/runtime-images" directory before exporting the runtime image configurations.To import runtime image configurations:
$ elyra-metadata import runtime-images \
--directory "/tmp/foo"
The above example will import all valid runtime image configurations in the "/tmp/foo" directory (files present in any sub-directories will be ignored).
Note that you must specify the --directory
option.
By default, metadata will not be imported if a runtime image configuration instance with the same name already exists. The --overwrite
flag can be used to override this default behavior and to replace any installed metadata with the newer file in the import directory.
To delete a runtime image configuration:
$ elyra-metadata remove runtime-images \
--name "my_image_name"
The runtime image configuration properties are defined as follows. The string in the headings below, which is enclosed in parentheses, denotes the CLI option name.
A user-friendly name for runtime image configuration. This property is required.
Example: My runtime image
Description for this runtime image configuration.
Example: My custom runtime container image
The name and tag of an existing container image in a container registry that meets the stated prerequisites. This property is required.
Example:
jdoe/my-image:1.0.0
Providing only owner/image:tag
uses default registry: Docker Hub registry
In general for other public container registries, the URL shall contain also registry
, therefore the complete URL to be used in this case is: registry/owner/image:tag
Example:
quay.io/jdoe/my-image:1.0.0
This field will be the pull policy of the image when the image is selected to be part of the pipeline. This field
is optional and not required to run a pipeline. If not selected, the behavior will default to that of the kubernetes
cluster. The three options are : Always
IfNotPresent
Never
Example:
IfNotPresent
This example will tell the kubelet to only pull the image if it does not exist.
If Image Name
references a container image in a secured registry (requiring credentials to pull the image), create a Kubernetes secret in the appropriate namespace and specify the secret name as image pull secret.
Restrictions:
Example:
my-registry-credentials-secret
A unique internal identifier for the runtime image configuration. The property is required when the command line interface is used manage a configuration. An identifier is automatically generated from the user-friendly name when a configuration is added using the UI.
Example: my_runtime_image