We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
Analysis Summary
Ask yourself: “Did I notice what this video wanted from me, and did I decide freely to say yes?”
Worth Noting
Positive elements
- This video provides a clear, high-quality technical walkthrough of Helm charts, Kubernetes secrets, and persistent storage configuration for a specific DevOps tool.
Be Aware
Cautionary elements
- The integration of affiliate hardware links means the 'Cloud Hardware' recommendations are commercially motivated rather than purely objective technical choices.
Influence Dimensions
How are these scored?About this analysis
Knowing about these techniques makes them visible, not powerless. The ones that work best on you are the ones that match beliefs you already hold.
This analysis is a tool for your own thinking — what you do with it is up to you.
Related content covering similar topics.
Installing Proxmox on a Home Lab
Heavy Metal Cloud
Talos Linux for Kubernetes on Proxmox
TheAltF4Archives
MUST HAVE Home Server Companion Apps (mobile)
TechHut
Kubernetes (k3s) for Shared Services
Heavy Metal Cloud
I might switch from Proxmox to MicroCloud...
TechHut
Transcript
Okay, my little cloud is starting to come together. I have one server that's dedicated to DNS and some other networking task. In my last video, I set up a server for shared services that'll be used by my Praxmax cluster. Today, I'm going to create my first shared service called a container registry. So, what's the purpose of a container registry and why do I need it in my little cloud? You see all my applications will be running on top of Kubernetes which sits on top of Proxmox. Let's zoom into Kubernetes and take a closer look. Applications in Kubernetes run in something called a pod. The pod contains your application code which runs inside containers like Docker. What the pod gives us is a life cycle for creating the containers and tearing them down. During the creation process, the pod will grab the container image and that image has to come from somewhere and that somewhere is called a container registry. A container registry is a repository that catalogs and stores container images. Some popular registries are DockerHub and Red Hats Quay.io, but for my cloud, I'll create my own so I can keep everything in house. The software I decided to use for my container registry is called Twony. I'll have a link to the GitHub page in the description below. Before the install, there are a few things I'll need. First is a way to authenticate to the service. And for that, I'll use a simple username and password. Those credentials will be encoded using a tool from the HTTP Apache project. Again, the Twi service will be installed on my shared services cluster on top of Kubernetes. I'll use a tool called Helm to handle that. Finally, I'll be securing the service using a TLS connection. If you want to learn more about how I created the certificates, check out my videos explaining TLS. Okay, from this point on, I'll be typing in some commands into a shell. To make things easier, I've created a GitHub page with all the steps. Link in the description below. I'll also assume that you have a Kubernetes cluster running and it's ready to go. To authenticate to our registry, we'll need an encoded username and password. I'll first need to install some tools from Apache and then run this command to perform the encoding. And this is what the encoding will look like. With that in place, I need to create a Kubernetes secret for my TLS certificate and private key. I'll use these cube cuddle commands to create the name space and the secret. The important part here are these two files, the certificate containing the public key and the private key. Make sure the files are located in the same directory where you're running the command. Here's another command to inspect the secret that we just created. With the dependencies out of the way, I can now run Helm to get everything installed. Helm uses a values file and this is just a YAML file with configurations for the installation. Let's take a closer look at the one I'll be using. At the top, there's some information about the Docker image and the version of Twi. This will be pulled from the public DockerHub repository. Further down is an ingress section. This defines how the registry will be exposed outside of Kubernetes. I'll be using a domain name called registry.heavy at heavy metalcloud.land, and I'll be securing that domain with TLS. The secret here contains the public and private key that I set up earlier. Further down, we have a persistent section. In my last video about shared services, I talked about persistent storage in Kubernetes. I'll be using the Longhorn storage class that I set up in the previous video. Basically, the Docker images have to be stored somewhere. So, I'll be storing them as files in the Longhorn storage system. Finally, there's a secret section. The important entry here is HT password. This is where you pass the encoded username and password from a previous step. All right, there's one more section I want to show you. Under the config data block, you have the option to add a proxy. This will allow you to mirror public container registries and effectively act as a pass through with some caching. In this case, I'm mirroring a Docker repo. Okay, with the values file configured, let's run the helm command to make sure that worked. I'll run a few cube cuddle commands. And here you can see the pod that was created. And this is what's actually running the container registry. This command shows the ingress along with the connection information. From a storage perspective, these are the Kubernetes objects that will handle persistence. The higher level abstraction is called a PVC and the low-level storage is a PV or persistent volume. Now, let's make sure everything is working. I'll hop on my laptop, then grab an EngineX image from a public docker hub repository. To access my trun service, I'll first have to log in. Then I'll tag the enginex image so that it points to my registry and then push it up. To test, we can use an endpoint that truin exposes as a web page. If everything is working, we should be able to see the EngineX image from the browser. And there it is. All right, my first shared service is installed and ready to go. In my next video, I'll install the next service called Open LDAP that I'll use to manage user accounts in my cloud. Thanks for stopping by and I'll see you in the next video.
Video description
In this video, I’m setting up Twuni, a private container registry, as a shared service on my Proxmox and Kubernetes cluster. We’ll walk through why you need a local registry to keep your container images in-house, how to handle authentication with Apache HTTP tools, and how to secure everything with TLS and Longhorn persistent storage. 🔔 **Subscribe** for more hands‑on cloud tutorials! *To follow along, check out my GitHub page! All the commands and instructions from this video are in a README file:* *https://github.com/heavy-metal-cloud/youtube/tree/main/videos/build-your-own-cloud-series/07-container-registry/twuni* 00:00:00 - Intro 00:02:11 - Creating Auth Credentials & K8s Secrets 00:03:01 - Helm Values for Twuni 00:03:48 - Persistent Storage with Longhorn 00:04:58 - Testing: Pushing your first Nginx image Links referenced in this video: https://github.com/twuni/docker-registry.helm https://hub.docker.com/ https://quay.io/ https://httpd.apache.org/docs/current/programs/htpasswd.html Amazon Affiliate Links - The Cloud Hardware: https://amzn.to/49GQo81 https://amzn.to/48c5nUT https://amzn.to/48bkX38 https://amzn.to/43Qeh9o https://amzn.to/43J6TfV https://amzn.to/4p7dsBx