Itt jársz most: Kezdőlap > Alkalmazásfejlesztés > Kezdőcsomag hobbi-projekt kezeléshez és üzemeltetéshez

Szűrő megjelenítése

Kezdőcsomag hobbi-projekt kezeléshez és üzemeltetéshez

Egy szoftver megtervezése nem kis munka, ezzel azt hiszem minden szoftverfejlesztő egyetért. Az üzemeltetése hasonlóképp ingoványos talaj, főleg ha a projektet mi magunk szeretnénk üzemeltetni, mindenféle külső segítség nélkül. Szerencsére számos kiváló szoftver áll rendelkezésünkre, melyekkel a fenti problémák megoldhatóak, vagy legalábbis megkönnyítik annyira a helyzetet, hogy ne ezeken csússzon el projektünk. Ebben a cikkben a Leaflet projekt dokumentálására, és üzemeltetésére felhasznált szoftvereket szeretném bemutatni, remélhetőleg a cikk végére valamelyest tiszta képet adva egy lehetséges opcióról a korábban említett problémák megoldására. Szóval mielőtt belemennék a részletekbe, hadd mutassam be a Leaflet stack jelenlegi "külső résztvevőit":

Leaflet Stack CI/CD flow és support service-ek

Projekt "management" és dokumentálás

Számomra mindig is fontos volt, hogy a szoftver, amit fejlesztek precízen dokumentálva legyen, forráskód és követelmények szintjén is. Korábban dolgoztam olyan projekten, ahol a dokumentálás nem volt elvárás, ennek megfelelően nem is létezett - nem szeretnék hazudni, korábbi hobbi-projektjeim is pontosan így készültek. Az eredmény szinte már-már kísértetiesen mindig ugyanaz volt: a projekt követhetetlenné vált rövid időn belül, saját hobbi-projektjeim általában a digitális kukában landoltak idővel. A Leaflet egy tanulóprojektnek indult, aztán szépen lassan kinőtte magát, szerencsére még azelőtt, hogy hasonló sorsra jutott volna, mint korábbi projektjeim. Viszont a projekt és így vele a követelmények számának növekedése magával vonzotta az igényét egy megfelelő projekt management megoldás használatának. Szerencsére éppen akkortájt kezdtem el dolgozni az Atlassian termékeivel, így a kezdetben használt Asana issue tracking rendszert úgy döntöttem kicserélem a JIRA-ra, a Word dokumentumokat és szétszórt .txt fájlokat pedig a Confluence-re. Aki ismeri az Atlassian termékeit, most lehet felhúzta a szemöldökét, arra gondolva, hogy ez fölösleges pénzkidobás volt, de szerencsére van egy az Atlassian által kevésbé reklámozott tulajdonsága mindkét rendszernek: 5 felhasználóig ingyenesen használható. Így a Leaflet dokumentációi, követelményei ticket formátumban, fejlesztési ötletek, stb. teljes egészében a JIRA és a Confluence cloud verzióban találhatóak. Egy ilyen kicsi projekt managelése talán túlzásnak tűnhet ebben a két rendszerben, de őszintén szólva már mindkettő nagyon sokat segített abban, hogy ne veszítsem el a fonalat, így bátran tudom ajánlani bárkinek, aki hasonló projekt tervezésében és fejlesztésében érdekelt. Hasonló rendszerekből persze több is létezik, úgy mint a Jetbrains YouTrack szoftvere, a korábban már említett Asana, a Redmine, illetve számos másik - személy szerint a legkényelmesebbnek és legösszeszedettebbnek eddig a JIRA-t találtam.

Elsősorban a projekt modellezési, tervezési fázisában lehet hasznunkra, ha különböző UML diagramokat (elsősorban entitás modelleket, szekvenciadiagramokat) is készítünk. Az egyik személyes kedvencem erre a célra a diagrams.net (korábban draw.io) modellező alkalmazása, illetve specifikusan szekvenciadiagramok készítésére a PlantUML "nyelv" valamely renderer implementációját tudom javasolni (utóbbiról tervezek egy cikket készíteni a közeljövőben).

Continuous Integration és Continuous Delivery

Először is azt hiszem illik tisztázni a fenti fogalmak közti különbségét. Continuous Integration-ről beszélünk, ha a következő két feltétel teljesül:

  • A software deployment pipeline-nak része egy olyan szoftver vagy szolgáltatás, mely képes a szoftver forráskódját felügyelten, "központosítva" kezelni, tehát lényegében létezik egy olyan pont, ahonnan a kód fordítása és a célkörnyezetre telepítése majd megtörténhet.
  • És ez integrálva van egy olyan rendszerrel, mely automatikusan el tudja végezni a kód fordítását, minőség ellenőrzését (beleértve a statikus kódanalízist, különböző tesztkészletek lefuttatását, biztonsági rések felkutatását a kódban, stb.).

Egyszerűen fogalmazva, CI-ról tudunk beszélni, ha a szoftver forráskódja egy Git, SVN, vagy bármilyen más repositoryban jelen van és minden kódváltoztatás ebben a repositoryban integrálódik, emellett pedig használunk valamilyen automatizált fordító környezetet, mint a Bamboo, Jenkins, CircleCI, TeamCity, stb. A Continuous Delivery a CI kiterjesztése, mely automatizált pipeline-t biztosít a szoftver különböző célkörnyezetekre való telepítésére. Fontos azonban megemlíteni, hogy a Continuous Delivery tipikusan ezeket a telepítési lépéseket felhasználói interakcióhoz köti, tehát nem automatikusan történik meg. A teljesen automatizált deployment pipeline-ok szigorú tesztsorozatokat kell végrehajtsanak minden telepítési lépés előtt, biztosítva azt, hogy a szoftver automatikus telepítése nem fog problémát okozni az integrált környezetben. Ezeket Continuos Deployment pipeline-oknak hívják és - mint az sejthető - nem könnyű őket megvalósítani, hiszen a legkisebb hiányosságok is katasztrofális eredményhez vezethetnek. Az óvatosság jegyében személy szerint Continuous Delivery pipeline felépítését javaslom. Ez a Leaflet esetében a következők szerint néz ki.

A teljes rendszer forráskódja nyíltan elérhető GitHub-on - ezzel talán nem is mondok újat, hiszen állandó olvasóim tudják, hogy a cikkeimben bemutatott megoldásokhoz mindig mellékelem az éles referenciát. A GitHub rengeteget fejlődött az elmúlt évek során, különböző külső rendszerekkel való integrálása kifejezetten kényelmes és gyors, illetve már az ingyenes fiókok számára is elérhetőek a privát repositoryk, szóval ha bárki csupán ezért nem szerette volna a kódját GitHub-on hostolni, most már érdemes lehet megfontolni. CI megoldásnak épp az egyik beépített integrációját használom a GitHubnak: korábban self-hosted Jenkins vezényelte az alkalmazások fordítását és telepítését, azonban nagyjából egy éve a CircleCI cloud szolgáltatását használom. Ingyenes accounttal némi korlátozásokra kell számítanunk, de ez a projektunk méretétől függően akár nem is jelenthet valódi problémát. A legkomolyabb korlátozás ebben az esetben a heti 2500 "credit", mely heti 250 perc fordítási időt engedélyez. Ebbe természetesen beleszámít a virtuális (Docker alapú) build environment elindítása is a buildek elején, tehát ha ennél több fordítást fogunk végezni, egy magasabb planre kell váltanunk.

A lefordított artifactek szempontjából kicsit bonyolultabb a helyzet. Természetesen bőségesen szükségünk van tárhelyre meg a megfelelő repository motorokra. Mivel a Leaflet számára Maven és Docker repositorykra van szükség, self-hosted Aparche Archiva és Docker Registry szerverek mellett döntöttem. Mindkettő viszonylag könnyen beüzemelhető, elérhetőek Docker image-ek formájában és természetesen ingyenesek. Persze, léteznek más megoldások is, például a Docker Hub (csak Docker image-ek számára), JFrog Cloud (Maven + Docker + egyebek), Jetbrains Space (Maven + Docker + egyebek), stb. Ezek többsége azonban vagy nem elérhető ingyenes plan alatt, vagy csak különféle korlátozásokkal (például a Docker Hub-on csak egy private repository készíthető ingyenes fiókkal). Természetesen az integráció viszonylag könnyedén megoldható a CircleCI, és a self-hosted repository motorok között is, így gyakorlatilag a CircleCI az alkalmazások fordítása során az Archiva-ból tölti le a libraryket (illetve a libraryket fordítás után oda tölti fel), a lefordított Docker image-eket pedig a Docker Registryben perzisztálja.

Természetesen egy kritikus komponens még hiányzik: egy deployment manager ami a célszerveren végzi az alkalmazások telepítését és indítását. Ingyenesen és könnyen használható megoldás sajnos kevés van, sokszor a legtriviálisabb megoldás az SSH-n keresztüli belépés a szerverre és a szükséges parancsok lefuttatása. Ehelyett a Leaflet stackhez a Domino (Deployment Orchestration for Minor Infrastructures, powered by Node.js) nevű, saját fejlesztésű deployment manager alkalmazásomat használom - súlyos részletekbe itt most nem mennék bele, a cikk végén mellékelem a linket a repositoryhoz, ahol részletes útmutatót találtok a használatáról, illetve a későbbiekben szeretnék egy cikket is írni róla. A lényeg, hogy a CircleCI a build végén a Domino-n keresztül kezdeményezi az új verzió letöltését (Docker image-ből) és annak elindítását.

Infrastruktúra

Alapvetően a Leaflet stacket futtató szerver Docker alapokon fut, minden alkalmazás egy-egy Docker container. A Docker Engine integrálva van a már korábban említett Dominoval, így a manageléshez nem szükséges a Docker CLI vagy a Docker Engine API közvetlen használata - az integrációval természetesen csak meghatározott műveletek végezhetőek a Dominon keresztül, de ez a művelet-készlet éppen elegendő a telepítéshez és indításhoz. A szerver maga csak a legszükségesebb komponenseket tartalmazó Debian 10-et futtat. A Debian 10-et én kifejezetten szívesen ajánlom, bár egy GUI-mentes Ubuntu is kiváló választás lehet, főleg, hogy a kettő - azonos architektúrájuk miatt - gyakorlatilag szinte pontosan ugyanolyan módon kezelhető (beleértve például az APT package managert is).

Adatbázis téren kettő is fut a szerveren: egy MySQL 8.0 Community Edition tartalmaz minden fontos adatot, ami a blog üzemeltetéséhez szükséges, tehát a felhasználókat, bejegyzéseket, különböző metaadatokat, stb. Emellett egy MongoDB 4.2 is található a szerveren, ebben tárolódnak a TLP által összegyűjtött logok, valamint a nyelvi csomagok, melyek elsősorban a felhasználói front címkéit tartalmazzák. Természetesen mindkettő ingyenes és kiváló teljesítményű adatbázis motor, előbbi relációs, utóbbi NoSQL/document motor. Viszonylag kicsi rendszerigénnyel is képesek kielégítő teljesítményt hozni, így persze csak a rendszerünktől függ, melyikre lesz szükségünk - persze mindig érdemes megvizsgálni a lehetőségeket, és a felhasználási területnek megfelelő motort használni, így szükség lehet a számos további adatbázismotor közül választanunk.

Monitoring szempontjából a választásom egy régi kedvencemre, a Grafana-Graphite kombóra esett. A Graphite egy a Whisper nevű adatbázis motorra épülő, úgynevezett time-series adatokat kezelő motor. Az ilyen time-series adatok pontosan azok az adat-sorozatok, melyeket a metrikákat előállító alkalmazások generálnak, a Graphite pedig ezek kezelésére képes. Önmagában az adatokat azonban nem tudja tárolni, arra külön adatbázis motor szükséges, erre használja natívan a Whispert. A Grafana pedig a Graphite által kezelt adatok vizualizálására biztosít kényelmes és elegáns felületet, továbbá képes riasztásokat is kezelni. A riasztások lényegében bizonyos metrika sorozatokra felállított thresholdok - ha az adatpontok, vagyok azok aggregáltja elkezdi túllépni a beállított határértékeket, a Grafana képes különböző csatornákra (pl. emailben) értesítést küldeni. Kiváló eszköz, csak ajánlani tudom, bár érdemes megvizsgálni a Graphite helyett más szoftvereket is, mivel már léteznek jobb, hatékonyabb megoldások is, kisebb rendszerigénnyel. Emellett még szintén monitoring kategóriában a Google Analytics-et is használom - az élő felhasználói forgalom figyelemmel követésére egy kiváló ingyenes eszköz, és amennyiben rendelkezünk Google fiókkal, gyakorlatilag az Analytics is azonnal elérhető. Integrálása pofonegyszerű, részletes leírás található a dokumentációjában, de amúgy egy pár sornyi JavaScript kódot kell csupán elhelyezni a UI HTML kódjában. Ha már szóba kerültek az értesítések, emaileket a Leaflet a MailJet rendszerén keresztül küld ki. Ez szintén egy ingyenesen is elérhető szolgáltatás, havi 6000 email küldhető ki, de a fizetős planek sem igazán drágák.

A kapcsolatot a külvilág felé egy Apache HTTPD szerver biztosítja. A külső kommunikációt is igénylő alkalmazásokat az Apache vhost-okon keresztül proxyzza, minden esetben HTTPS kommunikációt igényelve (256 bites TLS 1.3 titkosítással). És ezzel rá is fordulunk az utolsó, de nagyon fontos komponensre, ez pedig a LetsEncrypt, illetve az azt kezelő utility alkalmazás, a Certbot. A LetsEncrypt azok számára biztos TLS certificate-eket, akik szeretnének biztonságos kommunikációs csatornát biztosítani weboldaluk látogatóinak, de nem érzik szükségét súlyos összegek kifizetésének. Sajnos egy "nagy" TLS certificate még mindig meglehetősen drága, sok esetben nem is feltétlenül járható út, hiszen ezek többsége vállalatok, vállalkozások számára biztosít certificate-et. A LetsEncrypt protokollja nem biztosít vállalat szintű verifikálást, csak a domain és a szerver kapcsolatát bizonyítja, azonban cserébe ingyenes, így kisebb személyes portálokat üzemeltetők számára is lehetővé teszi a HTTPS kapcsolatot. Fontos megemlíteni, hogy a Certbot által igényelt certificate-ek csupán 3 hónapig érvényesek, így megfontolandó azok megújításának automatizálása.

További megfontolandó dolgok

Nagyon fontos a szerver üzemeltetése szempontjából többek között az automatikus biztonsági mentés beállítása. És ez egy hatalmas hiányossága a jelenlegi infrastruktúrámnak, mivel erre még nem találtam meg a tökéletes megoldást. Természetesen ha "rendet tartunk" a szerveren, viszonylag könnyen lementhetőek az alkalmazások által generált fájlok, adatbázisok. Az adatbázisokat érdemes lehet a saját backup módszerükkel is menteni időnként, biztos ami biztos alapon. Emellett nagyon fontos biztonsági megfontolás a nem használt portok lezárása, amire kiváló eszköz az UFW nevű alkalmazás. Tipikusan a HTTP (80), HTTPS (443) és SSH (22) portokon kívül semmi mást nem érdemes nyitva hagyni. Ha az adatbázisokhoz szeretnénk hozzáférni, érdemesebb azt SSL tunnelön keresztül megtenni. Egy aktív vírusirtó sem rossz döntés, a ClamAV például egy tökéletes választás erre a célra Linux szervereken. Végezetül pedig, az egyik, ha nem a legfontosabb tanács: az SSH hozzáférés jelszavas azonosítással legyen kikapcsolva. A gépet telepítés után azonnal érdemes átállítani RSA kulcsos authentikálásra, és teljesen letiltani a jelszavas módot. Óh, és még az is sokat segíthet, ha nem mindig root fiókkal jelentkezünk be, szóval érdemes lehet egy másodlagos, de elevated executionre jogosult felhasználót használni. Ezzel a pár tanáccsal, egy managed hostingon futó VPS már egész jól védett, bár egy DevOps/SecOps kollega bizonyosan tudna még további jó tanácsokat adni. :)

Konklúzió

Szóval, mint az látható, egy a Leaflethez hasonló kisebb projekt üzemeltetése viszonylag könnyen megoldható feladat, és akár nagyobb rendszerekhez hasonló extrákkal is kiegészíthető (mint például a fejlett monitoring). Persze, egyáltalán nem mondom, hogy nem időigényes és nem igényel utánajárást a környezet kialakítása, illetve az üzemeltetés maga is rengeteg figyelmet igényel, de automatizálással, helyesen beállított riasztásokkal, automatikus mentésekkel egyáltalán nem lehetetlen feladat. Természetesen a fentebb leírt megoldás csupán egy a számtalan lehetőség közül, és nagyon hosszú fejlődési időszak előzte meg, és már most is új tervek felé haladok - a következő lépés már valószínűleg Kubernetes lesz.

Domino repository

Kommentek

Komment írásához jelentkezz be
Bejelentkezés

Még senki nem szólt hozzá ehhez a bejegyzéshez.