Custom registry support for PDS components

Custom registry support for PDS components involves the ability to specify and use custom image registries for storing and deploying PDS container images. This feature is particularly valuable in scenarios where organizations have their own private image registries or have pre-defined processes for scanning and validating images.

Prerequisite

• Ensure that you have access to the custom image registry where you want to store and deploy PDS container images. You should have the necessary permissions to push and pull images from this registry.
• Prepare the custom PDS container images that you intend to use. These images should be compatible with PDS and contain the necessary components and configurations.
• If the custom image registry requires authentication, make sure you have the required credentials, such as username and password or access tokens. Store these credentials securely.
• Ensure that your cluster or environment has the necessary network connectivity to reach the custom image registry. Firewalls, network policies, and security groups should be configured to allow outbound traffic to the registry.

Custom registry support for container images

To provide custom registry support for container images:

1. Obtain the custom PDS images from Docker Hub:

   docker pull <image>:<tag>
   note

   You should run this command individually for each container image.

   • docker pull: This is the Docker command used for pulling or downloading container images from a registry.
   • <image>: This part specifies the name of the container image you want to pull. Container images are typically named in the format
   • <registry>/<repository>/<image_name>, where <registry> is the image registry where the image is hosted, <repository> is an optional organizational grouping, and <image_name> is the name of the image. For example, ubuntu is a common image name for the Ubuntu Linux distribution.
   • <tag>: The tag allows you to specify a particular version or variant of the image. Images often have different tags representing different versions, configurations, or variants. For example, latest, 1.0, or development could be valid tags. If you omit the tag, Docker will default to using the latest.

2. Re-tag the images by replacing the registry name (for example,, docker.io) with your custom registry server. Optionally, you can use a new namespace in your registry other than portworx:

   docker tag <source-registry>/<namespace>/<image_name>:<tag> <private-registry>/<namespace>/<image_name>:<tag>
   • <source-registry>/<namespace>/<image_name>:<tag>: Specifies the source container image that you want to create a new tag for. <image_name> represents the name of the source image, and <tag> represents the specific version or tag of that image. For example, if you have an image named "myapp" with the tag "v1.0," you would specify it as "myapp:v1.0".
   • <private-registry>: This is the address of a private registry where you want to store the newly tagged image. A private registry is a secure location where you can store container images that are not publicly accessible. You need proper authentication and permissions to access and push images to a private registry.
   • <namespace>: This part represents an optional directory structure within the private registry where you want to store the image. You can organize your images into directories for better organization. It is common to use the name of the application or project as the directory name.
   • <image_name>: This is the name you want to give to the newly tagged image within the private registry. It must be the same source image's name if you wish to organize your images differently in the private registry.
   • <tag>: This is the tag you want to assign to the newly tagged image in the private registry. It must be the same as the source image's tag or a different one. Tags help you identify specific versions or variations of an image.
   note

   You should not change the <image_name> or <image>:<tag>, otherwise data services will fail to deploy. Tag the PDS component images with the appropriate names and versions matching the custom registry:

3. Push these tagged PDS images to your custom registry using the docker push command:

   docker push <private-repo>/<dir-name>/<image_name>:<tag>

4. Configure PDS components to utilize the custom image registry. For this, you should include the following parameters when executing the Helm command. These parameters are generated within the PDS user interface during the process of adding or upgrading a target cluster:

   • Set the image registry:

     Use the --set flag to specify the imageRegistry parameter. This parameter should be assigned the URL of your custom registry, formatted as <private-registry>/<namespace>, without any trailing slash.

     For example:

     --set imageRegistry=<private-registry>/<namespace>

   • (Optional) Provide the image pull secret:

     Similarly, employ the --set flag to define the imagePullSecret parameter. This parameter should be set to the name of the secret used for authentication when pulling images from the custom registry.

     For example:

     --set imagePullSecret=<my-imagepullsecret>

     You should include these parameters within your Helm command to ensure that PDS components use the specified custom registry and that they have the necessary credentials (provided by the image pull secret) to access images from that registry. This configuration enables PDS to seamlessly retrieve and deploy container images from your custom registry during the installation or upgrade process.