Not OP, but in general the process goes like this:

  - you pick a base image you want to use, like Alpine (small size, good security, sometimes compatibility issues) or Debian or Ubuntu LTS (medium size, okay security, good compatibility) or whatever you please
  - if you want a common base image for whatever you're building, you can add some tools on top of it, configuration, CAs or maybe use a specific shell; not a must but can be nice to have and leads to layer reuse
  - you build the image like you would any other, upload it wherever you please (be it Docker Hub, another registry, possibly something self-hosted like Sonatype Nexus): docker build -t "my-registry.com/base/ubuntu" -f "ubuntu.Dockerfile" . && docker push "my-registry.com/base/ubuntu"
  - then, when you're building something more specific, like a Python or JDK image or whatever, you base it on the common image, like: FROM my-registry.com/base/ubuntu
  - the same applies not just for language tooling and runtimes, but also for software like databases and key value stores and so on, albeit you'll need to figure out how to configure them better
  - as for any software you want to build, you also base it on your common images then

Example of cleanly installing some packages on Ubuntu LTS (in this case, also doing package upgrades in the base image) when building the base image, without the package caches left over:

  FROM ubuntu:noble
  
  ... (your custom configuration here, default time zones, shells etc.)
  
  RUN apt-get update \
      && apt-get upgrade -y \
      && apt-get install -y \
          curl \
          wget \
          net-tools \
          traceroute \
          iputils-ping \
          zip \
          unzip \
      && apt-get clean \
      && apt-get autoremove -y --purge \
      && rm -rf /var/lib/apt/lists/*

In general, you'll want any common base images to be as slim as possible, but on the other hand unless you're a bank having some tools for debugging are nice to have, in case you ever need to connect to the containers directly. In the end, it might look a bit like this:

  upstream image --> your own common base image --> your own PostgreSQL image
  upstream image --> your own common base image --> your own OpenJDK image --> your own Java application image

In general, building container images like this will lead to bigger file sizes than grabbing an upstream image (e.g. eclipse-temurin:21-jdk-noble) but layer reuse will make this a bit less of an issue (if you have the same server running multiple images) and also it can be very nice to know what's in your images and have them be built in fairly straightforwards ways. Ofc you can make it way more advanced if you need to.