Dzieje się tu kilka rzeczy:
Najpierw docker commit to zapach kodu. Zwykle jest używany przez tych, którzy tworzą obrazy w procesie ręcznym, zamiast automatyzować ich kompilacje za pomocą pliku Dockerfile, który umożliwiłby łatwe odtworzenie. Jeśli to w ogóle możliwe, polecam przejście do pliku Docker w celu stworzenia obrazu.
Następnie docker commit nie przechwyci zmian wprowadzonych w woluminie. Ten sam problem występuje, gdy próbujesz zaktualizować wolumin za pomocą RUN krok w pliku Dockerfile. Oba te przechwytują zmiany w systemie plików kontenera i przechowują te zmiany jako warstwę w obrazie Docker, a woluminy nie są częścią systemu plików kontenera. Jest to również widoczne po uruchomieniu docker diff o pojemnik. W tym przypadku obraz nadrzędny zdefiniował głośność w swoim pliku Docker:
VOLUME /var/lib/mysql
A docker nie ma polecenia cofnięcia utworzonego woluminu z pliku Dockerfile. Musisz albo bezpośrednio zmodyfikować definicję obrazu spoza dockera (niezalecane) albo zbudować własny obraz nadrzędny z usuniętym tym krokiem (zalecane).
To, co zapewnia obraz mysql, to możliwość wstrzykiwania własnych skryptów do tworzenia bazy danych w /docker-entrypoint-initdb.d , który możesz dodać z własnym obrazem rozszerzającym mysql lub zamontować jako wolumin. W tym miejscu możesz wstrzyknąć swój schemat lub zainicjować ze znanej kopii zapasowej w celu rozwoju.
Wreszcie, jeśli celem jest trwałość, należy przechowywać dane w woluminie, a nie przez zatwierdzanie kontenerów:
docker run -v mysql-data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql
Wolumin pozwala na odtworzenie kontenera, uaktualnienie do nowszej wersji mysql po wydaniu łatek (np. poprawek bezpieczeństwa) bez utraty danych.
Aby wykonać kopię zapasową woluminu, zostanie on wyeksportowany do tgz:
docker run --rm -v mysql-data:/source busybox tar -cC /source . >backup.tgz
Aby przywrócić wolumin, tworzymy go z tgz:
docker run --rm -i -v mysql-data:/target busybox tar -xC /target <backup.tgz
