Posts tagged: docker Archive

Prettier Docker ‘ps’ Command

2025-12-29T05:33:05Z

The docker ps command is very useful, but I hate reading the output. Turns out, you can make it prettier:

docker ps

–format “table” is implied with the command.


❯ docker ps --format "table" | grep can
9b716a7d1ab0   postgres:17                                               "docker-entrypoint.s…"   13 hours ago    Up 13 hours (healthy)            0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp                                                cannalyzer-db-1
f7708ea0c112   adminer                                                   "entrypoint.sh docke…"   13 hours ago    Up 13 hours                      0.0.0.0:8081->8080/tcp, [::]:8081->8080/tcp                                                cannalyzer-adminer-1
93cd67719ed4   frontend:latest                                           "/docker-entrypoint.…"   13 hours ago    Up 13 hours                      0.0.0.0:5173->80/tcp, [::]:5173->80/tcp                                                    cannalyzer-frontend-1
f517625fca98   traefik:3.0                                               "/entrypoint.sh --pr…"   13 hours ago    Up 13 hours                      0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:8090->8080/tcp, [::]:8090->8080/tcp           cannalyzer-proxy-1
f4daa036216e   schickling/mailcatcher                                    "sh -c 'mailcatcher …"   13 hours ago    Up 13 hours                      0.0.0.0:1025->1025/tcp, [::]:1025->1025/tcp, 0.0.0.0:1080->1080/tcp, [::]:1080->1080/tcp   cannalyzer-mailcatcher-1

But you can pass a template string to the --format option, like so:

docker ps --format "table {{.Names}}"


✗ docker ps --format "table {{.Names}}" | grep can
cannalyzer-db-1
cannalyzer-adminer-1
cannalyzer-frontend-1
cannalyzer-proxy-1
cannalyzer-mailcatcher-1

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"


❯ docker ps --format "table {{.Names}}\t{{.Ports}}" | grep can
cannalyzer-db-1             0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp
cannalyzer-adminer-1        0.0.0.0:8081->8080/tcp, [::]:8081->8080/tcp
cannalyzer-frontend-1       0.0.0.0:5173->80/tcp, [::]:5173->80/tcp
cannalyzer-proxy-1          0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:8090->8080/tcp, [::]:8090->8080/tcp
cannalyzer-mailcatcher-1    0.0.0.0:1025->1025/tcp, [::]:1025->1025/tcp, 0.0.0.0:1080->1080/tcp, [::]:1080->1080/tcp

Picture #

I noticed my template isn’t folding the codeblocks in a way that actually makes this post look like I’m lying!

💭 Docker | Atuin Docs

2025-11-22T20:58:59Z

Here’s my thought on Docker | Atuin Docs

A 2-fer… So I want to host atuin and share shell history across my machines on my tailnet I think… it’s such a nice interface but I barely use it so I’m sure the features will improve some aspects of my life. And secondly, this section on using systemd is interesting… I hadn’t thought to use systemd to schedule container upgrades - sounds incredibly trivial and probably a widely practiced thing now that I say it out loud… Saving here for implementing something… sometime…

Note

This is one of [[ my-thoughts ]]. I picked this up from Waylon Walker(https://thoughts.waylonwalker.com). It’s a short note that I make about someone else’s content online. Learn more about the process Thoughts

💭 Docker Swarm Still Rocks

2025-08-26T14:43:44Z

Here’s my thought on Docker Swarm Still Rocks

Apparently docker swarm is still a thing and now I have to try it

Note

Docker Volume Mounts Link to an Inode

2025-08-02T13:01:58Z

docker bind mounts are specified as filepaths - this is very intuitive. I want /path/to/directory on my host to be shared with /another/path/foo in a container. But what if /path/to/directory on the host is moved?

This is a situation I have found myself in at home and it turns out that I’m actually in almost zero trouble thankfully…

TLDR - I have a bunch of compose stacks in /home/projects/homelab-compose// and I want to move them to /home/projects/homelap-mono/compose//

I don’t want to take down all my stacks to do this because I don’t yet have a convenient way to do it - but can I just mv .../homelab-compose .../homelab-mono/compose and be done with it?

The issue is that some of my stacks use local volume mounts - ie. there is a data volume on the host in /home/projects/homelab-compose//docker-data for some of the applications… can I just move everything and docker is nonethewiser?

Turns out the answer is mostly yes with some caveats to keep in mind..

Let’s start with why it works and then show an example…

Why #

This works because of how docker interprets the bind mount location initially and with how mv is different from cp. When you speicify a volume mount for docker, the engine determines which inode contains the metadata for the filesystem object referenced by the original volume path /path/to/directory. I think about this like a string path is a pointer to a lower level identifier closer to the filesystem - if that pointer changes it doesn’t affect the pre-existing inode or data. So docker uses the inode that /path/to/directory points to when the container starts up.

The slight convenience in my case is that mv maintains the existing inode and so the new filepath is irrelevant to that existing container that was spun up with a now-non-existent host filepath.

So if you can imagine then - I spun up several containers in ///homelab-compose/... with many stacks - and I want to just move all the config files to new repo… thankfully, I actually can just mv everything and because the inode locations dont’ change, the stacks are fine!

caveat

Is the next issue apparent? What happens to those files whose volume mount configurations specify …/homelab-compose/…? Well, if the stacks are brought down and back up then docker will create that filepath on the host and a new inode reference will be had by all… so that’s a problem easily mitigated by some string replacement!

another note

Perhaps just don’t keep data next to your configuration either… In most of my stacks I have a determined docker volume that’s backed up etc. on my hosts and that’s what I’m moving towards on my desktop, but as of right now I’ve put myself in an odd situation via not participating in a proper thinking exercise when standing up all these stacks on my desktop

Example #

Finally let’s just see it in action quickly…

I have a directory /tmp/foo/source with a compose file in it.

❯ tree source       
source
└── docker-compose.yml

That file is simple:

services:
  app:
    image: nginx
    ports:
      - "8070:80"
    volumes:
      - /tmp/foo/source:/usr/share/nginx/html

Now I can spin that container up, exec in, drop a file in /usr/share/nginx/html and we’ll see it in /tmp/foo/source as expected…

nic in /tmp/foo   (dev)
❯ docker exec source-app-1 touch /usr/share/nginx/html/file.txt

nic in /tmp/foo   (dev)
❯ tree source                                                       
source
├── docker-compose.yml
└── file.txt

1 directory, 2 files

Now let’s mv the source directory somewhere else and see what happens

nic in /tmp/foo   (dev)
❯ mv source target 

nic in /tmp/foo   (dev)
❯ tree target 
target
└── source
    ├── docker-compose.yml
    └── file.txt

2 directories, 2 files

OK everything is there - now let’s drop another file in the container - remember the compose file still has the host path as /tmp/foo/source, not /tmp/foo/target/source.

nic in /tmp/foo   (dev)
❯ docker exec source-app-1 touch /usr/share/nginx/html/another-file.txt

nic in /tmp/foo   (dev)
❯ tree target                                                          
target
└── source
    ├── another-file.txt  # BAM! New file still here...
    ├── docker-compose.yml
    └── file.txt

2 directories, 3 files

Few Things #

cp as noted before, creates new inodes and so if I were to have cp -r that source directory to target then the container would’ve dropped er exec source-app-1 touch /usr/share/nginx/html/another-file.txc in /tmp/foo  (dev) 󰒄 󱔎 NO PYTHON ENVIORNMENT SET t another-file.txt to /tmp/source and we’d be in a pretty confusing state
Let me stress again the importance of managing your docker volumes in a sane way… I have on any of my hosts a /path/to/docker/data which is backed up in a way that makes sense for the host (usually zfs + sanoid, otherwise restic backup TO a remote zfs dataset - see Using restic to backup my home directory)

💭 Docker Brings Compose to the AI Agent Era | Docker

2025-07-11T11:49:41Z

Here’s my thought on Docker Brings Compose to the AI Agent Era | Docker

Seems like docker is leaning harder into compose - which is great for me as a heavy compose user. I had heard about some of the LLM enablements directly through docker desktop - for example taking fuller advantage of the host’s compute power without paying the penalty of the nvidia runtime or something… I can’t claim to have followed it all but I heard “run LLMs in docker directly for a bigger boost” and I’m in.

Note

Jellyfin container updates for HWE + AMD

2024-12-14T11:27:15Z

I use LSIO Jelyfin container for the easy addon they provide for AMD GPUs but I couldn’t get trickplay to work with HWE…

There was almost NOTHING on the internet about the error, and all the threads were about BSD systems…

Thankfully someone posted on the formum here but the only answer was to literally upgrade stuff in the container…

Someday maybe I’ll build off of LSIO to add this, but until then I shell’d in and homelab’d the hell out of it

THIS IS INSIDE THE CONTAINER - I use Portianer to make it easy


apt update && apt install -y curl gpg

mkdir -p /etc/apt/keyrings

curl -fsSL https://repo.radeon.com/rocm/rocm.gpg.key | gpg --dearmor -o /etc/apt/keyrings/rocm.gpg

cat <<EOF | tee /etc/apt/sources.list.d/rocm.sources

Types: deb

URIs: https://repo.radeon.com/rocm/apt/latest

Suites: ubuntu

Components: main

Architectures: amd64

Signed-By: /etc/apt/keyrings/rocm.gpg

EOF

apt update && apt install -y rocm-opencl-runtime

Adding docker daemon.json broke docker

2022-12-21T10:02:25Z

in /lib/systemd/system/docker.service there is an ExecStart command that got placed there when I setup Docker with Ansible - it threw the -H flag which told the daemon what hosts to setup. But I added the “hosts” key in my daemon.json and it broke - so removing the -H flag from the systemd unit fixed it

Cron for Nextcloud in Docker

2022-12-13T06:43:45Z

AJAX wasn’t cutting it, traditional crontab in containers doesn’t make much sense to me, webcron is recommended but I don’t want to register with anything outside my LAN… Turns out you can just spin up an identical container with a different entrypoint to /cron.sh that does what you need!

Note that this is a task in an Ansible playbook - but the docker-compose is straight forward

So the only thing you need to make sure of is that all the configuration options - data volumes, user permissions, etc. are identical between the containers running the cron job and the one actually hosting NextCloud. This ensures that the container running cron has proper access to the database and filesystem - or at least the same access as NextCloud proper.

- name: Nextcloud Cron Docker Container
  docker_container:
    name: nextcloud-cron
    image: "{{ nextcloud_image }}"
    pull: true
    links:
      - nextcloud-mysql:mysql
    entrypoint: /cron.sh
    volumes:
      - "{{ nextcloud_data_directory }}/nextcloud:/var/www/html:rw"
    env:
      MYSQL_HOST: "mysql"
      MYSQL_DATABASE: "nextcloud"
      MYSQL_USER: "{{ nextcloud_sql_user }}"
      MYSQL_PASSWORD: "{{ nextcloud_sql_password }}"
      NEXTCLOUD_TRUSTED_DOMAINS: "{{ nextcloud_hostname }}.{{ ansible_nas_domain }}"
      PUID: "{{ nextcloud_user_id }}"
      PGID: "{{ nextcloud_group_id }}"
      TZ: "{{ ansible_nas_timezone }}"
    restart_policy: unless-stopped
    memory: "{{ nextcloud_memory }}"