Använda Azure Front Door i en lösning med flera klientorganisationer

Azure Front Door är ett modernt nätverk för innehållsleverans i molnet (CDN) som ger snabb och tillförlitlig åtkomst mellan användare och program statiskt och dynamiskt webbinnehåll över hela världen. I den här artikeln beskrivs några av funktionerna i Azure Front Door som är användbara när du arbetar i system med flera klientorganisationer. Den innehåller även länkar till ytterligare vägledning och exempel.

När du använder Azure Front Door som en del av en lösning med flera klientorganisationer måste du fatta vissa beslut baserat på din lösnings design och krav. Du måste tänka på följande faktorer:

• Hur många klienter har du och hur många förväntar du dig att ha i framtiden?
• Delar du programnivån mellan flera klienter, distribuerar många programinstanser med en klientorganisation eller distribuerar separata distributionsstämplar som delas av flera klientorganisationer?
• Vill dina klienter ta med egna domännamn?
• Kommer du att använda jokerteckendomäner?
• Behöver du använda dina egna TLS-certifikat, eller kommer Microsoft att hantera dina TLS-certifikat?
• Har du övervägt de kvoter och gränser som gäller för Azure Front Door? Vet du vilka gränser du kommer att närma dig när du växer? Om du misstänker att du kommer att närma dig dessa gränser bör du överväga att använda flera Azure Front Door-profiler. Eller fundera på om du kan ändra hur du använder Azure Front Door för att undvika gränserna. Observera att Premium SKU har högre gränser än Standard SKU.
• Har du eller dina klienter krav på IP-adressfiltrering, geoblockering eller anpassning av WAF-regler?
• Är alla klientorganisationers programservrar internetuppkopplade?

Funktioner i Azure Front Door som stöder flera klientorganisationer

I det här avsnittet beskrivs flera viktiga funktioner i Azure Front Door som är användbara för lösningar med flera klientorganisationer. Den beskriver hur Azure Front Door kan hjälpa dig att konfigurera anpassade domäner, inklusive information om jokerteckendomäner och TLS-certifikat. Den sammanfattar också hur du kan använda Azure Front Door-routningsfunktioner för att stödja flera klientorganisationer.

Anpassade domäner

Azure Front Door tillhandahåller ett standardvärdnamn för varje slutpunkt som du skapar, till exempel contoso.z01.azurefd.net. För de flesta lösningar associerar du i stället ditt eget domännamn med Azure Front Door-slutpunkten. Med anpassade domännamn kan du använda din egen varumärkesanpassning och konfigurera routning baserat på det värdnamn som anges i en klients begäran.

I en lösning med flera klienter kan du använda klientspecifika domännamn eller underdomäner och konfigurera Azure Front Door för att dirigera klientorganisationens trafik till rätt ursprungsgrupp för klientorganisationens arbetsbelastning. Du kan till exempel konfigurera ett anpassat domännamn som tenant1.app.contoso.com. Med Azure Front Door kan du konfigurera flera anpassade domäner på en enda Azure Front Door-profil.

Mer information finns i Lägga till en anpassad domän i din Front Door.

Jokerteckendomäner

Jokerteckendomäner förenklar konfigurationen av DNS-poster och Azure Front Door-trafikroutningskonfiguration när du använder en delad stamdomän och klientspecifika underdomäner. Anta till exempel att dina klienter har åtkomst till sina program med hjälp av underdomäner som tenant1.app.contoso.com och tenant2.app.contoso.com. Du kan konfigurera en jokerteckendomän i *.app.contoso.comstället för att konfigurera varje klientspecifik domän individuellt.

Azure Front Door har stöd för att skapa anpassade domäner som använder jokertecken. Du kan sedan konfigurera en väg för begäranden som kommer till jokerteckendomänen. När du registrerar en ny klient behöver du inte konfigurera om DINA DNS-servrar, utfärda nya TLS-certifikat eller uppdatera konfigurationen för din Azure Front Door-profil.

Jokerteckendomäner fungerar bra om du skickar all trafik till en enda ursprungsgrupp. Men om du har separata stämplar för din lösning räcker det inte med en jokerteckendomän på en nivå. Du måste antingen använda stamdomäner på flera nivåer eller ange extra konfiguration genom att till exempel åsidosätta de vägar som ska användas för varje klientorganisations underdomän. Mer information finns i Överväganden när du använder domännamn i en lösning för flera klienter.

Azure Front Door utfärdar inte hanterade TLS-certifikat för jokerteckendomäner, så du måste köpa och ange ett eget certifikat.

Mer information finns i Jokerteckendomäner.

Hanterade TLS-certifikat

Att hämta och installera TLS-certifikat kan vara komplext och felbenäget. Och TLS-certifikat upphör att gälla efter en tidsperiod, vanligtvis ett år, och måste återutfärdas och installeras om för att undvika avbrott i programtrafiken. När du använder Azure Front Door-hanterade TLS-certifikat ansvarar Microsoft för att utfärda, installera och förnya certifikat för din anpassade domän.

Ditt ursprungsprogram kan finnas på en annan Azure-tjänst som även tillhandahåller hanterade TLS-certifikat, till exempel Azure App Service. Azure Front Door fungerar transparent med den andra tjänsten för att synkronisera dina TLS-certifikat.

Om du tillåter att dina klienter tillhandahåller sina egna anpassade domäner och du vill att Azure Front Door ska utfärda certifikat för dessa domännamn bör dina klienter inte konfigurera CAA-poster på sina DNS-servrar som kan blockera Azure Front Door från att utfärda certifikat för deras räkning. Mer information finns i TLS/SSL-certifikat.

Mer information om TLS-certifikat finns i TLS från slutpunkt till slutpunkt med Azure Front Door.

Routning

Ett program med flera klienter kan ha en eller flera programstämplar som betjänar klienterna. Stämplar används ofta för att aktivera distributioner i flera regioner och för att stödja skalning av en lösning till ett stort antal klienter.

Azure Front Door har en kraftfull uppsättning routningsfunktioner som kan stödja ett antal arkitekturer med flera klientorganisationer. Du kan använda routning för att distribuera trafik mellan ursprung inom en stämpel eller för att skicka trafik till rätt stämpel för en specifik klientorganisation. Du kan konfigurera routning baserat på enskilda domännamn, jokerteckendomännamn och URL-sökvägar. Och du kan använda regelmotorn för att ytterligare anpassa routningsbeteendet.

Mer information finns i Översikt över routningsarkitektur.

Regelmotor

Du kan använda Azure Front Door-regelmotorn för att anpassa hur Azure Front Door bearbetar begäranden vid nätverksgränsen. Med regelmotorn kan du köra små logikblock i pipelinen för bearbetning av Azure Front Door-begäranden. Du kan använda regelmotorn för en mängd olika uppgifter, inklusive följande:

• Hämta information om HTTP-begäran, inklusive segment av URL:en och sökvägen, och sprid informationen till en annan del av begäran.
• Ändra element i HTTP-begäran innan den skickas till ursprunget.
• Ändra vissa delar av HTTP-svaret innan det returneras till klienten.
• Åsidosätt routningskonfigurationen för en begäran, till exempel genom att ändra den ursprungsgrupp som en begäran ska skickas till.

Här följer några exempel på metoder för att använda Azure Front Door-regelmotorn i en lösning med flera klientorganisationer:

• Anta att du distribuerar en programnivå för flera klienter där du även använder klientspecifika underdomäner för jokertecken enligt beskrivningen i följande exempelscenarier. Du kan använda regelmotorn för att extrahera klientidentifieraren från underdomänen för begäran och lägga till den i ett begärandehuvud. Den här regeln kan hjälpa programnivån att avgöra vilken klientorganisation begäran kom från.
• Anta att du distribuerar en programnivå för flera klienter och använder sökvägsbaserad routning (till exempel https://application.contoso.com/tenant1/welcome https://application.contoso.com/tenant2/welcome för klientorganisationer 1 respektive 2). Du kan använda regelmotorn för att extrahera klientidentifierarsegmentet från url-sökvägssegmentet och skriva om URL:en så att den inkluderar klientidentifieraren i en frågesträngsparameter eller begäranderubrik som programmet ska använda.

Mer information finns i Vad är Azure Front Door-regelmotorn?.

Exempelscenarier

Följande exempelscenarier visar hur du kan konfigurera olika arkitekturer för flera klientorganisationer i Azure Front Door och hur de beslut du fattar kan påverka din DNS- och TLS-konfiguration.

Många lösningar för flera klientorganisationer implementerar mönstret Distributionsstämplar. När du använder den här distributionsmetoden distribuerar du vanligtvis en enda delad Azure Front Door-profil och använder Azure Front Door för att dirigera inkommande trafik till rätt stämpel. Den här distributionsmodellen är den vanligaste och scenarier 1 till 4 i den här artikeln visar hur du kan använda den för att uppfylla en rad olika krav.

I vissa situationer kan du dock distribuera en Azure Front Door-profil i varje stämpel i din lösning. Scenario 5 beskriver den här distributionsmodellen.

Scenario 1: Providerhanterad jokerteckendomän, enkel stämpel

Contoso skapar en liten lösning för flera klientorganisationer. Företaget distribuerar en enda stämpel i en enda region och den stämpeln hanterar alla sina klienter. Alla begäranden dirigeras till samma programserver. Contoso bestämde sig för att använda jokerteckendomäner för alla klienter, som tenant1.contoso.com och tenant2.contoso.com.

Contoso distribuerar Azure Front Door med hjälp av den här konfigurationen:

DNS-konfiguration

Engångskonfiguration: Contoso konfigurerar två DNS-poster:

• En TXT-post med jokertecken för *.contoso.com. Den är inställd på det värde som anges av Azure Front Door under registreringsprocessen för anpassad domän.
• En CNAME-post med jokertecken, *.contoso.com, som är ett alias för Contosos Azure Front Door-slutpunkt: contoso.z01.azurefd.net.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

TLS-konfiguration

Engångskonfiguration: Contoso köper ett TLS-certifikat med jokertecken, lägger till det i ett nyckelvalv och ger Azure Front Door åtkomst till valvet.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

Azure Front Door-konfiguration

Engångskonfiguration: Contoso skapar en Azure Front Door-profil och en enskild slutpunkt. De lägger till en anpassad domän med namnet *.contoso.com och associerar sitt jokerteckens TLS-certifikat med den anpassade domänresursen. De konfigurerar sedan en enda ursprungsgrupp som innehåller ett enda ursprung för deras programserver. Slutligen konfigurerar de en väg för att ansluta den anpassade domänen till ursprungsgruppen.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

Förmåner

• Den här konfigurationen är relativt enkel att konfigurera och ger kunderna contoso-märkta URL:er.
• Metoden stöder ett stort antal klienter.
• När en ny klientorganisation registreras behöver Contoso inte göra ändringar i Azure Front Door-, DNS- eller TLS-certifikat.

Nackdelar

• Den här metoden kan inte enkelt skalas bortom en enda programstämpel eller region.
• Contoso måste köpa ett jokertecken för TLS-certifikat och förnya och installera certifikatet när det upphör att gälla.

Scenario 2: Providerhanterad jokerteckendomän, flera stämplar

Proseware skapar en lösning för flera klientorganisationer över flera stämplar som distribueras till både Australien och Europa. Alla begäranden inom en enda region hanteras av stämpeln i den regionen. Precis som Contoso bestämde sig Proseware för att använda jokerteckendomäner för alla klienter, till exempel tenant1.proseware.com och tenant2.proseware.com.

Proseware distribuerar Azure Front Door med hjälp av den här konfigurationen:

DNS-konfiguration

Engångskonfiguration: Proseware konfigurerar två DNS-poster:

• En TXT-post med jokertecken för *.proseware.com. Den är inställd på det värde som anges av Azure Front Door under registreringsprocessen för anpassad domän.
• En CNAME-post med jokertecken, *.proseware.com, som är ett alias för Prosewares Azure Front Door-slutpunkt: proseware.z01.azurefd.net.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

TLS-konfiguration

Engångskonfiguration: Proseware köper ett TLS-certifikat med jokertecken, lägger till det i ett nyckelvalv och ger Azure Front Door åtkomst till valvet.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

Azure Front Door-konfiguration

Engångskonfiguration: Proseware skapar en Azure Front Door-profil och en enskild slutpunkt. Företaget konfigurerar flera ursprungsgrupper, en per programstämpel/server i varje region.

När en ny klientorganisation registreras: Proseware lägger till en anpassad domänresurs i Azure Front Door. De använder namnet *.proseware.com och associerar sitt jokerteckens TLS-certifikat med den anpassade domänresursen. De skapar sedan en väg för att ange vilken ursprungsgrupp (stämpel) som klientorganisationens begäranden ska dirigeras till. I föregående diagram tenant1.proseware.com dirigerar du till ursprungsgruppen i Australien-regionen och tenant2.proseware.com dirigerar till ursprungsgruppen i Regionen Europa.

Förmåner

• När nya klienter registreras krävs inga DNS- eller TLS-konfigurationsändringar.
• Proseware har en enda instans av Azure Front Door för att dirigera trafik till flera stämplar i flera regioner.

Nackdelar

• Proseware måste konfigurera om Azure Front Door varje gång en ny klientorganisation registreras.
• Proseware måste vara uppmärksam på kvoter och gränser för Azure Front Door, särskilt antalet vägar och anpassade domäner samt den sammansatta routningsgränsen.
• Proseware måste köpa ett TLS-certifikat med jokertecken.
• Proseware ansvarar för att förnya och installera certifikatet när det upphör att gälla.

Scenario 3: Providerhanterade, stämpelbaserade jokerteckenunderdomäner

Fabrikam skapar en lösning för flera klientorganisationer. Företaget distribuerar stämplar i Australien och USA. Alla begäranden inom en enda region hanteras av stämpeln i den regionen. Fabrikam använder stämpelbaserade stamdomäner som tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comoch tenant3.us.fabrikam.com.

Företaget distribuerar Azure Front Door med hjälp av den här konfigurationen:

DNS-konfiguration

Engångskonfiguration: Fabrikam konfigurerar följande två DNS-poster med jokertecken för varje stämpel.

• En jokertecken-TXT-post för varje stämpel: *.australia.fabrikam.com och *.us.fabrikam.com. De anges till de värden som anges av Azure Front Door under registreringsprocessen för anpassad domän.
• En CNAME-post med jokertecken för varje stämpel *.australia.fabrikam.com och *.us.fabrikam.com, som båda är alias för Azure Front Door-slutpunkten: fabrikam.z01.azurefd.net.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

TLS-konfiguration

Engångskonfiguration: Fabrikam köper ett jokertecken-TLS-certifikat för varje stämpel, lägger till dem i ett nyckelvalv och ger Azure Front Door åtkomst till valvet.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

Azure Front Door-konfiguration

Engångskonfiguration: Fabrikam skapar en Azure Front Door-profil och en enskild slutpunkt. De konfigurerar en ursprungsgrupp för varje stämpel. De skapar anpassade domäner med ett jokertecken för varje stämpelbaserad underdomän: *.australia.fabrikam.com och *.us.fabrikam.com. De skapar en väg för varje stämpels anpassade domän för att skicka trafik till lämplig ursprungsgrupp.

När en ny klientorganisation registreras: Ingen ytterligare konfiguration krävs.

Förmåner

• Med den här metoden kan Fabrikam skala till ett stort antal klienter över flera stämplar.
• När nya klienter registreras krävs inga DNS- eller TLS-konfigurationsändringar.
• Fabrikam underhåller en enda instans av Azure Front Door för att dirigera trafik till flera stämplar i flera regioner.

Nackdelar

• Eftersom URL:er använder en stamdomänstruktur för flera delar kan URL:er vara mer komplexa för användare att arbeta med.
• Fabrikam måste köpa flera TLS-certifikat med jokertecken.
• Fabrikam ansvarar för att förnya och installera TLS-certifikaten när de upphör att gälla.

Scenario 4: Vanity-domäner

Adventure Works Cycles skapar en lösning för flera klientorganisationer. Företaget distribuerar stämplar i flera regioner, till exempel Australien och USA. Alla begäranden inom en enda region hanteras av stämpeln i den regionen. Adventure Works gör det möjligt för sina klienter att ta med sina egna domännamn. Till exempel kan klientorganisation 1 konfigurera ett anpassat domännamn som tenant1app.tenant1.com.

Företaget distribuerar Azure Front Door med hjälp av den här konfigurationen:

DNS-konfiguration

Engångskonfiguration: Ingen.

När en ny klientorganisation registreras: Klienten måste skapa två poster på sin egen DNS-server:

• En TXT-post för domänverifiering. Till exempel måste klientorganisation 1 konfigurera en TXT-post med namnet tenant1app.tenant1.com och ställa in den på det värde som anges av Azure Front Door under registreringsprocessen för anpassad domän.
• En CNAME-post som är alias för Adventure Works Azure Front Door-slutpunkten. Till exempel måste klient 1 konfigurera en CNAME-post med namnet tenant1app.tenant1.com och mappa den till adventureworks.z01.azurefd.net.

TLS-konfiguration

Adventure Works och dess klienter måste bestämma vem som utfärdar TLS-certifikat:

• Det enklaste alternativet är att använda Azure Front Door för att utfärda och hantera certifikaten, men klientorganisationer bör inte konfigurera CCA-poster på sina DNS-servrar. Om de gör det kan posterna hindra Azure Front Door-certifikatutfärdare från att utfärda certifikat.
• Alternativt kan klientorganisationer tillhandahålla sina egna certifikat. De måste arbeta med Adventure Works för att ladda upp certifikatet till ett nyckelvalv och ge åtkomst till Azure Front Door.

Azure Front Door-konfiguration

Engångskonfiguration: Adventure Works skapar en Azure Front Door-profil och en enda slutpunkt. De konfigurerar en ursprungsgrupp för varje stämpel. De skapar inte anpassade domänresurser eller vägar.

När en ny klientorganisation registreras: Adventure Works lägger till en anpassad domänresurs i Azure Front Door. De använder det klientspecifika domännamnet och associerar lämpligt TLS-certifikat med den anpassade domänresursen. De skapar sedan en väg för att ange vilken ursprungsgrupp (stämpel) som klientorganisationens begäranden ska dirigeras till. I föregående diagram tenant1app.tenant1.com dirigeras till ursprungsgruppen i Australien-regionen och tenant2app.tenant3.com dirigeras till ursprungsgruppen i regionen USA.

Förmåner

• Kunder kan ange sina egna domännamn. Azure Front Door dirigerar transparent begäranden till lösningen för flera klienter.
• Adventure Works underhåller en enda instans av Azure Front Door för att dirigera trafik till flera stämplar i flera regioner.

Nackdelar

• Adventure Works måste konfigurera om Azure Front Door varje gång en ny klientorganisation registreras.
• Klienter måste vara involverade i registreringsprocessen. De måste göra DNS-ändringar och eventuellt utfärda TLS-certifikat.
• Klientorganisationer styr sina DNS-poster. Ändringar i DNS-poster kan påverka deras möjlighet att komma åt Adventure Works-lösningen.
• Adventure Works måste vara uppmärksamma på Azure Front Door-kvoter och -gränser, särskilt på antalet vägar och anpassade domäner och den sammansatta routningsgränsen.

Scenario 5: Azure Front Door-profil per stämpel

Du kan distribuera en Azure Front Door-profil för varje stämpel. Om du har 10 stämplar distribuerar du 10 instanser av Azure Front Door. Den här metoden kan vara användbar om du behöver begränsa hanteringsåtkomsten för varje stämpels Azure Front Door-konfiguration. Det kan också vara användbart om du behöver använda flera Azure Front Door-profiler för att undvika att överskrida resurskvoter eller gränser.

Dricks

Azure Front Door är en global resurs. Även om du distribuerar stämplar med regionalt omfång distribueras varje Azure Front Door-profil globalt. Du bör överväga om du verkligen behöver distribuera flera Azure Front Door-profiler och vilka fördelar du får genom att göra det.

Om du har en stämpel som hanterar flera klienter måste du överväga hur du dirigerar trafik till varje klientorganisation. Granska de metoder som beskrivs i föregående scenarier och överväg att kombinera metoder som passar dina behov.

Förmåner

• Om du utökar konfigurationen mellan flera profiler är det mindre troligt att du når resursgränserna för Azure Front Door. Om du till exempel behöver stöd för ett stort antal anpassade domäner kan du dela upp domänerna mellan flera Azure Front Door-profiler och hålla dig inom gränserna för varje profil.
• Med den här metoden kan du omfångsbegränsa dina azure Front Door-resurshanteringsbehörigheter. Du kan använda rollbaserad åtkomstkontroll i Azure (RBAC) för att ge administratörer åtkomst till en enskild stämpels profil.

Nackdelar

• Den här metoden medför vanligtvis en hög kostnad eftersom du distribuerar fler profiler. Mer information finns i Förstå Front Door-fakturering.
• Det finns en gräns för hur många Azure Front Door-profiler som du kan distribuera till en enda Azure-prenumeration. Mer information finns i Front Door-kvoter och -gränser.
• Du måste konfigurera varje stämpels Azure Front Door-profil separat och du måste hantera DNS-konfiguration, TLS-certifikat och TLS-konfiguration för varje stämpel.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Raj Nemani | Direktör, partnerteknikstrateg
• John Downs | Huvudprogramtekniker

Övriga medarbetare:

• Mick Alberts | Teknisk författare
• Fernando Antivero | Fullstack Developer & Cloud Platform Engineer
• Duong Au | Senior Content Developer, C+E Skilling Content R&D
• Harikrishnan M B (HARI) | Product Manager 2, Azure Networking
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Utbildning: Introduktion till Azure Front Door
• Introduktion till Azure Front Door
• Vad är Azure Front Door?

Relaterade resurser

• Skapa lösningar för flera klientorganisationer i Azure
• Checklista för att utforma och skapa lösningar för flera klientorganisationer i Azure
• Innehavarmodeller att överväga för en lösning med flera klientorganisationer