Modified Dockerfile for timescaledb

[einarwar]

Hello, and thanks for this tool.

I am working in a project where we needed to smoothly upgrade from postgres 15 to 16, where different running instances had different postgres versions. We easilly solved this by replacing the official postgres-image with the docker-pgautoupgrade image.

We now plan to add the timescaledb, preferably by using an image. I tried to modify and apply the example for postGIS, but was not able to get it to work.

FROM docker.io/timescale/timescaledb:latest-pg16 as pg16
FROM docker.io/pgautoupgrade/pgautoupgrade:16-bookworm as pgautoupgrade

# Original entrypoint overwritten in /usr/local/bin, so copy elsewhere
RUN cp /usr/local/bin/docker-entrypoint.sh /docker-entrypoint.sh

# Copy in TimescaleDB libs/bins, Not sure about this one
COPY --from=pg16 /usr/lib /usr/lib

# Copy extensions for postgresql 16
COPY --from=pg16 /usr/local /usr/local

# Squash image to reduce size
FROM scratch
COPY --from=pgautoupgrade / /
ENV \
    PGTARGET=16 \
    PGDATA=/var/lib/postgresql/data
WORKDIR /var/lib/postgresql
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["postgres"]

Trying to build this results in the following error:
/docker-entrypoint.sh: line 92: /usr/local/bin/initdb: cannot execute: required file not found

Do you have any suggestions or pointers on what i am doing wrong, and do you think it would be possible to make an example like the postgis one, but for timescaleDB as well?

[justinclift]

Interesting problem. 😄

Let's see if we can first figure out why it's throwing that error for you, as there might turn out to be a simple fix. 😄

The "required file not found" sounds like either initdb itself is in a different location, or one of it's dependencies.

Are you able to check if the /usr/local/bin/initdb file is present, and at exactly that path?

If it is, are you able to run ldd on it? ie: ldd /usr/local/bin/initdb

That should (in theory) output a list of the dependency libraries that initdb tries to load. That might also reveal what's broken. 😄

[einarwar]

It seems to be there. It seems like libc.musl-x86_64.so.1 is not found

root@e90d3ae57568:/# ldd /usr/local/bin/initdb 
        linux-vdso.so.1 (0x00007ffccebf7000)
        libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x00007f1ce0482000)
        libicuuc.so.74 => /lib/libicuuc.so.74 (0x00007f1ce02de000)
        libc.musl-x86_64.so.1 => not found
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f1ce0235000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f1cdfdaf000)
        libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f1cdfd5a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1cdfc7b000)
        libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007f1cdfc1c000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1cdfa3b000)
        libicudata.so.74 => /lib/libicudata.so.74 (0x00007f1cdfa38000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1cdf81e000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1cdf7fc000)
        libc.musl-x86_64.so.1 => not found
        libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f1cdf722000)
        libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f1cdf6f5000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f1cdf6ef000)
        libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f1cdf6df000)
        /lib/ld-musl-x86_64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f1ce050b000)
        liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007f1cdf6cf000)
        libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f1cdf6b2000)
        libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f1cdf496000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f1cdf48f000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1cdf47c000)
        libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f1cdf348000)
        libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f1cdf317000)
        libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f1cdf161000)
        libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f1cdf14c000)
        libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f1cdf0fc000)
        libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f1cdf0b3000)
        libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f1cdf032000)
        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007f1cdf026000)

[justinclift]

Ahhh. That might be some kind of Alpine vs Debian problem. Musl is a special library of C routines that does things (a bit) differently than glibc which Debian uses.

To me, that looks like you're attempting to use PostgreSQL binaries compiled on Alpine (and therefore expecting musl) then trying to use that on a system that uses something-other-than-musl.

That's kind of weird though, if that's the output from PostgreSQL from the pgautoupgrade/pgautoupgrade:16-bookworm image. That's supposed to be Debian based rather than Alpine based.

Hmmm, maybe double check where the PostgreSQL you're running the ldd is from? My first guess is it's just a simple cut-n-paste typo or similar simple mix up in the image tag you're using?

Well, hopefully it does turn out to be that simple. 😁

[einarwar]

Im not sure how to do that. The output from cat /etc/os-release says debian at least:

root@9f4eed1247de:/# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[einarwar]

It seems like the timescaleDB image is alpine. This might maybe cause the issues? Output from cat /etc/os-release when trying to only build with FROM docker.io/timescale/timescaledb:latest-pg16:

/ # cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.20.2
PRETTY_NAME="Alpine Linux v3.20"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

[justinclift]

This might maybe cause the issues?

Yeah, that might be the thing.

Maybe try using the timescaledb (alpine based) image with one of the alpine based pgautoupgrade images. i.e. pgautoupgrade/pgautoupgrade:latest, and see if the behaviour changes?

[einarwar]

Testing with docker.io/pgautoupgrade/pgautoupgrade:16-alpine seems to solve the issue. This introduces some difficulties as some existing systems would need to go from a debian-based image to an alpine-based image. But that is not in the hands of pgautoupgrade, i guess timescaledb would need to have a debian-based alternative.

I don't know if you have in-depth knowledge of how to modify the example to work with timescaledb. I'll try to reverse-engineer the steps taken and files modified in the timescaledb-image. If I get it to work, I can maybe provide an example that could be added to the wiki if that would be interesting :)

[justinclift]

Interesting. Yeah, if you get that written up on the wiki then that'd be potentially useful for people. It's good to have more (coherent) docs than less. 😁