AIKester Docs

This is the documentation site for a number of Docker containers I build and maintain. These containers I use internally for the most part, but I make them public for others who want a stable Docker container setup.

Philosophy

In order for me to rely on a container in my setup, I want it to have these things:

  • Stable, known versions. For example, a tool like PHP or Hugo should have containers tagged for current major and minor versions. You should be able to opt for a latest version, or lock to a fairly specific version should you need to. In many cases, tools and other parts of the application need updated with major version changes, so containers that just use latest as the only available version in most cases are not my preference.
  • Regular updates. Containers, even if the software version doesn’t change, should see some sort of regular updates. The contaienr image and libraries need routine updates to ensure security issues and the like are patched.
  • Transparent The container’s source should be public and easy to replicate.
  • A good fit The reason I made most of these is because I didn’t want to bend how I operate to fit a mold of some container that may or may not be a good overall fit.

In the containers I build, you’ll hopefully see those ideas materialized.

I realize in some cases I’m duplicating the efforts of tools like linuxserver.io that do a great job maintaing a collectin of tools that are ready to ship in containers, but other tools weren’t a great fit.

Source

I mirror all my container source code to GitHub from a local Gitlab instance that houses the authoritative copy of the code. I realize this fuzzies up transparency a bit, but there’s no secrets kept locally; you should be able to replicate the full build process.

The primary reasons I don’t allow access into my personal Gitlab instance is performance and privacy for other projects I maintain that do contain more sensitive information.

Each container page should have a link to its GitHub repository, and I do monitor those for pull requests, issues, etc.

Updates

All these containers get updates every first and third Tuesday of the month. If I see a notice that there’s a security update in the underlying container, I’ll push updates manually outside that schedule.