Thread: Filled Postgres server as Docker image

Hi,

for development and testing (integration testing) I want to have a
Docker image with a pre-filled Postgres database. It should be a simple
and quick task to spin-up this database, e.g., in a docker compose setup.

Suggested solutions to achieve this goal are

(1) To place initialization scripts at /docker-entrypoint-initdb.d and
do the filling of the DB when the container is started the first time ->
I want to avoid this, as it takes 20 minutes

(2) To mount a volume to /var/lib/postgresql and have the data there ->
I want to avoid this, as it requires to move and maintain the data
folder separately

Not suggested (at least this is what I found at mailing lists and at
StackOverflow) is to burn the data into the container image. However,
the reasons that are mentioned in these discussions "data is gone when
the container is gone ..." is not my concern.

As it is not easy to write a Docker build to achieve my goal, I would
like to ask if there are reference projects / Docker build processes
that perform this workflow? Reason why I consider it as not too easy: I
have to manually start the Postgres server ignoring the intended
entry-point script and then fill it with my data.

Looking forward to your comments/suggestions!

Bernd

El día viernes, enero 05, 2024 a las 11:31:34 +0100, Bernd Graf escribió:

> Hi,
> 
> for development and testing (integration testing) I want to have a
> Docker image with a pre-filled Postgres database. It should be a simple
> and quick task to spin-up this database, e.g., in a docker compose setup.
> 
> Suggested solutions to achieve this goal are
> 
> (1) To place initialization scripts at /docker-entrypoint-initdb.d and
> do the filling of the DB when the container is started the first time ->
> I want to avoid this, as it takes 20 minutes
> 
> ...

Interesting, I'm working on a similar project. Having a podman image,
with:

- SuSE SLES 15
- PostgreSQL 15.x server with loaded database
- starting a bunch of application server on top of the PostgreSQL
  server and offering there service on network sockets;
- and (ofc) having SSH into the image for debugging/testing;

I plan to have a similar PostgreSQL server outside the image, with
loaded database. Shut this down and create a tar archive of the full
server which then will be COPY'ed into the image at build time
and scripts in /entrypoint.d will arange everything.

    matthias

-- 
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

I am not at war with Russia.  Я не воюю с Россией.
Ich bin nicht im Krieg mit Russland.

On 2024-01-05 20:31, Bernd Graf wrote:
<snip>
> As it is not easy to write a Docker build to achieve my goal ...

That kind of depends.  If this is a test image that you don't
need to update frequently, then you can probably take the approach
of using an existing image, and extending it to have your data.

It's pretty easy to do.  As an example, here's one using that
same concept:

   
https://github.com/sqlitebrowser/dbhub.io/blob/e1cf6d5ecd32dfcc797a95884e78d8665087eba5/docker/Dockerfile

That Dockerfile grabs an existing image (for Alpine Linux in
this example), then extends it by running a bunch of commands
to do stuff I need.

The resulting image then gets tagged with a useful (to me)
name "dbhub-build:latest" so I can stop and start it as needed.

For your scenario, you could instead do something like this:

   FROM postgres:latest

   LABEL maintainer="Bernd Graf <gbernd@gmx.de>"

   # Load the PostgreSQL data
   RUN createdb -U postgres somedb

   RUN psql -U postgres somedb < yourdata.sql

That will create a new Docker image based upon the "latest"
Docker PostgreSQL release, and it will load a bunch of data into
it with those last two RUN steps.  Of course, you might need
different commands in the RUN steps depending on how you've
got your data prepared for loading. :)

You build the image using docker like this:

   docker build --tag myimage /PATH/TO/THE/ABOVE/Dockerfile

When it finishes building the image it'll tag it as "myimage:latest",
which you can then use as you need later on.

Does that make sense?

Regards and best wishes,

Justin Clift