Komplettera Azure Owner-taggar på äldre resursgrupper

Taggning börjar ofta som ett styrningskrav och blir snabbt en operativ nödvändighet. I Azure är en av de viktigaste taggarna ofta Owner, eftersom den svarar på en grundläggande men kritisk fråga: vem ansvarar för den här resursen?

I en mogen miljö bör svaret vara lätt att hitta. I verkligheten innehåller många Azure-miljöer en blandning av gamla och nya distributioner. Nyare resurser kan följa en taggningsstandard som upprätthålls av policy, medan äldre resursgrupper och resurser skapades innan den standarden fanns. Resultatet är ett vanligt styrningsgap: standarden finns idag, men delar av den befintliga miljön saknar fortfarande taggar.

Ett praktiskt sätt att lösa detta är att börja på resursgruppsnivå.

Problemet med äldre taggar

Föreställ dig ett företag med flera domäner, som integration, analys, ERP, kundplattformar och interna verktyg. Över tid har varje domän byggt upp sina egna Azure-resursgrupper och resurser. Senare inför organisationen en styrningsstandard som kräver att varje resurs har en Owner-tagg.

Azure Policy är väl lämpad för att upprätthålla den standarden framåt. Men äldre resursgrupper kanske aldrig fick en Owner-tagg från början. Om den överordnade resursgruppen saknar Owner-tagg finns det inget för underliggande resurser att ärva.

Det skapar ett gap:

• Styrningsmodellen är definierad
• Policyn är redo
• Men äldre resursgrupper saknar fortfarande den överordnade taggen som behövs för arv

Det är här ett litet PowerShell-skript blir användbart.

Varför ett skript fortfarande är relevant när Azure Policy finns

Azure Policy är rätt långsiktig kontroll. Det ger centraliserad upprätthållning, efterlevnadsvisibilitet och åtgärdsstöd över prenumerationer och hanteringsgrupper.

Men ett skript kan fortfarande vara rätt kortsiktigt verktyg.

Ett manuellt skript är användbart när du behöver komplettera en saknad tagg på en känd uppsättning äldre resursgrupper, särskilt när dessa grupper tillhör en specifik domän och kan identifieras med en namnkonvention. I det fallet ersätter inte skriptet policyn. Det förbereder miljön så att policyn kan fungera som avsett.

Det är den viktiga distinktionen:

• Ett skript hanterar engångsrensning av historiska luckor
• En policy hanterar löpande upprätthållning och åtgärdande

Det rekommenderade mönstret

Ett praktiskt styrningsmönster för detta scenario ser ut så här:

1. Identifiera de äldre resursgrupperna som tillhör en domän och bör dela samma ägarvärde
2. Stämpla Owner-taggen på dessa resursgrupper
3. Tilldela en Azure Policy som låter underliggande resurser ärva Owner-taggen från resursgruppen när den saknas

Detta tillvägagångssätt fungerar särskilt väl när resursgruppen representerar en tydlig ägarskapsgräns inom företaget. Det kan vara en affärsdomän, en applikationsdomän, ett plattformsteam eller ett produktområde.

Exempelscenario

Antag att ett företag har flera domäner, och en av dem är finansdomänen. Den domänen innehåller resursgrupper som:

• finance-dev-we
• finance-test-we
• finance-prod-we

Dessa resursgrupper skapades innan Owner-taggstandarden infördes. Företaget vill nu att alla resurser i den domänen ska kopplas till samma ägare, till exempel finance-platform@contoso.com.

Istället för att öppna varje resursgrupp manuellt i Azure-portalen kan ett skript lägga till Owner-taggen på alla matchande resursgrupper i den domänen. Därefter kan Azure Policy sprida samma ägarvärde till underliggande resurser som saknar det.

Den viktiga poängen är att logiken baseras på domänägarskap, inte på en specifik arbetsbelastning som en data lake.

Skriptet

Följande PowerShell-funktion hittar resursgrupper efter namnprefix och stämplar Owner-taggen. Den stöder -WhatIf för säker förhandsgranskning innan ändringar görs och bevarar alla befintliga taggar på resursgrupperna.

Viktiga designbeslut

Prefixbaserad matchning möjliggör gruppering efter domänkonvention istället för att lista individuella resursgrupper. Detta skalar bra när en domän har många resursgrupper över miljöer.

WhatIf-stöd genom SupportsShouldProcess låter dig förhandsgranska exakt vilka resursgrupper som kommer att ändras innan du verkställer. Kör alltid med -WhatIf först.

Bevarande av befintliga taggar är kritiskt. Funktionen kopierar alla befintliga taggar och lägger bara till eller uppdaterar Owner-taggen. Den tar aldrig bort taggar som redan finns.

Valfri överskrivning via -OverwriteExisting-switchen låter dig korrigera ett felaktigt ägarvärde utan att påverka resursgrupper som redan har det korrekta värdet.

Vad som kommer efter skriptet

När resursgrupperna har Owner-taggen är nästa steg att tilldela en Azure Policy med effekten Ärv en tagg från resursgruppen om den saknas. Denna policy kommer automatiskt att sprida Owner-taggen till nya och befintliga underliggande resurser som saknar den.

Kombinationen av ett engångsskript för komplettering och en löpande policy för upprätthållning ger dig en ren och underhållbar styrningsmodell.