Submit flows directly to different infrastructure types without a deployment
Beta Feature
This feature is currently in beta. While we encourage you to try it out and provide feedback, please be aware that the API may change in future releases, potentially including breaking changes.
Prefect allows you to submit workflows directly to different infrastructure types without requiring a deployment. This enables you to dynamically choose where your workflows run based on their requirements, such as:
Submitting workflows directly to dynamic infrastructure provides several advantages:
Direct submission of workflows is currently supported for the following infrastructures:
Infrastructure | Required Package | Decorator |
---|---|---|
Docker | prefect-docker | @docker |
Kubernetes | prefect-kubernetes | @kubernetes |
AWS ECS | prefect-aws | @ecs |
Google Cloud Run | prefect-gcp | @cloud_run |
Google Vertex AI | prefect-gcp | @vertex_ai |
Azure Container Instances | prefect-azure | @azure_container_instance |
Each package can be installed using pip, for example:
Before submitting workflows to specific infrastructure, you’ll need:
Create work pools for each infrastructure type using the Prefect CLI:
For detailed information on creating and configuring work pools, refer to the work pools documentation.
To enable Prefect to run workflows in remote infrastructure, work pools need an associated storage location to store serialized versions of submitted workflows and results from workflow runs.
Configure storage for your work pools using one of the supported storage types:
To allow Prefect to upload and download serialized workflows, you can create a block containing credentials with permission to access your configured storage location.
If a credentials block is not provided, Prefect will use the default credentials (e.g., a local profile or an IAM role) as determined by the corresponding cloud provider.
You can inspect your storage configuration using:
Local storage for @docker
When using the @docker
decorator with a local Docker engine, you can use volume mounts to share data between your Docker container and host machine.
Here’s an example:
To use local storage, ensure that:
LocalFileSystem
block’s basepath
matches the path specified in the volume mountTo submit a flow to specific infrastructure, use the appropriate decorator for that infrastructure type.
Here’s an example using @kubernetes
:
When you run this code on your machine, my_flow
will execute locally, while my_remote_flow
will be submitted to run in a Kubernetes job.
Parameters must be serializable
Parameters passed to infrastructure-bound flows are serialized with cloudpickle
to allow them to be transported to the destination infrastructure.
Most Python objects can be serialized with cloudpickle
, but objects like database connections cannot be serialized. For parameters that cannot be serialized, you’ll need to create the object inside your infrastructure-bound workflow.
You can override the default configuration by providing additional kwargs to the infrastructure decorator:
Any kwargs passed to the infrastructure decorator will override the corresponding default value in the base job template for the specified work pool.