README.md

Containers

An opinionated collection of container images

Welcome to container images, if looking for a container start by browsing the GitHub Packages page for this repo's packages. Please also check out the inspiration repo from onedr0p.

Mission statement

The goal of this project is to support semantically versioned, rootless, and multiple architecture containers for various applications.

I try to adhere to a KISS principle, logging to stdout, one process per container, no s6-overlay and all images are built on top of Alpine or Ubuntu.

Rootless

To run these containers as non-root make sure you update your configuration to the user and group you want.

Docker compose

networks:
  sonarr:
    name: sonarr
    external: true
services:
  sonarr:
    image: ghcr.io/joryirving/sonarr:3.0.8.1507
    container_name: sonarr
    user: 65534:65534
    # ...

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sonarr
# ...
spec:
  # ...
  template:
    # ...
    spec:
      # ...
      securityContext:
        runAsUser: 65534
        runAsGroup: 65534
        fsGroup: 65534
        fsGroupChangePolicy: OnRootMismatch
# ...

Tag immutability

The containers built here do not use immutable tags, as least not in the more common way you have seen from linuxserver.io or Bitnami.

We do take a similar approach but instead of appending a -ls69 or -r420 prefix to the tag we instead insist on pinning to the sha256 digest of the image, while this is not as pretty it is just as functional in making the images immutable.

Container	Immutable
ghcr.io/joryirving/sonarr:rolling	❌
ghcr.io/joryirving/sonarr:3.0.8.1507	❌
ghcr.io/joryirving/sonarr:rolling@sha256:8053...	✅
ghcr.io/joryirving/sonarr:3.0.8.1507@sha256:8053...	✅

If pinning an image to the sha256 digest, tools like Renovate support updating the container on a digest or application version change.

Passing arguments to a application

Some applications do not support defining configuration via environment variables and instead only allow certain config to be set in the command line arguments for the app. To circumvent this, for applications that have an entrypoint.sh read below.

1. First read the Kubernetes docs on defining command and arguments for a Container.

2. Look up the documentation for the application and find a argument you would like to set.

3. Set the extra arguments in the args section like below.

   args:
     - --port
     - "8080"

Configuration volume

For applications that need to have persistent configuration data the config volume is hardcoded to /config inside the container. This is not able to be changed in most cases.

Available Images

Each Image will be built with a rolling tag, along with tags specific to it's version. Available Images Below

Container	Channel	Image
actions-runner	stable	ghcr.io/joryirving/actions-runner
bazarr	stable	ghcr.io/joryirving/bazarr
caddy-scratch	stable	ghcr.io/joryirving/caddy-scratch
free-game-notifier	stable	ghcr.io/joryirving/free-game-notifier
home-assistant	stable	ghcr.io/joryirving/home-assistant
it-tools	stable	ghcr.io/joryirving/it-tools
plex	stable	ghcr.io/joryirving/plex
plex-beta	beta	ghcr.io/joryirving/plex-beta
prowlarr	master	ghcr.io/joryirving/prowlarr
prowlarr-develop	develop	ghcr.io/joryirving/prowlarr-develop
prowlarr-nightly	nightly	ghcr.io/joryirving/prowlarr-nightly
qbittorrent	stable	ghcr.io/joryirving/qbittorrent
qbittorrent-beta	beta	ghcr.io/joryirving/qbittorrent-beta
radarr	master	ghcr.io/joryirving/radarr
radarr-develop	develop	ghcr.io/joryirving/radarr-develop
radarr-nightly	nightly	ghcr.io/joryirving/radarr-nightly
readarr-develop	develop	ghcr.io/joryirving/readarr-develop
readarr-nightly	nightly	ghcr.io/joryirving/readarr-nightly
redlib	stable	ghcr.io/joryirving/redlib
sabnzbd	stable	ghcr.io/joryirving/sabnzbd
smartctl_exporter	stable	ghcr.io/joryirving/smartctl_exporter
sonarr	main	ghcr.io/joryirving/sonarr
sonarr-develop	develop	ghcr.io/joryirving/sonarr-develop
tautulli	master	ghcr.io/joryirving/tautulli
volsync	stable	ghcr.io/joryirving/volsync

Deprecations

Containers here can be deprecated at any point, this could be for any reason described below.

1. The upstream application is no longer actively developed
2. The upstream application has an official upstream container that follows closely to the mission statement described here
3. The upstream application has been replaced with a better alternative
4. The maintenance burden of keeping the container here is too bothersome

Note: Deprecated containers will remained published to this repo for 6 months after which they will be pruned.

Credits

A lot of inspiration and ideas are thanks to the hard work of onedr0p, hotio.dev and linuxserver.io contributors.