A collection of architecture diagrams that shows the interactions of different environments in mature productions settings.
In order to understand the interaction between ZenML clients, a ZenML Server and other environments, we have compiled a collection of diagrams that highlight certain interactions.
The most basic production stack will contain an orchestrator, an artifact store and a Container registry. The following diagram show how a pipeline is run in such a configuration. After fetching the necessary information from the ZenML Server (which orchestrator, which container registry), the user code is built into a docker image on the client side. It is then pushed to the container registry. The ZenML client then kicks off the pipeline run on the orchestrator side. The orchestrator pulls the image containing the user code then assembles and launches the pipeline. The individual steps communicate with the ZenML Server, to fetch information on other components and to read and write metadata pertaining to the current pipeline run (this includes the location of previous step outputs/ cached data).
In many production settings it is undesirable to have all developers accessing and running on the production environments. Instead, this is usually centralized through the means of git ops. This same principle can be easily used for pipeline deployments using ZenML. Here is an example repository that shows how. The following architecture diagram visualizes how a pipeline would be run through an automated action that is triggered when new code is pushed to the main code repository.
ZenML with Git Ops
In most production settings it is preferred to store/rotate secrets within one unified secret manager. The client machines as well as the orchestration components (orchestrator/ step operator) can be separately authenticated with this secret manager (e.g. with CLI authentication). Now the component configurations and docker images no longer rely on baked in credentials.
The experiment tracker is a very popular component of the stack that helps log and compare the metrics of different runs. This diagram shows how the experiment tracker fits into the overall architecture.