1. rész: Elmélet

Mi az az OCI?

Az Oracle az elmúlt években gőzerővel dolgozott azon, hogy a felhős szolgáltatásokban is szintre hozza a képességeit, sőt innovatív megoldásokkal meg is előzhesse főbb versenytársait, akik ezen a területen az Amazon AWS, Microsoft Azure és Google Cloud. Az IaaS (Infrastructure-as-a-Service) és PaaS (Platform-as-a-Service) szegmensben is olyan arzenált vonultat fel az Oracle 2. generációs (Gen2) felhője, amely árban és minőségben is felveszi a kesztyűt.

Leegyszerűsítve: a felhő szolgáltatók számítókapacitást és szoftvert adnak bérbe ügyfeleiknek úgy, hogy az üzemeltetés egy részét vagy akár egészét a szolgáltató végzi. Az alapján különböztetjük meg az IaaS, PaaS és SaaS szegmenseket, hogy az erőforrásoknak mekkora részét menedzseli a szolgáltató. Természetesen a csomag részét képezi az is, hogy a távoli szervereken futó erőforrásainkat összehangoltan kezelni, skálázni és felügyelni tudjuk, beleértve ebbe a költségek kordában tartását is.

A továbbiakban az Oracle Cloud Infrastructure világát járjuk körbe, és ezen belül is elsősorban az IaaS területhez tartozó elemeket. Megjegyzendő, hogy az IaaS / PaaS határvonalak időnként kissé összemosódnak. A szolgáltatók ezzel is egy egységes, koherens platform képét próbálják sugallani, és ténylegesen egyetlen Oracle accounton keresztül hozzáférhetünk az IaaS, PaaS, SaaS kínálat teljes skálájához. Amiről most nem lesz szó bővebben: az OCI keretében elérhető PaaS szolgáltatások, elsősorban fejlesztői és integrációs eszközök, mint a Java Cloud, a Visual Builder vagy az Oracle Integration.

A felhővel való ismerkedést kezdhetjük lépésről lépésre, koncentrálva az általunk fontosnak és érdekesnek vélt részekre. De azért nem árt előre tudni, hogy mibe vágunk bele. A sok idegenül hangzó szakkifejezés, szolgáltatásnév és menüpont elsőre nagyon riasztó lehet. Ha az alapokat átlátjuk, könnyebb lesz eligazodni, és megérteni, hogy pontosan mi történik a második, gyakorlati részben.

A fogalmak tisztázásakor többnyire a hivatalos magyar fordításokat használom, mivel az OCI Console (azaz a webes kezelőfelület) magyar nyelven is elérhető. Néhány magyarítás szerintem elég furán hangzik, a biztonság kedvéért feltüntetem az angol változatot is zárójelben.

Fizikai tagoltság

Ha felhőről beszélünk, hajlamosak vagyunk valami elvont, megfoghatatlan dologra gondolni, amiből felhasználóként nagyjából csak egy webes felületet érzékelünk. A valóságban persze minden felhős szolgáltatás valós fizikai hardvereken fut egy adatközpontban. Az Oracle esetében az Exadata szervereket kifejezetten úgy tervezték, hogy az Oracle adatbázissal minél hatékonyabban együttműködjön. Ebből a csúcstechnológiából hasíthatunk ki mi is egy apró (vagy akár nagyobbacska) szeletet az OCI-on keresztül.

Régiók

Amikor regisztrálunk egy Oracle Cloud accountot, meg kell jelölnünk, hogy a „bérleményünk” (tenancy) melyik régióban leleddzen (home region). Európában jelenleg Frankfurt, Amsterdam, London és Zürich közül választhatunk, de világszerte minden földrészen van több választható régió, és persze folyamatosan bővül a választék. A kormányzati szektor ügyfelei számára elkülönített régiók vannak dedikálva. Célszerű minél közelebbi régiót választani, hogy minimálisra csökkentsük a hálózati várakozási időt (latency). Az viszont fontos, hogy nem vagyunk egy régióra korlátozva. Ugyanazzal az accounttal egyszerre több régióban is használhatunk erőforrásokat, ezeket virtuális hálózatokkal összekapcsolhatjuk. Így a magas rendelkezésre állás és katasztrófavédelem (HA/DR) legszigorúbb elvárásait is teljesíteni lehet.

Hibatűrés régión belül

Egy régión belül lehet több „rendelkezésre állási tartomány” (Availability Domain), melyek fizikailag elkülönített, de földrajzilag egymáshoz közel levő adatközpontokat jelentenek. Ezen túl minden AD három különálló „tartalék tartományra” (Fault Domain) van bontva. A különböző FD-k önálló hardver csoportokat jelentenek, amelyek között nincsen átfedés, és külön áramellátásuk is van. Tehát az egyikben beálló váratlan műszaki hiba vagy áramkimaradás nincsen kihatással a többire. Az erőforrások, például virtuális gépek létrehozásakor az AD és FD is szabadon választható. Ezáltal biztosíthatunk egy régión belül is megfelelő hibatűrő képességet a hálózati infrastruktúránknak.

Az erőforrások logikai szervezése

Rekeszek és címkék

A bérleményen (tenancy) belül minden OCI erőforrást (virtuális gépet, adatbázist, tárhelyet, stb.) egy konkrét logikai egység, úgynevezett „útvonalválasztási szegmens” (compartment) alatt hozhatunk létre. A tömörség végett ezeket a továbbiakban rekesznek fogom hívni, mert itt a magyarítást elhibázottnak éreztem. A rekeszek hierarchikusan egymásba ágyazhatók. A bérleménnyel együtt automatikusan létrejön egy gyökér (root) rekesz, ami a bérlemény nevét viseli, ezen belül hozhatjuk létre a többi rekeszt. A rekeszekhez rendelhetünk hozzáférési szabályokat, amelyeket a rekeszben levő összes erőforrás és alrekesz megörököl. Emiatt célszerű külön rekeszbe tenni a teszteléshez, fejlesztéshez használt (sandbox) és az élesben futó (production) erőforrásainkat, de ennek kialakítása teljességgel rajtunk múlik. Erőforrást másik rekeszbe mozgatni nem lehet, de rekeszek közötti hozzáférést lehet engedélyezni. A rekeszek átívelnek az AD-kon és a régiókon is, a különböző fizikai helyen levő erőforrásokat közös csoportba foghatják össze.

Az OCI-ban használt dolgainkat emellett címkékkel (tag) is elláthatjuk. Minden címke egy kulcsból és egy értékből áll. Kétfajta címkét használhatunk: kötetlen (free-form), illetve előre definiált, ahol a címke névtéren belül a kulcsokat határozzuk meg előre, és opcionálisan megadhatunk előre rögzített értéklistát is. A címkék alapján kereshetünk, és használhatjuk szűrőfeltételként a konzolban elérhető költségelemzés (cost analysis) riporton belül. Ez elősegíti a felhős költések tervezését és felügyeletét.

Hozzáférési rendszer

A felhős jogosultságok kezelésére az Identity and Access Management (IAM) nevű keretrendszer szolgál. Ebben hozhatunk létre új felhasználókat (user), akiket csoportokhoz (group) rendelhetünk. Az „alapszabályok” (policy) határozzák meg, hogy melyik csoport, melyik rekesznek milyen típusú erőforrásain milyen műveleteket végezhet. A szabályokat egy viszonylag közérthető, angol-szerű leíró nyelven kell megfogalmazni, például az alapértelmezett Tenant Admin Policy így néz ki:

• ALLOW GROUP Administrators to manage all-resources IN TENANCY

Virtuális hálózat

Hálózati topológiánk kialakítására a „felhőalapú virtuális hálózatokat” (virtual cloud network, VCN) használhatjuk. Itt határozzuk meg, hogy az egymással kommunikáló hálózati elemek milyen portokon keresztül érintkezhetnek, és hogy a publikus internetről érkező forgalmat hova irányítjuk. Létrehozhatunk zárt (private) vagy nyilvános (public) alhálózatokat (subnet). A virtuális hálózatok a rekeszekhez hasonlóan átívelhetnek régiókon is.

Elérhető szolgáltatások

Aki már találkozott más felhő szolgáltató kínálatával (pl. Azure, AWS), az találhat ismerős tételeket a következő listában. Az OCI központi eleme és húzóterméke mindenképpen az adatbázis, de az infrastruktúra szolgáltatás kikerekítéséhez számos open source technológiát is beépített az Oracle, és ez a hordozhatóság szempontjából előnyösnek tekinthető.

Először vegyük sorra az ingyenesen elérhető és használható elemeket:

• Adatbázis
  • Az Oracle világszínvonalú és innovatív adatbázis szolgáltatásának kétféle változata van: Autonomous Transaction Processing (ATP) és Autonomous Data Warehouse (ADW). Ez a kettő valójában ugyanaz a termék, csak a paraméterezésben (tárolási mód, lekérdezési sebesség) különbözik. Az ATP általános üzleti alkalmazásokhoz való, az ADW pedig adattárház és analitikus célokra.
  • Az autonóm adatbázisokba számos, mesterséges intelligenciával is támogatott automatizmus van építve, amelyek segítségével a rendszer önmagát optimalizálja, felügyeli és karbantartja, DBA beavatkozásra szinte csak a monitoring területén lehet szükség.
  • A relációs adatmodell mellett támogatja a JSON, key-value, blockchain, geolokációs és gráf adattípusokat is (lásd: konvergens adatbázis), ezáltal minden elképzelhető adatbázis-igényre megoldást kínál egyetlen mindentudó termékben.
  • Az adatbázisnak része az APEX, ami egy low-code fejlesztőeszköz adatcentrikus alkalmazásokhoz.
  • A gépi tanulás (machine learning) munkafolyamatokat beépített Apache Zeppelin munkafüzetek, és az adatbázisból közvetlenül hívható, PL/SQL alapú statisztikai és ML függvények támogatják.
• Virtuális gépek
  • A számítókapacitást (compute) virtuális gépek (virtual machine instance) formájában bérelhetjük, amelyek előre meghatározott vagy rugalmasan skálázható processzor- és tárkapacitással, előre telepített oprendszerrel igényelhetők (többféle választható Linux, vagy akár Windows Server).
  • Az összehasonlíthatóság végett az Oracle az OCPU/hour mértékegységet használja, ez egy processzor egy órán át tartó használatát jelenti, és ez képezi leggyakrabban az árazás és számlázás alapját is.
  • Az igényelt virtuális gépeket tetszés szerint leállíthatjuk és újraindíthatjuk. Terminálon keresztül SSH használatával tudunk bejelentkezni, és bármit telepíthetünk rá.
  • Másik fajta compute opció a bare metal, amely egy virtualizáció nélküli dedikált hardverkörnyezetet jelent, egy kicsit borsosabb áron.
• Tárhely
  • A „blokkalapú köteg” (block storage) egy VM-hez csatlakoztatható extra tárterületet jelent, amit adatok mozgatásához vagy biztonsági mentéshez is használhatunk.
  • Az objektumtár (object storage) egy nagyon hasznos koncepció, nem strukturált objektumok ideiglenes vagy tartós tárolására alkalmas. Keresztül lehet folyatni rajta logokat, IoT adatokat, illetve lehet feltölteni tetszőleges fájlokat, és megosztani publikusan vagy kulcs ellenében, meghatározott érvényességi ideig.

További ingyenesen használható kiegészítők:

• Terheléselosztó (load balancer)
  • A beérkező adatforgalom szétterítése több kiszolgáló között a virtuális hálózaton belül.
• Rendszerfigyelés (monitoring) és riasztások (alarms)
  • Az általunk konfigurálható metrikák, KPI-ok segítségével követhetjük nyomon a felhőnk egészségi állapotát és teljesítményét
• Értesítések (notifications)
  • Ezeket kiválthatja egy rendszeresemény (bármely akció vagy történés, amely az OCI tevékenységei között logolásra kerül), vagy egy rendszerfigyelő, vagy külső alkalmazás REST API-n keresztül. Az értesítés történhet emailben, HTTP protokollon keresztül (API hívás), vagy egy függvény hívásán keresztül.
• Erőforrás-kezelő (resource manager)
  • A Terraform open-source alkalmazás segítségével megvalósul az „Infrastructure-as-code” koncepció: komplett hardver és szoftver környezeteket, hálózati konfigurációkat írhatunk le egy adatfájlban, és élesíthetjük egy gombnyomással a hozzájuk tartozó OCI erőforrásokat. Ez nagymértékben megkönnyítheti a rendszer-adminisztrátori feladatok automatizálását.

Fizetős fiókkal elérhető elemek:

• API átjáró (API gateway)
  • API végpontok egyszerű publikálását teszi lehetővé a felhős hálózatunkon belülre és kívülre.
  • Az autentikáció az IAM szabályrendszerével integráltan működik.
• Függvények (functions)
  • Az Fn Project nevű, nyílt forráskódú megoldásra épülő szolgáltatás.
  • Serverless web szolgáltatások, minialkalmazások és API-k futtatása konténeres környezetben.
• Események (events)
  • Meghatározott metrikák alapján az OCI erőforrásokon bekövetkezett változások figyelése
  • Automatizált válaszként értesítések vagy funkció hívások kezdeményezése.
• Adatfolyamok (streams)
  • Apache Kafka-hoz hasonló, publish/subscribe rendszerű üzenetsor (message queue) szolgáltatás.
  • Nagy mennyiségű adat (pl. logok) valós idejű feldolgozására alkalmas.
• Tárolófürtök (Oracle Container Engine for Kubernetes, OKE)
  • Kubernetes fürtök (cluster) telepítésére és menedzselésére alkalmas eszköz az OCI erőforrásait felhasználva.

Always Free

Korábban már írtunk az Oracle Always Free szolgáltatásának beharangozásáról. Ez nem más, mint az Oracle felhő ingyenes kipróbálási lehetősége. A regisztrációval két dologra tehetünk szert:

• egy hónapon keresztül 300 USD keretet kapunk arra, hogy az Oracle Cloud Infrastructure bármely fizetős részét teszteljük, kipróbáljuk;
• és ezen túl időlimit nélkül szabadon használhatjuk a Mindig ingyenes címkével megjelölt erőforrásokat, a megadott szolgáltatási korlátokon belül (például legfeljebb 2 adatbázis, legfeljebb 2 virtuális gép a legkisebb 1 OCPU mérettel).

A regisztrációnál meg kell adni egy valós hitelkártyát, viszont amíg szándékosan, explicit nem állunk át fizetős fiókra, addig az Oracle garantáltan semmit nem fog számlázni. A 30 nap próbaidő után, ha maradunk Mindig ingyenes státuszban, akkor az Oracle lekapcsolja, illetve automatikusan törli azokat a próbaidő alatt kiosztott erőforrásokat, melyekre nem vonatkozik az ingyenes ajánlat. Erre figyelmeztető üzenetet is kapunk, tehát érdemes jó előre gondolkodni, hogy elkerüljük az adatvesztést.

Személyesen én azt javaslom minden rendszergazdának, DBA-nak, programozónak, hogy ha van rá lehetősége és ideje, akkor barangoljon a felhőben, ismerkedjen az IaaS és PaaS szolgáltatásokkal, az árazási modellekkel, a fejlesztő, kezelő és felügyelő eszközökkel. Érdemes a többi szolgáltató kínálatát is megnézni, hogy legyen összehasonlítási alap. Nem árt tisztában lenni a legfrissebb technológiákkal, amelyek a következő évek IT trendjeit meg fogják határozni, és a jelenlegi IT iparágban megszokott feladatköröket és munkaerőpiaci állapotokat gyökeresen felforgatják. Készüljünk fel a jövőre, tanuljunk és tájékozódjunk. Ha rászánjuk magunkat, hogy regisztrálunk egy Oracle Always Free accountot, akkor érdemes már előzetesen utánanézni a lehetőségeknek, és kész tervvel nekimenni az első 30 napnak, hogy minél több dolgot legyen mód kipróbálni és átlátni ebből a hatalmas, összetett, izgalmas világból. Ne feledjük: egy olyan eszköz lesz a kezünkben, ami képes a legmodernebb technológiákkal a legnagyobb világcégek IT igényeit is lefedni. Ehhez mérten be kell látni, hogy a rendszer teljes komplexitását is lehetetlen 30 nap alatt befogadni.

2. rész: Gyakorlat

Egy mini esettanulmányon keresztül szeretném bemutatni, hogy nekem, aki hivatásosan sem fejlesztő, sem rendszergazda nem vagyok, hogyan sikerül a saját kis félkész hobbiprojektemet feltölteni az Oracle felhőbe. Egy Vaadin keretrendszerben íródó, még félkész Java web alkalmazásról van szó, amit előre becsomagoltam egy Docker konténerbe.

Egyébként az alábbi leíráshoz hasonló, fejlesztőknek szóló recepteket találhatunk az Oracle dokumentációi és az Always Free kipróbálását népszerűsítő hivatalos blogok között is.

Regisztráció és bejelentkezés

Keressük fel a https://www.oracle.com/cloud/free/ címet, és a Start for free gombbal máris elkezdhetjük a regisztrációt. Csak minimális adatot kell megadnunk első körben: ország, email cím, az account neve és típusa (céges vagy személyes), a saját régió, végül a hitelkártya adatai. Az fontos, hogy egy email címet és egy hitelkártyát nem használhatunk fel egynél többször. Az account nevét meg lehet változtatni később, ha nagyon muszáj.

Rövidesen érkezik egy megerősítő emailt (ha mégsem, akkor ellenőrizzük a spam között is). Nagyjából 20 perc alatt az új account teljesen elkészül, és használatba vehető a tenancy.

Az illusztrációkkal most ugrok egy kicsit az időben, mert az én próbaidőm már lejárt, és a menürendszeremben a tételek többsége szürkének látszik, csak az ingyenes opciók vannak kiemelve. Viszont így azt is be tudom mutatni, hogy ennek ellenére az Always Free erőforrásokkal továbbra is lehet használni a rendszert.

Az emailben kapott linken keresztül jelentkezhetünk be a Console-nak nevezett vezérlő képernyőre. A jobb felső sarokban levő földgömb ikonnal lehet nyelvet váltani.

Új rekesz

Létrehozok egy rekeszt, hogy abban tárolhassam a tesztelésre szánt erőforrásokat. Ez a menürendszerben az Identitás / Útvonalválasztási szegmens alatt található, de a menüben bolyongás helyett használhatjuk a lap tetején levő keresőmezőt is. Válasszuk ki az account névvel megegyező gyökér rekeszt, és ezen belül készítsük el a sandbox nevű új rekeszt.

Virtuális hálózat beállítása

Minden compute erőforrást egy VCN-en belül kell létrehozni. Opcionálisan arra is van lehetőség, hogy a VM példány készítésekor ezt rábízzuk a rendszerre default beállításokkal, de most külön lépésben fogom megtenni. A menüben a Hálózatkezelés / Felhőalapú virtuális hálózatok pontot kell keresni. A bal oldali almenü alatt módosítani kell a Lista hatókörét és kijelölni a sandbox-ot mint Útvonalválasztási szegmens. Így a hálózatot már ezen a rekeszen belül fogom létrehozni.

A VCN varázsló elindítása gomb megnyomása után, a VCN internetkapcsolattal opcióval lépek tovább.

A következő képernyőn megadom a VCN nevét (sandbox), a többi beállítást pedig alapértelmezetten hagyom. Az áttekintő képernyőn a Létrehozás gombbal indul a folyamat.

Néhány pillanat múlva el is készül a VCN, és látható az eredmény. Egy dolgot még fontos beállítani: a Nyilvános alhálózat alatt engedélyezni kell egy portot a külső internet felől, amin keresztül az alkalmazásomat el lehet majd érni. Tehát az újdonsült sandbox VCN-ben megnyitom a Nyilvános alhálózat - sandbox nevű alhálózatot (public subnet), ezen belül a Default Security List for sandbox nevű biztonsági listát (security list). A TCP protokoll számára egyedül a 22-es port van nyitva, ez azt jelenti, hogy SSH-n keresztül terminállal be lehet csatlakozni a virtuális hálózatra. Itt hozzáadok egy új bemeneti szabályt (ingress rule), amelyben megnyitom a 8090-es portot bármely külső kliens számára (ezt jelenti a 0.0.0.0/0 forrás CIDR). Azért pont ezt a portot használom, mert így állítottam be a Docker konténerben futó appot. Egy átlagos weblaphoz a 80-as, HTTPS protokollhoz a 443-as portot kell engedélyezni.

Az első virtuális gép

A következő lépés most már a virtuális gép létrehozása, a Compute / Példányok menüből. Megint figyelni kell, hogy a sandbox rekesz (compartment) legyen aktív. VM létrehozás képernyőn a következő opciókat kell megadni:

• Név: nem kell túlzásokba esni, ne felejtsük, hogy címkékkel is el lehet látni az erőforrásokat, ha később be akarjuk azonosítani őket. Én maradok a test-webapp névnél.
• Útvonalválasztási szegmens: sandbox
• Lemezkép kiválasztása: mindenképp a „Mindig ingyenes jogosultság” címkével ellátott képek közül kell választani. Én kipróbálom az Oracle Linux 7.8 opciót, ami a Red Hat alapjaira épített disztro.
• Elképzelhető, hogy a választott image nem hozható létre abban a rendelkezésre állási tartományban (availability domain), amelyiket elsőre felkínálja a rendszer. Ilyenkor le kell nyitni „A kialakítás, a hálózat és a tároló beállításainak megjelenítése” szekciót, és másik AD-t választani.
• Hálózatkezelésnél is a sandbox VCN-t használjuk, és az alapbeállításnak megfelelően szükségem lesz nyilvános IP címre.
• A lap alján az SSH-kulcsok hozzáadása fontos lépés, hogy távvezérléssel rá tudjak csatlakozni a virtuális gépre. Két kulcs van: egy nyilvános (public) és egy titkos (private). A felhőben a nyilvános kulcsot kell a VM-hez társítani, nekem pedig a titkos kulcsra van szükségem a saját gépemen ahhoz, hogy terminálon becsatlakozzak. A Generate SSH keys opció lehetővé teszi, hogy letöltsek egy frissen létrehozott kulcs párt. Utána a nyilvános kulcs (pub) tartalmát az SSH-kulcsok beillesztése opció alatt másoljuk be. Ezt kritikus itt és most megcsinálni, mert utólag sokkal bonyolultabb lenne.

Ezek után elindítom a példány létrehozását, és néhány perc múlva már kész is az új virtuális gép. A nyilvános IP címet fel kell jegyezni a következő lépéshez! A Példányhozzáférés alatt látható.

Szükség esetén, kulcsgenerálás manuálisan terminálban az ssh-keygen paranccsal történhet:

ssh-keygen -t rsa -b 2048 -C "sandbox-webapp-key" -f .\sandbox-webapp-key

Terminál és az app telepítése

Ha a VM már futó állapotban van, akkor elővehetjük a kedvenc terminál programunkat (ssh, putty, openssh…), és csatlakozhatunk a virtuális géphez a nyilvános IP cím és a titkos kulcs használatával. A felhasználói név opc.

ssh opc@158.101.175.118 -i .\sandbox-webapp-key

Egy üres Linux VM áll rendelkezésünkre, amiben először a Dockert telepítem az alábbi parancsokkal:

sudo yum-config-manager --enable ol7_addons

sudo yum install docker-engine -y

sudo systemctl start docker

sudo systemctl enable docker

Engedélyezem a Docker futtatását nem root user számára, ezzel biztonságosabbá tehetem a konténer futtató környezetet:

sudo groupadd docker

sudo service docker restart

sudo usermod -a -G docker opc

Utána ki kell jelentkezni SSH-ból, majd újra belépni. Ezt követően már az alapértelmezett opc felhasználó is futtathat Docker konténert, sudo nélkül.

Most már elindíthatom a Docker Hub-ra publikált konténeremet az alábbi paranccsal:

docker run -d --restart always -p 8090:8080 --name enni maquirag/enni:1.0

A végeredmény: a web app projektem egy web böngészőben, a felhőn kívülről elérhető a publikus IP címen és a megnyitott porton keresztül.