web-dev-qa-db-fra.com

Docker Compose mysql import .sql

J'ai du mal à importer un fichier de vidage .sql avec docker-compose. J'ai suivi les documents, qui apparemment chargeront le fichier .sql à partir de docker-entrypoint-initdb.d. Cependant, lorsque je lance docker-compose up, le fichier sql n'est pas copié dans le conteneur.

J'ai essayé d'arrêter les conteneurs avec -vf flag, mais cela n'a pas fonctionné non plus. Suis-je en train de faire quelque chose de mal dans mon script .yml?

J'ai dump.sql dans le répertoire database/db-dump/à la racine où se trouve mon fichier de composition.

frontend:
  image: myimage
  ports:
   - "80:80"
  links:
   - mysql
mysql:
  image: mysql
  ports:
   - "3306:3306"
  environment:
    MYSQL_ROOT_PASSWORD: rootpass
    MYSQL_USER: dbuser
    MYSQL_PASSWORD: userpass
    MYSQL_DATABASE: myimage_db
  volumes:
   - ./database/db-dump:/docker-entrypoint-initdb.d
mysqldockerdocker-compose
17
GafferG

Après de nombreuses tentatives avec le réglage des volumes, j'ai trouvé une solution de contournement

J'ai créé une autre image basée sur mysql avec ce qui suit dans le Dockerfile

FROM mysql:5.6

ADD dump.sql /docker-entrypoint-initdb.d

Ensuite, supprimé les volumes de composer et exécuté la nouvelle image

frontend:
  image: myimage
  ports:
   - "80:80"
  links:
   - mysql
mysql:
  image: mymysql
  ports:
   - "3306:3306"
  environment:
    MYSQL_ROOT_PASSWORD: rootpass
    MYSQL_USER: dbuser
    MYSQL_PASSWORD: userpass
    MYSQL_DATABASE: myimage_db

De cette façon, le vidage est toujours copié et exécuté au démarrage

24
GafferG

Cela a fonctionné pour moi,

version: '3.1'

services:

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    volumes:
      - ./mysql-dump:/docker-entrypoint-initdb.d
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_DATABASE: ecommerce

  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080

mysql-dump doit être un répertoire. Tous les .sql du répertoire seront importés.

12
Sridhar Sg

Cela apparaît sur la page de documentation de l'image Docker MySQL: https://hub.docker.com/_/mysql/

Initialisation d'une nouvelle instance

Lorsqu'un conteneur est démarré pour la première fois, une nouvelle base de données avec le nom spécifié sera créée et initialisée avec les variables de configuration fournies. De plus, il exécutera des fichiers avec des extensions .sh, .sql et .sql.gz qui se trouvent dans /docker-entrypoint-initdb.d. Les fichiers seront exécutés par ordre alphabétique. Vous pouvez facilement remplir vos services mysql en en montant un vidage SQL dans ce répertoire et en fournissant images personnalisées avec les données apportées. Les fichiers SQL seront importés par défaut dans la base de données spécifiée par le MYSQL_DATABASE variable.

11
Mvochoa

Le vidage de la base de données Mysql schema.sql réside dans le répertoire / mysql-dump/schema.sql et crée des tables pendant le processus d'initialisation.

docker-compose.yml:

mysql:
    image: mysql:5.7
    command: mysqld --user=root
    volumes:
      - ./mysql-dump:/docker-entrypoint-initdb.d
    environment:
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
9
ufukomer

J'avais un problème similaire avec mysql où je montais un répertoire local dans/configs/mysql/data contenant un fichier mydatabasedump.sql via docker-compose sur le volume docker-entrypoint-initdb.d, le fichier était chargé sur le conteneur mais pas exécuter ou remplir la base de données lors de l'initialisation du conteneur. Mon docker-compose.yml initial ressemble à ceci:

#docker-compose.yml
version: '3'
services:
    db:
        build: ./build/mysql/ #this is pointing to my Dockerfile
        container_name: MYSQL_Database
        restart: always
        environment:
        MYSQL_PORT: 3306
        MYSQL_ROOT_PASSWORD: admin
        MYSQL_DATABASE: my_app_database
        MYSQL_USER: admin
        MYSQL_PASSWORD: admin
    volumes:
        - ./configs/mysql/data:/docker-entrypoint-initdb.d:

J'ai trouvé deux solutions de travail pour ce problème:

Le premier est venu après que je me suis connecté au conteneur en cours d'exécution et ai confirmé que le fichier mydatabasedump.sq était présent et exécutable dans le répertoire docker-entrypoint-initdb.d du conteneur; J'ai créé et ajouté un script bash à mon répertoire local/configs/mysql/data appelé dump.sh qui a été exécuté après l'initialisation du conteneur. Il contient une seule commande mysql qui copie my_database_dump.sql dans my_app_database. Le script bash ressemble à ceci

    #!/bin/bash
    #dump.sh
    mysql -uadmin -padmin my_app_database < my_database_dump.sql 
    #end of dump.sh

J'ai exécuté ce script via mon Dockerfile dans la directive ENTRYPOINT comme ceci:

    #Dockerfile
    FROM mysql:5.5
    ENTRYPOINT [ "dump.sh" ]
    EXPOSE 80
    #end of Dokerfile

Après avoir réalisé que le problème initial était dû aux volumes en cours de montage après la construction du cotainer et donc à ne pas intégrer la base de données avec le fichier de vidage (ou exécuter des scripts dans ce répertoire) au démarrage, la deuxième solution consistait simplement à déplacer la directive volumes dans mon fichier de composition au-dessus de la directive construite. Cela a fonctionné et m'a permis de supprimer le script dump.sh et la directive DOCKERENTRY dans mon Dockerfile. Le docker-compose.yml modifié ressemble à ceci

#docker-compose.yml
version: '3'
services:
    db:
        volumes:
          - ./configs/mysql/data:/docker-entrypoint-initdb.d
       build: ./build/mysql/ #this is pointing to my Dockerfile
         container_name: MYSQL_Database
         restart: always
     environment:
         MYSQL_PORT: 3306
         MYSQL_ROOT_PASSWORD: admin
         MYSQL_DATABASE: my_app_database
         MYSQL_USER: admin
         MYSQL_PASSWORD: admin
0
Andre Myrtil