Come rendere i volumi permanenti con Docker Compose v2

Question

Mi rendo conto che altre persone hanno avuto domande simili ma questo utilizza il formato di file di composizione v2 e non ho trovato nulla per quello.

Voglio fare un'app di prova molto semplice per giocare con MemSQL ma non riesco a ottenere i volumi per non essere cancellato dopo docker-compose down. Se ho capito bene Docker Docs, i volumi non dovrebbero essere cancellati senza esplicitarlo. Tutto sembra funzionare con docker-compose up ma dopo essere andato giù e poi di nuovo tutti i dati vengono cancellati dal database.

Come consigliato, utilizzo un servizio separato di memsqldata come livello dati separato.

Ecco la mia finestra mobile-compose.yml:

version: '2' 
services: 
    app: 
     build: . 
     links: 
      - memsql 
    memsql: 
     image: memsql/quickstart 
     volumes_from: 
      - memsqldata 
     ports: 
      - "3306:3306" 
      - "9000:9000" 
    memsqldata: 
     image: memsql/quickstart 
     command: /bin/true 
     volumes: 
      - memsqldatavolume:/data 

volumes: 
    memsqldatavolume: 
     driver: local 

Answer 1

Questo è stato fatto risalire a una cattiva documentazione da MemSQL. Il percorso dei dati MemSQL nel contenitore è /memsql e non nello /var/lib/memsql come in un'installazione autonoma (e nei documenti MemSQL), e sicuramente non nello /data come qualcuno mi ha detto.

Answer 2

Si utilizza docker-compose down e se si guarda la documentazione here

contenitori di arresto e rimuovere i contenitori, le reti, i volumi e le immagini creato da up. Solo i contenitori e le reti vengono rimossi per impostazione predefinita.

Avete ragione, non dovrebbe rimuovere i volumi (per impostazione predefinita). Potrebbe essere un bug o potresti aver cambiato la configurazione predefinita. Ma penso che il comando giusto per te sia docker-compose stop. Proverò a eseguire alcuni test con casi più semplici per il comando down.

Answer 3

Non sicuro se questo aiuta o no. Quando si utilizza docker-compose up -d, il contenitore viene scaricato e le immagini sono state create. Per fermare le immagini del docker, le immagini rimarranno e potranno essere riavviate con docker-compose start

Stavo usando i comandi su/giù e continuavo a perdere i miei dati finché non ho provato lo stop/start e ora i dati persistono.

Answer 4

La soluzione più semplice è utilizzare docker-compose stop anziché docker-compose down. E poi docker-compose start per riavviare.

In base allo docs, down "interrompe i contenitori e rimuove contenitori, reti, volumi e immagini creati da up."

Answer 5

Mi rendo conto che questo è un thread vecchio e risolto in cui l'OP stava puntando a una directory nel contenitore piuttosto che al volume che avevano montato, ma voleva chiarire parte della disinformazione che sto vedendo.

docker-compose down non rimuove i volumi, è necessario eseguire docker-compose down -v se si desidera eliminare anche i volumi.Ecco il testo della guida direttamente dalla finestra mobile-composizione (notare il "default" lista):

$ docker-compose down --help 
Stops containers and removes containers, networks, volumes, and images 
created by `up`. 

By default, the only things removed are: 

- Containers for services defined in the Compose file 
- Networks defined in the `networks` section of the Compose file 
- The default network, if one is used 

Networks and volumes defined as `external` are never removed. 

Usage: down [options] 

Options: 
... 
    -v, --volumes  Remove named volumes declared in the `volumes` section 
         of the Compose file and anonymous volumes 
         attached to containers. 
... 

$ docker-compose --version 
docker-compose version 1.12.0, build b31ff33 

Ecco un yml campione con un volume di nome per testare e un comando fittizio:

$ cat docker-compose.vol-named.yml 
version: '2' 

volumes: 
    data: 

services: 
    test: 
    image: busybox 
    command: tail -f /dev/null 
    volumes: 
    - data:/data 

$ docker-compose -f docker-compose.vol-named.yml up -d 
Creating volume "test_data" with default driver 
Creating test_test_1 

Dopo l'avvio il contenitore, il volume è inizializzato vuoto poiché l'immagine è vuota in quella posizione. Ho creato un mondo ciao veloce in quella posizione:

$ docker exec -it test_test_1 /bin/sh 
/# ls -al /data 
total 8 
drwxr-xr-x 2 root  root   4096 May 23 01:24 . 
drwxr-xr-x 1 root  root   4096 May 23 01:24 .. 
/# echo "hello volume" >/data/hello.txt 
/# ls -al /data 
total 12 
drwxr-xr-x 2 root  root   4096 May 23 01:24 . 
drwxr-xr-x 1 root  root   4096 May 23 01:24 .. 
-rw-r--r-- 1 root  root   13 May 23 01:24 hello.txt 
/# cat /data/hello.txt 
hello volume 
/# exit 

Il volume è visibile al di fuori finestra mobile ed è ancora lì dopo un docker-compose down:

$ docker volume ls | grep test_ 
local    test_data 

$ docker-compose -f docker-compose.vol-named.yml down 
Stopping test_test_1 ... done 
Removing test_test_1 ... done 
Removing network test_default 

$ docker volume ls | grep test_ 
local    test_data 

Ricreare il contenitore utilizza il vecchio volume con il file ancora all'interno visibile:

$ docker-compose -f docker-compose.vol-named.yml up -d 
Creating network "test_default" with the default driver 
Creating test_test_1 

$ docker exec -it test_test_1 /bin/sh 
/# cat /data/hello.txt 
hello volume 
/# exit 

e l'esecuzione di un docker-compose down -v finalmente rimuove sia il contenitore e il volume:

$ docker-compose -f docker-compose.vol-named.yml down -v 
Stopping test_test_1 ... done 
Removing test_test_1 ... done 
Removing network test_default 
Removing volume test_data 

$ docker volume ls | grep test_ 

$ 

Se trovate i dati è solo essere persisteva se si utilizza uno stop/start, piuttosto che un down/up, quindi i dati vengono archiviati nel contenitore, piuttosto che un volume, e il contenitore non è persistente . Assicurati che la posizione dei dati all'interno del contenitore sia corretta per evitare questo.