Slutpunkter

En slutpunkt gör en port i en komponent nåbar från utanför klustret. En instans har högst 12. Fliken Slutpunkter listar dem med adress och certifikat; att lägga till, ändra och ta bort dem kräver containerinstance/write — och, på en instans som använder valvhemligheter, rollen Owner på de valven, se Behörigheter — och startar inte om några poddar.

Lägg till en slutpunkt

1. Välj Lägg till slutpunkt på instansens flik Slutpunkter. Panelen Ny slutpunkt öppnas. Exponera porten, i en komponents redigeringspanel, öppnar samma panel med komponent och port ifyllda.
2. Fyll i:
   • Namn — gemener, siffror och bindestreck, med en bokstav först, och unikt i instansen. Panelen låter dig inte ändra det senare.
   • Komponent — komponenten som betjänar slutpunkten.
   • Exponering — Ingress för HTTPS på ett värdnamn, eller Lastbalanserare för en egen adress som bär rå TCP eller UDP.
   • Port — en av portarna som komponenten deklarerar. Den väljs med namn, så att ett ändrat portnummer senare inte kopplar loss slutpunkten. En ingress-slutpunkt kan inte använda en UDP-port.
   • För Ingress även Värdnamn, Sökvägar och Kräv inloggning, som beskrivs nedan.
3. Välj Spara slutpunkt.

Slutpunkten börjar svara när alla instansens startvågor är uppe. En ingress-slutpunkt betjänas över HTTPS; plattformen avslutar TLS-anslutningen och skickar vidare förfrågan till containern som vanlig HTTP på den valda porten.

Värdnamn

• Plattformens värdnamn. Lämna Värdnamn tomt så ger plattformen slutpunkten ett värdnamn under apps.example.com, byggt av boundaryn, resursgruppen och instansen: <boundary>-<resource group>-<instance>.apps.example.com, där <boundary> är början på boundaryns slug. Den första ingress-slutpunkten i instansens lista får det namnet; de övriga lägger till sitt eget namn sist. Namnet lagras med slutpunkten när du sparar. Panelens platshållare visar alltid formen med slutpunktens namn sist, även när slutpunkten blir den första.
• Din egen domän. Ange ett fullständigt domännamn som shop.example.com och skapa en DNS-post som pekar det på plattformen — din plattformsadministratör vet målet. Med den vanliga certifikatuppsättningen kan certifikatet utfärdas först när namnet pekar på plattformen.
• Flera slutpunkter på ett värdnamn. Ge dem Sökvägar — absoluta sökvägsprefix som /api — för att dela värdnamnet mellan dem; en slutpunkt utan sökvägar betjänar hela värdnamnet. Ett prefix matchar början av sökvägens text, så /admin matchar även /administrator. När sökvägar överlappar avgörs vilken slutpunkt som betjänar en förfrågan av routeprioritet, inte av vilken sökväg som är mest specifik, och panelen varnar för överlapp inom instansen.
• Att byta värdnamn kräver att du bekräftar. Slutpunkten slutar svara på det gamla namnet direkt och svarar på det nya när dess DNS pekar rätt och dess certifikat har utfärdats.

TLS-certifikat

Plattformen begär ett certifikat för varje värdnamn som en ingress-slutpunkt använder; slutpunkter som delar ett värdnamn delar dess certifikat. Kolumnen Certifikat visar Väntar på certifikat tills det har utfärdats och Certifikat klart därefter. För din egen domän betyder ett väntande certifikat oftast att DNS-posten saknas eller ännu inte pekar på plattformen.

Kolumnen Adress visar slutpunktens URL så snart slutpunkten har sparats, oavsett om den svarar ännu; kolumnen Certifikat är ett bättre tecken på att den gör det.

Endast internt

En instans utan slutpunkter kan inte nås från utanför klustret; dess Översikt visar Endast internt. Dess komponenter svarar fortfarande inom boundaryn på sina klusternamn — se Hur en instans nås. Tar du bort alla slutpunkter blir instansen intern igen.

Slutpunkter med lastbalanserare

En slutpunkt med Lastbalanserare får en egen adress från klustret, som bär exakt den ena porten. Kolumnen Adress visar den som address:port när den har tilldelats, och Väntar på adress från lastbalanseraren fram till dess. Den tar inget värdnamn, inga sökvägar och ingen inloggning och får inget certifikat.

Se upp

En slutpunkt med lastbalanserare tar emot anslutningar på sin port från vilken källa som helst, och det finns ingen lista över tillåtna adresser som begränsar det. Förutom klienter utanför klustret gäller det arbetslaster i andra boundaries: varje arbetslast får öppna TCP 443 mot vilken adress som helst, så på port 443 kan de också ansluta till den. Boundaryns nätverksregler gäller inte för den porten, så applikationen måste själv avgöra vem som får använda den.

Kräv inloggning

Slå på Kräv inloggning på en ingress-slutpunkt för att sätta plattformens inloggning framför den:

• En webbläsare utan session skickas till inloggning med ett plattformskonto, via auth.apps.example.com.
• Efter inloggningen behöver personen containerinstance/access, via en roll som är tilldelad på instansens resursgrupp, dess boundary eller hela plattformen; en roll som är tilldelad på själva instansen känns inte igen. Kontrollen läser bara roller som har åtgärden som en vanlig åtgärd: Owner, Contributor, Platform Owner och Platform Contributor släpps igenom. Reader, Blueprint Reader och Blueprints Operator listar den som en dataåtgärd, som den här kontrollen inte läser, så de nekas. Den som nekas får 403 Forbidden. En återkallad roll slutar gälla inom ungefär 30 sekunder.
• Förfrågningar som släpps igenom har rubrikerna X-Forwarded-User (användarnamnet) och X-Forwarded-Email, så att applikationen kan se vem som anropar.
• En inloggning varar i upp till åtta timmar. Där klustret routar via Traefik förlängs den inte av att slutpunkten används, så folk loggar in igen åtta timmar efter att de loggade in.

Viktigt

Lita på X-Forwarded-User och X-Forwarded-Email bara i förfrågningar som kom genom en slutpunkt med Kräv inloggning. Genom en slutpunkt utan den innehåller rubrikerna det klienten skickade. Och inloggningen skyddar bara slutpunkten: varje arbetslast i boundaryn kan ansluta direkt till komponenten på dess klusternamn, utan att logga in och med de rubriker den vill.

Använd inloggningsskydd på värdnamn under apps.example.com. Inloggningen sparas i en webbläsarcookie för den domänen, som webbläsaren inte skickar till en egen domän, så en slutpunkt på din egen domän skickar hela tiden tillbaka folk till inloggningen.

Viktigt

Eftersom cookien hör till hela apps.example.com skickar webbläsaren den också till alla andra värdnamn under den domänen — andra teams appar och containerinstanser inräknade — och den som kör tjänsten bakom ett sådant värdnamn får den med varje förfrågan.

Inloggningen kräver instansens managed identity. Varje instans som skapas på plattformen har en; utan den är reglaget inaktiverat.

Ändra eller ta bort en slutpunkt

• Pennikonen öppnar slutpunktens panel; allt utom namnet kan ändras.
• Papperskorgsikonen tar bort slutpunkten efter att du bekräftat: dess route och inloggning rivs och den slutar svara. Certifikatet behålls, så att lägga till samma värdnamn igen kräver inget nytt.
• Tar du bort en port eller en container som en slutpunkt använder, i en komponents redigeringspanel, tas slutpunkten bort i samma sparning, efter att du bekräftat.

Med CLI:t

Slutpunkter är en del av instansen. Skriv hela listan till en fil och uppdatera instansen med den; listan ersätter den som instansen har:

{
  "endpoints": [
    { "name": "web", "component": "main", "port": "http", "expose": "ingress" },
    { "name": "api", "component": "main", "port": "http", "expose": "ingress",
      "hostname": "api.example.com" },
    { "name": "admin", "component": "main", "port": "admin", "expose": "ingress", "authGuard": true },
    { "name": "mqtt", "component": "broker", "port": "mqtt", "expose": "loadBalancer" }
  ]
}

stsh ci update worker -g my-resource-group --file endpoints.json

Kopiera de befintliga posterna från stsh ci get worker -o json oförändrade, även deras hostname: en ingress-post som skickas utan värdnamn får plattformens värdnamn för sin plats i listan, som inte behöver vara det den hade.