Kan två Compose-projekt dela en databaskontainer på ett säkert sätt?

Ja, när databasen har ett stabilt externt nätverk, separata databaser och användare, tydligt ägarskap över livscykeln samt säkerhetskopior som är oberoende av båda appprojekten.

Beslutet är viktigt när två självvärdbaserade appar bör återanvända en PostgreSQL- eller MariaDB-container för att spara minne. De två konkurrerande tillstånden är en delad tjänst med klientisolering samt kopplade uppgraderingar, autentiseringsuppgifter, omstarter och resurskonkurrens. Börja med en sparad konfiguration och data som kan kastas, observera en gren i taget och avbryt om testet ökar risken för dataförlust, behörighetsproblem eller otillgänglighet.

Definiera villkoren bakom beslutet om en delad databastjänst mellan Compose-projekt

Dokumentera miljön innan du ändrar något: programvaru- och firmwareversioner, enhetsidentiteter, monterings- eller nätverkssökväg, ledigt utrymme, behörigheter och det observerbara symtomet. Baslinjen måste innehålla tillräckligt med detaljer för att återskapa situationen där två självvärdbaserade appar bör återanvända en PostgreSQL- eller MariaDB-container för att spara minne.

Den första kandidaten är en delad tjänst med klientisolering. Den andra är kopplade uppgraderingar, autentiseringsuppgifter, omstarter och resurskonkurrens. De aktuella externa Compose-nätverken definierar mekanismen eller kommandogränsen som används i testet; de ersätter inte observationer från just denna hemmaserver.

Skriv ned godkännandevillkoret och stoppvillkoret innan du kör särskiljningstestet. Ett godkänt resultat måste ändra de evidens som förutsägs av en gren samtidigt som orelaterade tjänster förblir oförändrade; ett misslyckat resultat måste återställa systemet till det sparade tillståndet i stället för att utlösa en kedja av spekulativa korrigeringar.

Testa påståendet utan att sänka det ursprungliga kravet

Använd detta särskiljningstest: anslut varje projekt via ett externt nätverk, skapa användare med minsta nödvändiga behörighet och stoppa och uppdatera sedan den ena appen medan den andra körs. Håll arbetsbelastning, klient, sökväg, filuppsättning och tidsförlopp konstanta så att resultatet kan tillskrivas den ändrade variabeln.

Använd livscykeln för Compose-nätverk för att välja det fält som faktiskt kan skilja grenarna åt och samla sedan in tidsstämpel, avslutningsstatus, feltext, enhets- eller ögonblicksbildsidentitet, svarstid, överförda byte, behörigheter och återställningsstatus. Ett rent kommandoavslut räcker inte när identitet, beständighet eller applikationstillstånd är det som testas.

Upprepa testet en gång efter en omstart, återanslutning, ominmontering eller tom cache när den händelsen ingår i det ursprungliga villkoret. Om den första körningen är destruktiv eller miljön inte kan återställas ska du avbryta och återskapa testet på en kopia som kan kastas.

networks:
  database-net:
    external: true
# Databasens livscykel tillhör ett separat infrastrukturprojekt

Tolka godkända, underkända och avvikande resultat

GODKÄNT: varje app kommer endast åt sitt schema eller sin databas och det går att distribuera om ett projekt utan att återskapa den delade databasen. Dokumentera den exakta versionen, identiteten och arbetsbelastningen som godkändes så att slutsatsen förblir villkorad i stället för att bli ett universellt påstående.

UNDERKÄNT: Compose down tar bort delat tillstånd, en användare kan läsa en annan databas eller migreringar och resursökningar påverkar båda. Ett underkänt resultat bevisar inte automatiskt den motsatta grenen när nätverk, minne, behörigheter eller källans konsistens kan påverka båda; isolera dessa gemensamma beroenden innan du eskalerar.

AVVIKANDE ELLER TVETYDIGT RESULTAT: separera databaserna eller distribuera ett dedikerat Compose-projekt för infrastruktur som äger den delade tjänsten. Bevara loggarna och kör inte kommandon för reparation, rensning, radering, ompartitionering eller rekursiv ägarändring förrän det finns en återställningsbar kopia.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bekräfta beslutet under den ursprungliga arbetsbelastningen

Tillämpa åtgärden som motsvarar den observerade grenen och upprepa sedan det ursprungliga villkoret i stället för en förenklad ersättning. Beslutet gäller endast när varje app endast kommer åt sitt schema eller sin databas och ett projekt kan distribueras om utan att återskapa den delade databasen under två cykler eller den relevanta omstarten, viloläget, störningen eller belastningsövergången.

Använd de dedikerade Docker-nätverken för att kontrollera det närmast beroende arbetsflödet, men behåll den ursprungliga utlösaren oförändrad. Orelaterade datauppsättningar, delningar, containrar, användare och återställningspunkter måste behålla sin tidigare åtkomst och tidsförlopp.

Stoppgränsen är tydlig: om Compose down tar bort delat tillstånd, en användare kan läsa en annan databas eller migreringar och resursökningar påverkar båda ska du återgå till den senast verifierade konfigurationen, behålla evidensen och eskalera till ett djupare plattforms- eller hårdvarutest endast när grenen kan reproduceras.

När målresultatet har uppnåtts ska du jämföra det med omstartspolicyerna för tjänster så att korrigeringen inte flyttar risken till en närliggande tjänst. Ett framgångsrikt måltest med ett nytt fel i säkerhetskopiering, identitet, tidsgräns eller tillgänglighet är fortfarande en misslyckad ändring.

Vanliga frågor

För delade databastjänster mellan Compose-projekt gäller de återstående frågorna vanligtvis om depends_on kan hantera en databas i ett annat projekt, om båda apparna bör dela en databasanvändare och vem som kör säkerhetskopieringar och uppdateringar av databasen. Svaren nedan håller dessa specialfall åtskilda från huvudbeslutet.

Godkännandegränsen ändras inte: varje app kommer endast åt sitt schema eller sin databas och ett projekt kan distribueras om utan att återskapa den delade databasen. Om ett uppföljande villkor ändrar filsystemet, identiteten, nätverkssökvägen eller applikationsversionen ska du upprepa endast det särskiljningstest som påverkas av ändringen.

Sluta bredda experimentet när Compose down tar bort delat tillstånd, en användare kan läsa en annan databas eller migreringar och resursökningar påverkar båda. Då ska du separera databaserna eller distribuera ett dedikerat Compose-projekt för infrastruktur som äger den delade tjänsten; bevara evidensen innan du eskalerar till ägaren av plattformen, lagringen eller hårdvaran.

Kan depends_on hantera en databas i ett annat projekt?

Inte direkt mellan oberoende projektmodeller; använd hälsokontroller och återförsök från applikationen i stället.

Bör båda apparna dela en databasanvändare?

Nej. Använd separata autentiseringsuppgifter och behörigheter enligt principen om minsta privilegium för granskning och begränsning.

Vem kör säkerhetskopieringar och uppdateringar av databasen?

En dedikerad infrastrukturägare eller ett dedikerat infrastrukturprojekt, inte den applikation som råkar starta först.

För delade databastjänster mellan Compose-projekt är det praktiska svaret fortfarande villkorat: varje app kommer endast åt sitt schema eller sin databas och ett projekt kan distribueras om utan att återskapa den delade databasen. När Compose down tar bort delat tillstånd, en användare kan läsa en annan databas eller migreringar och resursökningar påverkar båda ska du separera databaserna eller distribuera ett dedikerat Compose-projekt för infrastruktur som äger den delade tjänsten; en delvis lyckad lösning som inte klarar den ursprungliga arbetsbelastningen är inte kompatibilitet.