to execute commands against a running container use docker exec.

to copy a file (ex: dump.sql) into a container, use docker cp

So your approach might look something like this:

docker cp ./dump.sql pg_test:/docker-entrypoint-initdb.d/dump.sql
docker exec -u postgres pg_test psql postgres postgres -f docker-entrypoint-initdb.d/dump.sql

here it is in generic form:

docker cp ./localfile.sql containername:/container/path/file.sql
docker exec -u postgresuser containername psql dbname postgresuser -f /container/path/file.sql

And note that if you need to seed your database every time it is run, the folder /docker-entrypoint-initdb.d/ does have special significance, if you're using the offical postgres image

Its correct but it needs to be in your Db service

Example:

services:
    my_db:
      image: postgres:latest    
      volumes:
          - ./init.sql:/docker-entrypoint-initdb.d/init.sql
  

UPDATE:

problem with running in any other service is that its not going to have the credentials to connect to the database. So you can just create a shell script and run it the old fashioned way like so:

services:
    some_service:
        image: your_image    
        volume: ./init.sh:/init.sh
        entrypoint: sh -c "/init.sh"

assuming of course that you have the shell already installed in your image

You are overriding the original command and you do not start postgres in this script which is why your database is not available.

You can put your database initialization into the container's entrypoint directory: /docker-entrypoint-initdb.d. This executes all *.sh and *.sql files in this directory and does not touch the original command.
All files in this directory are automatically executed in the alphabetical order on container creation. Therefore, create a volume to add your scripts / sql files to the entrypoint and let the container execute them. This is described in the official postgres documentation, section "How to extend this image".

Your compose file then changes to something like this:

postgres:
  build: ./postgres
  volumes:
    - /shared_folder/postgresql:/var/lib/postgresql
    - ./db-init-scripts:/docker-entrypoint-initdb.d
  ports:
    - "5432:5432"

whereas a local directory, e.g. db-init-scripts, contains your initialization scripts (rename it if you want). Copy create_db.sh to this folder and it will be automatically executed when you create a new container.

Several database-images watch this entrypoint-directory, which is very convenient.

Your container_name: postgres seems redundant.

It didn't work for me with the COPY approach in Dockerfile. But I managed to run my init.sql file by adding the following to docker-compose.yml:

    volumes:
        - ./init.sql:/docker-entrypoint-initdb.d/init.sql

init.sql was in the same directory as my docker-compose.yml. I picked the solution from this gist. Check this article for more information.

Do you have two Dockerfiles? Looks like you built your own MySQL container?

Otherwise, these shouldn't be part of your Java multi-stage build

FROM mysql:5.7

ADD ./database/tshirtshop.sql /docker-entrypoint-initdb.d

Assuming that you did build a separate image for mysql, in the Docker-Compose, you're not using it, as you're still referring to image: mysql:5.7

Rather than building your own, you should mount the SQL script into it

For example

  mysqldb:
    image: mysql:5.7
    ...
    volumes:
      - db-data:/var/lib/mysql
      - ./database/tshirtshop.sql:/docker-entrypoint-initdb.d/0_init.sql

Then, forget the Java service for a minute and use MySQL workbench or the mysql CLI to verify that data is actually there. Once you do, then startup the API

docker exec -it yiialkalmi_postgres_1 psql -U project -W project

Some explanation

• docker exec -it The command to run a command to a running container. The it flags open an interactive tty. Basically it will cause to attach to the terminal. If you wanted to open the bash terminal you can do this

docker exec -it yiialkalmi_postgres_1 bash

• yiialkalmi_postgres_1 The container name (you could use the container id instead, which in your case would be 40e39bd0329a )

• psql -U project -W project The command to execute to the running container

• U user

• W Tell psql that the user needs to be prompted for the password at connection time. This parameter is optional. Without this parameter, there is an extra connection attempt which will usually find out that a password is needed, see the PostgreSQL docs.

• project the database you want to connect to. There is no need for the -d parameter to mark it as the dbname when it is the first non-option argument, see the docs: -d "is equivalent to specifying dbname as the first non-option argument on the command line."

These are specified by you here

environment:
    POSTGRES_DB: project
    POSTGRES_USER: project
    POSTGRES_PASSWORD: project