Closed DrWarpMan closed 2 months ago
Thanks for the PR 😍
Define the SYMFONY_ENDPOINT
environment variable:
# On Unix-like (BSD, Linux and macOS)
export SYMFONY_ENDPOINT=https://raw.githubusercontent.com/symfony/recipes/flex/pull-1307/index.json
# On Windows
SET SYMFONY_ENDPOINT=https://raw.githubusercontent.com/symfony/recipes/flex/pull-1307/index.json
Install the package(s) related to this recipe:
composer req 'symfony/flex:^1.16'
composer req 'doctrine/doctrine-bundle:^2.12'
Don't forget to unset the SYMFONY_ENDPOINT
environment variable when done:
# On Unix-like (BSD, Linux and macOS)
unset SYMFONY_ENDPOINT
# On Windows
SET SYMFONY_ENDPOINT=
In order to help with the review stage, I'm in charge of computing the diff between the various versions of patched recipes. I'm going keep this comment up to date with any updates of the attached patch.
I am having problems with this healthcheck change, as database containers state they are unhealthy. Turns out that making the test
line look like
test: ["CMD", "pg_isready", "-U", "${POSTGRES_USER:-app}"]
partially solves the problem (containers are now healthy) but logs are populated with the following message:
FATAL: database "<redacted - shows $POSTGRES_USER variable value>" does not exist
Further modification of the line solves the problem for me:
test: ["CMD", "pg_isready", "-d", "${POSTGRES_DB:-app}", "-U", "${POSTGRES_USER:-app}"]
Not sure, but it seems something related with using CMD
vs. CMD-SHELL
and/or incorrectly escaping variables. Can anyone share some thoughts about this?
The reason for this seems to be in the logged error that you provided.
It appears that if you don't provide database name to the pg_isready
command, it defaults to the name of the provided user.
I did not notice this, because I was using the default database & user name which is app
.
@gabrielpenide Can you confirm that your database name and database user name are different in your application?
Yes. They are both different from the default value app
and they are both different from each other.
The change you made should solve the issue, would you like to make the pull request yourself?
test: ["CMD", "pg_isready -d ${POSTGRES_DB:-app} -U ${POSTGRES_USER:-app}"]
I can make the pull request, of course. But first I want to notice that I wasn't able to make this work with your exact suggestion. I mean that I need to use the comma-separated style for the healthcheck to pass:
test: ["CMD", "pg_isready", "-d", "${POSTGRES_DB:-app}", "-U", "${POSTGRES_USER:-app}"]
I'm very far from a Docker expert. That's why I pointed out this on my original message:
Not sure, but it seems something related with using
CMD
vs.CMD-SHELL
and/or incorrectly escaping variables.
I would appreciate if you or anyone else elaborates on this before I make the pull request, because it slightly changes your original choice.
Yes, you are right. In this case your provided solution is better. Apparently the two type of syntaxes are called "shell" and "exec" forms.
This answer explains it more: https://stackoverflow.com/a/47940538 It also references to the following Docker documentation, which provides even more information: https://docs.docker.com/reference/dockerfile/#shell-and-exec-form
Does your database name contain any special characters, spaces or something?
It doesn't. Just lowercase [a-z] letters, not even numbers or special characters.
From what I tested, it seems there are only two possible combinations, either you use:
test: ["CMD-SHELL", "pg_isready -d ${POSTGRES_DB:-app} -U ${POSTGRES_USER:-app} || exit 1"]
or
test: ["CMD", "pg_isready", "-d", "${POSTGRES_DB:-app}", "-U", "${POSTGRES_USER:-app}"]
(Apparently when using CMD, || exit 1
is appended automatically.)
Can you try both syntaxes and see if both of them work @gabrielpenide ?
Both work for me. Personally, I would go with the CMD
option, but I guess that's a matter of taste.
By default, root user is used to connect to the postgres database. If the database does not have a "root" role, the following error is logged everytime the health check happens:
FATAL: role "root" does not exist
It does not seem to affect the 'healthy' status of the container (the command still returns zero exit code), but it spams the log: