Migrating from runner to taskRunner​Migrating from runner to task​Runner

The runner property in script tasks will be deprecated in Kestra 0.18.0. Use the taskRunner property instead.

Task Runners Before Kestra 0.16.0

The runner property allowed script tasks to run in local processes or Docker containers. Here’s an example of a script task configured with the runner property:

yaml
- id: script_task
  type: io.kestra.plugin.scripts.python.Commands
  runner: DOCKER # βœ… This is the deprecated runner property
  docker:
    image: python:3.11
Full example of a task with a DOCKER runner

And here is the equivalent task using the taskRunner property:

yaml
- id: script_task
  type: io.kestra.plugin.scripts.python.Commands
  containerImage: python:3.11
  taskRunner:
    type: io.kestra.core.models.script.types.DockerTaskRunner # βœ… the runner is now a plugin

Transition to taskRunner in Kestra 0.16.0 and Beyond

Kestra 0.16.0 introduced the taskRunner property, offering broader execution options, such as Kubernetes, AWS Batch, Azure Batch, and Google Batch. This approach decouples the execution environment configuration from the script tasks, making it easier to manage and extend. Below is an updated example of the same script task, but this time using the taskRunner property.

Updated script task using a task runner

Why the Change?

The runner property was limited to a few predefined options, and extending it required modifications to the core script plugin. By transitioning to the taskRunner, each environment type is a plugin, which simplifies maintenance and customization. You can create your own Task Runner plugins and if you'd like, you can contribute them to kestra.

We envision task runners as a pluggable system allowing you to orchestrate any code anywhere without having to worry about the underlying infrastructure.

Advantages of Using taskRunner

  • Flexibility: Configure various environments easily using plugins.
  • Decoupling: Separate the script task configuration from execution environment details.
  • Scalability: Easily add new environments as plugins without having to change anything in your business logic.

Steps for Migration

  1. Review Existing Tasks: Identify all script tasks using the runner or docker properties.
  2. Choose Suitable taskRunner: Select the appropriate taskRunner type based on your execution environment. The DockerTaskRunner is the default.
  3. Update Your Configuration: Replace the runner property with taskRunner and adjust the configuration to match the new structure, including replacing the docker.image with containerImage.
  4. Test Changes: Validate the updated configurations in a development or staging environment before deploying to production.

Support for Legacy runner Property

While the runner property is deprecated, it will continue to be supported for a couple of releases, allowing a gradual transition to taskRunner. However, we recommend to switch as soon as possible to take advantage of the new capabilities.

Was this page helpful?