Run flows in Docker containers
Learn how to deploy a flow to a Docker work pool with workers
In this example, you will set up:
- a Docker work pool: stores the infrastructure configuration for your deployment
- a Docker worker: process that polls the Prefect API for flow runs to execute as Docker containers
- a deployment: a flow that should run according to the configuration on your Docker work pool
Then you can execute your deployment via the Prefect API (through the SDK, CLI, UI, etc).
You must have Docker installed and running on your machine.
Executing flows in a long-lived container
This guide shows how to run a flow in an ephemeral container that is removed after the flow run completes. To instead learn how to run flows in a static, long-lived container, see this guide.
Create a work pool
A work pool provides default infrastructure configurations that all jobs inherit and can override. You can adjust many defaults, such as the base Docker image, container cleanup behavior, and resource limits.
To set up a Docker type work pool with the default values, run:
… or create the work pool in the UI.
To confirm the work pool creation was successful, run:
You should see your new my-docker-pool
listed in the output.
Next, check that you can see this work pool in your Prefect UI.
Navigate to the Work Pools tab and verify that you see my-docker-pool
listed.
When you click into my-docker-pool
, you should see a red status icon signifying that this work pool is not ready.
To make the work pool ready, you’ll need to start a worker. We’ll show how to do this next.
Start a worker
Workers are a lightweight polling process that kick off scheduled flow runs on a specific type of infrastructure (such as Docker).
To start a worker on your local machine, open a new terminal and confirm that your virtual environment has prefect
installed.
Run the following command in this new terminal to start the worker:
You should see the worker start.
It’s now polling the Prefect API to check for any scheduled flow runs it should pick up and then submit for execution.
You’ll see your new worker listed in the UI under the Workers tab of the Work Pools page with a recent last polled date.
The work pool should have a Ready
status indicator.
Pro Tip:
If my-docker-pool
does not already exist, the below command will create it for you automatically with the default settings for that work pool type, in this case docker
.
Keep this terminal session active for the worker to continue to pick up jobs. Since you are running this worker locally, the worker will if you close the terminal. In a production setting this worker should run as a daemonized or managed process.
Create the deployment
From the previous steps, you now have:
- A work pool
- A worker
Next, you’ll create a deployment from your flow code.
Automatically bake your code into a Docker image
Create a deployment from Python code by calling the .deploy
method on a flow:
Now, run the script to create a deployment (in future examples this step is omitted for brevity):
You should see messages in your terminal that Docker is building your image.
When the deployment build succeeds, you will see information in your terminal showing you how to start a worker for your
deployment, and how to run your deployment.
Your deployment is visible on the Deployments
page in the UI.
By default, .deploy
builds a Docker image with your flow code baked into it and pushes the image to the
Docker Hub registry specified in the image
argument`.
Authentication to Docker Hub
Your environment must be authenticated to your Docker registry to push an image to it.
You can specify a registry other than Docker Hub by providing the full registry path in the image
argument.
If building a Docker image, your environment with your deployment needs Docker installed and running.
To avoid pushing to a registry, set push=False
in the .deploy
method:
To avoid building an image, set build=False
in the .deploy
method:
The specified image must be available in your deployment’s execution environment for accessible flow code.
Prefect generates a Dockerfile for you that builds an image based off of one of Prefect’s published images.
The generated Dockerfile copies the current directory into the Docker image and installs any dependencies listed
in a requirements.txt
file.
Automatically build a custom Docker image with a local Dockerfile
If you want to use a custom Dockerfile, specify the path to the Dockerfile with the DockerImage
class:
The DockerImage
object enables image customization.
For example, you can install a private Python package from GCP’s artifact registry like this:
-
Create a custom base Dockerfile.
-
Create your deployment with the DockerImage class:
private-package.py
Note that you used a Prefect Secret block to load the URL configuration for the artifact registry above.
See all the optional keyword arguments for the DockerImage class.
Default Docker namespace
You can set the PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE
setting to append a default Docker namespace to all images
you build with .deploy
. This is helpful if you use a private registry to store your images.
To set a default Docker namespace for your current profile run:
Once set, you can omit the namespace from your image name when creating a deployment:
The above code builds an image with the format <docker-registry-url>/<organization-or-username>/my_image:my_image_tag
when PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE
is set.
Store your code in git-based cloud storage
While baking code into Docker images is a popular deployment option, many teams store their workflow code in git-based storage, such as GitHub, Bitbucket, or GitLab.
If you don’t specify an image
argument for .deploy
, you must specify where to pull the flow code from at runtime
with the from_source
method.
Here’s how to pull your flow code from a GitHub repository:
The entrypoint
is the path to the file the flow is located in and the function name, separated by a colon.
See the Store flow code guide for more flow code storage options.
Additional configuration with .deploy
Next, see deployment configuration options.
To pass parameters to your flow, you can use the parameters
argument in the .deploy
method. Just pass in a dictionary of
key-value pairs.
The job_variables
parameter allows you to fine-tune the infrastructure settings for a deployment.
The values passed in override default values in the specified work pool’s
base job template.
You can override environment variables, such as image_pull_policy
and image
, for a specific deployment with the job_variables
argument.
Similarly, you can override the environment variables specified in a work pool through the job_variables
parameter:
The dictionary key “EXTRA_PIP_PACKAGES” denotes a special environment variable that Prefect uses to install additional
Python packages at runtime.
This approach is an alternative to building an image with a custom requirements.txt
copied into it.
See Override work pool job variables for more information about how to customize these variables.
Work with multiple deployments with deploy
Create multiple deployments from one or more Python files that use .deploy
.
You can manage these deployments independently of one another to deploy the same flow with different configurations
in the same codebase.
To create multiple work pool-based deployments at once, use the deploy
function, which is analogous to the serve
function:
In the example above you created two deployments from the same flow, but with different work pools. Alternatively, you can create two deployments from different flows:
In the example above, the code for both flows is baked into the same image.
You can specify one or more flows to pull from a remote location at runtime with the from_source
method.
Here’s an example of deploying two flows, one defined locally and one defined in a remote repository:
You can pass any number of flows to the deploy
function.
This is useful if using a monorepo approach to your workflows.
Learn more
Was this page helpful?