Waarom koppelt een Compose-stack na herimplementatie een nieuw leeg benoemd volume?
Een Compose-stack kan een nieuw leeg benoemd volume koppelen wanneer bij een nieuwe implementatie de projectgebonden volumenaam verandert of het oorspronkelijke volume niet kan worden gevonden.
De oude gegevens kunnen nog in een ander Docker-volume staan, terwijl de opnieuw aangemaakte service een nieuw gegenereerd volume op hetzelfde containerpad koppelt. Veelvoorkomende oorzaken zijn een gewijzigde stack- of projectnaam, een hernoemde volumesleutel, verwijdering met een opdracht die volumes verwijdert, het wegvallen van een externe declaratie, implementatie via een andere beheerder of een expliciete volumenaam die nu anders wordt opgelost. Inventariseer zowel het gekoppelde volume als verweesde kandidaten voordat je gegevens terugzet of de app initialiseert.
Identificeer het exacte volume dat door de nieuwe container is gekoppeld
Inspecteer de koppelingen van de actieve container en noteer de volumenaam, driver, koppelpunt, labels, aanmaaktijd, bestemmingspad in de container en lees-schrijfmodus. Vergelijk deze gegevens met registraties van vóór de nieuwe implementatie.
De Ubuntu-opdracht docker volume inspect toont de volume-identiteit, zodat het nieuwe lege volume kan worden onderscheiden van een ouder, niet-gekoppeld volume met een vergelijkbare naam.
Kopieer geen gegevens naar het nieuwe volume voordat het oorspronkelijke volume is gevonden. Als je de app start, kan deze een nieuwe database aanmaken, waardoor de bestemming eruitziet alsof die bewust is geïnitialiseerd.
Controleer of de naam van het Compose-project is gewijzigd
Vergelijk de oude en nieuwe projectnaam, stacknaam, Compose-map, de optie -p, COMPOSE_PROJECT_NAME, de bovenliggende name: en de implementatiebeheerder.
Docker legt uit dat Compose een volume normaal gesproken benoemt als projectnaam plus volumesleutel, tenzij een expliciete naam of een zoekopdracht naar een extern volume is geconfigureerd.
Als je hetzelfde Compose-bestand naar een andere map verplaatst, kan daardoor een tweede project en een tweede volume ontstaan, zelfs wanneer de service- en volumesleutels ongewijzigd zijn.
Controleer stabiele naam- en externe-instellingen voor volumes
Vergelijk de bovenliggende volumedefinitie vóór en na de nieuwe implementatie. Controleer name:, external:, driveropties, interpolatievariabelen en of het verwachte volume bestaat.
De Docker Compose-tutorial van Microsoft vermeldt dat benoemde volumes onafhankelijk van containervervanging blijven bestaan. Een nieuwe lege toestand betekent daarom meestal dat een ander volume is gekoppeld of dat het oude volume is verwijderd.
Markeer een volume alleen als extern wanneer de levenscyclus ervan bewust buiten de stack wordt beheerd. Compose moet duidelijk falen wanneer een extern volume ontbreekt, in plaats van stilzwijgend een vervanging aan te maken.
Controleer of een opruimactie het oorspronkelijke volume heeft verwijderd
Bekijk implementatielogboeken, scripts, acties in de gebruikersinterface, opruimtaken en opdrachten voor volumeverwijdering. Vergelijk de aanmaaktijd van het volume met het moment van de nieuwe implementatie.
Red Hat documenteert dat door containers beheerde benoemde volumes afzonderlijke opslaglocaties hebben ten opzichte van beschrijfbare containerlagen. Daarom zijn het verwijderen van een container en het verwijderen van het bijbehorende benoemde volume twee verschillende levenscyclusgebeurtenissen.
Als het oorspronkelijke volume ontbreekt, stop dan automatische starts en herstel alleen vanuit een gecontroleerde back-up. Ga er niet van uit dat een leeg vervangend volume een herstelbare verwijderde laag bevat.
Vergelijk de identiteit van de stackbeheerder en de implementatiemethode
Leg vast of de stack is gestart via de CLI, Portainer, een NAS-appwinkel, een Git-implementatie of een andere automatiseringstool. Vergelijk de stacknaam en omgevingswaarden die door die beheerder zijn opgeslagen.
Portainer vereist bij de implementatie een beschrijvende stacknaam. De identiteit die door deze beheerder wordt gebruikt, kan verschillen van de mapgebaseerde projectnaam die een handmatige Compose-opdracht gebruikt.
Een handmatige noodstart kan daardoor resources met een ander projectvoorvoegsel aanmaken. Kies één eigenaar voor de implementatie en documenteer de opgeloste volumenamen die deze aanmaakt.
Sluit gegevens uit die onder de nieuwe volumekoppeling verborgen zijn
Stop de container en inspecteer de image of het bindpad zonder het benoemde volume eraan gekoppeld, in een wegwerptest. Bepaal of het opstartproces gegevens naar de containerlaag heeft geschreven voordat het volume werd gekoppeld.
De Linux-handleiding voor koppelen legt uit dat een koppeling bestaande inhoud in mappen verbergt. Daardoor kunnen gegevens ontbreken wanneer een nieuw leeg volume bestanden uit de image- of beschrijfbare laag afschermt.
Voeg de verborgen laag en het oude persistente volume niet zomaar samen. Bepaal welke toestand leidend is en gebruik de door de toepassing ondersteunde herstelmethode.
Koppel het oorspronkelijke volume opnieuw voor een gecontroleerde test
Stop de stack, maak een back-up van beide kandidaatvolumes, koppel het oorspronkelijke volume aan een wegwerpcontainer of tijdelijke servicepad en controleer toepassingsbestanden, database-identiteit, eigenaarschap en tijdstempels.
De ZimaSpace-handleiding voor het verplaatsen van containergegevens zonder koppelingen te verbreken beschrijft de aangrenzende workflow voor padtoewijzing; dit artikel richt zich op de identiteit van projectgebonden benoemde volumes.
Het probleem is opgelost wanneer het bedoelde oude volume onder een stabiele expliciete of externe naam is gekoppeld en herhaalde nieuwe implementaties het opnieuw gebruiken zonder nog een lege kandidaat aan te maken.
Veelgestelde vragen
Betekent een leeg benoemd volume dat de oude gegevens zijn verwijderd?
Niet noodzakelijk. Het oude volume kan nog bestaan onder een ander projectvoorvoegsel of een andere expliciete naam, terwijl de nieuwe container een ander leeg volume gebruikt.
Kan het wijzigen van de naam van de Compose-map een nieuw volume creëren?
Ja. Wanneer geen projectnaam is vastgelegd, kan Compose deze afleiden uit de projectmap en resources met andere voorvoegsels aanmaken.
Moeten belangrijke volumes als extern worden gemarkeerd?
Externe volumes kunnen voorkomen dat het verwijderen van een stack hun levenscyclus beheert, maar vereisen wel bewuste aanmaak, naamgeving, back-ups en controles bij de implementatie.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
