OpenShift áttekintés

A Docker konténerek önmagukban még nem alkalmasak arra, hogy egy teljes PaaS megoldást nyújtsanak.

A következő problémákra kell még megoldás:

Ezekre a problémákra vannak létező megoldások, technológiák:

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 elsősorban a Kubernetes-re.

OpenShift OKD

OKD = The Origin Community Distribution of Kubernetes

OpenShift történelem

OpenShift jövő

OpenShift vs Kubernetes

Alapfogalmak

OpenShift Architektúra

openshift_arch2 openshift_arch4 openshift_arch6

Alkalmazásfejlesztés

s2i_2

Build folyamat

https://docs.openshift.org/latest/dev_guide/application_lifecycle/new_app.html

A következő módon lehet az OpenShift-en alkalmazásokat buildelni:

  1. Docker: ez gyakorlatilag a Dockerfile alapú buildelési folyamat
  2. 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)
  3. Custom build - Teljesen customizált build folyamat, saját Builder image-el.
  4. 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.

openshift_arch5

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.)

Forrás konvenciók

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:

  1. Assemble script - az eredménytermék összecsomagolását lehet vele customizálni (pl. zipek, tarok, war-ok, stb.)
  2. Run script - Hogyan kell majd futtatni az előállt eredményterméket.
  3. 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.

Telepítési folyamat

appflow1 appflow

DeploymentConfig

Leírja a telepítési folyamat részleteit.

OpenShift adminisztráció

  1. OpenShift dashboard GUI felület: https://127.0.0.1:8443 (oc cluster up után)
  2. oc CLI kliens

Authentikáció és Authorizáció

Jelenleg password nélkül be lehet lépni az előírt felhasználónevekkel. A CLI OAuth tokennel is használható.

Legfontosabb CLI parancsok

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 anyagokban

OpenShift skálázási lehetőségek

scaling

Replication Controller-ek

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.

Autoscaling

A Pod-ok erőforrás igényei alapján automatikus skálázás is lehetséges.

https://www.youtube.com/watch?v=lk1IXYOs3WM

OpenShift hálózati kommunikáció

A következő hálózati problémákra ad megoldást az OpenShift

Illusztrált Kubernetes networking: https://sookocheff.com/post/kubernetes/understanding-kubernetes-networking-model/

networking

Routing

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 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.

Docker containerek közötti kommunikáció

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.

OpenShift SDN

https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/sdn.html#architecture-additional-concepts-sdn

A következő hálózati interfészeket hozza létre Node-onként:

  1. 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
  2. lbr0 - Docker Bridge, a Docker containerek ehhez kapcsolódnak (veth)
    • vlinuxbr - Linux peer virtual Ethernet - Docker containerek eléréséhez

networking2

networking3 Pod indulása

  1. A Docker beköti a containert veth párral az lbr0-ba
  2. Az előbbi átkerül az OVS br0-ba
  3. OpenFlow route szabályok rögzítése az OVS DB-be

Példa hívási lánc:

  1. A és B konténer egy hoston van: A(eth0,vethA)-B(eth0,vethB) A->eth0->vethA->br0->vethB->eth0->B
  2. A és B konténer más hoston van: A(eth0,vethA)-B(eth0,vethB) A->eth0->vethA->br0->vxlan0->br0->vethB->eth0->B
  3. 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