Skip to main content
  1. Posts/

Storing Helm in Docker Registries

··278 words·2 mins
Author
Hairizuan Noorazman
Software engineering experiments, implementation notes, and lessons learned.

We can apparently now store helm charts in Docker registries - this was made available via helm commands since v3.8.0. https://helm.sh/docs/topics/registries/

Now with that being available for use, we can now use it across a variety of storage mechanism (as compared in the past when the artifacts produced through it has to be managed in some of file system and would require some of index file to list all available helm charts available).

To try things out locally, let’s try setting up a simple Docker registry on our host machine:

docker run -d -p 5000:5000 --restart always --name registry registry:2

We can then try to push a golang image into it

docker pull golang
docker tag golang:latest localhost:5000/golang:latest
docker push localhost:5000/golang:latest

Building helm chart and pushing it in
#

First things first is to ensure that our helm version is valid and has the capability to do the following task of pushing helm charts into oci registries

helm version
# Output:
# version.BuildInfo{Version:"v3.10.1", GitCommit:"9f88ccb6aee40b9a0535fcc7efea6055e1ef72c9", GitTreeState:"clean", GoVersion:"go1.18.7"}

Next step is to build up a helm chart. Here is an example of one:
https://github.com/hairizuanbinnoorazman/Go_Programming/tree/master/Web/basicHelm

Within this folder, run the following command to package it:

helm package ./basic-app/

This command would create the basic-app-0.1.0.tgz file which we can then push the registry

helm push basic-app-0.1.0.tgz oci://localhost:5000/basic-app
Pushed: localhost:5000/basic-app/basic-app:0.1.0
Digest: sha256:6d3557ff6044f490d535e0cda7bbf979c7879a1380af6cf6a1dc9d8b532d5134

With that, we now have a proper place to put our helm artifacts - they can all be centralized in container based registries (since it supports the oci standard). We no longer need to consider putting it in alternative storage locations e.g. a simple filesystem or even blob storage.

More details of this is available on the following documentation page:
https://helm.sh/docs/topics/registries/

Related

Access Cloud SQL from Google Kubernetes Cluster without Cloud SQL Proxy

··673 words·4 mins
Introduction # Similar to my previous blog post, we would usually be connecting Google Kubernetes Engine (GKE) clusters to Cloud SQL databases by using the Cloud SQL Proxy. However, we can now use Private Service Connect, which allows for private communication between different Google Cloud services, similar to how we did for connecting our application in Google Compute Engine (VM) to a Cloud SQL instance.

Deploy Golang Apps that interact with headless service in Kubernetes

In certain application scenarios - there is a need to have applications that need to do client side load balancing to a bunch of servers. Such cases are pretty rare - but we won’t be covering the exect reasons or scenarios or when these are needed. Instead, we will cover how we can do so with Golang applications in Kubernetes cluster.

Building a code assessment tool but in Kubernetes

··1933 words·10 mins
Container based security measures Smaller images for code execution platform Not running the container as root Kubernetes related Run the deployment in different namespace Setting up a new Service account in kubernetes Ensuring service account token is not mounted in potentially vulnerable pods Ensuring that the container is started with non-root access Ensuring resource limits are set Set security context Setting network policy Using a stricter seccomp/apparmor profile Tool related Ensure limited logs sniffed Ensure that there is a time limit of code executions Future efforts I had previously attempted to build a code assessment tool in docker. That involves doing the following:

Debugging Distroless Kubernetes Pods

There is a trend of images that follow the philosophy of minimizing the size of image by removing almost everything out of image. This helps with getting image downloaded more quickly by kubelet into the nodes as well as possibly reducing the attack surface of the container even further (I suppose it’s harder to do things in a container if utilities like shell or bash don’t exist within it). You would probably see errors such as this for those containers that have somewhat remove the shell/bash: