Develop a Custom Container Registry
How to develop a custom container registry
Base Abstraction
In the current version of ZenML, container registries have a rather basic base abstraction. In essence, their base configuration only features a uri
and their implementation features a non-abstract prepare_image_push
method for validation.
This is a slimmed-down version of the base implementation which aims to highlight the abstraction layer. In order to see the full implementation and get the complete docstrings, please check the API docs.
Building your own container registry
If you want to create your own custom flavor for a container registry, you can follow the following steps:
- Create a class which inherits from the
BaseContainerRegistry
class and if you need to execute any checks/validation before the image gets pushed, you can define these operations in theprepare_image_push
method. As an example, you can check theAWSContainerRegistry
. - If you need further configuration, you can create a class which inherits from the
BaseContainerRegistryConfig
class. - Bring both of the implementation and the configuration together by inheriting from the
BaseContainerRegistryFlavor
class.
Once you are done with the implementation, you can register it through the CLI as:
It is important to draw attention to when and how these base abstractions are coming into play in a ZenML workflow.
- The CustomContainerRegistryFlavor class is imported and utilized upon the creation of the custom flavor through the CLI.
- The CustomContainerRegistryConfig class is imported when someone tries to register/update a stack component with this custom flavor. Especially, during the registration process of the stack component, the config will be used to validate the values given by the user. As
Config
object are inherentlypydantic
objects, you can also add your own custom validators here. - The CustomContainerRegistry only comes into play when the component is ultimately in use.
The design behind this interaction lets us separate the configuration of the flavor from its implementation. This way we can register flavors and components even when the major dependencies behind their implementation are not installed in our local setting (assuming the CustomContainerRegistryFlavor
and the CustomContainerRegistryConfig
are implemented in a different module/path than the actual CustomContainerRegistry
).