Deploying ZenML
A guide on how to deploy ZenML
As with any other service, however, ZenML needs to be deployed first in order to be able to use it. This section covers the various scenarios when it comes to deploying ZenML, from starting locally to transitioning to the cloud.
The components of a ZenML Deployment
A ZenML deployment can consist of the following three components:
The ZenML client.
A SQL database.
An optional FastAPI HTTP server that exposes a RESTful API as well as a UI.
An optional external secrets management service that is used as a backend for the ZenML secrets store.
ZenML can also be deployed with an HTTP REST interface between the client machine and the database. This is also the interface used by the ZenML dashboard when loaded in your browser. Especially in multi-user settings, this is the recommended configuration scenario.
Running ZenML Locally
Running ZenML locally is an easy way to experiment with your pipelines and design proof-of-concepts. Scenarios 1 and 2 below deal with the local deployment of ZenML. In these scenarios, the ZenML client and database are both located on the same machine.
Scenario 1: Direct interaction with Local SQLite
This is likely the first experience that users will run into. Simply pip install zenml
and dive right in without having to worry about a thing. Your stacks, stack components, pipeline runs and secrets are all stored in a SQLite database located in your global configuration directory (e.g. at ~/.config/zenml/local_stores/default_zen_store/zenml.db
if you're running on Linux). The ZenML client creates and directly connects to this database. You don't need to worry about a thing.
Scenario 2: Local Deployment of the HTTP server
In this use-case, a local version of the ZenML HTTP server is running on your machine and is using the same database as your local client in Scenario 1. All client calls go through REST API endpoints instead of writing directly to the database. This option allows you to visualize and navigate your stacks and tracked pipeline information in the ZenML dashboard.
Switching from Scenario 1 to Scenario 2 and back is as simple as running zenml up
and zenml down
.
Deploying ZenML in the Cloud: Remote Deployment of the HTTP server and Database
For a lot of use cases like sharing stacks and pipeline information with your team and for using cloud services to run your pipelines, you have to deploy ZenML in the cloud.
Your ZenML code interacts with the server across different concerns. For example,
your local machine connects to the server to read and write the stack configurations to allow collaboration.
the individual orchestrators and step operators communicate with the server to write and track your pipeline run data.
the dashboard is served from the server to give a UI interface to all of your metadata.
the ZenML server also acts as a central point of access for managing secrets.
As such, it is important that you deploy ZenML in a way that is accessible from your machine as well as from all stack components that need access to the server.
Scenario 3: Server and Database hosted on cloud
This is similar to Scenario 2, with the difference that both the HTTP server and the database are running remotely rather than on your local machine. This is how you can unleash the real collaborative power of ZenML. With this type of deployment, stacks and pipeline runs can be shared with other users across larger teams and organizations. If you are using cloud, or shared on-premise services to run your pipelines, such as Kubeflow, GitHub, Spark, Vertex AI, AWS Sagemaker or AzureML, a centralized shared ZenML Server is also the recommended deployment strategy for ZenML, because these services will need to communicate with the ZenML server.
When deploying the ZenML server in the cloud, you may also opt to use a cloud secrets management back-end like the AWS Secrets Manager, GCP Secrets Manager or Azure Key Vault to store your secrets. This is the recommended way to store your secrets in production. The ZenML server will act as a proxy for all secrets related requests, which means that the chosen secrets store back-end is not visible to the ZenML client.
The diagram below shows the architecture: both the server and database are remote and can be provisioned and managed independently. The server takes the connection details of the database as one of its inputs and that's how they work together. You can refer to the deployment options pages, to see how it's done in each case. Using a cloud deployment enables you to collaborate with your team members by sharing stacks and having visibility into the pipelines run by your team. This new paradigm will also evolve to include more advanced access control features that you can use to manage the roles and responsibilities of everyone in your team through the ZenML Server.
Such a remote deployment unlocks ZenML to its full potential as the MLOps hub within your production stacks. The diagram below visualizes how a pipeline is run through a deployed ZenML Server with a remote orchestrator, artifact store and container registry.
You can use any of the following ways to get started:
In the following pages, we take a look at each of those options.
Last updated