symfony cli not setting port for dockerized postgresql db #472

naturefund-falk · 2024-05-03T13:12:10Z

I created a new symfony (7.0.7) webapp, created an entity and wanted to run symfony console doctrine:database:create. Output:
An exception occurred in the driver: SQLSTATE[08006] [7] connection to server at "127.0.0.1", port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections?
Apparently the port number is wrong here. As i understood the symfony command, it should detect the real port number of the postgres container and then call the doctrine:database:create command. But it seems this is not happening. Running 'symfony run printenv' does not print anything related to the database.

The database is running inside docker (status=unhealthy, but running 'pg_isready -U ${POSTGRES_USER:-app}' inside the container is running ok and no error messages in logs).
Docker 26.1.1 is installed in rootless mode on a debian 12 system.
Symfony cli version is 5.8.16.

The text was updated successfully, but these errors were encountered:

ebitkov · 2024-05-22T10:33:24Z

Kinda the same problem here, but with a MySQL Server.

I'm debugging this for a few days now, but coming to the conclusion, that the CLI is not detecting the Docker containers.

My System:

Symfony CLI version 5.8.15

Docker Desktop 4.29.0
Docker Compose version v2.26.1-desktop.1 (comes pre-packed with Docker Desktop)

Linux
Zorin OS 17.1 (Ubuntu-based)

My compose.yaml:

services:
    ###> doctrine/doctrine-bundle ###
    database:
        image: mysql:${MYSQL_VERSION:-8.0.33}
        volumes:
            - ./docker/provision/mysql/init:/docker-entrypoint-initdb.d
        environment:
            MYSQL_DATABASE: ${MYSQL_DATABASE:-app}
            MYSQL_ROOT_PASSWORD: root
            MYSQL_PASSWORD: ${MYSQL_PASSWORD:-!ChangeMe!}
            MYSQL_USER: ${MYSQL_USER:-app}
        healthcheck:
            test: [ "CMD", "mysqladmin" ,"ping", "-h", "localhost" ]
            timeout: 5s
            retries: 10
        ports:
            -   "3306:3306"
    ###< doctrine/doctrine-bundle ###

I can connect to the database, but have to bind the port statically. Ideally you could just set "ports: [ 3306 ]" and the CLI would automatically pick up the port set by Docker, right?

Also the web profiler indicates, that Docker is not running:

Note, that in the latest version of Docker, the docker-compose command is deprecated and removed, only leaving docker compose (at least on my system). Could it be, that the Docker Compose API changed and the CLI is not able to detect the containers correctly?

Also: Docker Desktop sets the unix socket on unix:///home/user/.docker/desktop/docker.sock. Could this be a problem? Is there a way to manually configure the path to the socket? I couldn't find any documentation about that.

tucksaun · 2024-09-09T12:45:05Z

Note, that in the latest version of Docker, the docker-compose command is deprecated and removed, only leaving docker compose (at least on my system). Could it be, that the Docker Compose API changed and the CLI is not able to detect the containers correctly?

This is unlikely as we directly use the Go library from Docker Compose and do not rely on the docker-compose or docker binaries to be present.

Also: Docker Desktop sets the unix socket on unix:///home/user/.docker/desktop/docker.sock. Could this be a problem? Is there a way to manually configure the path to the socket? I couldn't find any documentation about that.

We rely on the Docker official source code for this (see above). So if the docker binary can detect the path we should also be able to detect it (see

symfony-cli/envs/docker.go

Lines 72 to 91 in 37bdf46

    
           opts := [](docker.Opt){docker.FromEnv} 
        
           if host := os.Getenv(docker.EnvOverrideHost); host != "" && !strings.HasPrefix(host, "unix://") { 
        
           	// Setting a dialer on top of a unix socket breaks the connection 
        
           	// as the client then tries to connect to http:///path/to/socket and 
        
           	// thus tries to resolve the /path/to/socket host 
        
           	dialer := &net.Dialer{ 
        
           		Timeout: 2 * time.Second, 
        
           	} 
        
           	opts = append(opts, docker.WithDialContext(dialer.DialContext)) 
        
           } 
        
           client, err := docker.NewClientWithOpts(opts...) 
        
           if err != nil { 
        
           	if l.Debug { 
        
           		fmt.Fprintf(os.Stderr, "ERROR: %s\n", err) 
        
           	} 
        
           	return nil 
        
           } 
        
           defer client.Close() 
        
           client.NegotiateAPIVersion(context.Background())

).

To debug, you should be able to use symfony var:export -v=5 --debug to get a bit more information about what is going on.
Also a random question: do you happen to have your Docker compose project name defined in your compose.yaml file?

ebitkov · 2024-09-09T13:04:54Z

I can confirm, that this problem still exists:

Symfony CLI version  5.10.2

Client: Docker Engine - Community
 Cloud integration: v1.0.35+desktop.13
 Version:           27.2.0
 API version:       1.45 (downgraded from 1.47)
 Go version:        go1.21.13
 Git commit:        3ab4256
 Built:             Tue Aug 27 14:15:13 2024
 OS/Arch:           linux/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.29.0 (145265)
 Engine:
  Version:          26.0.0
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.8
  Git commit:       8b79278
  Built:            Wed Mar 20 15:18:01 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.28
  GitCommit:        ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

To debug, you should be able to use symfony var:export -v=5 --debug to get a bit more information about what is going on.

It returns the following (first two lines added by me):

Symfony CLI version 5.10.2
symfony var:export -v=5 --debug
{"level":"trace","time":"2024-09-09T14:52:44+02:00","message":"Using CLI flags for 'log-level' configuration entry.\n"}
{"level":"trace","time":"2024-09-09T14:52:44+02:00","message":"Using CLI flags for 'v' configuration entry.\n"}
{"level":"trace","time":"2024-09-09T14:52:44+02:00","message":"Using CLI flags for 'debug' configuration entry.\n"}
{"level":"warn","time":"2024-09-09T14:52:44+02:00","message":"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"}
SYMFONY_APPLICATION_DEFAULT_ROUTE_URL=https://127.0.0.1:8000/ 
SYMFONY_APPLICATION_DEFAULT_ROUTE_SCHEME=https 
SYMFONY_DOCKER_ENV= 
SYMFONY_PROJECT_DEFAULT_ROUTE_PATH=/
SYMFONY_DEFAULT_ROUTE_URL=https://127.0.0.1:8000/ 
SYMFONY_TUNNEL_BRAND= 
SYMFONY_DEFAULT_ROUTE_HOST=127.0.0.1:8000 
SYMFONY_PROJECT_DEFAULT_ROUTE_PORT=8000 
SYMFONY_PROJECT_DEFAULT_ROUTE_SCHEME=https 
SYMFONY_DEFAULT_ROUTE_SCHEME=https 
SYMFONY_APPLICATION_DEFAULT_ROUTE_HOST=127.0.0.1:8000 
SYMFONY_APPLICATION_DEFAULT_ROUTE_PATH=/ 
SYMFONY_TUNNEL= 
SYMFONY_PROJECT_DEFAULT_ROUTE_URL=https://127.0.0.1:8000/ 
SYMFONY_DEFAULT_ROUTE_PORT=8000 
SYMFONY_TUNNEL_ENV= SYMFONY_DEFAULT_ROUTE_PATH=/ 
SYMFONY_PROJECT_DEFAULT_ROUTE_HOST=127.0.0.1:8000 
SYMFONY_APPLICATION_DEFAULT_ROUTE_PORT=8000

The daemon and container was running when I executed:

Also a random question: do you happen to have your Docker compose project name defined in your compose.yaml file?

I think not. I posted my compose file above. Since then I didn't changed anything about it, so you can double check, if you want.

tucksaun · 2024-09-09T13:17:22Z

{"level":"warn","time":"2024-09-09T14:52:44+02:00","message":"Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?"}

there it is.

can you try enabling this option?

thanks!

ebitkov · 2024-09-10T06:36:57Z

Looks like the solution... Sadly I'm missing the "Advanced" tab in my Docker Desktop app - probably an error on dockers side. ~~Trying to fix it and going to respond as soon as I can confirm the option does fix the issue.~~

ebitkov · 2024-09-10T10:23:00Z

It seems like there is currently a bug in Docker Desktop, where the "Advanced" tab might be not appear for some users (see docker/for-mac#7127).

For anybody, who has the same problem, can use the following fix for now:

Get the unix path with docker context ls. This should return something similar like this:

NAME              DESCRIPTION                               DOCKER ENDPOINT                                    ERROR
default           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                        
desktop-linux *   Docker Desktop                            unix:///home/<USERNAME>/.docker/desktop/docker.sock

You need the Docker Desktop Endpoint.

Set the DOCKER_HOST variable on your system:
export DOCKER_HOST="unix:///home/<USERNAME>/.docker/desktop/docker.sock"
You can add this to your .bashrc file to set it on every startup.

The Symfony CLI does pick up the DOCKER_HOST variable and connects to the daemon successfully.

@naturefund-falk you might want to check your configured Docker endpoint (docker context ls) and check, if the CLI can connect to it (symfony var:export -v=5 --debug). Maybe this fix applies to you, too?

naturefund-falk · 2024-09-10T13:15:04Z

The solution from @ebitkov seems to work that way. My docker context ls output is:

NAME DESCRIPTION DOCKER ENDPOINT ERROR
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
rootless * Rootless mode unix:///run/user/1000/docker.sock

So i used the rootless socket for the DOCKER_HOST variable and the warning in (symfony var:export -v=5 --debug) about not connecting to docker is gone.

nathanheffley · 2024-12-26T20:48:50Z

Just dropping in here that I had a similar but slightly different problem. For anyone who tries these things but sees ERROR: unable to find a compose directory for the current directory when running the var:export --debug command, I hadn't initialized a git repository which is what the CLI uses to find your project directory which is then in turn used to find the Docker project used for the auto detection discussed here.

#551 is looking to add more detection methods which would hopefully make this misconfiguration issue less likely to occur.

ChoppyThing · 2024-12-30T18:43:40Z

Just dropping in here that I had a similar but slightly different problem. For anyone who tries these things but sees ERROR: unable to find a compose directory for the current directory when running the var:export --debug command, I hadn't initialized a git repository which is what the CLI uses to find your project directory which is then in turn used to find the Docker project used for the auto detection discussed here.

#551 is looking to add more detection methods which would hopefully make this misconfiguration issue less likely to occur.

I'm having this exact issue. I don't totally get it, but i removed the .git folder from the symfony directory as it lives in a larger project.

Sadly everything worked well on previous days but i cannot get it to work now.

Any ideas would be appreciated!

nathanheffley · 2024-12-31T18:12:30Z

Unfortunately, as my comment explains, the .git repository is how Symfony CLI detects the compose directory so without that it won't work. You could manually install the branch of the PR I linked as your Symfony CLI so that it detects other files as well.

Otherwise, with the current version, you'll have to turn your Symfony CLI into its own git project and then include it in the larger one as a submodule.

nathanheffley · 2024-12-31T18:14:48Z

I'm having this exact issue. I don't totally get it, but i removed the .git folder from the symfony directory as it lives in a larger project.

Sadly everything worked well on previous days but i cannot get it to work now.

Any ideas would be appreciated!

Oh, actually, the git repo change was recent.

f11e67e

Use a version of the CLI from before a month ago and you should go back to old behavior.

fabpot · 2025-01-01T21:39:16Z

See #555

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

symfony cli not setting port for dockerized postgresql db #472

symfony cli not setting port for dockerized postgresql db #472

naturefund-falk commented May 3, 2024

ebitkov commented May 22, 2024 •

edited

Loading

tucksaun commented Sep 9, 2024

ebitkov commented Sep 9, 2024 •

edited

Loading

tucksaun commented Sep 9, 2024

ebitkov commented Sep 10, 2024 •

edited

Loading

ebitkov commented Sep 10, 2024

naturefund-falk commented Sep 10, 2024 •

edited

Loading

nathanheffley commented Dec 26, 2024

ChoppyThing commented Dec 30, 2024

nathanheffley commented Dec 31, 2024

nathanheffley commented Dec 31, 2024

fabpot commented Jan 1, 2025

symfony cli not setting port for dockerized postgresql db #472

symfony cli not setting port for dockerized postgresql db #472

Comments

naturefund-falk commented May 3, 2024

ebitkov commented May 22, 2024 • edited Loading

tucksaun commented Sep 9, 2024

ebitkov commented Sep 9, 2024 • edited Loading

tucksaun commented Sep 9, 2024

ebitkov commented Sep 10, 2024 • edited Loading

ebitkov commented Sep 10, 2024

naturefund-falk commented Sep 10, 2024 • edited Loading

nathanheffley commented Dec 26, 2024

ChoppyThing commented Dec 30, 2024

nathanheffley commented Dec 31, 2024

nathanheffley commented Dec 31, 2024

fabpot commented Jan 1, 2025

ebitkov commented May 22, 2024 •

edited

Loading

ebitkov commented Sep 9, 2024 •

edited

Loading

ebitkov commented Sep 10, 2024 •

edited

Loading

naturefund-falk commented Sep 10, 2024 •

edited

Loading