Prisma1: Initializing Prisma + Database at once might result in undefined behaviour

[marktani]

Bug Report

Current behavior

run docker-compose up -d with this:

version: '3'
services:
  prisma:
    image: prismagraphql/prisma:1.7
    restart: always
    ports:
    - "4466:4466"
    environment:
      PRISMA_CONFIG: |
        port: 4466
        databases:
          default:
            connector: mysql
            active: true
            host: db
            port: 3306
            user: root
            password: prisma
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: prisma

Sometimes, the Prisma container will be "faster" than the MySQL container. Then the DB refuses to be connected to, and the Prisma container runs into undefined behaviour.

Expected behavior?

Be super resilient about weird edge cases similar to the one described above.

[codepunkt]

What about

services:
  prisma:
    image: prismagraphql/prisma:1.7
    restart: always
    ports:
    - "4466:4466"
    depends_on:
      - db
    environment:
      PRISMA_CONFIG: |
        port: 4466
        databases:
          default:
            connector: mysql
            active: true
            host: db
            port: 3306
            user: root
            password: prisma
  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: prisma

[marktani]

This looks like exactly what we need, thanks @codepunkt! 👍
For reference, @codepunkt suggested to add depends_on 🙂

[divyenduz]

depends_on won't solve this as depends on does not wait for DB to be ready.

[dpetrick]

This is not really a bug, it is rather by design.

The Prisma container (correctly) fails fast until the DB is available. It is a much cleaner design to gear Prisma towards failing fast in these scenarios as opposed to having some waiting / retry heuristic build around that. If you really need a solution that has the Prisma container waiting (a common example being CI/CD), I would make the following proposal, which utilizes an already implemented mechanism.

Prisma calls a script before executing, prerun_hook.sh. The file is located (on the container) at /app/prerun_hook.sh. You can inject your own script using a custom docker file, for example:

FROM prismagraphql/prisma:<TagYouWantHere>
RUN apk --no-cache add mysql-client
COPY ./prerun_hook.sh /app/prerun_hook.sh

What you do in that script is up to you. The default script contained in our pre-build images is just blank and serves as a placeholder. You can invoke a node / ruby / python / go / ... script or executable that checks the connectivity (given that you have the required runtimes installed on the image), or solve it via pure shell scripting. In the example above I pull in the mysql-client, which could then be used to poll the DB every x seconds via the shell script until a command succeeds, resulting in the container not dying and effectively waiting for the DB to be ready before booting Prisma.

[marktani]

Awesome, thanks @dpetrick 🙌 Let's add this to the documentation 🙂

[codepunkt]

@dpetrick @marktani docs with a working implementation for every supported db would be great - preferably in a language/runtime that already exists in the container

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.