Context
VMware Cloud Foundation (VCF) Operations offers comprehensive IT management, focusing on proactive operations and security. It monitors, manages, and optimizes IT operations by collecting data using management packs. VCF Operations includes built-in packs for components like vCenter and VCF. Additionally, it provides tools—a management pack builder and an Integration SDK—that enable users to develop custom management packs for monitoring applications and infrastructure components not covered by the built-in options. These user-developed management packs can be uploaded and deployed to specific environments, allowing organizations to tailor their monitoring capabilities and integrate diverse technologies within their VCF ecosystem.
The Integration SDK provides tools and libraries in Python and Java to aid in development of management packs to add custom objects, data, and relationships from an endpoint into VCF Operations. The Integration SDK generates containerized management packs and hence requires a container registry for its storage and retrieval. This container registry must be accessible by the VCF Operations Cloud Proxies to download the container.
By default, the Integration SDK’s build environment’s container registry must be accessible by the VCF Operations Cloud proxies in the intended deployment environment. In most scenarios, the container registry used by the Integration SDK’s build environment is accessible by the VCF Operations Cloud Proxies in the deployed environment. However, in the following situations, Integration SDKs build environment’s container registry may not be accessible by the VCF Operations Cloud proxies in the intended deployment environment:
- VCF Operations has been deployed in an air-gapped environment and there is no connectivity to the internet to access public container registry.
- The VCF Operations Integration SDK’s build environment has used a private container registry and there is no connectivity from the customer’s infrastructure to this private container registry.
This blog outlines the steps required in both the build environment and the deployed VCF Operations environment to transfer VCF Operations Integration SDK builds from the DEV container registry to a private registry in the deployed environment, where direct connectivity to the build environment’s container registry is unavailable. These steps are not required in most scenarios where the container registry used by the Integration SDK’s build environment is accessible by the VCF Operations Cloud Proxies in the deployed environment.
Steps to transfer VCF Operations Integration SDK builds from build container registry to a private registry in deployed VCF Operations environment
Follow the steps below to transfer the container image and the management pack’s PAK file from the Integration SDK’s build environment to the deployed VCF Operations environment that does not have access to the container registry in the Integration SDK’s build environment:
Steps to be performed in the Integration SDK’s build environment
- Set up your VCF Operations Integration SDK build environment by following the steps outlined in the VCF Operations Integration SDK Get Started guide.
- Build the management pack by running the following command:
mp-build
This command produces a container image and a management pack (PAK) file. - In the lower portion of the $ManagementPackProjectDirectory/logs/build.log file, locate the following line:
17:21:18,950 urllib3.connectionpool DEBUG http://localhost:None “POST /v1.47/images/vcfOperations-local.packages.xyz.com/vcf_operations_Integration_sdk_mps/mpname/push?tag=1.0.0_1756336878.8444002 HTTP/1.1″ 200 None - Note down the repository path in the container registry for the container image and the image tag name. In this example, container registry path for the container image is vcfOperations-local.packages.xyz.com/vcf_operations_Integration_sdk_mps/mpname and the image tag is 1.0.0_1756336878.8444002
- Pull the newly built container image to your build environment by running the following command:
docker pull FullPathToContainerImageInRegistry:Tag
For example:
docker pull vcfOperations-local.packages.xyz.com/vcf_operations_Integration_sdk_mps/mpname:1.0.0_1756336878.8444002 - Save the container image as a tar file by running the following command:
docker save -o mpname_imagetag.tar
For example: docker save -o mpname_1.0.0_1756336878.8444002.tar - In the $ManagementPackProjectDirectory/build directory, there will be a mpname_1.0.0.pak file.
- Share the mpname_1.0.0.pak and mpname_1.0.0_1756336878.8444002.tar files with someone who has access to the deployed VCF Operations environment, using a file-sharing mechanism (e.g., Google Drive, OneDrive, etc.).
Steps to be performed in the deployed VCF Operations environment
- Establish a private container registry within the air-gapped target environment, ensuring it’s accessible by the VCF Operations Cloud proxies. Alternatively, if the target environment has internet connectivity, you can set up a container registry on the internet, provided Cloud Proxies can connect to it.
- On a local laptop or server, configure a Docker client to connect to the private container registry within the air-gapped environment.
- Download the following shared files to the computer that has access to the internet: mpname_1.0.0.pak and mpname_image_tag.tar
- Transfer the downloaded files from the computer to the local laptop or a local server with docker client with access to the private container registry.
- Load the container image on the docker client system, by running the following command:
docker load -i mpname_image_tag.tar
For example:
docker load -i mpname_1.0.0_1756336878.8444002.tar - Note down the current docker image repository and tag of the newly loaded container image by running the following command:
docker images - Tag the newly loaded container image with the private registry’s repository path by running the following command:
docker tag current_repository/path/to/image:Tag private-registry.local.network/new_path/to/image:Tag
For example:
docker tag vcfOperations-local.packages.xyz.com/vcf_operations_Integration_sdk_mps/mpname:1.0.0_1756336878.8444002 private-registry.local.network/new_path/to/mpname:1.0.0_1756336878.8444002 - If previously uploaded container images for this management pack are not needed, remove those images from the private container registry.
- Push the image to the private container registry by running the following command:
docker push private-registry.local.network/new_path/to/image:Tag
For example:
docker push private-registry.local.network/new_path/to/mpname:1.0.0_1756336878.8444002 - Get the docker image digest (SHA256: alphanumerictext) for the newly loaded container image by running the following command:
docker images --digests - Update the REGISTRY, REPOSITORY and DIGEST fields in the management pack adapter’s $VCOPS_BASE/user/plugins/inbound/mpname.conf file for each node in the VCF Operations Cluster, excluding cloud proxies. REGISTRY field value must be set to private container registry’s FQDN, REPOSITORY field value must be set to the container image path in the customer’s private registry and the DIGEST value must be set to the SHA256 digest value that was retrieved in earlier steps.
For Example:
REGISTRY=private-registry.local.network
REPOSITORY=/new_path/to/image
DIGEST=sha256:a48fb2266cd625159c56699d754446937707c348298dd17416ee7bce771595eb - For each Cloud Proxy running this management pack’s adapter, log in and restart the Cloud Proxy service using the command:
service collector restart - Login to VCF Operations user interface with administrator privileges
- Install or upgrade the management pack using the mpname_1.0.0.pak file.
- Add an Integration account that uses the cloud proxy as the collector with this management pack, and then test the connection. The cloud proxy will pull the container image from the private container registry, after which the adapter begins collecting data.
Credits
Thanks to Mark Arbogast and Sven Gmelin for their valuable inputs and validating these steps in a customer environment.
