When starting the container, I substitute docker-php-entrypoint.sh. There is code in the file that writes to /etc/hosts ip host.docker.internal
#!/bin/sh
set -e
HOST_DOMAIN="host.docker.internal"
if ! ping -q -c1 $HOST_DOMAIN > /dev/null 2>&1
then
HOST_IP=$(ip route | awk 'NR==1 {print $3}')
# shellcheck disable=SC2039
echo -e "$HOST_IP\t$HOST_DOMAIN" >> /etc/hosts
fi
#first arg is `-f` or `--some-option`
if [ "${1#-}" != "$1" ]; then
set -- php-fpm "$@"
fi
exec "$@"
I also change the user that runs the container from root to app
FROM php:8.1-cli-alpine
....................................
COPY ./common/entrypoint.sh /usr/local/bin/docker-php-entrypoint
RUN chmod +x /usr/local/bin/docker-php-entrypoint
RUN addgroup -g 1000 app && adduser -u 1000 -G app -s /bin/sh -D app
WORKDIR /app
USER app
Launching the container is terminated with the error âPermission deniedâ
In general, it is clear that the app user does not have permissions to write to /etc/hosts.
I tried to run docker-php-entrypoint via RUN right after setting execution rights and before creating the app user - error âRead-only file systemâ.
I tried to use su in docker-php-entrypoint, no result.
How can I solve this problem, so that the container is started from app, but it is possible to make an entry in /etc/hosts?
This changes the group ownership to the user group with ID 1000 and sets the permissions so that both the owner (root) and group (1000) can read and write, while others can only read. (ChatGPT)
A bit cleaner would be this, but itâs not always available
setfacl -m u:app:rw /etc/hosts
In general this does have security implications! If some can abuse your app and make changes to the file, it might be a security risk.
Of course itâs a permission problem, but I canât figure out how to solve it.
Iâll try your way, maybe it will help.
The sudo requires a password, when launching the container you need to launch without a password.
This is required on the local server, the production server will not use this code.
This is a good example for doing something that shouldnât be done at all with Docker. As you already knew, app user canât write the hosts file, but even if it could, it doesnât need to. In old Docker versions that didnât use buildkit by default, you could write the hosts file during build, but I never needed it. Buildkit uses a different method to build images running (If I remember correclty) runc and the hosts file is not writeable.
What you need is --add-host hostname:ip passed to docker run or extra_hosts in compose.
But why do you want to refer to the containerâs IP address using host.docker.internal? That is pointed to the physical host through a proxy in Docker Desktop and you can implement a similar feature on Linux without the Desktop as well:
By the way the hosts file is not actually part of the containerâs filesystem. It is mounted into it. You can use docker container inspect to get its path:
I have something like that too based it on jwilder/docker-gen and I similarly supported only Linux, possibly MacOS, but never tried it there. However, in this topic the goal was to edit the hosts file inside the container, not on the host. Changing it inside the container is what the add-host parameter is for. I still thank you for sharing your image.
I get that but this is still not what this topic was about. Docker has its own DNS server so for container to container communication you donât need to create one manually. You can also use network aliases so donât have to use the name of the service or container, you can have any alias you like without knowing the IP address.
However, this topic was about accessing the Docker host. You could probably still use a new DNS server to support that hostname in containers but why would you run a DNS server for that when --add-host adds that host and IP without any additional service?
So it seems to me that a DNS server would be useful only when you want to use that from the host too, and resolve internal domain names of containers so you donât have to edit the hosts file on the Docker host.