Hoe gaan mensen om met permanente opslag voor uw Docker-containers?
Ik gebruik momenteel deze aanpak: bouw de afbeelding, b.v. voor PostgreSQL, en start vervolgens de container met
docker run --volumes-from c0dbc34fd631 -d app_name/postgres
IMHO, dat heeft het nadeel, dat ik nooit (per ongeluk) container “c0dbc34fd631” mag verwijderen.
Een ander idee zou zijn om hostvolumes “-v” in de container te mounten, maar de useridin de container komt niet noodzakelijk overeen met de useridvan de host, en dan kunnen de rechten in de war raken.
Opmerking: in plaats van --volumes-from 'cryptic_id'kunt u ook --volumes-from my-data-containergebruiken waar my-data-containeris een naam die u hebt toegewezen aan een container met alleen gegevens, bijv docker run --name my-data-container ...(zie het geaccepteerde antwoord)
Antwoord 1, autoriteit 100%
Docker 1.9.0 en hoger
Gebruik volume-API
docker volume create --name hello
docker run -d -v hello:/container/path/for/volume container_image my_command
Dit betekent dat het containerpatroon met alleen gegevens moet worden opgegeven ten gunste van de nieuwe volumes.
In feite is de volume-API alleen een betere manier om te bereiken wat het datacontainerpatroon was.
Als u een container maakt met een -v volume_name:/container/fs/pathzal Docker automatisch een benoemd volume voor u maken dat:
- Wees vermeld via het
docker volume ls - Identificeer je via de
docker volume inspect volume_name - Geback-upt als een normale map
- Geback-upt zoals voorheen via een
--volumes-fromverbinding
De nieuwe volume-API voegt een handig commando toe waarmee je bungelende volumes kunt identificeren:
docker volume ls -f dangling=true
En verwijder het dan via zijn naam:
docker volume rm <volume name>
Zoals @mpugach onderstreept in de reacties, kun je alle bungelende volumes kwijt met een mooie oneliner:
docker volume rm $(docker volume ls -f dangling=true -q)
# Or using 1.13.x
docker volume prune
Docker 1.8.x en lager
De aanpak die het beste lijkt te werken voor productie, is het gebruik van een data-only container.
De container met alleen gegevens wordt uitgevoerd op een barebones-image en doet eigenlijk niets anders dan een gegevensvolume blootleggen.
Vervolgens kunt u elke andere container uitvoeren om toegang te krijgen tot de datacontainervolumes:
docker run --volumes-from data-container some-other-container command-to-execute
- Hierkun je een goede afbeelding van hoe de verschillende containers te rangschikken.
- Hieris er een goed inzicht in hoe volumes werken.
In dit blogberichter is een goede beschrijving van de zogenaamde container als volumepatroondie het belangrijkste punt verduidelijkt van het hebben van data-only containers.
Docker-documentatie heeft nu de DEFINITIEVE beschrijving van de container als volume/spatroon.
Hier volgt de back-up-/herstelprocedure voor Docker 1.8.x en lager.
BACK-UP:
sudo docker run --rm --volumes-from DATA -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data
- –rm: verwijder de container wanneer deze wordt afgesloten
- –volumes-from DATA: voeg toe aan de volumes die worden gedeeld door de DATA-container
- -v $(pwd):/backup: bind mount de huidige map in de container; om het tar-bestand te schrijven naar
- busybox: een kleine, eenvoudigere afbeelding – goed voor snel onderhoud
- tar cvf /backup/backup.tar /data: maakt een ongecomprimeerd tar-bestand van alle bestanden in de /data-directory
HERSTEL:
# Create a new data container
$ sudo docker run -v /data -name DATA2 busybox true
# untar the backup files into the new container᾿s data volume
$ sudo docker run --rm --volumes-from DATA2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
data/
data/sven.txt
# Compare to the original container
$ sudo docker run --rm --volumes-from DATA -v `pwd`:/backup busybox ls /data
sven.txt
Hier is een mooi artikel van de uitstekende Brian Goffuitleggen waarom het goed is om dezelfde afbeelding te gebruiken voor een container en een datacontainer.
Antwoord 2, autoriteit 8%
In Docker release v1.0kan het koppelen van een bestand of directory op de hostcomputer worden gedaan met het gegeven commando:
$ docker run -v /host:/container ...
Het bovenstaande volume kan worden gebruikt als permanente opslag op de host waarop Docker draait.
Antwoord 3, autoriteit 4%
Vanaf Docker Compose 1.6 is er nu verbeterde ondersteuning voor datavolumes in Docker Compose. Het volgende samengestelde bestand maakt een gegevensafbeelding die blijft bestaan tussen het opnieuw opstarten (of zelfs verwijderen) van bovenliggende containers:
Hier is de blogaankondiging: Compose 1.6: Nieuw Compose-bestand voor het definiëren van netwerken en volumes
Hier is een voorbeeld van een opstelbestand:
version: "2"
services:
db:
restart: on-failure:10
image: postgres:9.4
volumes:
- "db-data:/var/lib/postgresql/data"
web:
restart: on-failure:10
build: .
command: gunicorn mypythonapp.wsgi:application -b :8000 --reload
volumes:
- .:/code
ports:
- "8000:8000"
links:
- db
volumes:
db-data:
Voor zover ik kan begrijpen: hierdoor wordt een gegevensvolumecontainer (db_data) gemaakt die blijft bestaan tussen het opnieuw opstarten.
Als je: docker volume lsuitvoert, zou je je volume moeten zien verschijnen:
local mypthonapp_db-data
...
Je kunt wat meer details krijgen over het datavolume:
docker volume inspect mypthonapp_db-data
[
{
"Name": "mypthonapp_db-data",
"Driver": "local",
"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/mypthonapp_db-data/_data"
}
]
Enkele testen:
# Start the containers
docker-compose up -d
# .. input some data into the database
docker-compose run --rm web python manage.py migrate
docker-compose run --rm web python manage.py createsuperuser
...
# Stop and remove the containers:
docker-compose stop
docker-compose rm -f
# Start it back up again
docker-compose up -d
# Verify the data is still there
...
(it is)
# Stop and remove with the -v (volumes) tag:
docker-compose stop
docker=compose rm -f -v
# Up again ..
docker-compose up -d
# Check the data is still there:
...
(it is).
Opmerkingen:
-
Je kunt ook verschillende stuurprogramma’s specificeren in het
volumes-blok. U kunt bijvoorbeeld het Flocker-stuurprogramma voor db_data specificeren:volumes: db-data: driver: flocker - Naarmate ze de integratie tussen Docker Swarm en Docker Compose verbeteren (en mogelijk beginnen Flocker te integreren in het Docker-ecosysteem (ik hoorde een gerucht dat Docker Flocker heeft gekocht), denk ik dat deze aanpak steeds krachtiger moet worden.
>
Disclaimer:deze aanpak is veelbelovend en ik gebruik hem met succes in een ontwikkelomgeving. Ik zou huiverig zijn om dit nu al in productie te gebruiken!
Antwoord 4, autoriteit 2%
In het geval dat niet duidelijk wordt uit update 5 van het geselecteerde antwoord, kunt u vanaf Docker 1.9 volumes maken die kunnen bestaan zonder te zijn gekoppeld aan een specifieke container, waardoor het patroon “alleen-gegevenscontainer” overbodig wordt.
Zie Data-only containers verouderd met docker 1.9.0? #17798.
Ik denk dat de Docker-beheerders zich realiseerden dat het containerpatroon met alleen data een beetje een ontwerpgeur was en besloten om van volumes een aparte entiteit te maken die kan bestaan zonder een bijbehorende container.
Antwoord 5
Hoewel dit nog steeds een onderdeel is van Docker die wat werk, moet u het volume in het Docker-bestand plaatsen met de VOLUME-instructiezodat u de volumes niet uit een andere container hoeft te kopiëren.
Dat maakt uw containers minder onderling afhankelijk en u hoeft zich geen zorgen te maken dat het verwijderen van de ene container gevolgen heeft voor de andere.
Antwoord 6
Als u Docker Composegebruikt, voegt u gewoon een benoemd volume toe, bijvoorbeeld:
version: '2'
services:
db:
image: mysql:5.6
volumes:
- db_data:/var/lib/mysql:rw
environment:
MYSQL_ROOT_PASSWORD: root
volumes:
db_data:
Antwoord 7
Het antwoord van @tommasop is goed, en verklaart enkele van de mechanismen van het gebruik van data-only containers. Maar als iemand die aanvankelijk dacht dat datacontainers dwaas waren als je gewoon een volume aan de host kon binden (zoals gesuggereerd door verschillende andere antwoorden), maar nu beseft dat in feite alleen-datacontainers behoorlijk netjes zijn, kan ik mijn eigen voorstellen blogbericht over dit onderwerp: Waarom Docker Data Containers (Volumes!) zijn goed
Zie ook: mijn antwoordop de vraag “Wat is de (beste) manier om machtigingen voor gedeelde Docker-volumes te beheren?” voor een voorbeeld van hoe gegevenscontainers te gebruiken om problemen zoals machtigingen en uid/gid-toewijzing met de host te voorkomen.
Om een van de oorspronkelijke zorgen van het OP aan te pakken: dat de gegevenscontainer niet mag worden verwijderd. Zelfs als de gegevenscontainer wordt verwijderd, gaan de gegevens zelf niet verloren zolang een container een verwijzing naar dat volume heeft, d.w.z. elke container die het volume via --volumes-fromheeft aangekoppeld. Dus tenzij alle gerelateerde containers worden gestopt en verwijderd (men zou dit kunnen beschouwen als het equivalent van een onbedoelde rm -fr /), zijn de gegevens veilig. U kunt de gegevenscontainer altijd opnieuw maken door --volumes-fromelke container te doen die een verwijzing naar dat volume heeft.
Maak echter zoals altijd back-ups!
UPDATE: Docker heeft nu volumes die onafhankelijk van containers kunnen worden beheerd, waardoor dit nog eenvoudiger te beheren is.
8
Het hangt af van uw scenario (dit is niet echt geschikt voor een productieomgeving), maar hier is een manier:
Een MySQL Docker container maken
Deze gist ervan is om een map op uw host te gebruiken voor data-persistentie.
9
Ik gebruik gewoon een vooraf gedefinieerde map op de host om gegevens voor PostgreSQL te blijven bestaan. Op deze manier is het mogelijk om de bestaande postgresql-installaties eenvoudig te migreren naar Docker Containers: HTTPS: // Crondev.com/persistent-postgresql-inside-docker/