Prefect Application Services¶
events¶
events The API service that is responsible for creating events external to the Prefect API.
For example, a task emits an event as it changes states, which is received and action taken by the events service.
Additionally, events is one of the core services required for automations, the others being triggers and actions.
Emitted events are consumed by triggers to evaluate automation trigger conditions.
A flow run is orchestrated server side, and is not an external event. A flow-run that transitions from a Scheduled state to a Pending state emits an internal event to the Prefect API via the server service.
Triggers¶
Triggers is comprised of two separate services - triggers-reactive and triggers-proactive.
triggers-reactive that manages and actions reactive events and automations, such as "If this Flow Run is marked Crashed, then take some action".
One of the core services required for automations, the others being events and actions.
triggers-proactive manages actions, proactive events, and automations, such as "If a work-queue is unhealthy for 5 minutes, then take some action".
One of the core services required for automations, the others being events and actions.
actions¶
actions is one of the services responsible for some task as the result of an automation being triggered by triggers.
actions is a consumer from Redis for tasks that need to take action, such as "Schedule a Deployment", or "Disable a work-queue".
ladler¶
ladler is an event driven service that moves / migrates event messages from Redis into the Postgres Event Database for long term storage.
server-background¶
server-background is a background worker process that retrieves scheduling and orchestration tasks from Redis.
For performance reasons, a server task can be enqueued in Redis, and deferred to a later time. Execution is then submitted to server-background asynchronously.
One such example is deleting a flow. This can be an expensive and time-consuming operation to ensure all child elements of a flow are properly deleted, such as flow-runs, task-runs, and logs.
This service allows for flows that are marked as deleted, to perform the operation in an asynchronous manner.
nebula-background¶
nebula-background is a background worker process that retrieves administrative tasks from Redis, similar to server-background.
cloud-work-pools-background¶
cloud-work-pools-background is a background worker process that reads work pool tasks from Redis and executes them asynchronously.
cancellation-cleanup¶
cancellation-cleanup is a loop service that continuously polls the server database for cancelled flow runs that also need to cancel child-runs like subflows and tasks.
expiration-processor¶
expiration-processor is a loop service responsible for identifying flow runs whose expires_at date has passed and soft-deleting them and their related objects.
expiration-setter¶
expiration-setter is a loop service responsible for identifying flow runs that do not have an expiration set and setting them based on the run_retention_days of the flow's workspace's terms.
fail-expired-pauses¶
fail-expired-pauses is a loop service responsible for identifying Paused flow runs that no longer can be resumed. Runs that have been paused past their pause timeout will be marked as Failed.
mark-late-runs¶
mark-late-runs is a loop service responsible for querying runs in a Scheduled state which should have already started and marking them as Late.
partman¶
partman is a loop service responsible for maintaining partitions in the events database. Manages:
* Ensuring daily partitions of the events table exist for the next week.
* Cleaning up partitions older than 30 days.
* Asynchronous index creation on the events table
push-pools-poller¶
push-pools-poller is a loop service that polls flow-runs that are part of a push work pool. This creates asynchronous tasks using arq to be handled by cloud-work-pools-background. For example, a task in a scheduled state will defer / background a submit task, while a task in Completed will queue a clean-up task.
reaper-man¶
reaper-man is a loop service responsible for removing soft-deleted rows.
It is often not feasible to synchronously delete data on request (prompting the necessity of background services).
Instead, some tables have an additional column deleted_at, which is set to the timestamp at which we want to delete rows.
scheduler¶
scheduler is a loop service responsible for querying Deployments and creating scheduled flow runs based on the deployment.
work-queue-monitor¶
work-queue-monitor is a loop service that monitors the health of work-queues. This service checks status in the server DB based on criteria, then emits a health event based health status.
Auth¶
The auth service is one of four separate possible services, depending on the IAM implementation in use.
This can be adfs-auth, okta-auth, ldap-auth, or auth.
Only one auth service should be deployed in any given Self Managed Prefect Instance. Any references to auth anywhere in documentation, are referring to the one of the deployed auth service appropriate for your environment.
auth¶
auth is a web service responsible for authentication and permission lookup. Additionally handles SCIM and user management actions.
The performance of auth is critical - all requests to nebula or server pass through auth first to authenticate the request and populate actor permissions.
adfs-auth¶
adfs-auth web service responsible for ADFS authentication and permission lookup. Similar to the auth service, this service handles user management actions. The main difference between this service and the auth service is that this service directly communicates with an ADFS instance to authenticate.
Similarly to the auth service, the performance of adfs-auth is critical - all requests to nebula or server pass through adfs-auth first to authenticate the request and populate actor permissions.
okta-auth¶
Currenting being implemented.
ldap-auth¶
Currenting being implemented.
events-webhooks¶
events-webhooks is an API web service, specifically for created event webhooks in the UI under the Event Webhooks header.
events-websockets¶
events-websockets maintains and manages the websocket implementation for streaming events. This provides the same purposes as the events-webhooks but is specifically implemented
for Websockets.
server¶
server is the core orchestration and scheduling service.
Additionally, server is one of the main two base Docker images used for the Kubernetes pods.
It comprises all of the core Prefect orchestration and scheduling.
There are four core components of the server service that are segmented using Istio and VirtualServices to improve efficiency and throughput.
flow-run-reads¶
flow-run-reads is a notional / VirtualService that solely handles the flow-run-reads responsibility for the server service.
It is a core service that is configured as part of kubernetes and istio routing policy. Uses the server base Docker image, with service specific (flow-run-reads) parameters passed to it.
flow-run-writes¶
flow-run-writes, like flow-run-reads, is a notional / VirtualService that solely handles the flow-run-writes responsibility for the server service.
It is a core service that is configured as part of kubernetes and istio routing policy. Uses the server base Docker image, with service specific (flow-run-writes) parameters passed to it.
task-run-reads¶
task-run-reads is a notional / VirtualService that solely handles the task-run-reads responsibility for the server service.
It is a core service that is configured as part of kubernetes and istio routing policy. Uses the server base Docker image, with service specific (task-run-reads) parameters passed to it.
task-run-writes¶
task-run-writes is a notional / VirtualService that solely handles the task-run-writes responsibility for the server service.
It is a core service that is configured as part of kubernetes and istio routing policy. Uses the server base Docker image, with service specific (task-run-writes) parameters passed to it.
logs¶
logs is a Web service responsible for writing and reading flow and task run logs.
Separate from the server service - high volumes of logs do not impact orchestration.
Conversely, orchestration can continue to function while logs can be batch written asynchronously.
nebula¶
nebula is a user management API that permissions access to accounts and workspaces.
Authorization is performed on a per-request basis based on information from auth (or ).
Each route is associated with one or more required account level or user level permissions.
Using FastAPI dependencies, each request will ensure the actor has the correct permissions to call a route.
For server, all requests are made against a single workspace and will be of the form <endpoint>/accounts/<account_id>/workspaces/<workspace_id>/<server-endpoint>.
UI¶
ui is a Web Service responsible for displaying and presenting the web user interface frontend.
One of two core Docker images used for the Kubernetes cluster.
Background Tasks¶
Consumers¶
Loop Services¶
Web Services¶
