Sovellusyhdyskäytävät
Sovellusyhdyskäytävä asettaa yhden julkisen osoitteen monen VPC:ssäsi olevan palvelun eteen ja ohjaa jokaisen pyynnön oikealle palvelulle isäntänimen ja URL-polun perusteella. Se päättää TLS-yhteyden, voi salata liikenteen uudelleen matkalla taustapalveluihisi, ja soveltaa verkkopalomuuria — lähde-CIDR-sääntöjä, maakohtaista estoa ja nopeusrajoituksia — ennen kuin pyyntö edes saavuttaa sovelluksesi.
Se on hallittu laite: oma instanssi omassa VPC:ssäsi, jolla on koko, versio ja oma rivinsä laskullasi.
Sovellusyhdyskäytävä vai kuormantasaaja?
Molemmat ottavat vastaan julkista liikennettä. Ne vastaavat eri kysymyksiin.
| Kuormantasaaja | Sovellusyhdyskäytävä | |
|---|---|---|
| Mitä se tekee | Jakaa liikennettä taustapalveluryhmän kesken | Päättää minne kukin pyyntö menee, ja saako se mennä lainkaan |
| Reititys | Yksi palvelu kuuntelijaporttia kohti | Monta palvelua yhden osoitteen takana, isäntänimen ja polun mukaan |
| Tarvittavat osoitteet | Yksi kuormantasaajaa kohti | Yksi, kaikille sen takana oleville palveluille |
| Pyyntökohtaiset säännöt | — | Polun uudelleenkirjoitus, otsakkeet, reittikohtainen taustapalvelu |
| Suojaus | Sallitut CIDR:t kuuntelijassa | CIDR-säännöt, maaesto, nopeusrajat, yhteyskatot |
Lyhyesti: jos haluat jakaa liikennettä, käytä kuormantasaajaa. Jos haluat ohjata sitä, käytä sovellusyhdyskäytävää. Ne toimivat yhdessä — yhdyskäytävän taustapalveluryhmä voi osoittaa kuormantasaajan osoitteeseen.
Yhdyskäytävän luominen
Yhdyskäytävä sijaitsee yhdessä VPC:ssä ja yhdessä aliverkossa, ja tarvitsee julkisen osoitteen. Anna joko alustan varata sellainen, tai tuo mukanasi osoite, joka sinulla jo on.
# Alustan varaama osoite
fm appgw create --name edge --flavor agw.co1.medium \
--vpc <vpc-id> --subnet <subnet-id>
# Tuo oma julkinen 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>Nämä kaksi tilaa eroavat yhdellä tavalla, jolla on merkitystä myöhemmin: alustan varaama osoite vapautetaan, kun poistat yhdyskäytävän; mukanasi tuomaa osoitetta ei vapauteta. Se palaa julkisiin IP-osoitteisiisi ja pysyy sinun.
Koot tulevat luettelosta:
fm appgw flavorsKoko kuvaa sitä, mitä laite kestää, ei sen alla olevaa konetta: ilmoitettua suorituskykyä, samanaikaisten yhteyksien määrää sekä sitä, kuinka monta kuuntelijaa, reittiä, taustapalvelua ja palomuurisääntöä se hyväksyy.
Nämä neljä rajaa ovat ehdottomia — rajan ylittäminen hylätään, sitä ei rajoiteta — joten valitse koko sen säännöstön perusteella, jonka aiot kirjoittaa, älä pelkän liikenteen. Pyyntöä sekunnissa on ilmoitettu arvo, ei takuu: todellinen suorituskyky riippuu säännöistäsi, TLS-asetuksistasi ja taustapalveluistasi.
Et valitse laitteiston versiota. Frostmoln hallitsee sitä: sinä määrität reitit, taustapalvelut ja WAF-säännöt, et koskaan niiden alla olevaa datatason asetusta. Versioluonteinen valinta, jota hallitset, on WAF-säännöstösi, jolla on omat versionsa, julkaisunsa ja palautuksensa.
Terraformissa resurssi on frostmoln_application_gateway, ja sen alla frostmoln_appgw_listener, frostmoln_appgw_route, frostmoln_appgw_backend_pool, frostmoln_appgw_backend, frostmoln_appgw_health_check ja frostmoln_appgw_certificate. TCP-kuuntelija on protocol = "tcp" yhdessä backend_pool_id-kentän kanssa ja valinnaisesti port_range_end; PROXY-protokolla on ryhmän proxy_protocol ja terveystarkistuksen proxy_protocol sen luotausyhteydelle.
Kuuntelijat — mistä liikenne saapuu
Kuuntelija sitoo protokollan ja portin. HTTPS-kuuntelijat päättävät TLS-yhteyden, joten ne tarvitsevat varmenteen.
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 modernAnna --private-key-valitsimelle polku, tai - lukeaksesi vakiosyötteestä. Avaimen tekstin antaminen suoraan tallentaa sen komentotulkin historiaan ja prosessiluetteloon.
Palveletko useaa isäntänimeä yhdestä kuuntelijasta? Lisää varmenteita --sni-certificate-valitsimella (toistettavissa); oikea valitaan yhteyskohtaisesti.
Tavallinen HTTP-kuuntelija voi yksinkertaisesti ohjata kaikki HTTPS:ään:
fm appgw listener create --gateway <gw-id> --name http \
--protocol http --port 80 --redirect-to-httpsTCP-kuuntelijat — kun liikenne ei ole HTTP:tä
Kaikki julkaistava ei puhu HTTP:tä: sähköpostipalvelin, MQTT-välittäjä laitejoukolle, tietokantareplika, pelipalvelin. TCP-kuuntelija kuljettaa ne yhdyskäytävän läpi lukematta niitä.
fm appgw listener create --gateway <gw-id> --name smtp \
--protocol tcp --port 25 --backend-pool <pool-id>Sen muoto on toinen kuin HTTP-kuuntelijan, ja erot ovat hylkäyksiä, eivät puutteita — alusta sanoo ei sen sijaan että ottaisi asetuksen vastaan ja jättäisi sen hiljaa huomiotta:
- Se nimeää yhden taustapalveluryhmän. TCP-kuuntelijalla ei ole reittejä, koska reititys tarkoittaa isäntänimen, polun tai otsakkeen täsmäytystä, eikä mitään niistä ole tavuvirrassa.
--backend-poolvaaditaan tässä ja hylätään HTTP- tai HTTPS-kuuntelijalla, jossa jokainen reitti nimeää oman ryhmänsä. - Se ei päätä TLS-yhteyttä. Ei varmennetta, ei vähimmäisversiota, ei salausprofiilia, ei ohjausta HTTPS:ään. TLS pysyy päästä päähän asiakkaan ja taustapalvelusi välillä — mikä on usein koko pointti: yhdyskäytävä ei koskaan hallitse kyseisen palvelun avainmateriaalia.
- Verkkosovelluspalomuuri ei koske sitä. Palomuuri tarkastaa pyyntöjä, eikä niitä ole. Sääntöjoukkoa ei voi liittää TCP-kuuntelijaan, eikä yhdyskäytävään liitetty sääntöjoukko ulotu siihen.
- Ryhmän on oltava HTTP-ryhmä, se ei saa jo vastaanottaa liikennettä reitiltä eikä se saa käyttää evästepohjaista istuntosidontaa — eväste on HTTP-otsake, jota yhdyskäytävä ei voi asettaa kerroksella 4.
Kaikki muu suojauksessa pätee muuttumattomana. Lähdeosoitesäännöt, maaestot, nopeusrajat, yhteyskatot ja kuntotarkistukset toimivat samalla tavalla kuin HTTPS-kuuntelijalla:
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 2000Juuri siksi kannattaa valita sovellusyhdyskäytävä kuormantasaajan sijaan palvelulle, joka ei ole HTTP: saat silti yhden osoitteen, yhden paikan jossa säännöt asuvat, ja yhden asian auditoitavaksi.
TCP-kuuntelijalla rajat laskevat YHTEYKSIÄ, eivät pyyntöjä
HTTP:ssä ja HTTPS:ssä --rate-limit-rps ja --rate-limit-burst laskevat pyyntöjä. Kerroksella 4 ei ole pyyntöä laskettavaksi, joten ne laskevat yhteyksiä.
Kun yksi yhteys kantaa koko istunnon — SMTP, IMAP, MQTT — sama luku on paljon tiukempi raja kuin se olisi verkkokuuntelijalle. HTTPS-kuuntelijalta kopioitu luku kuristaa sähköpostipalvelimen useita kertaluokkia. Aseta se todella odottamiesi yhteyksien mukaan.
Porttialueet
TCP-kuuntelija voi sitoa yhden portin sijaan alueen:
fm appgw listener create --gateway <gw-id> --name ftp-data \
--protocol tcp --port 30000 --port-range-end 30099 \
--backend-pool <pool-id>Alue on inklusiivinen, sen on noustava --port-arvosta ylöspäin ja se voi kattaa enintään 512 porttia. Jokainen yhteys välitetään samaan porttiin taustapalvelussasi, johon asiakas yhdisti — 30000-30099 tavoittaa 30000-30099 palvelimillasi. Juuri se saa passiivisen FTP:n data-alueen tai palvelukohtaisten porttien lohkon ylipäätään toimimaan.
Tästä seuraa kaksi asiaa:
- Alueellisen kuuntelijan takana olevan ryhmän on annettava kuntotarkistukselleen oma portti. Sen taustapalveluihin otetaan yhteys siihen porttiin, johon kukin asiakas saapui, joten muuten luotauksella ei ole mitään mihin soittaa. Katso Terveystarkistukset.
- Kaksi kuuntelijaa samassa yhdyskäytävässä eivät saa mennä päällekkäin porttiavaruudessa. Toinen kuuntelija, joka vaatii minkä tahansa portin jonka olemassa oleva sitoo, hylätään riippumatta siitä onko törmäys kahden yksittäisen portin vai kahden alueen välillä.
Muutamat portit ovat laitteiston omia ja ne hylätään kaikilla protokollilla. Jos alue hylätään siitä syystä, viesti nimeää portin — siirrä aluetta tai jaa se kahteen sen ympäriltä.
Kuuntelijan poistaminen sulkee sen portin välittömästi
Kuuntelijan luominen avaa sen portin yhdyskäytävän julkisessa sisääntulossa, ja poistaminen sulkee sen — kumpikin odottamatta käyttöönottoa. Elävän TCP-palvelun korvaaminen poistamalla kuuntelija ja luomalla uusi menettää siis liikennettä kahden kutsun välisen aukon ajan. Luo korvaaja ensin, kun voit, ja kun haluat muuttaa sen takana olevan ryhmän asetusta: päivitä ryhmä sen sijaan että rakentaisit kumpaakaan uudelleen.
Kuuntelijan suojaaminen
Nämä koskevat jokaista kuuntelijan pyyntöä, ennen reititystä:
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 on sidottu kokoosi: kuuntelija, joka pyytää enemmän kuin koolle on ilmoitettu, nostaa laitteen oman rajan samaan arvoon — se kuormittaa laitetta eikä tuo lisää kapasiteettia. Tarkista arvo komennolla fm appgw flavors.
--allowed-cidr ja --denied-cidr ovat toistettavissa. --geo-block-mode on off, allow (vain nämä maat) tai deny (kaikki paitsi nämä), ISO-maakoodeilla.
Taustapalveluryhmät ja taustapalvelut
Ryhmä on joukko taustapalveluita, joille yhdyskäytävä välittää liikennettä, sekä se, miten se valitsee niiden välillä ja miten se puhuu niille.
fm appgw pool create --gateway <gw-id> --name app-pool \
--protocol http --algorithm round_robin \
--timeout-connect-ms 2000 --timeout-response-ms 30000--algorithm on round_robin, least_connections tai source_ip. Istuntojen sitomiseen käytä --session-affinity cookie --session-cookie <nimi> tai --session-affinity source_ip.
Salataksesi liikenteen uudelleen matkalla sovellukseesi tee ryhmästä https ja kerro, miten taustapalvelun varmenne tarkistetaan:
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.internalPROXY-protokolla — taustapalveluillesi kerrotaan kuka soittaa
TCP-kuuntelijan takana oleva taustapalvelu näkee asiakkaana yhdyskäytävän osoitteen, ei todellista. Sähköpostipalvelimelle se on lähes kohtalokasta: roskapostipisteytys, nopeusrajoitus, greylisting ja väärinkäyttölokit lasketaan kaikki yhtä ainoaa osoitetta vastaan — meidän. X-Forwarded-For ei auta, koska se on HTTP-otsake eikä TCP-kuuntelija kanna HTTP:tä.
PROXY-protokolla asettaa todellisen asiakasosoitteen jokaisen yhteyden eteen:
fm appgw pool create --gateway <gw-id> --name mail-pool \
--protocol http --proxy-protocolMääritä ENSIN taustapalvelu lukemaan otsake
Tämän käyttöön ottaminen muuttaa taustapalvelusi vastaanottamia tavuja. Palvelin, joka ei odota otsaketta, lukee sen protokollasi ensimmäisinä tavuina, ja jokainen yhteys epäonnistuu.
Järjestyksellä on väliä molempiin suuntiin:
- Määritä taustapalvelu hyväksymään PROXY-protokolla yhdyskäytävältä — Postfixissa se on
smtpd_upstream_proxy_protocol, nginxissäproxy_protocollisten-rivillä, Dovecotissa asetus joka nimeää mitkä ylävirran lähteet saavat sen lähettää. - Ota se käyttöön täällä.
- Ota yhdyskäytävän kokoonpano käyttöön.
Sen poistaminen käytöstä on sama muutos päinvastaisessa järjestyksessä: poista asetus yhdyskäytävältä ja ota kokoonpano käyttöön, lopeta vasta sitten otsakkeen odottaminen taustapalvelussa.
Se on oletuksena pois päältä ja pysyy siellä, kunnes pyydät sitä.
Ryhmän muuttaminen ilman uudelleenrakentamista
Kaikkea ryhmässä nimeä lukuun ottamatta voi muuttaa paikallaan:
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 60000Asetus, jota et nimeä, jätetään rauhaan, ja muutos tulee voimaan seuraavassa käyttöönotossa kuten kaikki muukin yhdyskäytävän kokoonpano.
Näin PROXY-protokolla otetaan käyttöön jo olemassa olevalle ryhmälle. Ilman sitä ainoa tie olisi poistaa ryhmä — mikä tarkoittaa ensin sitä pitävän TCP-kuuntelijan poistamista ja sen julkisen portin sulkemista samalla hetkellä — ja rakentaa molemmat uudelleen: katkos yhden asetuksen muuttamiseksi, jonka koko tarkoitus on tulla muutetuksi kun taustapalvelu on oppinut lukemaan otsakkeen.
Kaksi muutosta hylätään niin kauan kuin TCP-kuuntelija välittää ryhmään, samoista syistä kuin ne hylätään kyseistä kuuntelijaa luotaessa: cookie-istuntosidonta on HTTP-eväste, jota yhdyskäytävä ei voi asettaa kerroksella 4, ja https ryhmän protokollana salaisi uudelleen tavut, jotka ovat jo sitä mitä asiakas lähetti.
Taustapalvelut nimetään yhdyskäytävän VPC:n sisäisellä IP-osoitteella ja portilla:
fm appgw backend add --gateway <gw-id> --pool <pool-id> \
--address 10.0.1.10 --port 8080 --weight 1Yhdyskäytävän oman VPC:n ulkopuolinen osoite hylätään. Tämä on tarkoituksellista: ilman sitä yhdyskäytävä välittäisi liikennettä minne tahansa osoittaisit.
Terveystarkistukset
Ryhmä ilman terveystarkistusta lähettää liikennettä taustapalveluille, jotka ovat alhaalla.
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 on oltava lyhyempi kuin --interval.
--protocol tcp avaa yhteyden porttiin ja sulkee sen taas. Se ei lähetä pyyntöä eikä vertaa mitään tilaa, joten --path ja --expected-status eivät päde ja ne hylätään siinä. Käytä sitä kaikkeen, joka ei vastaa HTTP:llä.
health-check set KORVAA tarkistuksen — se ei yhdisty siihen
Komento ilmaisee koko tarkistuksen. Asetus, jonka jätät pois, ei jää ennalleen: se palaa alustan oletukseen. --port palaa luotaamaan kunkin taustapalvelun omaa porttia, ja --proxy-protocol palaa pois päältä.
Yhden luvun hienosäätö tarkoittaa siis muiden ilmaisemista uudelleen. Tarkistus, joka luotaa porttia 8080 PROXY-protokolla päällä ja asetetaan uudelleen pelkillä --protocol-, --path- ja --interval-valitsimilla, menettää hiljaisesti molemmat — ja luotaus, joka lakkaa lähettämästä otsaketta sitä vaativaan porttiin, epäonnistuu joka kerta ja merkitsee ryhmän jokaisen taustapalvelun sairaaksi, vaikka taustapalvelut voivat hyvin. Katso PROXY-protokolla luotauksessa.
Lue tarkistus ensin komennolla fm appgw health-check get ja anna takaisin se, mitä siinä oli. Jos et halua tarkistusta lainkaan, käytä komentoa health-check delete etkä tyhjää set-komentoa.
Toisen portin luotaaminen
Oletuksena luotaus soittaa kunkin taustapalvelun omaan porttiin. --port lähettää sen muualle:
fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
--protocol http --path /healthz --port 8080Kaksi tapausta kaipaa tätä. Ensimmäinen on palvelu, jonka kuntopääte on muualla — sähköpostipalvelin joka vastaa SMTP:hen portissa 25 ja tarjoaa pienen HTTP-kuntopäätteen portissa 8080. Ilman sitä ainoa käytettävissä oleva luotaus on "avaa yhteys porttiin 25", jonka kuormitettu sähköpostipalvelin ottaa vastaan ja sitten lykkää, joten taustapalvelu näyttää terveeltä samalla kun se hylkää jokaisen viestin.
Toinen ei ole valinnainen: porttialueellisen TCP-kuuntelijan takana olevan ryhmän on asetettava --port. Sen taustapalveluihin otetaan yhteys siihen porttiin, johon kukin asiakas saapui, joten kiinteää porttia luotaukselle ei ole, ja tarkistus ilman porttia hylätään.
PROXY-protokolla luotauksessa
Ryhmä, joka lähettää PROXY-protokollan, voi antaa terveystarkistuksensa lähettää sen myös luotausyhteydellä:
fm appgw health-check set --gateway <gw-id> --pool <pool-id> \
--protocol http --path /healthz --port 8080 --proxy-protocolSe, haluatko sitä, riippuu siitä, mihin porttiin luotaus soittaa, ja vain sinä tiedät vastauksen. Luotausportti on olemassa juuri siksi, että se tavoittaa toisen palvelun kuin sen, joka kantaa liikennettä — sähköpostipalvelin joka vastaa SMTP:hen portissa 25 ja tarjoaa pienen HTTP-kuntopäätteen portissa 8080 — eikä tuollaisella kuntopäätteellä ole yleensä mitään syytä puhua PROXY-protokollaa. Tavallinen tapaus ei halua otsaketta.
Jos lähetät sen porttiin, joka ei sitä odota, portti lukee otsakkeen protokollasi ensimmäisinä tavuina. Luotaus epäonnistuu, ja epäonnistuva luotaus merkitsee ryhmän jokaisen taustapalvelun sairaaksi, vaikka taustapalvelut itse voivat hyvin — ryhmä palauttaa 503, vaikka palvelimet palvelevat moitteettomasti. Kuten muukin yhdyskäytävän kokoonpano, tämä tapahtuu seuraavassa käyttöönotossa, ei silloin kun asetat sen.
Pois päältä EI tarkoita, ettei luotaus lähetä otsaketta
Luotaus ilman omaa --port-valitsinta soittaa kunkin taustapalvelun omaan osoitteeseen ja porttiin, joten se perii ryhmän yhteysasetukset — PROXY-protokollan niiden joukossa. Tällainen luotaus kantaa otsaketta jo silloin, kun ryhmän oma PROXY-protokolla on päällä, tämän asetuksen ollessa pois päältä.
Luotausportin nimeäminen --port-valitsimella jättää nuo asetukset pois ja vie otsakkeen mukanaan. Tällä asetuksella panet sen takaisin.
fm appgw health-check get näyttää nämä kaksi yhdessä juuri siksi: ilman luotausporttia rivi PROXY protocol on probe lukee no (the probe follows the pool's setting) eikä pelkkää ei-vastausta.
Ryhmän oman PROXY-protokollan on oltava päällä ensin. Sen käyttöön ottaminen luotaukselle ryhmässä, joka ei lähetä otsaketta, hylätään — lähetettävää otsaketta ei ole. Myös päinvastainen hylätään: ryhmän asetuksen poistaminen hylätään niin kauan kuin luotaus yhä lähettää otsakkeen. Järjestys on ryhmä päälle, sitten luotaus, ja luotaus pois, sitten ryhmä.
Sen ottaminen käyttöön silloin, kun luotauksella ei ole omaa porttia, hyväksytään ja tallennetaan eikä muuta mitään — tuo luotaus perii jo ryhmän asetuksen. Se alkaa merkitä jotakin sillä hetkellä, kun luotaus nimeää portin.
Portaalissa se on kytkin ryhmän terveystarkistuspaneelissa. Terraformissa se on proxy_protocol resurssissa frostmoln_appgw_health_check, ja yllä kuvatulla järjestyksellä on siellä vielä yksi seuraus: yksi ainoa terraform apply, joka poistaa käytöstä sekä tämän että ryhmän asetuksen, epäonnistuu ryhmän kohdalla, koska Terraform päivittää ryhmän ennen siihen viittaavaa tarkistusta. Poista luotauksen asetus yhdessä käyttöönotossa ja ryhmän asetus myöhemmässä.
Kuntotarkistuksen poistaminen
fm appgw health-check delete --gateway <gw-id> --pool <pool-id>Seuraavasta käyttöönotosta alkaen yhdyskäytävä lakkaa luotaamasta tätä ryhmää ja käsittelee jokaista käytössä olevaa taustapalvelua saatavilla olevana.
Se on oikea vastaus, kun taustapalvelut päättävät itse saatavuutensa — valvottu palvelu tai sellainen, joka on oman kuormantasaajansa takana — ja yhdyskäytävän luotaus vain lisäisi toisen mielipiteen. Kaikessa muussa: pidä tarkistus. Ilman sitä vastaamasta lakannut taustapalvelu saa yhä osuutensa liikenteestä.
Mitä yhdyskäytävä on havainnut
fm appgw backend list ja portaali näyttävät kumpikin tilan taustapalvelua kohden sekä ajan, jolloin se viimeksi havaittiin.
Taustapalveluiden kuntoa ei vielä raportoida
Tämän täyttävää raportointia rakennetaan yhä, joten jokainen taustapalvelu näkyy nyt tilassa ei havaittu riippumatta sen todellisesta tilasta. Se on väite meidän raportoinnistamme, ei palvelimistasi — havaitsematon taustapalvelu ei ole alustan tietämän mukaan terve eikä sairas, eikä liikennettä pidätetä siltä sen vuoksi. Tämä sivu kertoo, kun asia muuttuu.
Valtuuta jokainen taustapalvelu — tämä vaihe ei ole valinnainen
Taustapalvelun lisääminen kertoo yhdyskäytävälle, minne välittää liikenne. Se ei anna sille lupaa päästä sinne: taustapalveluidesi suojausryhmät päättävät siitä, eikä yhdyskäytävä kuulu niihin.
Valtuuta se nimenomaisesti:
fm appgw backend authorize --gateway <gw-id> --pool <pool-id> \
--backend <backend-id> --security-group <security-group-id>Tämä lisää yhden saapuvan liikenteen säännön sinun suojausryhmääsi, joka päästää yhdyskäytävän sisään kyseiseen porttiin. Mitään ei avata puolestasi — alusta ei muuta suojausryhmiäsi hiljaisesti.
Kaksi seurausta, jotka on hyvä tietää:
- Jos ohitat tämän, ensimmäinen yhdyskäytäväsi vastaa 503, koska yhteys taustapalveluun hylätään.
- Sääntö on jaettu. Se kirjoitetaan suojausryhmää, protokollaa ja porttia kohti, joten jokainen kyseisen ryhmän takana kyseisessä portissa oleva taustapalvelu on tavoitettavissa sen kautta — ja säännön peruuttaminen sulkee reitin niiltä kaikilta, ei vain nimeämältäsi.
fm appgw authorization list --gateway <gw-id>
fm appgw authorization revoke --gateway <gw-id> <authorization-id>Reitit — mikä palvelu vastaa
Reitti vastaa isäntänimeä ja polkua kuuntelijassa ja välittää pyynnön ryhmälle.
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 on prefix, exact tai regex. --host hyväksyy jokerimerkin (*.example.com).
Reitit arvioidaan prioriteetin mukaan, pienin ensin — nimenomaisena lukuna, ei koskaan arvattuna sen perusteella, miten tarkalta polku näyttää. Uusi reitti menee viimeiseksi, ellet toisin määrää. Järjestä uudelleen luomatta mitään uudestaan:
fm appgw route reorder --gateway <gw-id> --listener <listener-id> \
--route <route-id>=10 --route <other-route-id>=20Nimenomainen prioriteetti on juuri se, mikä estää yhtä uutta reittiä hiljaisesti muuttamasta sitä, minne olemassa oleva liikenne menee.
Reitti voi myös kirjoittaa pyynnön uudelleen ennen välittämistä:
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"Käyttöönotto — mikään ei ole tuotannossa ennen sitä
Kuuntelijat, reitit, ryhmät, taustapalvelut ja varmenteet ovat laadittuja. Ne tallennetaan heti kun kirjoitat ne, ja yhdyskäytävä jatkaa sen palvelemista, mitä sillä jo oli, kunnes otat ne käyttöön:
fm appgw apply <gateway-id>Yhdyskäytävä tarkistaa uuden kokoonpanon, vaihtaa siihen, lataa sen uudelleen ja tarkistaa itsensä ennen kuin raportoi takaisin. Jos jokin näistä epäonnistuu, se palauttaa sen, mitä se palveli ja kertoo miksi — rikkinäinen kokoonpano ei kaada sivustoasi kenellekään.
fm appgw get <gateway-id> näyttää, onko laatimasi se, mikä on ajossa. Portaali näyttää saman banderollina, ja molemmat toistavat laitteen omat sanat, kun käyttöönotto hylätään.
Käyttöönotto edellyttää, että yhdyskäytävä on running, ja vain yksi käyttöönotto on käynnissä kerrallaan.
Verkkosovelluspalomuuri
Jokainen sovellusyhdyskäytävä sisältää verkkosovelluspalomuurin ilman lisämaksua — erillistä tuotetta ei tarvitse ostaa eikä lisäosaa ottaa käyttöön. Säännöt laaditaan yhdyskäytäväkohtaisesti ylläpidetyn perustason päälle, jonka Frostmoln pitää ajan tasalla.
Ei vielä saatavilla
Sääntöjen laatiminen ei ole vielä avoinna asiakkaille. Tämä sivu dokumentoi sen, kun se on; mikään yhdyskäytäväsi kokoonpanossa ei muutu sillä välin.
Yhdyskäytävän poistaminen
fm appgw delete <gateway-id>Liikenne pysähtyy välittömästi. Se, säilyykö julkinen osoite, riippuu siitä, miten yhdyskäytävä sen sai: alustan varaama osoite vapautetaan, ja mukanasi tuoma osoite säilytetään ja palaa julkisiin IP-osoitteisiisi.
Laskutus
Sovellusyhdyskäytävä laskutetaan tunneittain kokonsa perusteella, kuten mikä tahansa muu hallittu instanssi, ja verkkosovelluspalomuuri sisältyy tähän hintaan. Jos yhdyskäytävän julkisen osoitteen varasi alusta, se laskutetaan julkisena IP-osoitteena erikseen ja vain kerran; jo omistamasi osoite on jo laskullasi eikä sitä laskuteta kahdesti.
Käytettävyys
Vakiomuotoinen sovellusyhdyskäytävä on yksi hallittu laite. Jos sen isäntä kaatuu, se rakennetaan uudelleen, mikä ei tapahdu hetkessä. Varaudu siihen kuten minkä tahansa yksittäisen instanssin kohdalla — ja jos lyhyt katkos on mahdoton hyväksyä liikenteelle, jonka eteen sen asetat, sano se ennen kuin viet tuotannon sen taakse.