3.7 Miten julkaisen sovellukseni internetiin?

Yleistä

TIKEn Openshift-klusterissa on kaksi kaikkien projektien kesken yhteistä ingressiä. Kaikki projektit ottavat asiakasliikenteen vastaan yhteisten, kellutettujen ip-osoitteiden kautta. Huomaa, että klusterista ulospäin suuntautuvat yhteydenotot eivät kierrä näiden ip-osoitteiden kautta, vaan ne tulevat suoraan klusterin virtuaalikoneiden omista ip-osoitteista.

Openshiftissä palvelut (Service) julkaistaan yhteiseen ingressiin luomalla Route-objekti. Projektin ylläpitäjä voi luoda routen ilman ylläpidon apua. Routessa määritellään DNS-nimi, joka on myös http(s)-palvelun hostname. Ingressi yhdistää liikenteen oikeaan routeen http-protokollan Host-otsakkeen avulla.

Versiosta 4.6 eteenpäin Openshift luo Ingress-objektien pohjalta Routeja: https://docs.openshift.com/container-platform/4.6/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration

Sekä testi- että tuotantoklusterissa on kaksi ingressiä. Näistä toisen (*.apps) ip-osoite on rajattu yliopiston sisä- ja eteisverkkoon, toinen (*.ext) taas on avattu ulkoverkkoon. Route-objektissa valitaan palvelulle jompikumpi ingress. Valinnan avulla päätetään myös, halutaanko palvelu julkaista koko internetille vai pelkästään yliopistolaisille.

Lyhyesti ja ytimekkäästi Olettaen että Route ja Service luotiin automaattisesti, ja sinulla ei ole custom hostnamea ja sen tuomaa säätöä.

Ulkoverkkoon julkaisu: Web-konsoli → Administrator perspective → Networking → Routes → "Klikkaa haluamaasi routea" → "Actions -> Edit Route"→ Tee muutokset -> Save -> Reload

Host on muotoa ("sovellus"-"kontti"."apps tai ext".ocp-"test tai prod"-0.k8s.it.helsinki.fi)

HUOM!! tässä kohtaa pitää muuttaa kohta apps-> ext

Jos Route ei anna muuttaa itseään, lataa se lokaalisti, tee muutokset lokaaliin tiedostoon, poista vanha Route, luo uusi Route->Edit YAML->Vedä tiedosto omalta koneelta ikkunaan ja tallenna muutokset.

Sertifikaatin lisäys

Lisää Routen YAML-tiedostoon allaolevat pätkät.

Sovelluksen url-osoite on nyt Routen tiedoissa olevassa linkissä. Löydät sen myös Dev-näkymä → Topology → Oikea deployment → Laatikon alalaidassa oleva url.

Tarkka ohjeistus

Huomautus yliopiston domainiin julkaisusta

Yliopiston digiviestintä (digiviestinta@helsinki.fi) hallinnoi .helsinki.fi -osoitteen suoria alidomaineja, eli kaikki osoitteet muotoa nimi.helsinki.fi täytyy hyväksyttää heillä. Jos haluat testiosoitteita, on suositeltavaa sijoittaa ne .it.helsinki.fi -alidomainin alle, eli nimi.helsinki.fi oikealle sivustolle ja nimi-test.it.helsinki.fi sivustosi testiversiolle.

Routen luominen

Jos lisäsit kontin Openshift consolesta (nettisivulta), kannattaa tarkastaa luotiinko Service ja Route automaattisesti.
Ennen routen luomista palvelulla täytyy olla service, sekä sen takana vähintään yksi pod vastaamassa pyyntöihin.

Komentoriviltä route luodaan oc expose -komennolla:

oc expose svc palvelunnimi --name routennimi -n projektinnimi

Yllä oleva komento luo routen, joka näkyy yliopiston sisäverkossa. Palvelu tarjottaisiin nyt: 

• vain sisä- ja eteisverkossa
• osoitteessa routennimi-palvelunnimi-projektinnimi.apps.klusterinnimi.k8s.it.helsinki.fi
• vain salaamattomana http:nä

Oletuksena route aukeaa konttialustan oletus-ingressiin, joka on saavutettavissa vain yliopiston sisä- ja eteisverkosta. Default-ingressin osoite on  *.apps.<klusterin-nimi>.k8s.it.helsinki.fi.

Palvelun avaaminen ulkoverkkoon

Jos palvelun on oltava avoin koko internetille, käytä Route-objektissa external-ingressiä. Sen osoite on *.ext.<klusterin-nimi>.k8s.it.helsinki.fi.

Lisää Route-objektiin label ja hostname alla olevan mukaisesti:

Sama Route esitettynä vaihtoehtoisesti oc expose -komennolla:

HY:n ulkopalomuuriin (pm-rekisteri) ei tarvitse, eikä pidä, tilata avauksia.

Palvelu voi tarvittaessa suodattaa asiakkaiden IP-osoitteita tarkemmin Route-objektin konfiguraatiolla ("haproxy.router.openshift.io/ip_whitelist") tai Forwarded-For-otsakkeen perusteella. (Tätä ei ole juuri testattu, joten varmistathan tarkasti, että toimii.)

Klusterin tarjoamat vakionimet

Routen yaml-määrityksessä kohta spec.host voi periaatteessa olla mitä tahansa. Kaikki routet palvellaan kuitenkin saman ip-osoitteen kautta, johon on määritetty wildcard-DNS muodossa *.(apps|ext).<klusterinnimi>.k8s.it.helsinki.fi.

Esimerkiksi:

• apps.ocp-prod-0.k8s.it.helsinki.fi

• ext.ocp-prod-0.k8s.it.helsinki.fi

ja

• apps.ocp-test-0.k8s.it.helsinki.fi

• ext.ocp-test-0.k8s.it.helsinki.fi

   

Projekti voi itse, ilman CNAME:n tai sertifikaattien lisäämistä, luoda palveluosoitteen. Tällöin palveluosoitteen on oltava muotoa, joka osuu johonkin ylläolevaan wildcardiin. Tällaisen palveluosoitteen voi myös suojata https:llä ilman oman sertifikaatin hakemista, ohjeet myöhemmässä kohden tätä sivua. URL-osoitteet muotoa palvelu.apps.ocp-prod-0.k8s.it.helsinki.fi voivat olla hyödyllisiä esim. API-gateway -palvelussa julkaistavien rajapintojen taustaosoitteina.

Huomaathan, että myös wildcardin alla oleva osa nimestä voi olla mitä tahansa! Aiemmassa esimerkissä oc expose -komennolla luotu "routennimi-palvelunnimi-projektinnimi" on pelkkä oletusmuoto. Kunhan nimi on jotain, mikä täsmää wildcardiin, route toimii. Jos nimi on jo käytössä, routen luominen epäonnistuu.

• Varoitus: on teknisesti mahdollista luoda route, joka nimen tasolla esittää toisen projektin routea! Tiken OpenShift-ympäristössä toiseen projektiin viittaavan nimen käyttäminen routen hostnamessa on kiellettyä.

Jos haluat palvelullesi paremman URL-osoitteen, lue eteenpäin.

Oman palveluosoitteen käyttäminen

Voit vaihtaa palvelusi osoitteen mihin tahansa DNS-nimeen, jonka CNAME osoittaa mihin tahansa sellaiseen nimeen, joka osuu wildcardiin *.(apps|ext).klusterinnimi.k8s.it.helsinki.fi. Tällaiselle nimelle tarvitset oman TLS-varmenteen, ja varmenne täytyy asettaa mukaan Route-määritykseen. Tästä lisää alempana.

Esimerkiksi host.apps toimii:

• Julkiseen internetiin tarjottava palvelu:
  • Tuotanto: palvelunimi.helsinki.fi → host.ext.ocp-prod-0.k8s.it.helsinki.fi
  • Testi: palvelunimi-testi.it.helsinki.fi → host.ext.ocp-test-0.8s.it.helsinki.fi
• Sisä- ja eteisverkkoon tarjottava palvelu:
  • Tuotanto: palvelunimi.helsinki.fi → host.ext.ocp-prod-0.k8s.it.helsinki.fi
  • Testi: palvelunimi-testi.it.helsinki.fi → host.apps.ocp-test-0.8s.it.helsinki.fi

Esimerkki CNAME-palveluosoitteesta

Julkaistaan projektista neljä eri routea:

• tuotantoversio tuotantoklusterissa julkiseen internetiin nimellä tahtitaivas.helsinki.fi, 
• staging-versio tuotantoklusterissa sisä- ja eteisverkkoon nimellä tahtitaivas-stage.it.helsinki.fi, 
• development-versio sisä- ja eteisverkkoon testiklusterissa nimellä tahtitaivas-dev.it.helsinki.fi ja
• testiversio sisä- ja eteisverkkoon testiklusterissa nimellä tahtitaivas-test.it.helsinki.fi.

1. Varmista, että olet onnistuneesti luonut oikeisiin klustereihin routet, joiden spec.host määrittää haluamasi palvelunimen kokonaisuudessaan.
   1. Tuotantoklusterissa routet:
      1. hostname: tahtitaivas.helsinki.fi
         ingress: external
      2. hostname: tahtitaivas-stage.it.helsinki.fi
         ingress: default
   2. Testiklusterissa routet:
      1. hostname: tahtitaivas-dev.it.helsinki.fi
         ingress: default
      2. hostname: tahtitaivas-test.it.helsinki.fi
         ingress: default
2. Valitse yksi allaolevista reiteistä (suositusjärjestyksessä):
   1. Jos voit käyttää IP-Reg-järjestelmää, tee CNAME itsepalveluna siellä.
   2. Jos sinulla ei ole pääsyä IP-Reg -järjestelmään, lähetä vapaamuotoinen sähköposti osoitteeseen atk-verkko@helsinki.fi. Pyydä seuraavanlaiset CNAMEt:
      - tahtitaivas.helsinki.fi →  host.ext.ocp-prod-0.k8s.it.helsinki.fi,
      - tahtitaivas-stage.it.helsinki.fi → host.apps.ocp-prod-0.k8s.it.helsinki.fi
      - tahtitaivas-dev.it.helsinki.fi → host.apps.ocp-test-0.k8s.it.helsinki.fi ja
      - tahtitaivas-test.it.helsinki.fi →  host.apps.ocp-test-0.k8s.it.helsinki.fi
   3. Pyydä konttialustan ylläpitoa järjestämään CNAMEt. Ota yhteyttä osoitteeseen grp-openshift-owner@helsinki.fi.
3.  Valmis!

Route ja HTTPS

Oletusmuotoista osoitetta käyttäenOletuksena routet saavat alidomainin muotoa routennimi-palvelunnimi-projektinnimi.(apps|ext).klusterinnimi.k8s.it.helsinki.fi 

Ingressien wildcard-domaineilla on asennettu julkisesti luotettu sertifikaatti. Saat routen suojaamaan liikenteen tällä sertifikaatilla siten, että lisäät Route-objektin määritykseen seuraavanlaisen kohdan:

tai komennolla:

HUOM! Varmenne saattaa mennä läpi, mutta ei näy oikein jos sivu on välimuistissa. Kokeile incognito-tilaa tai toista laitetta jos haluat varmistua asiasta.

Omaa palveluosoitetta käyttäen

Jos haluat käyttää omaa, erillistä palveluosoitettasi, määritä se Route-objektissa, luo asianmukainen CNAME kuten edellä. Hanki tämän lisäksi palveluosoitteellesi oma varmenne (esim. pyytämällä osoitteesta ca@helsinki.fi) ja sisällytä sertifikaattiketju avaimineen Route-objektin spec.tls-osioon.

Tarkemmat ohjeet täällä: https://docs.openshift.com/container-platform/4.13/networking/routes/secured-routes.html

Varmennepyynnön tilaaminen

• Varmista että CNAME-ohjaukset on pyydetty yllä olevien ohjeiden mukaisesti.
• Asenna koneellesi OpenSSL
• Kirjaudu terminaalilla siihen Openshiftin puoleen kummalle haluat sertifikaatin. Ohje
• Jos haluat varmenteen sekä testi- että tuotantopuolelle, lähetä sähköposti erikseen kummastakin tai liitä sähköpostiin selkeästi nimetyissä kansioissa req.pem tiedostot. Varmenne ei mene läpi, jos tiedostot sekoittuvat.
• Suorita komento

• Toimita varmennepyyntö (req.pem) osoitteeseen ca@helsinki.fi. HUOM! Älä jaa key.pem tiedostoa kenellekkään.
• Kun saat sähköpostilla vastauksen joka sisältää kaikki varmenne tiedostot, tallenna tiedostot esim. pilveen. Voit tarvita niitä vielä uudestaan.

Tarkemmat ohjeet löytyvät tästä PDF-tiedostosta:Varmennepyynto_ja_varmenteen_tilaus_Helsingin_yliopistolla_v01.pdf

Sen jälkeen sijoita kontin joka palvelee yllä-olevaa verkko-osoitetta Route tiedostoon seuraavat rivit (sisennykset pitää korjata ohjeen mukaisiksi).

Esimerkki-Route käyttäen omaa palvelunimeä ja varmennetta:

Jos jossain tiedostossa on useampi kuin yksi sertifikaatti, lisää ne peräkkäin siten, että jokaisella on omat begin ja end certificate rivit.

Sertifikaattia ei ole pakko upottaa YAMLiin jos käytät nginxiä reverse-proxyna. 

Ei toimi vieläkään! Väittää ettei ole podeja tai serviceä

Tarkista seuraavat asiat:

1. Pod oikeasti toimii. Ota port-forward suoraan podin palvelevaan porttiin:
   1. oc port-forward <podin-nimi> <paikallinen-portti>:<podin-portti>
   2. sekä toisessa terminaalissa: curl localhost:<paikallinen-portti>
2. Servicelläsi on endpointit oikein. Mahdollisesti Service-objektin selectorLabel-valitsimet eivät täsmää oikeisiin podeihin. Komennon "oc get endpoints" pitäisi listata servicet ja niiden endpointit. Vähintään yksi endpoint mallia 10.12.*:<podin-portti> pitää olla.

Automaattisesti uusiutuvat sertifikaatit

HUOM! Tämä on tulossa oleva palvelu (varmaankin syksyllä 2024), ohjeet luotu etukäteen.

Kaikkiin klustereihin on asennettu cert-manager -operaattorista Red Hatin tukema versio. Cert-managerista lisätietoja löytyy sen omilta sivuilta. Jos palvelusi URL on muotoa palveluni.helsinki.fi, voit pyytää sille konttiylläpidolta ACME-tunnuksen ja CNAMEn rekisteröinnin kun olet ensin hakenut domainille hyväksynnän viestinnältä (digiviestinta@helsinki.fi). Osoitteen palveluni.web.helsinki.fi voit pyytää suoraan konttiylläpidolta. Jos käytät helsinki.fi:n ulkopuolista domainia, esim palveluni.fi, pitää sinun itse hoitaa DNS-muutokset ja sertifikaatit esimerkiksi Let's Encrypt -palvelua käyttäen. Tähän tulee ohjeet myöhemmin. 

Cert-manager -operaattori

Palveluissa joiden url loppuu .helsinki.fi konttiylläpito luo sinulle Sectigon portaaliin domainin ja ACME-tunnuksen. Jos haluat nimet palveluni-test.web.helsinki.fi ja palveluni.helsinki.fi, joista toinen viittaa Tiken testiklusteriin ja toinen tuotantoon, luodaan sinulle yksi ACME-tunnus testiä varten ja yksi tuotantoon. Tuotantonimien ohjaaminen testiklusteriin ei ole sallittu pysyväisratkaisuna. Useampi nimi voidaan luvittaa yhdelle ACME-tunnukselle, eli jos sinulla on useampi palvelu jotka toimivat samasta namespacesta, voidaan sinulle luoda monta sertifikaattia yhdellä Issuer-objektilla.

Klusteriin konttiylläpidon toimesta luotavat objektit ja niiden merkitykset.

• SealedSecret = Klusteri/namespace comboa vasten salattu Secret objekti, joka valutetaan käyttäjien namespaceen Gitopsilla. Tämä luo "acme-key-XXXX" nimisen Secretin
• Secret = Secret objekti joka sisältää ACME-tunnuksen HMAC-key tiedon. Tieto löytyy muuttujasta eab-hmac-key. Namespace kohtainen tunnus
• Issuer = Objekti jossa määritellään sertifikaattien myyjään yhdistäminen
• Certificate = Objekti hakee pyydetyille domaineille sertifikaatit käyttäen Issueria.

Käyttäjän tehtäväksi jää luoda Ingress-objekti (josta OpenShift automaattisesti luo Routen), koska cert-manager ei tällä hetkellä tue Routejen käyttämistä. Jos Ingressin haluaa näkyvän julkimaailmaan, pitää siihen lisätä

HUOM! DNS ohjaukset pitää määritellä kuten ylhäällä kohdassa "Oman palveluosoitteen käyttäminen".

Jos olet luonut Routen, niin kohta "paths:" pitäisi löytyä Routen tiedoista. Cert-managerin dokumentaatio on pääasiassa hyvää, mutta selkeyden vuoksi lisätään vielä Issuer ja Certificate esimerkit.