Applikasjonsgatewayer

En applikasjonsgateway setter én offentlig adresse foran mange tjenester i VPC-en din og sender hver forespørsel videre til riktig tjeneste ut fra vertsnavn og URL-sti. Den terminerer TLS, kan kryptere trafikken på nytt på vei til backend-ene dine, og bruker en nettverksbrannmur — regler for kilde-CIDR, blokkering per land og hastighetsbegrensning — før en forespørsel i det hele tatt når applikasjonen din.

Den er en forvaltet appliance: en dedikert instans i din egen VPC, med en størrelse, en versjon og sin egen post på fakturaen din.

Applikasjonsgateway eller lastbalanserer?

Begge tar imot offentlig trafikk. De svarer på ulike spørsmål.

	Lastbalanserer	Applikasjonsgateway
Hva den gjør	Fordeler trafikk over en pool av backend-er	Avgjør hvor hver forespørsel går, og om den får gå i det hele tatt
Ruting	Én tjeneste per lytterport	Mange tjenester bak én adresse, per vertsnavn og sti
Adresser som kreves	Én per lastbalanserer	Én, for alle tjenestene bak den
Regler per forespørsel	—	Omskriving av sti, headere, backend per rute
Beskyttelse	Tillatte CIDR-er på en lytter	CIDR-regler, landblokkering, hastighetsgrenser, tilkoblingstak

Kort sagt: vil du fordele trafikk, bruk en lastbalanserer. Vil du styre den, bruk en applikasjonsgateway. De kan kombineres — en gateway-pool kan peke på en lastbalanserers adresse.

Opprett en gateway

En gateway ligger i én VPC og ett subnett, og trenger en offentlig adresse. La enten plattformen tildele en, eller ta med en du allerede har.

# Adresse tildelt av plattformen
fm appgw create --name edge --flavor agw.co1.medium \
  --vpc <vpc-id> --subnet <subnet-id>

# Ta med din egen offentlige IP
fm appgw create --name edge --flavor agw.co1.medium \
  --vpc <vpc-id> --subnet <subnet-id> \
  --public-ip-mode selected --public-ip <public-ip-id>

De to modusene skiller seg på én måte som betyr noe senere: en adresse plattformen tildelte frigjøres når du sletter gatewayen; en adresse du tok med gjør det ikke. Den går tilbake til dine offentlige IP-adresser og forblir din.

Størrelser kommer fra katalogen:

fm appgw flavors

En størrelse beskriver hva appliancen tåler, ikke maskinen under den: oppgitt kapasitet, antall samtidige tilkoblinger den holder, og hvor mange lyttere, ruter, backend-er og brannmurregler den tar imot.

De fire grensene er harde — å overskride en av dem avvises, den strupes ikke — så velg størrelse ut fra regelverket du har tenkt å skrive, ikke bare ut fra trafikken. Antall forespørsler per sekund er en oppgitt kapasitet, ikke en garanti: hva du faktisk får avhenger av reglene dine, TLS-innstillingene dine og backend-ene dine.

Du velger ingen appliance-versjon. Frostmoln styrer den: du lager ruter, backend-er og WAF-regler, aldri datalagskonfigurasjonen under dem. Versjonsvalget du faktisk styrer er WAF-regelverket ditt, som har egne versjoner, publisering og tilbakerulling.

I Terraform heter ressursen frostmoln_application_gateway, med frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_health_check og frostmoln_appgw_certificate under seg. En TCP-lytter er protocol = "tcp" med backend_pool_id, og valgfritt port_range_end; PROXY-protokollet er proxy_protocol på poolen, og på helsesjekken for dens sonderingstilkobling.

Lyttere — der trafikken kommer inn

En lytter binder en protokoll og en port. HTTPS-lyttere terminerer TLS og trenger derfor et sertifikat.

fm appgw certificate upload --gateway <gw-id> --name example-com \
  --chain ./fullchain.pem --private-key ./privkey.pem

fm appgw listener create --gateway <gw-id> --name https \
  --protocol https --port 443 --certificate <certificate-id> \
  --tls-min-version 1.2 --tls-cipher-profile modern

Gi --private-key en sti, eller - for å lese fra standard input. Å sende nøkkelteksten direkte legger den i shell-historikken din og i prosesslisten.

Serverer du flere vertsnavn fra én lytter? Legg til flere sertifikater med --sni-certificate (kan gjentas); riktig sertifikat velges per tilkobling.

En vanlig HTTP-lytter kan ganske enkelt sende alle videre til HTTPS:

fm appgw listener create --gateway <gw-id> --name http \
  --protocol http --port 80 --redirect-to-https

TCP-lyttere — når trafikken ikke er HTTP

Noe av det du trenger å publisere snakker ikke HTTP: en e-postserver, en MQTT-megler for en flåte av enheter, en databasereplika, en spillserver. En TCP-lytter bærer dem gjennom gatewayen uten å lese dem.

fm appgw listener create --gateway <gw-id> --name smtp \
  --protocol tcp --port 25 --backend-pool <pool-id>

Den har en annen form enn en HTTP-lytter, og forskjellene er avslag, ikke utelatelser — plattformen sier nei i stedet for å ta imot en innstilling og stille ignorere den:

• Den navngir én backend-pool. En TCP-lytter har ingen ruter, fordi ruting betyr å matche et vertsnavn, en sti eller et hode, og ingenting av det finnes i en strøm av byte. --backend-pool kreves her, og avvises på en HTTP- eller HTTPS-lytter der hver rute navngir sin egen pool.
• Den terminerer ingen TLS. Ingen sertifikat, ingen minsteversjon, ingen cipher-profil, ingen omdirigering til HTTPS. TLS forblir ende til ende mellom klienten og backend-en din — som ofte er hele poenget: gatewayen holder aldri nøkkelmaterialet for den tjenesten.
• Brannmuren for nettapplikasjoner gjelder ikke for den. Brannmuren inspiserer forespørsler, og det finnes ingen. Et regelsett kan ikke kobles til en TCP-lytter, og et som er koblet til gatewayen når den ikke.
• Poolen må være en HTTP-pool, må ikke allerede motta trafikk fra en rute, og må ikke bruke informasjonskapselbasert sesjonsbinding — en informasjonskapsel er et HTTP-hode gatewayen ikke kan sette på lag 4.

Alt annet ved beskyttelsen gjelder uendret. Kildeadresseregler, landsblokkering, hastighetsgrenser, tilkoblingstak og helsesjekker virker på samme måte som på en HTTPS-lytter:

fm appgw listener create --gateway <gw-id> --name smtp \
  --protocol tcp --port 25 --backend-pool <pool-id> \
  --allowed-cidr 203.0.113.0/24 \
  --rate-limit-rps 20 --rate-limit-burst 40 \
  --max-connections 2000

Det er grunnen til å velge en applikasjonsgateway framfor en lastbalanserer for en tjeneste som ikke er HTTP: du får fortsatt én adresse, ett sted reglene bor og én ting å revidere.

På en TCP-lytter teller grensene TILKOBLINGER, ikke forespørsler

På HTTP og HTTPS teller --rate-limit-rps og --rate-limit-burst forespørsler. På lag 4 finnes ingen forespørsel å telle, så de teller tilkoblinger.

Der én tilkobling bærer en hel sesjon — SMTP, IMAP, MQTT — er det samme tallet en langt strammere grense enn det ville vært for en nettlytter. Et tall kopiert fra en HTTPS-lytter struper en e-postserver med flere størrelsesordener. Sett det etter tilkoblingene du faktisk venter deg.

Portområder

En TCP-lytter kan binde et område av porter i stedet for én:

fm appgw listener create --gateway <gw-id> --name ftp-data \
  --protocol tcp --port 30000 --port-range-end 30099 \
  --backend-pool <pool-id>

Området er inklusivt, må gå oppover fra --port, og kan omfatte høyst 512 porter. Hver tilkobling videresendes til samme port på backend-en din som klienten koblet til — 30000-30099 når 30000-30099 på serverne dine. Det er det som i det hele tatt får et passivt FTP-dataområde, eller en blokk med porter per tjeneste, til å virke.

To ting følger av det:

• En pool bak en områdelytter må gi helsesjekken sin en egen port. Backend-ene nås på den porten hver klient kom inn på, så en sondering har ellers ingenting å ringe opp. Se Helsesjekker.
• To lyttere på én gateway kan ikke overlappe i portrommet. En annen lytter som gjør krav på en port en eksisterende binder, avvises, uansett om kollisjonen er mellom to enkeltporter eller to områder.

Noen porter er appliancens egne og avvises for alle protokoller. Blir et område avvist av den grunnen, navngir meldingen porten — flytt området, eller del det i to rundt den.

Å slette en lytter stenger porten dens umiddelbart

Å opprette en lytter åpner porten dens i gatewayens offentlige inngang, og å slette en stenger den — begge uten å vente på en iverksetting. Å erstatte en levende TCP-tjeneste ved å slette lytteren og opprette en ny mister derfor trafikk i gapet mellom de to kallene. Opprett erstatningen først der du kan, og for å endre en innstilling på poolen bak den: oppdater poolen i stedet for å bygge om noen av dem.

Beskytte en lytter

Dette gjelder hver forespørsel på lytteren, før ruting:

fm appgw listener create --gateway <gw-id> --name https \
  --protocol https --port 443 --certificate <certificate-id> \
  --allowed-cidr 203.0.113.0/24 --allowed-cidr 198.51.100.0/24 \
  --geo-block-mode allow --geo-country SE --geo-country NO \
  --rate-limit-rps 50 --rate-limit-burst 100 \
  --max-connections 4000

--max-connections begrenses av størrelsen din: en lytter som ber om mer enn størrelsen er oppgitt å tåle, hever appliancens egen grense til samme verdi — det er en måte å overbelaste den på, ikke en måte å få mer kapasitet. Sjekk verdien med fm appgw flavors.

--allowed-cidr og --denied-cidr kan gjentas. --geo-block-mode er off, allow (bare disse landene) eller deny (alle unntatt disse), med ISO-landkoder.

Backend-pooler og backend-er

En pool er en gruppe backend-er gatewayen sender videre til, pluss hvordan den velger mellom dem og hvordan den snakker med dem.

fm appgw pool create --gateway <gw-id> --name app-pool \
  --protocol http --algorithm round_robin \
  --timeout-connect-ms 2000 --timeout-response-ms 30000

--algorithm er round_robin, least_connections eller source_ip. For klebrige økter, bruk --session-affinity cookie --session-cookie <navn> eller --session-affinity source_ip.

For å kryptere trafikken på nytt på vei til applikasjonen din, gjør poolen https og angi hvordan backend-ens sertifikat skal kontrolleres:

fm appgw pool create --gateway <gw-id> --name secure-pool \
  --protocol https --tls-verify-backend \
  --tls-ca-certificate ./internal-ca.pem --tls-server-name app.internal

PROXY-protokoll — å fortelle backend-ene dine hvem som ringer

En backend bak en TCP-lytter ser gatewayens adresse som klient, ikke den virkelige. For en e-postserver er det nesten fatalt: spamvurdering, hastighetsbegrensning, greylisting og misbrukslogger beregnes alle mot én enkelt adresse, vår. Det finnes ingen X-Forwarded-For å falle tilbake på, fordi det er et HTTP-hode og en TCP-lytter bærer ingen HTTP.

PROXY-protokollet setter den virkelige klientadressen først i hver tilkobling:

fm appgw pool create --gateway <gw-id> --name mail-pool \
  --protocol http --proxy-protocol

Sett FØRST opp backend-en til å lese hodet

Å slå på dette endrer bytene backend-en din mottar. En server som ikke venter hodet leser det som de første bytene i protokollen din, og hver tilkobling mislykkes.

Rekkefølgen betyr noe, begge veier:

1. Sett opp backend-en til å ta imot PROXY-protokollet fra gatewayen — i Postfix er det smtpd_upstream_proxy_protocol, i nginx proxy_protocol på listen-linjen, i Dovecot innstillingen som sier hvilke oppstrøms som får sende det.
2. Slå det på her.
3. Iverksett gatewaykonfigurasjonen.

Å slå det av igjen er den samme endringen motsatt vei: fjern innstillingen på gatewayen og iverksett, og la deretter backend-en slutte å vente den.

Det er av som standard, og forblir av til du ber om det.

Å endre en pool uten å bygge den om

Alt på en pool bortsett fra navnet kan endres på stedet:

fm appgw pool update <pool-id> --gateway <gw-id> --proxy-protocol
fm appgw pool update <pool-id> --gateway <gw-id> \
  --algorithm least_connections --timeout-response-ms 60000

En innstilling du ikke navngir, blir liggende urørt, og endringen trer i kraft ved neste iverksetting som all annen gatewaykonfigurasjon.

Det er slik PROXY-protokollet slås på for en pool som allerede finnes. Uten det ville eneste vei være å slette poolen — som først betyr å slette TCP-lytteren som holder den, og stenge den offentlige porten i samme øyeblikk — og bygge begge på nytt: et avbrudd for å endre én innstilling hvis hele formål er å bli endret når backend-en har lært å lese hodet.

To endringer avvises mens en TCP-lytter videresender til poolen, av de samme grunnene som de avvises når den lytteren opprettes: cookie som sesjonsbinding er en HTTP-informasjonskapsel gatewayen ikke kan sette på lag 4, og https som poolprotokoll ville kryptert om byte som allerede er det klienten sendte.

Backend-er angis med IP-adresse inne i gatewayens VPC, og en port:

fm appgw backend add --gateway <gw-id> --pool <pool-id> \
  --address 10.0.1.10 --port 8080 --weight 1

En adresse utenfor gatewayens egen VPC avvises. Det er med vilje: uten den regelen ville gatewayen sendt trafikk dit du enn pekte den.

Helsesjekker

En pool uten helsesjekk sender trafikk til backend-er som er nede.

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --expected-status 200-299 \
  --interval 10 --timeout 5 --healthy-threshold 2 --unhealthy-threshold 3

--timeout må være kortere enn --interval.

--protocol tcp åpner en tilkobling til porten og lukker den igjen. Den sender ingen forespørsel og sammenligner ingen status, så --path og --expected-status gjelder ikke og avvises på den. Bruk den for alt som ikke svarer med HTTP.

health-check set ERSTATTER sjekken — den slås ikke sammen med den

Kommandoen angir hele sjekken. En innstilling du utelater blir ikke stående som den var: den går tilbake til plattformens standard. --port går tilbake til å sondere hver backends egen port, og --proxy-protocol går tilbake til av.

Å justere ett enkelt tall betyr altså at du oppgir resten på nytt. En sjekk som sonderer 8080 med PROXY-protokollet på, satt på nytt med bare --protocol, --path og --interval, mister stille begge — og en sondering som slutter å sende hodet til en port som krever det, feiler hver gang og markerer hver backend i poolen som syk selv om backend-ene har det bra. Se PROXY-protokoll på sonderingen.

Les sjekken med fm appgw health-check get først, og send tilbake det den hadde. For å ikke ha noen sjekk i det hele tatt, bruk health-check delete heller enn et tomt set.

Å sondere en annen port

Som standard ringer sonderingen opp hver backends egen port. --port sender den et annet sted:

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --port 8080

To tilfeller vil ha dette. Det første er en tjeneste hvis helseendepunkt ligger et annet sted — en e-postserver som svarer SMTP på 25 med et lite HTTP-helseendepunkt på 8080. Uten det er eneste tilgjengelige sondering "åpne en tilkobling til 25", som en belastet e-postserver tar imot og deretter utsetter, så backend-en leses som frisk mens den avviser hver melding.

Det andre er ikke valgfritt: en pool bak en TCP-lytter med portområde må sette --port. Backend-ene nås på den porten hver klient kom inn på, så det finnes ingen fast port for en sondering å nå, og en sjekk uten port avvises.

PROXY-protokoll på sonderingen

En pool som sender PROXY-protokollet kan la helsesjekken sin sende det på sonderingstilkoblingen også:

fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
  --protocol http --path /healthz --port 8080 --proxy-protocol

Om du vil ha det, avhenger av hvilken port sonderingen ringer opp, og bare du vet svaret. En sonderingsport finnes nettopp for å nå en annen tjeneste enn den som bærer trafikken — en e-postserver som svarer SMTP på 25 med et lite HTTP-helseendepunkt på 8080 — og et slikt helseendepunkt har sjelden noen grunn til å snakke PROXY-protokollet. Det vanlige tilfellet vil ikke ha hodet.

Sender du det til en port som ikke venter det, leser den porten hodet som de første bytene i protokollen din. Sonderingen feiler, og en feilende sondering markerer hver backend i poolen som syk selv om backend-ene selv har det bra — poolen svarer 503 for servere som fungerer utmerket. Som resten av gatewayens konfigurasjon skjer det ved neste iverksetting, ikke når du stiller det inn.

Av betyr IKKE "sonderingen sender ikke noe hode"

En sondering uten egen --port ringer opp hver backends egen adresse og port, så den arver poolens tilkoblingsinnstillinger — PROXY-protokollet blant dem. En slik sondering bærer allerede hodet så snart poolens eget PROXY-protokoll er på, med denne innstillingen av.

Å gi sonderingen en --port velger bort de innstillingene, og tar hodet med seg. Denne innstillingen er slik du setter det tilbake.

fm appgw health-check get viser de to sammen nettopp derfor: uten sonderingsport lyder raden PROXY protocol on probe no (the probe follows the pool's setting) i stedet for et blankt nei.

Poolens eget PROXY-protokoll må være på først. Å slå det på for sonderingen i en pool som ikke sender noe hode avvises — det finnes ikke noe hode å sende. Det motsatte avvises også: å slå av poolens avvises så lenge sonderingen fortsatt sender det. Rekkefølgen er poolen på, deretter sonderingen, og sonderingen av, deretter poolen.

Å slå det på mens sonderingen mangler egen port tas imot og lagres, og endrer ingenting — den sonderingen arver allerede poolens innstilling. Det begynner å bety noe i samme øyeblikk som sonderingen navngir en port.

I portalen er det en bryter i poolens helsesjekkpanel. I Terraform er det proxy_protocol på frostmoln_appgw_health_check, der rekkefølgen over får én konsekvens til: én enkelt terraform apply som slår av både denne og poolens, feiler på poolen, fordi Terraform oppdaterer poolen før sjekken som refererer til den. Slå av sonderingens i én iverksetting og poolens i en senere.

Å fjerne en helsesjekk

fm appgw health-check delete --gateway <gw-id> --pool <pool-id>

Fra neste iverksetting slutter gatewayen å sondere denne poolen og behandler hver aktivert backend som tilgjengelig.

Det er riktig svar når backend-ene selv avgjør tilgjengeligheten sin — en overvåket tjeneste, eller en som sitter bak sin egen lastbalanserer — og en sondering fra gatewayen bare ville lagt til en annen mening. For alt annet: behold en sjekk. Uten den fortsetter en backend som har sluttet å svare å få sin del av trafikken.

Hva gatewayen har observert

fm appgw backend list og portalen viser begge en status per backend, med tidspunktet den sist ble observert.

Backend-helse rapporteres ikke ennå

Rapporteringen som fyller dette inn bygges fortsatt, så hver backend leses nå som ikke observert, uansett virkelig tilstand. Det er en påstand om vår rapportering, ikke om serverne dine — en uobservert backend er verken frisk eller syk så vidt plattformen vet, og ingenting holdes unna trafikk på grunn av det. Denne siden sier fra når det endrer seg.

Godkjenn hver backend — det steget er ikke valgfritt

Å legge til en backend forteller gatewayen hvor den skal sende trafikken. Det gir den ikke tillatelse til å komme dit: backend-enes sikkerhetsgrupper avgjør det, og gatewayen er ikke i dem.

Godkjenn den uttrykkelig:

fm appgw backend authorize --gateway <gw-id> --pool <pool-id> \
  --backend <backend-id> --security-group <security-group-id>

Det legger til én ingress-regel i din sikkerhetsgruppe som slipper gatewayen inn på den porten. Ingenting åpnes for deg — plattformen endrer ikke sikkerhetsgruppene dine i stillhet.

To følger verdt å kjenne til:

• Hopper du over det, svarer den første gatewayen din 503, fordi tilkoblingen til backend-en avvises.
• Regelen er delt. Den skrives per sikkerhetsgruppe, protokoll og port, så hver backend bak den gruppen på den porten nås gjennom den — og å trekke den tilbake stenger veien for alle sammen, ikke bare den du navnga.

fm appgw authorization list --gateway <gw-id>
fm appgw authorization revoke --gateway <gw-id> <authorization-id>

Ruter — hvilken tjeneste som svarer

En rute matcher et vertsnavn og en sti på en lytter og sender videre til en pool.

fm appgw route create --gateway <gw-id> --listener <listener-id> \
  --name api --host api.example.com --path /v1 --match-type prefix \
  --pool <pool-id>

--match-type er prefix, exact eller regex. --host tar imot et jokertegn (*.example.com).

Ruter evalueres etter prioritet, lavest først — et uttrykkelig tall, aldri gjettet ut fra hvor spesifikk stien ser ut. En ny rute havner sist med mindre du sier noe annet. Endre rekkefølge uten å opprette noe på nytt:

fm appgw route reorder --gateway <gw-id> --listener <listener-id> \
  --route <route-id>=10 --route <other-route-id>=20

At prioriteten er uttrykkelig er det som hindrer at én ny rute i stillhet endrer hvor eksisterende trafikk går.

En rute kan også skrive om forespørselen før den sendes videre:

fm appgw route create --gateway <gw-id> --listener <listener-id> \
  --name legacy --host example.com --path /old --match-type prefix \
  --pool <pool-id> --rewrite-path-prefix /new \
  --set-header X-Tenant=acme --remove-header X-Debug \
  --set-response-header Strict-Transport-Security="max-age=31536000"

Iverksett — ingenting er live før du gjør det

Lyttere, ruter, pooler, backend-er og sertifikater er forfattet. De lagres så snart du skriver dem, og gatewayen fortsetter å servere det den allerede hadde til du iverksetter:

fm appgw apply <gateway-id>

Gatewayen validerer den nye konfigurasjonen, bytter til den, laster om og kontrollerer seg selv før den rapporterer tilbake. Feiler noe av det, gjenoppretter den det den serverte og forteller deg hvorfor — en ødelagt konfigurasjon tar ikke ned nettstedet ditt for noen.

fm appgw get <gateway-id> viser om det du forfattet er det som kjører. Portalen viser det samme som et banner, og begge gjengir appliance-ens egne ord når en iverksetting avvises.

Iverksetting krever at gatewayen er running, og bare én iverksetting kjører om gangen.

Brannmur for webapplikasjoner

Hver applikasjonsgateway inkluderer en brannmur for webapplikasjoner, uten ekstra kostnad — det finnes ingen separat produkt å kjøpe og ingen tilleggstjeneste å aktivere. Regler forfattes per gateway, oppå en vedlikeholdt baslinje som Frostmoln holder oppdatert.

Ikke tilgjengelig ennå

Å forfatte regler er ennå ikke åpent for kunder. Denne siden dokumenterer det når det er; ingenting i gatewayens konfigurasjon endres i mellomtiden.

Slette en gateway

fm appgw delete <gateway-id>

Trafikken stopper umiddelbart. Om den offentlige adressen overlever avhenger av hvordan gatewayen fikk den: en adresse plattformen tildelte frigjøres, og en adresse du tok med beholdes og går tilbake til dine offentlige IP-adresser.

Fakturering

En applikasjonsgateway faktureres per time ut fra størrelsen sin, som enhver annen forvaltet instans, og brannmuren for webapplikasjoner inngår i den prisen. Hvis gatewayens offentlige adresse ble tildelt av plattformen, faktureres den som en offentlig IP, separat og bare én gang; en adresse du allerede har ligger allerede på fakturaen din og faktureres ikke to ganger.

Tilgjengelighet

En standard applikasjonsgateway er én enkelt forvaltet appliance. Hvis verten dens går ned, bygges den opp igjen, noe som ikke skjer umiddelbart. Planlegg for det slik du ville gjort for enhver enkeltinstans — og hvis et kort avbrudd er uakseptabelt for trafikken du setter den foran, si det før du legger produksjon bak en.