Beta FeatureThis 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.
- Training machine learning models that require GPUs
- Processing large datasets that need significant memory
- Running lightweight tasks that can use minimal resources
Benefits
Submitting workflows directly to dynamic infrastructure provides several advantages:- Dynamic resource allocation: Choose infrastructure based on workflow requirements at runtime
- Cost efficiency: Use expensive infrastructure only when needed
- Consistency: Ensure workflows always run on the appropriate infrastructure type
- Simplified workflow management: No need to create and maintain deployments for different infrastructure types
Supported infrastructure
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 |
Prerequisites
Before submitting workflows to specific infrastructure, you’ll need:- A work pool for each infrastructure type you want to use
- Object storage to associate with your work pool(s)
Setting up work pools and storage
Creating a work pool
Create work pools for each infrastructure type using the Prefect CLI:Configuring work pool storage
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:Local storage for To use local storage, ensure that:
@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:- The volume mount path is identical on both the host and container side
- The
LocalFileSystem
block’sbasepath
matches the path specified in the volume mount
Submitting workflows to specific infrastructure
To submit a flow to specific infrastructure, use the appropriate decorator for that infrastructure type. Here’s an example using@kubernetes
:
my_flow
will execute locally, while my_remote_flow
will be submitted to run in a Kubernetes job.
Parameters must be serializableParameters 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.Customizing infrastructure configuration
You can override the default configuration by providing additional kwargs to the infrastructure decorator:Further reading
- Work pools concept page