WilliamLam.com

How to setup Harbor registry on Synology

by // 6 Comments

With my recent exploration of GenAI and using a private ChatGPT solution with my own blog posts, I quickly realized in the space of AI/ML, the required software dependencies can take up a significant amount of storage, especially for a kubernetes/container-based deployment.

To give you an example, to deploy the private ChatGPT (h2ogpt) application using kubernetes, just the container image itself is a whopping 40GB+! 😲

Unfourntately, this is not a one off scenario but a common theme when working in the AI/ML space that the size of the packages and drivers are extremely large even when using containers. I figure I should probably setup my own container registry instead of pulling directly from the Internet given the size of these images.

I already have a local Harbor instance running in a VM but with my Synology, I have been using it centralize a number of functions and that would be the ideal place to actually run Harbor. While you can run individual containers on the Synology as I have demonstrated HERE with GitLab, the Harbor installation processes relies on Docker Compose, which Synology does not natively support using the Synology DiskStation Manager (DSM) interface.

With a little bit of tinkering and trial/error, I was able to finally get Harbor running on my Synology and centralize all my storage needs including having my own container registry.

[Read more...]

How to configure Knative and containerd in VMware Event Broker Appliance (VEBA) to use a private registry?

by // 2 Comments

I was recently helping out fellow colleague Patrick Kremer who was looking into an issue that one of our users had filed on how to configure the VMware Event Broker Appliance (VEBA) so that it can take advantage of a custom container registry for deploying VEBA functions. If you attempt to specify a container image from a private container registry, especially one that has a self-signed certificate, you will see the following error:

Unable to fetch image "harbor.primp-industries.local/library/veba/kn-py-echo:1.0": failed to resolve image to digest: Get "https://harbor.primp-industries.local/v2/": x509: certificate signed by unknown authority; Get "https://harbor.primp-industries.local:443/v2/": x509: certificate signed by unknown authority

I had assumed that this should have been a pretty trivial configuration change to make the underlying Kubernetes container runtime trust the desired container registry and that there would be an easy to follow tutorial that Patrick could search for. The latest release of VEBA has moved away from using the Docker runtime to containerd and this should have helped narrow down the search results, at least that was our assumption.

Not only are there plenty of resources online, but there seem to be multiple methods depending on the version of Kubernetes and containerd which was pretty overwhelming. After several attempts using various blog articles, Patrick found that the trust error has still not gone away. I finally decided to take a closer look and discovered that there are actually two components that must be updated to properly support a private container registry: containerd & Knative Serving Controller. I eventually found this page in the Knative Serving documentation that provided a hint but ultimately, I was not able to fully grok the details until I came across this Github thread that brought clarity on how to create the required secret for the root CA certificate which would allow the Knative Serving controller to trust the root CA certificate.

Below are the instructions for the required changes and I have also attempted to simplify the steps by providing automation snippets that makes it easy for anyone to consume. In my setup, I am using Harbor registry which was built from my Harbor Virtual Appliance but the steps should apply for any other private container registry.

[Read more...]

Enhancements to VMware Tools 12 for Container Application Discovery in vSphere 

by // 2 Comments

VMware Tools 12 was just released and it adds a number of new features including support for Windows 11 and Windows Server 2022, Salt Stack Minion deployment and the use of OpenSSL 3.0 library to just name a few.

One additional feature that is quite interesting is the enhancement to the Application Discovery feature that was shipped with VMware Tools 11 which provides organizations with additional visibility of the running processes within a VM.

With VMware Tools 12, we now have a more granular method for discovering container-based processes (Docker or Containerd) running within a Linux VM, which is pretty cool if you ask me!


Similiar to the Application Discovery feature, a new VM guestinfo variable has been introduced called guestinfo.vmtools.containerinfo that will be populated with the list of running containers. By default, the polling interval is every 6 hours with a default of listing the first 100 containers, these and other settings can be adjusted which you can find in the official VMware documentation.

Simliar to the Application Discovery feature, I have also updated my PowerCLI function Get-VMApplicationInfo.ps1 to include this additional functionality for users that would like to extract this information and I have created a new function called Get-VMContainerInfo, which you see how it functions in the screenshot above. In addition to console output, you can also save the information in both CSV and JSON format.