Flera saker händer här:
Först, docker commit är en kodlukt. Det tenderar att användas av dem som skapar bilder med en manuell process, snarare än att automatisera sina byggen med en Dockerfile som skulle möjliggöra enkel rekreation. Om det är möjligt rekommenderar jag att du byter till en Dockerfile för att skapa bilder.
Därefter en docker commit kommer inte att fånga ändringar som gjorts i en volym. Och samma problem uppstår om du försöker uppdatera en volym med en RUN steg i en Dockerfile. Båda dessa fångar in ändringar i containerfilsystemet och lagrar dessa ändringar som ett lager i docker-bilden, och volymerna är inte en del av containerfilsystemet. Detta är också synligt om du kör docker diff mot en container. I det här fallet har uppströmsbilden definierat volymen i sin Dockerfile:
VOLUME /var/lib/mysql
Och docker har inte ett kommando för att ångra en skapad volym från Dockerfilen. Du måste antingen ändra bilddefinitionen direkt utanför docker (rekommenderas inte) eller bygga din egen uppströmsbild med det steget borttaget (rekommenderas).
Vad mysql-bilden ger är möjligheten att injicera dina egna skript för att skapa databaser i /docker-entrypoint-initdb.d , som du kan lägga till med din egen bild som utökar mysql, eller montera som en volym. Det är här du skulle injicera ditt schema, eller initialisera från en känd säkerhetskopia för utveckling.
Slutligen, om målet är att ha uthållighet, bör du lagra dina data i en volym, inte genom att commitera behållare:
docker run -v mysql-data:/var/lib/mysql \
-e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql
Volymen låter dig återskapa behållaren, uppgradera till en nyare version av mysql när patchar släpps (t.ex. säkerhetskorrigeringar) utan att förlora din data.
För att säkerhetskopiera volymen kommer detta att exporteras till en tgz:
docker run --rm -v mysql-data:/source busybox tar -cC /source . >backup.tgz
Och för att återställa en volym skapas en från en tgz:
docker run --rm -i -v mysql-data:/target busybox tar -xC /target <backup.tgz