JB

Dxcker Rework

Some life lessons channeled into the Dxcker project

Dxcker Rework

Bitnami broke everything

I was already facing issues with linuxserver.io. Their containers were making a few too many assumptions and causing issues when I didn’t play by their inane rules.

I’ve also been running developer maintained Helm Charts. Sadly, developers are not sys engineers. It’s why we have “ops” in “devops”. Most of my Helm Charts were throwing errors over dependencies due to Bitnami.

This really forced my hand and here I am; making breaking changes to a stale project.

What is Dxcker.. now?

Dxcker is now publishing Helm Charts and Docker Images for public use.

Our project is hosted at gitlab.com/dxcker. Here, I maintain images which I personally use in my home lab and in production.

Dxcker Image Conventions

Dxcker Images are expected to be simple and easy to use. They’re to run a single service in the foreground with logging to stdout.

All Dxcker images live under (https://gitlab.com/dxcker/image).

Images were originally intended to only use ENTRYPOINT and CMD for better portability however it came at the detriment of pre-setup phases.

While this approach was/is fine for 90% of the images I had created, it presented some issues for services like MariaDB and Apache.

Sometimes you want a pre-init. In Apache I could define a minimal default config and load in from the /config directory. However in MariaDB you want to be able to run pre-init SQL scripts, which requires the use of an entrypoint script.

This limitation in my approach reworked our project goals to roughly be:

The above obviously only applies to the Docker images. The Helm Charts are another beast.

Dxcker Chart Conventions

I genuinely have no idea what best conventions are. I’m currently building out the catalog however maintaining standards between them all is time consuming.

At the moment, I am trying to configure things like annotations, labels, env vars, and other such configurables via the values.yaml. I’m also trying to pay special attention to passing env vars via secrets, as that’s the most useful thing in prod.

All Dxcker Charts live under (https://gitlab.com/dxcker/chart).

At the moment I am “getting them to work”, primarily with warp.dev. As I find my flow, I’ll start standardizing the deployment stack as it’s pretty consistent between services.

Once that’s done, I will start cleaning them up to be a little more readable.

Why Bother?

The way people are configuring Docker containers is quite frankly bullshit.

We used to have documentation freely available online to mentor us down the path of ‘best practices’, and educate us on creating usable and consistent experiences for developers using our systems.

Docker has many benefits but it has badly hurt that community spirit.

Between developers not knowing why they’re doing certain actions and sys admins stubbornly trying to put initrc into containers, it’s tough to know what to trust.

Dxcker provides me with a stable and consistent configuration. All images stem from a base image, which is based on Debian. No funky repos to break. No funky conventions that don’t make sense.

All containers run as the UID 1000 and GID 1000. You can reconfigure these. Sure the user ID might not matter to you running Docker Volumes and thinking they’re persistent, but it does matter to people using any form of volume mount that direct maps folders from a storage backend.

And I’m creating my perfect slice of Docker computing for myself. Why not share it with others.

Automations

The automation is kind of cool imo. But that’s just me.

The gitlab.com/dxcker/automations/gitlab project has the Tofu for building out the Gitlab Group. It bootstraps image and chart repo creations and centralizes build pipelines for easy updating.

There is some tweaking to go. Namely I want to have a bunch of avatars on projects. But it functions perfectly fine for adding and removing projects.

If you want to create a new project under dxcker please feel free to send an MR.

Container Registry

We store all containers and charts are OCI compliant images in Gitlab. This saves me bandwidth… thanks Gitlab :)

I have two short domains; rbcr.io and dxckr.io (I cant remember the second). I’ll adapt these to be OCI compliant registries eventually but there’s a bit of work there.

For now, for Dxcker, please just use registry.gitlab.com/dxcker/

Project Looks Empty

Yeah because I wiped it.

All legacy images have been re-added. Weirdly it seemed to just be the reverse proxy that was the massive one. All of the rest are being rebuilt and when I finish searching for a job, I’ll port over the old code bases.

If anyone wants something they can ask for it I guess.