A Docker konténerek önmagukban még nem alkalmasak arra, hogy egy teljes PaaS megoldást nyújtsanak. Egy PaaS teljeskörű és transzparens infrastruktúrán nyújtja az alkalmazásfuttatási platformot.
A következő problémákra kell még megoldás:
- A különböző konténerek összekapcsolása, management-je fapados, ha csak a Docker-re építkezünk.
- Nincs megoldva a skálázás(akár dinamikusan), failover, high-availability.
- Alkalmazás buildelési, deployálási folyamatok támogatása.
- Tenant/Project izoláció.
Ezekre a problémákra vannak létező megoldások, technológiák:
- Kubernetes, Docker Compose, Docker swarm - konténer menedzsment
- Alkalmazásfejlesztési módszertanok, eszközök: Git vagy más SCM, Jenkins,...
- Hálózati eszközök: Open vSwitch, Linux kernel technológiák
- Monitorozás: Hawkular
Az OpenShift az előbbi problémákra megoldást nyújt, ráépülve a Docker konténer technológiára és más bevált eszközökre.
- Project: adminisztratív izoláció, az egyes szállítók külön-külön egymástól izolálva dolgozhatnak. A Node-ot kivéve minden OpenShift entitás/resource Project scopeú.
- User: az OpenShift felhasználói, akik tevékenysége jogosultságkezeléssel korlátozható
- Container, Image, Registry: Az OpenShift a Docker-t használja konténer technológiaként ezért ezek pontosan a Docker foglamak.
- Pod: Egy vagy több konténer, közös tárterülettel, hálózattal. Telepítési, management egység.
- Node: Podokat futtató gép.
- Service: Egy belső hálózati portot reprezentál, amin -abstrakt módon- elérhetőek a mögé bekötött POD-ok ill. azok szolgáltatásai. Belső terhelés elosztóként működnek.
- Build, BuildConfig: Egy alkalmazás forráskódjából Docker image készül. Ez a folyamat a Build és ennek a paraméterezése a BuildConfig. Az OpenShift alapegységei YAML ill. JSON formátumban is leírhatók.
https://docs.openshift.org/latest/dev_guide/application_lifecycle/new_app.html
A következő módon lehet az OpenShift-en alkalmazásokat buildelni:
- Docker: ez gyakorlatilag a Dockerfile alapú buildelési folyamat
- S2I -Source to Image: a forráskód és egy Builder docker image alapján lefordítja, összeállítja a végterméket (itt is egy Docker image-et)
- Custom build - Teljesen customizált build folyamat, saját Builder image-el.
- Jenkins Pipeline build
A Buildeléshez is Docker containerek jönnek létre! Pl. a megadott forrást egy Java+Maven+Nexus -al konfigurált build container fordítja le.
BuildConfig
A buildelés konfigurációja, többek között leírja, hogy hol a forrás, mi a fordítás eredménye, milyen "stratégia" szerint fordítson, mi triggerelje a fordítást stb.
ImageStream
A fordítás eredménye egy Docker Image. Az egymást követő buildek láncolata egy ImageStream. Egy ilyen ImageStream egy nézetet biztosít egy vagy több Docker image-re a címkéken keresztül (pl. cimke a webszerveren, db-n,stb.)
A build folyamatokhoz a forrásainknak a nyelvi ill. technológiai standardeket követni kell, pl. Java buildeléshez kell lenni egy pom.xml-nek - Maven build. Ezen kívül a buildelési folyamat customizálható több ponton:
- Assemble script - az eredménytermék összecsomagolását lehet vele customizálni (pl. zipek, tarok, war-ok, stb.)
- Run script - Hogyan kell majd futtatni az előállt eredményterméket.
- Save-Artifacts - A build során használt csomagok, libek elmenthetők, hogy ne kelljen minden buildnél az összes - nem változott- függőséget letölteni.
DeploymentConfig
Leírja a telepítési folyamat részleteit.
- OpenShift dashboard GUI felület: https://bmepaas-master.openshift.local:8443
- oc CLI kliens
Jelenleg password nélkül be lehet lépni az előírt felhasználónevekkel. A CLI OAuth tokennel is használható.
oc help
oc CMD --help
oc types --OpenShift alap entitások leírása
oc login --belépés
oc new-app --új alkalmazás létrehozása
#stb. lsd. gyakorlati anyagokbanA következő hálózati problémákra ad megoldást az OpenShift
- Routing: hogyan érhetőek el kívülről az alkalmazásaink
- Összetartozó Docker containerek (Pod-ok) hogyan kommunikáljanak egymással
- Újrainduló Pod-ok változó IP címeinek lekövetése.
A fő problémát az jelenti, hogy a különböző Node-okon létrejövő Pod-okban futó alkalmazást, hogyan lehet kívülről elérni, használni. A Service fogalom egy hálózati végpontot reprezentál, ez kívülről még nem érhető el. A Service egy "stabil" hálózati port (nem egy belső docker által osztott port), amelyen elérhető akár több POD által is nyújtott szolgáltatás (loadbalancer).
Service
- A service nem kötődik konkrét POD-hoz(hiszen az dinamikusan változhat), hanem ún. selector-ral lehet POD-ok címkéire hivatkozni
- Egy POD egy másik POD-dal Service-en keresztül kommunikálhat egy projekten belül.
- A projekten belüli POD-ok konténereiben környezeti változók jönnek létre az egyes Service-ekhez: SVC_NAME_SERVICE_ADDRESS, _PORT
- Az OpenShift belső DNS megoldása alapján is feldoldhatóak a Service-ek host nevei: SVC_NAME.PROJECT_NAME.svc.cluster.local
A kívülről elérhetőség problémáját az OpenShift úgy oldja meg, hogy egy Router komponens segítségével biztosít belépést a külső hívóknak.
Az egyes Node-okra kerül egy Router, egy HAProxy, amely fogadja a hálózati forgalmat és megkeresi a megfelelő Service-ket, amelyek felé delegálnia kell. Pl. a :80 -as porton érkező forgalmat a Router a "frontend" címkével rendelkező Service-ek felé irányítja, ahonnan már a megfelelő Pod-ok elérhetőek.
A Kubernetes oldja meg, hogy egy Pod kap egy belső IP címet, mintha egy különálló Host gép lenne. Ezen a "virtualizált" hoston futnak a Docker containerek így azok képesek kommunikálni egymással. Pod-ok egymással nem (így) kommunikálnak. Pod-ok más Pod-okkal Service-en keresztül kommunikálhatnak.
- Open vSwitch alapú megoldás
- Az OpenShift a Pod-okat egy cluster network-be szervezni (etcd-ben regisztrált alhálózatok): 10.1.0.0/16
- Node-onként alhálózatok: 10.1.0.0/24, 10.1.1.0/24,... (256 db alhálózat)
- VNID használat multitenant megoldásoknál
A következő hálózati interfészeket hozza létre Node-onként:
- br0 - OVS bridge, a Pod-ok ehhez kapcsolódnak (veth párokkal)
- tun0 - OVS port a br0-n az external network felé, Pod-ok default gateway (IP tables, NAT)
- vovsbr - Docker containerek felé
- vxlan0 - Internet felé, Remote container hozzáférésekhez
- lbr0 - Docker Bridge, a Docker containerek ehhez kapcsolódnak (veth)
- vlinuxbr - Linux peer virtual Ethernet - Docker containerek eléréséhez
Pod indulása
- A Docker beköti a containert veth párral az lbr0-ba
- Az előbbi átkerül az OVS br0-ba
- OpenFlow route szabályok rögzítése az OVS DB-be
Példa hívási lánc:
- A és B konténer egy hoston van: A(eth0,vethA)-B(eth0,vethB) A->eth0->vethA->br0->vethB->eth0->B
- A és B konténer más hoston van: A(eth0,vethA)-B(eth0,vethB) A->eth0->vethA->br0->vxlan0->br0->vethB->eth0->B
- A és B konténer más hoston van, B pl. egy internetes cím: A(eth0,vethA) A->eth0->vethA->br0->tun0->...->eth0->B
Felelősek, hogy mindig a meghatározott számú Pod fusson. Pl. ha leáll egy, akkor indít újat, stb. Nem felelős azért, hogy mennyi is ez a Pod szám. Nem figyel forgalmat, terhelést, nem kalkulálja ki ezt a számot, csak végrehajt. Runtime is állítható, de redeployment esetén csak akkor lesz érvényes, ha DC szinten állítottuk be.
A Pod-ok erőforrás igényei alapján automatikus skálázás is lehetséges.
- A Pod-ok létrehozásakor meg lehet adni a szükséges resource szükségleteket (Requests).
- Előbbi alapján már kalkulálható, hogy a Pod hol jöjjön létre (scheduling)
- Limit-ek, felső korlátok is megadhatóak resource-onként Pod-okhoz (mennyi a becsült korlát)