Docker-compose dependent services

Minor thought:

Per the postgres docker-compose.yml example, near the bottom is the following:

# Wait 5 seconds to start n8n to make sure that PostgreSQL is ready
# when n8n tries to connect to it
command: /bin/sh -c "sleep 5; n8n start"

I’m no expert on it, but wouldn’t it work to do:

depends_on:
  - db

I don’t know if you would still need:
command: /bin/sh -c “n8n start”
…or if you could bake that in, but it would be cleaner and more steamlined if the image was set to automatically start. (And probably following best practices)

Not 100% sure. It would then for sure start the Postgres container earlier than the n8n one but would not have to mean that Postgres is actually ready to accept connections. For that we would have to have a proper start-script in place which checks if Postgres is ready before starting n8n (at least if I remember correctly).

Another thing to consider is that it is not possible in Docker-Swarm to use “depends_on”. By doing it like that people have also already a good start location to use it there.

So a proper start-script would be best for both cases.

Also, as podman is getting traction, it’s nice not to have to depend on “depends_on” as podman does not yet have a podman-compose type command and thus does not support it.

#!/bin/sh
# wait-for-postgres.sh

set -e

host="$1"
shift
cmd="[email protected]"

until PGPASSWORD=$POSTGRES_PASSWORD psql -h "$host" -U "postgres" -c '\q'; do
  >&2 echo "Postgres is unavailable - sleeping"
  sleep 1
done

>&2 echo "Postgres is up - executing command"
exec $cmd

@alxnzx Did not test it yet but looks very good. Thanks a lot for that! Do I have your approval to add it like that to the n8n repository? Or do you want to add it yourself to show so officially up as an n8n contributor?

Hey @jan, go ahead and use it, I think I just found it in the official docker documentation. I’ll have my contributor title when I finish fiddling with the timezone settings :stuck_out_tongue:

Ah ok, great thanks!

Sadly is not that easy after all. I forgot that the n8n image would have to have Postgres installed for that script to work. Which it obviously does not.

Maybe adding an ENV to specify if we want to use sqlite, postgres or mongo backend and handling all the cases from the n8n container entrypoint is the way to go ?

Something like DB_BACKEND for example.

Unless I am not understanding the issue correctly :slight_smile:

I am also not sure if I understand you correctly either :wink:

Sorry, I think I did not explain the problem very good. The issue is that the startup-script does get executed in the n8n container which has only n8n installed. But the script runs the “psql” command which only exists in the postgres container. So to be able to run that script we would have to add Postgres to the n8n container.

We could add the postgresql-client to the n8n container, or change the script to something like a netcat on the postgre port, which would be less precise but would work best than a wait 5 too :slight_smile:

Let me know what you prefer and I can work on this.

I guess actually the simplest solution there is to fix that issue in the n8n CLI itself.

We could simply build a catch and retry around the connect there. It would not require any additional software to be installed and would also fix that issue for other databases.