Tiken konttialusta - UKK

Last modified by Tomas Terälä on 2024/03/28 12:15

 

Kysymys

Vastaus

Tilaanko jokaiselle applikaatiolle oman projektin? Vai esim. tiimille yksi projekti?

Mieluummin yksi projekti per applikaatio. Jos se koetaan tarpeelliseksi, voi myös tilata tiimille yhteisen kokeiluprojektin. Omaa testailua varten voi käyttää myös Codeready Containersia, joka on omalla koneella toimiva yhden virtuaalikoneen kokoinen hiukan karsittu openshift.

Mikä on konttialustan osoite?

Etusivulla Tiken konttialusta "Openshift console ja cli"

Millainen Dockerfilen tulee olla?

Mahdollisuuksien mukaan on hyvä käyttää red hat universal base imagejen päälle tehtyjä kontteja. Lisäksi kannattaa käyttää Multi-stage dockerfilejä jolloin ajettavan kontin saa pidettyä mahdollisimman pienenä.

Kannattaa huomata, että vaikka Dockerfilessä ei määrittäisi itse USERia, OpenShift pakottaa kontin sisällä pyörivän sovelluksen normaaliksi käyttäjäksi myös kontin sisällä. Automatiikka tekee tämän puolestasi. Tällä voi olla vaikutuksia sovelluksesi toimintaan. Testaus/kehitysmielessä on suositeltavaa käyttää USER-määritystä jolloin saat ainakin osan näistä ongelmista taklattua jo varhaisessa vaiheessa.

Esimerkkejä: Esimerkkisovelluksia Dockerfileillä

Lisäohjeita: 3.4 Konttiprosessien UID:t OpenShiftissä

Miten Openshift saa yhteyden GitLabiin?

  • Gitlab → Openshift:
    • Yliopiston gitlab, version.helsinki.fi, on samassa sisäverkossa kuin Openshift-klusteri. Webhookit yliopiston Gitlabista tulisi siis toimia suoraan.
  • Openshift → Gitlab:
    • Yhteyttä ei ole rajoitettu. Jos käytät Buildeja/Buildconfigeja hakeaksesi gitlabista, joudut mahdollisesti määrittelemään ssh-avaimet jolle annetaan lukuoikeus gitlabissa ja syöttämään privaattipuolen avaimesta projektiisi salaisuutena.
  • Lisätietoa: 3.4 Git - OpenShift

Miten Openshift saa yhteyden GitHubiin?

  • Github → Openshift:
    • Githubin webhookit eivät tällä hetkellä toimi koska webhookit vaatisivat api-portin avaamista julkiseen internetiin / githubin ip-osoitteisiin. Asia on harkinnassa.
  • Openshift → Github:
    • Yhteyttä ei ole rajoitettu. Jos käytät Buildeja/Buildconfigeja hakeaksesi githubista, joudut mahdollisesti määrittelemään ssh-avaimet jolle annetaan lukuoikeus githubissa ja syöttämään privaattipuolen avaimesta projektiisi salaisuutena.

Saako tietokantoja ajaa konteissa?

Mielellään ei. Tässä otettava huomioon monia asioita mm. tietokannan on toivuttava klusterien päivityksestä. Tikessä on keskitetty tietokantapalvelu, josta saa replikoituja ja ylläpidettyjä tietokantoja. Näitä suositellaan käytettäväksi. Tietokantapalvelu tarjoaa SQL-kantoja (Postresql). Jos keskitetty tietokanta ei jostain syystä käy, niin silloin voi harkita esimerkiksi kontissa ajettavaa dokumenttikantaa. Konttialustan ylläpito ei vastaa tietokantojen varmuuskopioinneista, vikasietoisuudesta jne. 

Kubernetes-alustan projektikohtaiset konfiguraatiot ja niiden versiointi. Onko tarpeen versioida projekti- eli sovelluskohtaisesti Kubernetes-konfiguraatiot?

On.

Käytännössä haluat pitää jokaisen sovelluksen ja projektin toisistaan riippumattomana kokonaisuutena, vaikka konfiguraatiot toistuisivatkin melkein samanlaisina.

Toisteisuutta saman sovelluksen eri versioiden välillä voi vähentää esim. Helm-templateja käyttämällä.

Lähtökohtaisesti kaikki mitä tarvitaan toimivan sovelluskokonaisuuden käynnistämiseen, pitäisi olla versionhallinnassa max. ~3 komennon päässä tuotannosta. Paitsi tietysti salaisuudet kuten tokenit, salasanat, jne., ja niidenkin syöttäminen sopivilla nimillään projektiin tulisi olla dokumentoitu ja mieluusti skriptattu. 

Onko tarpeen määritellä sovelluskohtaisesti Kubernetes-konfiguraatioita?

On. Jokaisella sovelluksella on omat kubernetes-manifestinsa ja niiden mahdollinen jakaminen sovellusten välillä tapahtuu klusterin ulkopuolella esim. helm templateissa.

Pitäisikö appien deploy yml-tiedostot ottaa talteen, esim versionhallintaan? Suositaanko mielummin kälin kautta tehtävää deployta, vai CLI:n + yml-tiedostojen kautta tehtävää?

Yaml-tiedostot tulee viedä versionhallintaan. Softan voi ensin deployata käyttöliittymästä ja ottaa yaml-tiedostot sen jälkeen talteen versionhallintaan. Pullaamalla yamlit paikallisesti, voisi kontit deployata muokkaamalla yamleja ja käskyttämällä CLI:tä. Yamlien avulla softan saa pystyyn yhdellä komennolla ja konfiguraatio on versionhallinnassa tallessa.

 

Miten saan sovelluksen SSO:n taakse ("Shibboloin") OpenShiftissä? 

  • Ratkaisu on rakentaa kontti jossa pyörii konfiguroitu apache httpd joka välittää parametrit http-otsakkeissa sovellukselle joka toimii omassa kontissaan. Edelleen teet sp-rekisteriin itse sovelluksesi rekisteröinnin ym. asiat. Tarkemmat lisätiedot löytää Autentikonnin ohjeista: Shibboleth (SAML2 / OIDC) 
  • Esimerkkiratkaisu tarjolla: https://github.com/UniversityofHelsinki/shibboleth-sp-openshift
  • Joudut luultavasti tekemään jonkinlaisia sticky-session määrityksiä, jotta tietty kirjautunut käyttäjä palvellaan aina samalla kontilla. Lisäksi käyttäjän selain saattaa välillä (kontin migratoinnin eli tuhoamisen ja uudelleenluonnin yhteydessä) kiertää login.helsinki.fi:ssä saamassa uuden kirjautumisen sovellukseesi.

Missä ip-osoitteissa kontit pyörivät, jos haluan avata oman virtuaalikoneeni palomuurin konttiklusterilta tulevalle liikenteelle?

Konttiklusterien virtuaalikoneet elävät seuraavissa verkoissa ja näiden sisältämistä ip-osoitteista konttien yhteydenotot näyttävät ulkoapäin tulevan:

  • Testi (ocp-test-0) : 128.214.137.128/27
  • Tuotanto (ocp-prod-0) : 128.214.137.0/25

Miten varmistan, että Deploymentin podit hajautetaan eri virtuaalikoneille?

Pod Anti-affinityillä:
https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#more-practical-use-cases

Ylläolevassa linkissä olevaa matchExpressionia voi hiukan lyhentää käyttämällä matchLabelia: 
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements

 

Esimerkki
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: frontend           <=========== Tämän label sijoittuu kaikkiin podeihin
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - topologyKey: kubernetes.io/hostname   <========= hostnamen topologiassa
            labelSelector:
              matchLabels:                        <========= mätsätään labeleita (key-value -pareja)
                app: frontend                     <========= .... jotka määritellään samoiksi mitä template
                                                              metadata.labelsissa annettiin tämän Deploymentin podeille
       ....

 

Miten rajaan palveluni niin, että siihen pääsee vain tietyistä IP-osoitteista?

Aseta palvelusi routeen annotaatio avaimella 

haproxy.router.openshift.io/ip_whitelist

 ja arvolla, joka sisältää whitespace-erotellun luettelon sallituista IP-osoitteista. Lisätietoja täällä.
 

Mistä tiedän mikä versio esim. ohjelmointikielestä pyörii kontissa? Entä mitkä kaikki paketit konttiin on asennettu?

Mene podin sivulle ja valitse Terminal ja kirjoita komentoriville:

# tietyn ohjelman versio
<ohjelma> --version

# kaikki paketit
ls /usr/bin/

 

Hyödyllisiä työkaluja:

https://github.com/Azure/draft/