Open SamMousa opened 8 years ago
This is indeed very confusing, especially if one for example wanted to use unix sockets instead of TCP.
It would indeed be good to have this documented better -- I think the appropriate place would be a variant-fpm.md
file in https://github.com/docker-library/docs/tree/3383325346b0ac532752d2f3725d1c654c3a3227/php (see busybox
, debian
, geonetwork
, influxdb
, openjdk
, oraclelinux
, python
, sentry
, traefik
, wordpress
, or znc
for examples of how to structure that file). :heart:
Either adjusting or removing the Docker-provided configuration should be totally fine. I believe the rationale for us using zz-docker.conf
was simply to ensure that file was sourced after the upstream-provided www.conf
in order to overwrite the default listen address. It's perfectly reasonable for users of this image to replace that configuration completely with something that makes more sense for their use case, such as using Unix Sockets instead of TCP.
See also https://github.com/docker-library/php/issues/498 for another minor bit that ought to be included in such a docs PR, namely that --cap-add SYS_PTRACE
is necessary if request_slowlog_timeout
is enabled.
Any reason why zz- prefix is preferred instead of numeric prefix for config file ordering?
To make sure it comes after alphabetic configuration files (since [a-z] sorts lower than 0 lexicographically).
Why is listen 9000 added both in www.conf and zz-docker.conf files for pool www. I think latter is very unlogical and unnecessary.
@aleskinen if we look at their values, I think that should be a little more clear:
$ docker run --rm php:7.4-fpm sh -c "grep -rn 'listen =' /usr/local/etc/php-fpm.d/*.conf"
/usr/local/etc/php-fpm.d/www.conf:36:listen = 127.0.0.1:9000
/usr/local/etc/php-fpm.d/zz-docker.conf:5:listen = 9000
The one in www.conf
is hard-coded to 127.0.0.1 (which won't be accessible outside the container, and thus is of very limited usefulness). Also, the most important thing to note is that www.conf
is created/provided by PHP upstream, not something we create in this image. We only create docker.conf
and zz-docker.conf
:
The listen
parameter in zz-docker.conf
does not specify an IP specifically so that it will listen on all container IPs and be externally accessible (and thus usable from another container, such as one running NGINX to speak the FastCGI protocol and actually provide value).
This also makes it trivial for someone who wants the stock upstream configuration to revert to it (by deleting /usr/local/etc/php-fpm.d/*docker.conf
).
Any reason why 9000 port is used here as a default?
Since this is infra detail I would really recommend we use some other port. This way we need to change xdebug port for every project which has php-fpm setup.
XDebug changed its port to 9003
in version 3 ;) See: https://xdebug.org/docs/upgrade_guide#Step-Debugging
@tianon
The listen parameter in zz-docker.conf does not specify an IP specifically so that it will listen on all container IPs and be externally accessible (and thus usable from another container, such as one running NGINX to speak the FastCGI protocol and actually provide value).
then why I can't expose it using docker-compose
version: '3.9'
services:
php:
container_name: php
build:
context: .
dockerfile: ./docker/php.8/Dockerfile
volumes:
- ./src:/var/www/html/
user: 1000:1000
ports:
- 9001:9000
nginx:
container_name: nginx
build:
context: .
dockerfile: ./docker/nginx/Dockerfile
ports:
- 8000:80
volumes:
- ./src:/var/www/html/
- ./volumes/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./volumes/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
depends_on:
- php
default.conf
location ~ \.php$ {
fastcgi_pass php:9001;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
it gives me
nginx | 2021/09/24 18:31:55 [error] 24#24: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.30.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://172.30.0.3:9001", host: "localhost:8000"
:thinking: :thinking: :thinking:
@abdulrahman19, ports:
only affects things hitting the docker host which then proxies to the correct port. From another container like nginx, you have to hit the correct port (9000
). And you really shouldn't be exposing your PHP fpm port publicly.
@yosifkit yes, I understand that I shouldn't be exposing PHP-FPM port. I'm not talking about the correct thing.
I just don't understand the mechanism, why docker can't expose PHP-FPM port using port
even if port 9000
is on 0.0.0.0
host, which means anyone can use it!
I need to understand docker behavior in this case because I don't know why docker is not be able to expose this port, and I can't use it from anywhere, even nginx
in the same network!
ports:
only affects things hitting the docker host which then proxies to the correct port.
I don't get what do you mean by that? Isn't PHP-FPM use docker as a host! :slightly_frowning_face: If you can explain it more to me I will be thankful :pray:
I don't get what do you mean by that? Isn't PHP-FPM use docker as a host! :slightly_frowning_face: If you can explain it more to me I will be thankful :pray:
To connect from one service to another when using docker-compose, you must connect to the listening port. For example, php:fpm
listens on 9000
, so the nginx service needs to connect by that: fastcgi_pass php:9000
.
The port:
setting will have zero effect between services; it only effects connections coming from external hosts (i.e. anything on the host machine's network). For example, the port: 8000:80
on the nginx
service means that a user would hit http://ip-or-dns-name-of-host:8000
to access the web-server.
The configuration in
/usr/local/etc/php-fpm.d/
is a bit unclear to me:What is the purpose of
zz-docker.conf
anddocker.conf
why are there 2 files? Is this so thatdocker.conf
gets includes before andzz-docker.conf
after the pool configuration?If that's the case doesn't it make sense to use
aa-docker.conf
for consistency?Why would we always want to force the
[www]
pool to listen on[::]:9000
?It would be great if some documentation could be added regarding best / expected practices for changing configuration.