docker-compose y puertos expuestos

Hey JaroslavTyc,

Thanks for this tip! Yeah, docker compose is the command you should use these days.

Cheers!

Hey droptica_team,

Thank you for sharing this tip with others!

Cheers!

28/08/2024 Update:

docker compose exec database psql --user app --password app

Thanks for this tip!

Hello odds. I'm encountering the exact same problem. Did you find a solution ?

by the way, symfony console doctrine:database:create gives the following error:

An exception occurred in the driver: SQLSTATE[08006] [7] connection to server at "127.0.0.1", port 49154 failed: FATAL:  password authentication failed for user "app"

Hi there!

Sorry for the trouble, but I think I know what the problem is. Since a few weeks ago, the Doctrine recipe comes with Pgsql 14 instead of 13. That's actually fine. However, it's possible that you have an existing volume from running Docker earlier that had a pgsql "data" directory for pgsql 13. And this is causing problem with pgsql 14 operating properly.

This is what happened to me, and it gave me the same error that you're all getting. To see the error, try to start docker without the -d:

docker-compose up -d

This gave me a very clear error:

The data directory was initialized by PostgreSQL version 13, which is not compatible with this version 14.4.

So, where did this "volume" come from? With the docker-compose.yml file, when you start a database, it creates a volume whose name is generated from the name of the directory you're inside. If you download the course code and move into the start directory, then your directory name is start. This will cause a volume called start_db-data to be created, which stores your database data.

You can see all your volumes by running:

docker volume ls

So, if you're like me, the problem is caused by using Docker with pgsql 13 previously inside a directory named start. What's the fix? There are two:

1) Delete the old volume - this will only work if that docker container is no longer running: docker volume rm start_db-data

2) Rename the directory you're inside of.

Let me know if that helps!

Cheers!

That's unfortunately not my problem. My version is 14 on both, but it somehow did not make a role:

spellencafe-database-1  | 2022-12-11 12:46:06.167 UTC [40] FATAL:  password authentication failed for user "=app"
spellencafe-database-1  | 2022-12-11 12:46:06.167 UTC [40] DETAIL:  Role "=app" does not exist.
spellencafe-database-1  |       Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"

Now, when I log in with docker-compose exec and try and CREATE ROLE app it says:

[58] ERROR:  role "app" already exists

I`m guessing this has nothing to do with Symfony but more so with either PostgreSQL and/or Docker. If you could point me in the right direction, I would be greatfull.

No clue what's happening, but I downgraded the Postgres_version in docker-compose.yml from 14 to 13 (since that's the version on my production server). Although my local psql is on 14 and the server is now on 13, it seems to work, so far...

Super weird - thanks for the update. If you notice anything else strange, I'd love to know.

Hello @weaverryan
I do not get the same error as your's when I run docker-compose up
Here is what I get :

➜  mixed_vinyl git:(main) ✗ docker-compose up
Creating network "mixed_vinyl_default" with the default driver
Creating mixed_vinyl_database_1 ... done
Attaching to mixed_vinyl_database_1
database_1  |
database_1  | PostgreSQL Database directory appears to contain a database; Skipping initialization
database_1  |
database_1  | 2022-12-08 10:56:33.092 UTC [1] LOG:  starting PostgreSQL 14.6 on aarch64-unknown-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924, 64-bit
database_1  | 2022-12-08 10:56:33.092 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
database_1  | 2022-12-08 10:56:33.092 UTC [1] LOG:  listening on IPv6 address "::", port 5432
database_1  | 2022-12-08 10:56:33.094 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
database_1  | 2022-12-08 10:56:33.096 UTC [21] LOG:  database system was shut down at 2022-12-07 16:04:40 UTC
database_1  | 2022-12-08 10:56:33.101 UTC [1] LOG:  database system is ready to accept connections
database_1  | 2022-12-08 10:59:56.159 UTC [34] FATAL:  password authentication failed for user "app"
database_1  | 2022-12-08 10:59:56.159 UTC [34] DETAIL:  Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"

seems to be logging so we can see the failed connexion attempt

bye the way, here is the content of the services key in my docker-compose.yml :

  database:
    image: postgres:${POSTGRES_VERSION:-14}-alpine
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-app}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-ChangeMe}
      POSTGRES_USER: ${POSTGRES_USER:-app}
    volumes:
      - db-data:/var/lib/postgresql/data:rw

Hmm, does renaming your directory to something else help? I'm still suspect that there is an existing volume using pgsql 13 that is causing problems. Also, I can't think of why this would make a difference, but oddly your POSTGRES_PASSWORD is slightly different than the one that comes with the recipe: https://github.com/symfony/recipes/blob/main/doctrine/doctrine-bundle/2.4/manifest.json#L31

Cheers!

Hello @weaverryan.
I just started a new symfony project with symfony new and run the composer require doctrine commande right after, to put your theory to the test.
In this new project, everything seems to work perfectly :
I can connect to the database in the container with psql --user=app --port=56899 --host=127.0.0.1 --password app
and the symfony console doctrine:database:create yells at me something about a database "app" thas already exists... ;)
I'm glad to start this new week with Symfony, especially with this problem solved.

Thanks a lot for your help, and for all these useful (and fun) videos.
You rock, have a nice week.

PS : renaming the folder of the mixed_vinyl project works, too

Hey Xesh! Thank you for the update! This tells me that, at least some people had the same issue as me :).

Have a great week!

Hey FriendlyDev,

Thank for this tip! Yeah, you need to use your actual DB credentials you have set up in the .env files

Cheers!

Hey Def,

Hoe do you run your Symfony app? You should not use bin/console calls anymore if you're going to use Docker, you would need to replace all your commands with symfony console instead - that will handle all the Docker integration for you :)

So, e.g. instead of bin/console doctrine:query:execute run symfony console doctrine:query:execute, etc.

If still does not work - try to "down" all your containers. i.e. run docker composer down and then up them again with docker composer up - there might be a misconfiguration etc.

Cheers!

Thx Victor for your help

Unfortunatly, it seems like it's a biggest issue with my docker conf because i tried to install a whole new symfony project with a new docker-compose configuration and when i start my local webserver on this new project and up my containers I also have a docker compose down and "Env vars" none, so... yeah
I don't know what to do but thanks

Hey Def,

Hm, not sure then, I don't use Docker daily :) Maybe try to go through Docker docs to reinstall and configure it from scratch, maybe something is missing. Actually, check for updates first, maybe you just need to upgrade to the latest. Btw, laptop restart may help sometimes too.

Cheers!

Hey Stanislaw,

Thanks for this tip! Yeah, you need to run docker compose down to drop all the created containers and start them again with docker compose up.

Cheers!

Hey,

Thanks for the tip. Can you please share your OS version? Probably it's important because we all use different systems =)

Cheers and happy coding!

Hey Eric!

Apologies for my very slow reply! Holidays started early this year at my house :p.

Ok, this sounds frustrating :/. So, I CAN repeat your error message, but only if I change docker-compose.yml in a specific way. Here is an abbreviated version of my docker-compose.yml file, which came (like in the tutorial) from the DoctrineBundle recipe after installing Doctrine:

services:
###> doctrine/doctrine-bundle ###
  database:
    # ...
    volumes:
      - db-data:/var/lib/postgresql/data:rw
###< doctrine/doctrine-bundle ###

volumes:
###> doctrine/doctrine-bundle ###
  db-data:
###< doctrine/doctrine-bundle ###

With this config (well, again, I'm hiding less-important parts, but hopefully you get the idea), things work. How can I repeat your error? By removing the volumes section. In other words, it seem like, in your config, the volumes section is missing... or perhaps it's called something different than db-data. Basically, because we have - db-data:... above, we should have a volume called db-data: near the bottom.

Let me know if that helps! For reference, here is my full, unchanged, docker-compose.yml file after installing Doctrine (this version works for me):

version: '3'

services:
###> doctrine/doctrine-bundle ###
  database:
    image: postgres:${POSTGRES_VERSION:-14}-alpine
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-app}
      # You should definitely change the password in production
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-!ChangeMe!}
      POSTGRES_USER: ${POSTGRES_USER:-app}
    volumes:
      - db-data:/var/lib/postgresql/data:rw
      # You may use a bind-mounted host directory instead, so that it is harder to accidentally remove the volume and lose all your data!
      # - ./docker/db/data:/var/lib/postgresql/data:rw
###< doctrine/doctrine-bundle ###

volumes:
###> doctrine/doctrine-bundle ###
  db-data:
###< doctrine/doctrine-bundle ###

Cheers!

Hi Ryan,

Yes, having volumes: with a key that matches the volumes: in services.database.volumes helped. But my problem was I've been using colima as a docker context. I usually run a .ddev/colima with mutagen stack, which works great for Drupal and avoids the subscription service for Docker desktop as well as the Docker desktop app.

Once, I changed the docker context back to default (which means docker) and started the docker desktop app (bleh), the docker daemon was started and the symfony app found the database through doctrine right away.

My next questions are out of scope, but do you know how to run the docker daemon without the docker desktop app?
And can Colima be used as a replacement for Docker in Symfony?

Thanks. Enjoy the rest of the holidays.

Hey EricSod!

Ah, ok, this makes more sense then!

Once, I changed the docker context back to default (which means docker) and started the docker desktop app (bleh), the docker daemon was started and the symfony app found the database through doctrine right away.

Tbh, I'm not familiar with Colima, though it looks super interesting. Unfortunately, because I'm a bit clueless about it (other than reading about it just now for about 10 minutes), I don't know why you had the volumes problem when using it. But, as far as Symfony + Docker + Database is concerned the volumes part isn't important. What's important is that your docker-compose.yaml has a service called database. So, the whole solution may still be workable, but I don't know enough to say how.

My next questions are out of scope, but do you know how to run the docker daemon without the docker desktop app?

I'm a bit clueless here too :). But, from my reading, it sounds like one of the points of colima is to be able to run Docker without needing Docker desktop - but just by running brew install docker? I have a feeling you already knew that, but let me know.

And can Colima be used as a replacement for Docker in Symfony?

I can't say for certain, but the symfony basically looks for a docker-compose.yaml file, loops over the services inside, then (using the name of each service) it creates some environment variables that point to that service. If you satisfy both of these requirements - regardless of it's all setup, then it should all work. But also, keep in mind that this setup is just an "easy" way to get a database setup in Docker and hooked up with your Symfony app. It should be making your life easier, not harder. If it's not doing that, then don't use it (and that's totally ok!).

Cheers!

With the docker desktop app running, set the docker default to colima with

docker context use colima

and run

docker-compose up -d

The prompt returns

Cannot connect to the Docker daemon at unix:///Users/esod/.colima/default/docker.sock. Is the docker daemon running?

Symfony profiler reports Server -> Docker Compose -> Down.

Switch the docker default to docker with

docker context use default

run docker-compose up -d and confirm the Symfony profiler is reporting Docker Compose -> Up.

Note: Quit the Docker Desktop app and Symfony profiler reports Server -> Docker Compose -> Down.

Sounds like two problems now. Yay DevOps. :-)

Anyway, the recipe for success is what you're recommending in the tutorial.

1. Install Docker, Docker Compose, and Docker Desktop app.
2. Set docker context to use default (which is docker).
   1. Only necessary if you've been using Colima, like with .ddev.
3. Open Docker Desktop app.
4. docker-compose up -d
5. Confirm Symfony profiler reports Docker Compose -> Up.

Hey EricSod!

Thanks for the detailed reply - and boo when things don't work more easily! :P Happy you're at least not blocked.

Cheers!

Hey Laurent-G,

It seems like you're missing that psql command installed locally, though the error message is a bit weird to me. Do you have psql installed locally? You should have it installed to be able to connect to the DB from Docker. On my Mac when I execute psql --version it shows me psql (PostgreSQL) 14.5 (Homebrew), IIRC I installed the PostgreSQL via Brew package manager locally and it brought me that psql command. If you don't have PostgreSQL installed locally - try to install it first. But brew is specific for Mac, you should find a way to install PostgreSQL on Windows.

Of if you don't want to (or cannot) install it locally - see the next chapter where we execute that psql command directly from the Docker container.

Cheers!

Thanks Victor for your answer.

i don't have installed psql locally. I'm going to see for install psql on my windows system.
i already saw in the next chapter the command to execute psql from Docker container and it's work very good.

Thanks a lot,
Laurent

Hey Laurent-G,

Glad that executing it from the Docker container works for you, thanks for confirming! I bet you just need to install PostgreSQL and it will bring that psql command into your system automatically. Or you can just ignore it and execute it directly from the Docker container - that's the benefit of having Docker ;)

Cheers!

figured it out (lost a lot of time because of the stupid ! at the start of the !ChangeMe! password......)

1. change the DATABASE_URL in the .env file to the mysql one.
2. remove the !ChangeMe! password docker-compose doesn't like it when it tries to create a mysql container
3. comment out the the postgres lines in the docker-compose.yml (From the services: tag to the end)
4. Add the following lines to your docker-compose.yml

services:
  database:
    container_name: database
    image: mysql:8.0
    command: --default-authentication-plugin=mysql_native_password
    environment:
      MYSQL_ROOT_PASSWORD: yoursecretrootpassword
      MYSQL_DATABASE: yourdbname
      MYSQL_USER: app
      MYSQL_PASSWORD: yourpasswd   <-- the one you used in the .env file
    ports:
      - '3306:3306'
    volumes:
      - ./mysql:/var/lib/mysql`

Hey Red,

I'm happy to see you were able to find the solution! And thanks for sharing it with others :)

Cheers!

Hey Mark,

Hm, could you change that "!ChangeMe!" password in .env files to something without special chars, I guess that the exclamation char (!) may cause issues. And then restart the server and try to connect with the new credentials.

Cheers!

Hey Thomas A.!

Oh sheesh - try this instead - changing "symfony" to "app":

docker-compose exec database psql --username app --password app

Explanation: RIGHT after recording, the recipe was updated - you probably have the new version https://github.com/symfony/recipes/commit/b3395a2477b6d58089f92ef3a0d2e58226825a3a#diff-b52cb1d9a056076027dd6033aa8c573524746ed54fcdeeb5c8eef83431b9da9aL32

Let me know if that helps - we'll need to add a note about it :).

Cheers!