Any way to introspect the docker image?

[philippefutureboy]

Hi,

We are facing the issue described in #1857 with the patch Postgres 11.16 & PostgREST 6.0.2.
Our staging system is down, and our production could go down at any moment following an automatic patch of 11.15->11.16 from Google Cloud.
We are investigating a migration path from 11.16 -> 14 and PostgREST v6.0.2 -> v9.0.1.20220717.

Our image was previously the following:

FROM postgrest/postgrest:v6.0.2

USER root
COPY ./scripts/wait-for-hostfile.sh /usr/local/bin/wait-for-hostfile
RUN chmod +x /usr/local/bin/wait-for-hostfile

But upon upgrading to 9.0.1.20220717, we can no longer access the root user, and we are not able to login the image using docker exec -ti {container-id} /bin/sh or any variation thereof.

What user should we be using to carry out our Dockerfile extensions / Is there any way we can log in the container to investigate?

Thanks a lot,
Cheers,

[laurenceisla]

Hi. The Docker image for v9^ is very minimal, it doesn't have a shell and only runs the postgrest binary on it, so you won't be able to log in to it. You can configure it by using environment variables instead of a configuration file. Maybe you should use another image for your extra configuration and keep the postgrest image separately, or use docker-compose.

There was a similar question before (for kubernetes though) that may help you too: #2243 (comment)

[philippefutureboy]

Hi @laurenceisla !
Thanks for your answer. I figured as much, but it's the first time I see such an image. I'm surprised, puzzled, and impressed 🤔 😄

We are already using docker-compose - the goal of the extension is to ensure a fully ready postgres db is available before postgrest gets started. Back when we designed this image, the wait-for-it shell script approach was the official docker-compose way to wait for another container to initialize.

We need to run some migrations against our db before we can allow postgrest to access it. Otherwise it gets an imprint of a schema that's outdated and we have to kill it and reboot it to reload the schema once the migrations have finished applying.

Given that it's no longer possible to use this previously-official way of waiting on the db to be ready, how would you approach doing so?

Thanks!

[wolfgangwalther]

We need to run some migrations against our db before we can allow postgrest to access it. Otherwise it gets an imprint of a schema that's outdated and we have to kill it and reboot it to reload the schema once the migrations have finished applying.

I suggest using schema reload via NOTIFY. At the end of any migration you run, you issue NOTIFY pgrst, 'reload schema'. No need to restart PostgREST anymore after doing a migration.

[wolfgangwalther]

What user should we be using to carry out our Dockerfile extensions

If you want to use PostgREST in a "full" docker image, you can do the following:

# derive from any base image you want
FROM alpine:latest

# copy PostgREST over
COPY --from=postgrest/postgrest:v9.0.1.20220717 /bin/postgrest /bin

# add your other stuff

[philippefutureboy]

@wolfgangwalther Thanks for the two great answers! These will definitely be invaluable for us to cover our use case. I like the NOTIFY approach and I'll see what we can do with it :)

[ngmiduc]

It worked with the answer! Thanks!