Mönster för externt konfigurationslager

Flytta konfigurationsinformation utanför programpaketet för distribution till en central plats. Det kan göra hanteringen enklare och förbättra kontrollen av konfigurationsdata, och också ge möjlighet att dela konfigurationsdata över olika program och programinstanser.

Kontext och problem

De flesta programköringsmiljöer innehåller konfigurationsinformation som lagras i filer som distribueras med programmet. I vissa fall går det att redigera filerna om du vill ändra programmets beteende efter att det har distribuerats. Men om konfigurationen ändras måste programmet distribueras på nytt, vilket ofta ger oacceptabla driftstopp och andra administrativa kostnader.

Lokala konfigurationsfiler begränsar också konfigurationen till ett enda program, men ibland kan det vara praktiskt att dela konfigurationsinställningar över flera program. Exempel på det kan vara databasanslutningssträngar, UI-temainformation eller webbadresser för köer och lagring som används av en relaterad uppsättning program.

Det är svårt att hantera ändringar i lokala konfigurationer över flera programinstanser som är igång, särskilt i ett scenario med en värd i molnet. Det kan göra att olika instanser använder olika konfigurationsinställningar medan uppdateringen distribueras.

Dessutom kan konfigurationsscheman behöva ändras om program och komponenter uppdateras. Många konfigurationssystem kan inte användas med olika versioner av konfigurationsinformationen.

Lösning

Lagra konfigurationsinformationen i extern lagring och tillhandahåll ett gränssnitt som kan användas för att snabbt och effektivt läsa och uppdatera konfigurationsinställningar. Vilken typ av extern lagring som ska användas beror på programmets körningsmiljö. I ett molnbaserat scenario är det vanligtvis en molnbaserad lagringstjänst eller dedikerad konfigurationstjänst, men det kan vara en värdbaserad databas eller ett annat anpassat system.

Den lagringsenhet du väljer för konfigurationsinformationen bör ha ett gränssnitt som ger enhetlig och enkel åtkomst. Informationen bör visas i ett korrekt skrivet och strukturerat format. Implementeringen kan också behöva auktorisera användarnas åtkomst för att skydda konfigurationsdata och vara tillräckligt flexibel för att tillåta lagring av flera versioner av konfigurationen (till exempel utveckling, mellanlagring eller produktion, inklusive flera versioner av var och en).

Många inbyggda konfigurationssystem läser informationen när programmet startas och cachelagrar informationen i minnet för att ge snabb åtkomst minimera påverkan på programmets prestanda. Beroende på vilken typ av lagringsenhet som används och lagringsenhetens latens kan det vara bra att implementera en cachelagringsmekanism i den externa konfigurationslagringen. Mer information finns i Vägledning om cachelagring. Figuren visar en översikt över mönstret för externt konfigurationslager med valfritt lokalt cacheminne.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera mönstret:

Välj en lagringsenhet som ger acceptabel prestanda, hög tillgänglighet och stabilitet, och som kan säkerhetskopieras som en del av programmets underhåll och administration. I ett molnprogram är användning av en molnlagringsmekanism eller dedikerad konfigurationsplattformstjänst vanligtvis ett bra val för att uppfylla dessa krav.

Utforma schemat för lagringsenheten så att den kan innehålla olika typer av information. Se till att den uppfyller alla konfigurationskrav som skrivna data, inställningssamlingar, flera versioner av inställningar samt andra funktioner som krävs av de program som använder enheten. Schemat bör kunna utökas på ett enkelt sätt som stöd för ytterligare inställningar allt eftersom behoven förändras.

Överväg lagringsenhetens fysiska kapacitet, hur den relaterar till hur konfigurationsinformationen lagras och vilken inverkan detta har på prestanda. Exempel: När du lagrar ett XML-dokument som innehåller konfigurationsinformation måste antingen konfigurationsgränssnittet eller programmet parsa dokumentet för att kunna läsa individuella inställningar. Detta gör det mer komplicerat att uppdatera en inställning, även om cachelagringsinställningarna kan bidra till att förskjuta den långsammare läsprestandan.

Överväg hur konfigurationsgränssnittet ska bevilja styrning av omfång och arv av konfigurationsinställningar. Det kanske till exempel är ett krav att ha konfigurationsinställningar för omfång på organisations-, program- och datornivå. Gränssnittet an behöva ha stöd för styrningsdelegering över åtkomst till olika omfång och stöd för att förhindra och tillåta enskilda program att åsidosätta inställningarna.

Se till att konfigurationsgränssnittet kan exponera konfigurationsdata i de format som krävs, till exempel skrivna värden, samlingar, nyckel/värde-par och egenskapsuppsättningar.

Överväg hur konfigurationslagringsgränssnittet ska fungera om inställningarna innehåller fel eller inte finns på lagringsenheten. Det kan vara lämpligt att returnera standardinställningar och logga fel. Överväg också aspekter som skiftlägeskänslighet i konfigurationsinställningsnycklar och -namn, lagring och hantering av binära data och hur nullvärden eller tomma värden ska hanteras.

Överväg hur du ska skydda konfigurationsinformationen så att enbart behöriga användare och program får tillgång till den. Detta är troligen en funktion i konfigurationslagringsgränssnittet, men det behövs också för att säkerställa att data på lagringsenheten inte kan nås direkt utan rätt behörighet. Se till att det är en strikt åtskillnad mellan de behörigheter som krävs för att läsa och för att skriva konfigurationsdata. Fundera också på om du ska kryptera en del eller alla konfigurationsinställningar och hur detta ska implementeras i konfigurationslagringsgränssnittet.

Centralt lagrade konfigurationer som ändra programmets beteende under körning är ytterst viktiga och bör distribueras, uppdateras och hanteras med samma metoder som distribuerar programkoden. Ändringar som kan påverka mer än ett program måste genomföras med en fullständig testning och en mellanlagrad distributionsmetod för att säkerställa att ändringen är lämplig för alla program som använder den här konfigurationen. Om en administratör redigerar en inställning för att uppdatera ett program, kan detta få negativ påverkan andra program som använder samma inställning.

Om ett program cachelagrar konfigurationsinformation måste programmet få en avisering om konfigurationen ändras. Det kan vara möjligt att implementera en förfalloprincip över cachelagrade konfigurationsdata så att den här informationen uppdateras automatiskt med jämna mellanrum och eventuella ändringar identifieras (och åtgärdas).

Cachelagring av konfigurationsdata kan hjälpa till att åtgärda tillfälliga anslutningsproblem med det externa konfigurationsarkivet vid programkörning, men detta löser vanligtvis inte problemet om det externa arkivet ligger nere när programmet startas första gången. Se till att din programdistributionspipeline kan tillhandahålla den senaste kända uppsättningen konfigurationsvärden i en konfigurationsfil som reserv om programmet inte kan hämta livevärden när det startar.

När du ska använda det här mönstret

Det här mönstret är användbart för:

• Konfigurationsinställningar som delas mellan flera program och programinstanser, eller där en standardkonfiguration måste tillämpas i flera program och programinstanser.

• Ett standardkonfigurationssystem som inte har stöd för alla nödvändiga konfigurationsinställningar, till exempel lagring av bilder och komplexa datatyper.

• Som en kompletterande lagring för vissa inställningar för program, kanske för att tillåta program att åsidosätta en del av eller alla centralt lagrade inställningar.

• Som ett sätt att förenkla administrationen av flera program och eventuellt för övervakning av användningen av konfigurationsinställningarna genom loggning av en del eller alla typer av åtkomst till konfigurationslagringen.

Exempel på anpassad lagringsbacking

I ett Microsoft Azure värdprogram är ett möjligt alternativ för att lagra konfigurationsinformation externt att använda Azure Storage. Det är flexibelt med hög prestanda, och det replikeras tre gånger med automatisk redundans som ger hög tillgänglighet. Azure Table-lagring ger ett nyckel/värde-arkiv med möjlighet att använda ett flexibelt schema för värdena. Azure Blob-lagring tillhandahåller hierarkisk, containerbaserad lagring som kan innehålla alla typer av data i individuellt namngivna blobbar.

När du implementerar det här mönstret ansvarar du för att abstrahera bort Azure Blob Storage och exponera dina inställningar i dina program, inklusive att söka efter uppdateringar vid körning och hantera hur du svarar på dem.

I följande exempel visas hur ett förenklat konfigurationsarkiv kan visualiseras över Blob Storage för att lagra och exponera konfigurationsinformation. En BlobSettingsStore klass kan abstrahera Blob Storage för att lagra konfigurationsinformation och implementera ett enkelt ISettingsStore gränssnitt.

public interface ISettingsStore
{
    Task<ETag> GetVersionAsync();
    Task<Dictionary<string, string>> FindAllAsync();
}

Det här gränssnittet definierar metoder för att hämta konfigurationsinställningar som lagras i konfigurationsarkivet och innehåller ett versionsnummer som kan användas för att identifiera om några konfigurationsinställningar har ändrats nyligen. En BlobSettingsStore klass kan använda ETag blobens egenskap för att implementera versionshantering. Egenskapen ETag uppdateras automatiskt varje gång en blob skrivs.

Den här enkla bilden visar alla konfigurationsinställningar som strängvärden i stället för att ange värden.

En ExternalConfigurationManager klass kan sedan tillhandahålla en omser runt en BlobSettingsStore instans. Ett program kan använda den här klassen för att hämta konfigurationsinformation. Den här klassen kan använda något i stil med Microsoft Reactive Extensions för att publicera ändringar som görs i konfigurationen medan systemet körs. Det skulle också ansvara för att implementera Cache-Aside-mönstret för inställningar för att ge ökad återhämtning och prestanda.

Användningen kan se ut ungefär så här.

static void Main(string[] args)
{
    // Start monitoring configuration changes.
    ExternalConfiguration.Instance.StartMonitor();

    // Get a setting.
    var setting = ExternalConfiguration.Instance.GetAppSetting("someSettingKey");
    …
}

Använda Azure App Configuration

Det kan vara nödvändigt att skapa ett anpassat konfigurationsarkiv i vissa situationer, men många program kan i stället använda Azure App Configuration. Azure App Configuration har stöd för nyckel/värde-par som kan vara namnrymder. Nycklarna har skrivits och är individuellt versionerade. Azure App Configuration har även stöd för ögonblicksbilder av konfigurationen vid tidpunkt så att du enkelt kan inspektera eller återställa tidigare konfigurationsvärden. Konfigurationsvärden kan exporteras så att en kopia av konfigurationen kan levereras med ditt program om tjänsten inte kan nås när programmet startas.

Klientbibliotek

Många av dessa funktioner exponeras via klientbibliotek som integreras med programkörningen för att underlätta hämtning och cachelagring av värden, uppdatera värden vid ändringar och även hantera tillfälliga avbrott i App Configuration Service.

Förutom klientbibliotek finns det även en Azure App Configuration Sync GitHub Action och Azure App Configuration PullAzure App Configuration Push Azure DevOps-uppgifter för att integrera konfigurationssteg i byggprocessen.

Nästa steg

• Se ytterligare App Configuration exempel
• Lär dig hur du integrerar Azure App Configuration med Kubernetes-distributioner
• Lär dig Azure App Configuration också kan hjälpa dig att hantera funktionsflaggor