CODEWITHSUNDEEP
docker
Knows Not Much
Knows Not Much

Reputation: 31556

Not able to extend the parent's entry point

I am trying to extend the parent image's entry point by following this tutorial

This is the content of the child's entry point shell file new-initfile.sh

#!/bin/sh
exec /usr/local/bin/docker-entrypoint.sh "$@"
exec flyway migrate

So here basically I am executing the parent images entry point and then adding my own command to it.

Here is my docker file ↓

FROM postgres:alpine
RUN apk --no-cache add wget su-exec
RUN wget -qO- https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/7.3.2/flyway-commandline-7.3.2-linux-x64.tar.gz | tar xvz && su-exec sh ln -s `pwd`/flyway-7.3.2/flyway /usr/local/bin
RUN mv /flyway-7.3.2/conf/flyway.conf /flyway-7.3.2/conf/flyway.conf.orig
COPY flyway.conf /flyway-7.3.2/conf/flyway.conf
COPY new-initfile.sh /new-initfile.sh
RUN ["chmod", "+x", "/new-initfile.sh"]
ENTRYPOINT [ "/new-initfile.sh" ]

This is my docker-compose.yml file

version: "3.7"
services: 
  db:
    build: database
    container_name: db
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - ./pgdata:/var/lib/postgressql/data
      - ./database/migrations:/migrations
    ports:
      - "5432:5432"

When I do docker-compose up it goes to the last step and exits with code 0. If I comment out the last line in my dockerfile, it starts absolutely fine but then my extension commands are not run.

My end objective is that it should first run the parent's entry point command and then run mine.

Upvotes: 0

Views: 231

Answers (1)

anemyte
anemyte

Reputation: 20286

That is the way Docker works - it keeps a container up only while the process started by initial arguments is running. new-initfile.sh completes all the lines and exits normally and so does the container.

In general you need an endless task at the end of your entrypoint script so that it never exits unless an error or a stop signal happens. In your case, I would have delegated migrations to the application rather that the database. It is common to run migrations before starting an application and it's more convenient when you add new migrations (you don't have to mess with two images).

If you still wish the database to do migrations, here are two options:

  1. Postgres Docker image supports extension scripts but they only run at the first launch. That is when Postgres creates a database. It will not run extension scripts on consecutive launches. This is the best way to load a dump or something like that. To utilise the feature place the script in /docker-entrypoint-initdb.d/ inside the container. The script must have *.sql, *.sql.gz, or *.sh extension. Read more about initialization scripts here.

  2. Run the following command and examine the output: docker run --rm postgres:alpine cat /usr/local/bin/docker-entrypoint.sh. This is the default entrypoint script in this image. There are a lot of code in it but look at this first:

if ! _is_sourced; then
    _main "$@"
fi

It won't do much if it is sourced. So the idea is: you source the default entrypoint into your entrypoint script:

#!/bin/sh
. /usr/local/bin/docker-entrypoint.sh

Then you copy the contents of the _main function into your script by the way adding there flyway migrate where you think it fits. And this way you should have a proper entrypoint script.

Upvotes: 2

Related Questions