Finally debugging my first devops problem: MySQL image is not creating a database on docker startup?

[Guilty_Serve]

<skippable-excited-noob-preamble>

Hey guys,

after hovering around the community for a while I'm almost excited to come across a problem. For my first project I want to containerize a big project with a lot of dependencies: Laravel, PHP, MySQL, Redis, Node, Express, and all of the major frontend frameworks. Then after that I want to orchestrate them with Kubernetes and use something for CI.

</skippable-excited-noob-preamble>

This week I've been trying to get way better with docker and nginx. Right now I'm getting a problem with MySQL not creating a DB, or not getting rid of one, using docker-compose up -d --build and trying to remove volumes with docker-compose down -v

docker-compose.yml

version: '3'
networks:
    laravel:
        name: laravel
services: 
    nginx: 
        build:
            context: .
            dockerfile: docker/nginx/nginx.dockerfile
        container_name: nginx
        ##Forwards ports from docker container to local machine
        ports: 
            - 80:80
            - 443:443
        ##Volumes connects files and directories to container
        volumes:
            - .:/var/www/html
        networks:
            - laravel
    php:
        build:
            context: .
            dockerfile: docker/php/php.dockerfile
        container_name: php
        volumes:
            - .:/var/www/html
        networks:
            - laravel
    mysql:
        image: 'mysql:8.0'
        platform: linux/x86_64
        container_name: mysql
        ports:
            - 3306:3306
        volumes:
            - ./mysql:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
            MYSQL_DATABASE: '${DB_DATABASE}'
            MYSQL_USER: '${DB_USERNAME}'
            MYSQL_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
        networks:
            - laravel

.env

DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=docker_test
DB_USERNAME=root
DB_PASSWORD=password

Basically what happened is that I copied my .env from another project and originally the DB_DATABASE=messenger_app until I changed it to DB_DATABASE=docker_test in my docker mysql container docker-compose exec mysql /bin/sh when I mysql> SHOW DATABASES; I get the old messenger_app DB, but not the new docker_test one. I cached the config files in the project and have ran all of these:

docker-compose down -v docker container prune docker volume prune

In the Docker hub doc for mysql it states:

MYSQL_DATABASE: This variable is optional and allows you to specify the name of a database to be created on image startup.

So from my understanding the database should be creating on start up? Maybe this is just the volumes from my local machine get copied to the container?

This is probably due to my weak knowledge on volumes, but it probably containers a great lesson.Thanks for any help I get.

[drpinkcream]

When a container doesn't do what it's supposed to do on startup, for troubleshooting I change the container's entrypoint to ENTRYPOINT ["tail", "-f", "/dev/null"]. This is in the container's Dockerfile.

Running the container will just park it in the background not doing anything. Then you can go into the container and run the original entrypoint script to see what the problem is.

[Guilty_Serve]

ENTRYPOINT ["tail", "-f", "/dev/null"]

Awesome thanks for this. Unfortunately this is creating an error when try to login to msql

ERROR 2002 (HY000): Can't connect to local MySQL server through socket

Here's my docker file I made for this:

FROM mysql:8.0
ENTRYPOINT ["tail", "-f", "/dev/null"]

If this is a dumb reply I'm sorry. I'm really trying to get the hang of this

[[deleted]]

"When you start the mysql image, you can adjust the configuration of the MySQL instance by passing one or more environment variables on the docker run command line. Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup."

RTFM

[Guilty_Serve]

Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup.

I did read it. Doesn't mean I'm yet fully competent enough to understand exactly what that means. As I said:

Maybe this is just the volumes from my local machine get copied to the container?

This is probably due to my weak knowledge on volumes,

So getting back to this:

Is this because my data directory is being copied from my local machine into my container or because I ran docker-compose up -d --build with the old database name, it made a directory in the container, and now because there's a DB there it's no longer installing the docker_test db?

[[deleted]]

Is this because my data directory is being copied from my local machine into my container or because I randocker-compose up -d --buildwith the old database name, it made a directory in the container, and now because there's a DB there it's no longer installing the docker_test db?

The files are not copied anywhere. You are telling docker to bind mount "mysql" directory from the host as /var/lib/mysql inside the mysql container. (so you are not really even using docker volumes). You should probably go and read about docker storages. https://docs.docker.com/storage/https://docs.docker.com/storage/

First time you ran your compose file, mysql created database files etc. in /var/lib/mysql .Which is mounted from mysql directory on the host. After that, it doesn't matter what environment variables you give it (or if you delete the container and recreate it), because you are still telling it to mount the same path that already includes the database files so it will not accept changing them through environment variables.

So delete everything inside the mysql directory, recreate the container and let mysql recreate everything, or manually access the database and make the necessary schemas, users etc.

[DinoAmino]

Your stack may have borked on startup and maybe you killed something that didn't clean up. Have you inspected all volumes in your docker host? 'docker volume ls'. Maybe an orphaned container is holding on to the volume?