Deploy a stack component
Individually deploying different stack components.
This is an older version of the ZenML documentation. To read and view the latest version please visit this up-to-date URL.
Deploy a stack component
If you have used ZenML before, you must be familiar with the flow of registering new stack components. It goes something like this:
Commands like these assume that you already have the stack component deployed. In this case, it would mean that you must already have a bucket called my_bucket
on AWS S3 to be able to use this component.
We took inspiration from this design to build something that feels natural to use and is also sufficiently powerful to take care of the deployment of the respective stack components for you. This is where the <STACK_COMPONENT> deploy
CLI comes in!
The deploy
command allows you to deploy individual components of your MLOps stack with a single command 🚀. You can also customize your components easily by passing in flags (more on that later).
To install mlstacks
, either run pip install mlstacks
or pip install "zenml[mlstacks]"
to install it along with ZenML.
MLStacks uses Terraform on the backend to manage infrastructure. You will need to have Terraform installed. Please visit the Terraform docs for installation instructions.
MLStacks also uses Helm to deploy Kubernetes resources. You will need to have Helm installed. Please visit the Helm docs for installation instructions.
For example, to deploy an artifact store on a GCP account, you can run:
The command above takes in the following parameters:
Name: The name of the stack component. In this case, it is
my_store
.Flavor: The flavor of the stack component to deploy. Here, we are deploying an artifact store with the
gcp
flavor.Provider: The provider to deploy this stack component on. Currently, only GCP, AWS, and K3D are supported as providers.
Region: The region to deploy the stack component in.
Extra Config: Some components can be customized by the user and these settings are passed as flags to the command. In the example above, we pass the GCP project ID to select what project to deploy the component to.
Successful execution of this command does the following:
It also automatically registers the deployed stack component with your ZenML server, so you don't have to worry about manually configuring components after the deployment! 🤩
The command currently uses your local credentials for GCP and AWS to provision resources. Integration with your ZenML connectors might be possible soon too!
Destroying a stack component
Destroying a stack component is as easy as deploying one. You can run the following command to destroy the artifact store we created above:
This will destroy the deployed infrastructure and prompt you if you also want to remove and deregister the component from your ZenML server.
🍨 Available flavors for stack components
Here's a table of all the flavors that can be deployed through the CLI for every stack component. This is a list that will keep on growing and you can also contribute any flavor or stack component that you feel is missing. Refer to the Contribution page for steps on how to do that 😄
Component Type | Flavor(s) |
---|---|
Artifact Store | s3, gcp, minio |
Container Registry | aws, gcp |
Experiment Tracker | mlflow |
Orchestrator | kubernetes, kubeflow, tekton, vertex |
MLOps Platform | zenml |
Model Deployer | seldon |
Step Operator | sagemaker, vertex |
✨ Customizing your stack components
With simplicity, we didn't want to compromise on the flexibility that this deployment method allows. As such, we have added the option to pass configuration specific to the stack components as key-value arguments to the deploy CLI. Here is an assortment of all possible configurations that can be set.
Experiment Trackers
You can assign an existing bucket to the MLflow experiment tracker by passing the -x mlflow_bucket=...
configuration:
Artifact Stores
For an artifact store, you can pass bucket_name
as an argument to the command.
Container Registries
For container registries, you can pass the repository name using repo_name
:
This is only useful for the AWS case since AWS requires a repository to be created before pushing images to it and the deploy command ensures that a repository with the name you provide is created. In case of GCP and other providers, you can choose the repository name at the same time as you are pushing the image via code. This is achieved through setting the target_repo
attribute of the DockerSettings
object.
Other configuration
In the case of GCP components, it is required that you pass a project ID to the command as extra configuration when you're creating any GCP resource.
Last updated