Docker user apps

With system-apps in place, user-apps come next. There are a few I know I want in advance that I’m just going to install and get running out of the gate. But we can apply the same “what’s out there” approach to this too.

Skim around, see what fits, google collections of common names to see competing alternatives, etc.

Issue tracking and development via GitLab

I’ve been using GitLab for years. It’s not the first application I’ve used for project management and I doubt it’ll be the last, but it’s the best I’ve found so far.

Importantly, GitLab also does CI/CD, which helps enforce code quality standards and automates a large part of the development lifecycle. I don’t know how we got along before it came along. It should probably be noted that this blog itself is deployed via my GitLab’s CI/CD pipeline.

GitLab

The only significant concern with GitLab is that it’s fairly resource intensive for a self-hosted environment. Out of the box it requires about 8 GiB of RAM, which tempts some over to gitea/gitea. Though GitLab can be configured to use less resources by limiting the number of worker processes if you’re confident that your concurrent users hover between 0 and 1. puma['worker_processes'] = 2 as per my docker-compose.yml show below:

web:
  image: 'gitlab/gitlab-ce:latest'
  restart: always
  hostname: 'gitlab.home.lan'
  ports:
    - '10180:80'
    - '10122:22'
  volumes:
    - './config:/etc/gitlab'
    - './logs:/var/log/gitlab'
    - './data:/var/opt/gitlab'
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'https://gitlab.home.lan'
      nginx['listen_port'] = 80
      nginx['listen_https'] = false
      nginx['http2_enabled'] = false
      nginx['proxy_set_headers'] = {
        "Host" => "$$http_host",
        "X-Real-IP" => "$$remote_addr",
        "X-Forwarded-For" => "$$proxy_add_x_forwarded_for",
        "X-Forwarded-Proto" => "https",
        "X-Forwarded-Ssl" => "on"
      }
      puma['worker_processes'] = 2

Docker images: gitlab/gitlab-ce, gitlab/gitlab-runner

Dashboard via Heimdall

After more than a handful of services are up and running, it might be worthwhile creating a dashboard for them. You could argue the benefits of browser-native bookmarks and bookmark synchronization add-ons, but I’d rather not deal with the hassle of configuring all browsers. Instead, I’ve set up Heimdall on home.lan as an easy jumping-off point.

Heimdall

Docker image: linuxserver/heimdall

Home media server via Jellyfin

Having a pile of DVDs laying around from the pre-Netflix days, I figured I’d use my newly constructed infrastructure to rip and then expose them internally. There’s bound to be a day where the PS2 in the cupboard beneath the TV dies, and the accessibility Jellyfin provides by way of on-demand access to my media reduces that friction of trudging out the physical media, switching the TV to the PS2, pumping the volume because it comes in at a different base volume than the Chromecast, etc.

Further, a quick search for public domain movies will show a fair amount of additional content you can augment your library with.

Jellyfin

Docker image: jellyfin/jellyfin

Password management via Bitwarden

For a long while, I’d been using a password generation application of my own creation, but found the lack of integration with my phone to be a real sticking point. Enter Bitwarden as a fantastic tool to keep track of your passwords, auto-fill login forms, notify you of insecure passwords, etc. I wish I had switched over to this one sooner.

Admittedly, I’m currently making use of bitwardenrs/server instead of bitwarden/… as the deployment process on the former was notably smoother. Stock Bitwarden has documentented their deployment process, but it’s fair to say it’s a little more involved than bitwardenrs. That being said, I would strongly prefer to use the stock implementation and I have a open issue to migrate when I have time.

Bitwarden

Docker image: bitwardenrs/server

Static file sharing via Nginx

There are times where I want easy access to a file (e.g. accessing my custom root certificate from my phone). For this and other simple file sharing, nginx is actually sufficient for the moment and is running on static.home.lan. I’d like to investigate filebrowser/filebrowser and nextcloud. The former I have no experience with, the latter I fear may be overkill for my needs. For the time being, Nginx serving static files will do.

I hate to always end on the same point, but there are higher-priority issues to deal with before I go mucking around with alternatives I may or may not end up using.