Ahhoz, hogy korunkban saját webes alkalmazást készítsünk, nem elég, ha képesek vagyunk fejleszteni. Fontos szempont az alkalmazások telepítéséhez, figyeléséhez, valamint a működési környezet kezeléséhez és adminisztrálásához szükséges eszközök beállítása. Ahogy a kézi telepítés korszaka feledésbe merül, még a kis projektek esetében is, az automatizálási eszközök kézzelfogható előnyökkel járhatnak. A „kézzel” telepítéskor gyakran elfelejthetünk valamit megmozgatni, figyelembe venni egy-egy árnyalatot, lefuttathatunk egy elfelejtett tesztet, ez a lista még sokáig folytatható.
Ez a cikk azoknak segíthet, akik még csak most tanulják a webalkalmazások létrehozásának alapjait, és szeretnének egy kicsit megérteni az alapvető kifejezéseket és konvenciókat.
Tehát az alkalmazások létrehozása továbbra is két részre osztható: mindenre, ami az alkalmazás kódjához kapcsolódik, és mindenre, ami a kód végrehajtásának környezetéhez kapcsolódik. Az alkalmazáskód pedig szintén fel van osztva szerverkódra (amely a szerveren fut, gyakran: üzleti logika, jogosultság, adattárolás stb.) és klienskódra (amely a felhasználó gépén fut: gyakran az interfész és a hozzá kapcsolódó logika).
Kezdjük a szerdával.
Bármilyen kód, rendszer vagy szoftver működésének alapja az operációs rendszer, ezért az alábbiakban áttekintjük a tárhelypiac legnépszerűbb rendszereit, és röviden ismertetjük őket:
A windows Server - ugyanaz a Windows, de egy szerverváltozatban. A Windows kliens (normál) verziójában elérhető bizonyos funkciók itt nem találhatók meg, például egyes statisztikai gyűjtő szolgáltatások és hasonló szoftverek, de van egy sor hálózati adminisztrációs segédprogram, alapszoftver a szerverek telepítéséhez (web, ftp, ...). Általánosságban elmondható, hogy a Windows Server úgy néz ki, mint egy normál Windows, és úgy néz ki, mint a normál Windows, azonban kétszer többe kerül, mint a normál társa. Tekintettel azonban arra, hogy az alkalmazást nagy valószínűséggel egy dedikált/virtuális kiszolgálón fogja telepíteni, a végső költség, bár növekedhet, nem kritikus. Mivel a Windows platform elsöprő helyet foglal el a fogyasztói operációs rendszerek piacán, a legtöbb felhasználó számára a kiszolgálói kiadás lesz a legismertebb.
Unix- hasonló rendszer. A hagyományos munkavégzés ezekben a rendszerekben nem igényli a megszokott grafikus felület jelenlétét, csupán egy konzolt kínál a felhasználónak vezérlőelemként. Egy tapasztalatlan felhasználó számára nehéz lehet ebben a formátumban dolgozni, csak mennyibe kerül egy olyan szövegszerkesztőből való kilépés, amely igen népszerű az adatok terén életkedv, egy ehhez kapcsolódó kérdés 6 év alatt már több mint 1.8 millió megtekintést kapott. Ennek a családnak a fő disztribúciói (kiadásai) a következők: Debian - népszerű disztribúció, a benne lévő csomagverziók elsősorban az LTS-re koncentrálnak (Hosszú távú támogatás – hosszú távú támogatás), ami a rendszer és a csomagok meglehetősen magas megbízhatóságában és stabilitásában fejeződik ki; Ubuntu – tartalmazza az összes csomag legfrissebb verziójának disztribúcióit, amelyek befolyásolhatják a stabilitást, de lehetővé teszik az új verziókhoz tartozó funkciók használatát; Red Hat Enterprise Linux – OS, kereskedelmi használatra pozícionálva, fizetős, azonban magában foglalja a szoftverszállítók támogatását, egyes védett csomagokat és illesztőprogram-csomagokat; CentOS - nyílt forráskódú a Red Hat Enterprise Linux egy változata, amelyet a védett csomagok és támogatás hiánya jellemez.
Azoknak, akik most kezdik elsajátítani ezt a területet, a rendszereket ajánlom A windows ServerVagy Ubuntu. Ha a Windowst vesszük, akkor ez elsősorban a rendszer ismertsége, Ubuntu – nagyobb tolerancia a frissítésekkel szemben, és például kevesebb probléma az új verziót igénylő technológiákkal kapcsolatos projektek indításakor.
Tehát, miután eldöntöttük az operációs rendszert, térjünk át egy olyan eszközkészletre, amely lehetővé teszi az alkalmazás vagy részei üzembe helyezését (telepítését), frissítését és állapotának figyelését a kiszolgálón.
A következő fontos döntés az alkalmazás és a hozzá tartozó szerver elhelyezése lesz. Jelenleg 3 módszer a leggyakoribb:
- A szerver önálló tárolása (tartása) a leginkább költségkímélő lehetőség, de statikus IP-t kell rendelnie a szolgáltatótól, hogy az erőforrása idővel ne változtassa meg a címét.
- Béreljen dedikált szervert (VDS) – és önállóan adminisztrálja és méretezheti a terheléseket
- Fizessen (gyakran lehetőséget adnak arra, hogy ingyenesen kipróbálja a platform funkcióit), ha előfizet valamilyen felhőtárhelyre, ahol a felhasznált erőforrások fizetési modellje meglehetősen gyakori. Ennek az iránynak a legkiemelkedőbb képviselői: Amazon AWS (ingyenes évnyi szolgáltatást adnak, de havi korláttal), Google Cloud (300 dollárt adnak a számlára, amit év közben felhő hosting szolgáltatásokra költhetnek) , Yandex.Cloud (4000 rubelt adnak 2 hónapig), Microsoft Azure (ingyenes hozzáférést biztosítanak a népszerű szolgáltatásokhoz egy évig, + 12 500 rubelt bármely szolgáltatásért egy hónapig). Így ezen szolgáltatók bármelyikét kipróbálhatja anélkül, hogy egy fillért költene, de hozzávetőleges véleményt kaphat a nyújtott szolgáltatás minőségéről és színvonaláról.
A választott úttól függően csak az fog változni a jövőben, hogy ki a felelős egy vagy több igazgatási területért. Ha saját magát üzemelteti, akkor meg kell értenie, hogy az elektromos áram, az internet, maga a szerver és a rajta telepített szoftver megszakítása - mindez teljes mértékben az Ön vállán van. A képzéshez és a teszteléshez azonban ez több mint elég.
Ha nincs olyan plusz géped, amely kiszolgáló szerepet tölthet be, akkor a második vagy a harmadik módszert kell használnia. A második eset megegyezik az elsővel, azzal az eltéréssel, hogy a szerver elérhetőségéért és teljesítményéért a felelősséget a hoster vállára hárítja. A szerver és a szoftver adminisztrációja továbbra is az Ön irányítása alatt áll.
És végül a felhőszolgáltatók kapacitásának bérbeadásának lehetősége. Itt szinte bármit beállíthat automatikus vezérléssel anélkül, hogy túl sok technikai részletbe menne bele. Ezenkívül egy gép helyett több párhuzamosan futó példány is lehet, amelyek például az alkalmazás különböző részeiért felelősek, miközben költsége nem sokban tér el egy dedikált szerver birtoklásától. Ezenkívül vannak eszközök a hangszereléshez, a konténerezéshez, az automatikus telepítéshez, a folyamatos integrációhoz és még sok máshoz! Az alábbiakban ezek közül néhányat megvizsgálunk.
Általánosságban a szerver infrastruktúra így néz ki: van egy úgynevezett „orchestrator” (az „orchestráció” több szerverpéldány kezelésének folyamata), amely egy szerverpéldányon kezeli a környezeti változásokat, egy virtualizációs konténer (opcionális, de meglehetősen gyakran használt), amely lehetővé teszi az alkalmazás elkülönített logikai rétegekre való felosztását, valamint a Continuous Integration szoftvert, amely lehetővé teszi a hosztolt kód frissítését „szkripteken” keresztül.
Tehát a hangszerelés lehetővé teszi a kiszolgálók állapotának megtekintését, a kiszolgálókörnyezet frissítéseinek bevezetését vagy visszaállítását és így tovább. Eleinte ez a szempont nem valószínű, hogy téged érint, hiszen ahhoz, hogy bármit is lehessen hangszerelni, több szerverre van szükség (lehet egy is, de miért kell ez?), ahhoz pedig, hogy több szerver legyen, ezekre van szükség. Az ilyen irányú eszközök közül a legnépszerűbb a Kubernetes, amelyet a Google.
A következő lépés a virtualizáció az operációs rendszer szintjén. Napjainkban elterjedt a „dockerizálás” fogalma, amely az eszközből származik Dokkmunkás, amely az egymástól elszigetelt, de egy operációs rendszer keretében elindított konténerek funkcionalitását biztosítja. Mit jelent ez: ezekben a konténerekben futtathat egy alkalmazást, vagy akár egy alkalmazáskészletet, amelyek azt hiszik, hogy csak ők az egész operációs rendszerben, anélkül, hogy gyanítanák valaki más létezését ezen a gépen. Ez a funkció nagyon hasznos különböző verziójú azonos alkalmazások, vagy egyszerűen ütköző alkalmazások indításához, valamint egy alkalmazás részeinek rétegekre osztásához. Ez a rétegöntés később képbe írható, amely felhasználható például egy alkalmazás telepítésére. Vagyis ennek a képnek a telepítésével és a benne lévő tárolók telepítésével kész környezetet kap az alkalmazás futtatásához! Az első lépésekben ezt az eszközt mind információs célokra használhatja, mind pedig az alkalmazási logika különböző rétegekre osztásával valós előnyökhöz. De itt érdemes elmondani, hogy nem mindenkinek van szüksége dokkolásra, és nem mindig. A dokkolózás olyan esetekben indokolt, amikor az alkalmazás „töredezett”, apró részekre oszlik, amelyek mindegyike a saját feladatáért felelős, az úgynevezett „mikroszolgáltatási architektúra”.
Ezen túlmenően a környezet biztosítása mellett gondoskodnunk kell az alkalmazás hozzáértő telepítéséről is, amely magában foglal mindenféle kódátalakítást, az alkalmazáshoz kapcsolódó könyvtárak és csomagok telepítését, tesztek futtatását, értesítéseket ezekről a műveletekről stb. Itt kell figyelnünk egy olyan fogalomra, mint a „folyamatos integráció” (CI – Folyamatos integráció). Ezen a területen jelenleg a Jenkins a fő eszköz (a Java nyelven írt CI szoftver kezdetben kissé bonyolultnak tűnhet), Travis C.I. (Ruby nyelven írva, szubjektív, valamivel egyszerűbb Jenkinsazonban továbbra is szükség van bizonyos ismeretekre a telepítési konfiguráció terén), Gitlab CI (írva Ruby és Go).
Tehát, miután beszéltünk arról, hogy milyen környezetben fog működni az alkalmazása, itt az ideje, hogy végre megvizsgáljuk, milyen eszközöket kínál a modern világ ezeknek az alkalmazásoknak a létrehozásához.
Kezdjük az alapokkal: háttér (backend) – szerver rész. A nyelvválasztást, az alapfunkciók halmazát és az előre meghatározott struktúrát (keretrendszert) itt elsősorban a személyes preferenciák határozzák meg, de ennek ellenére érdemes megfontolni (a szerző véleménye a nyelvekről meglehetősen szubjektív, bár állításokkal). elfogulatlan leíráshoz):
- A Python meglehetősen barátságos nyelv egy tapasztalatlan felhasználó számára, elnéz néhány hibát, de elég szigorú is tud lenni a fejlesztővel, hogy ne csináljon semmi rosszat. Már egy meglehetősen érett és értelmes nyelv, amely 1991-ben jelent meg.
- Go - egy nyelv a Google-tól, szintén meglehetősen barátságos és kényelmes, meglehetősen könnyű lefordítani és letölteni egy futtatható fájlt bármilyen platformon. Lehet egyszerű és kellemes, de lehet összetett és komoly is. Friss és fiatal, viszonylag nemrég, 2009-ben jelent meg.
- Rust kicsit idősebb korábbi, 2006-ban megjelent kollégájánál, de társaihoz képest még elég fiatal. A tapasztaltabb fejlesztőket célozza meg, bár még mindig sok alacsony szintű feladatot próbál megoldani a programozó számára.
- A Java a kereskedelmi fejlesztés veteránja, 1995-ben vezették be, és ma az egyik leggyakrabban használt nyelv a vállalati alkalmazásfejlesztésben. Alapkoncepcióinak és nehéz beállításainak köszönhetően a futási idő meglehetősen nagy kihívást jelent egy kezdő számára.
- Az ASP.net a Microsoft által kiadott alkalmazásfejlesztő platform. A funkcionalitás írására elsősorban a 2000-ben megjelent C# nyelvet (ejtsd: C Sharp) használják. Bonyolultsága hasonló a Java és a Rust közötti szinthez.
- Az eredetileg HTML előfeldolgozásra használt PHP jelenleg, bár abszolút vezető szerepet tölt be a nyelvi piacon, a használat visszaesése felé mutat. Alacsony belépési küszöbe és egyszerű kódírása van, ugyanakkor meglehetősen nagy alkalmazások fejlesztésekor a nyelv funkcionalitása nem biztos, hogy elegendő.
Nos, alkalmazásunk utolsó része - a legkézzelfoghatóbb a felhasználó számára - frontend (frontend) – az alkalmazás arca; a felhasználó ezzel a résszel lép kapcsolatba közvetlenül.
Anélkül, hogy belemennénk a részletekbe, a modern frontend három pilléren, kereteken (és nem annyira) áll a felhasználói felületek létrehozásához. Ennek megfelelően a három legnépszerűbb:
- A ReactJS nem keretrendszer, hanem könyvtár. Valójában a keretrendszer csak abban különbözik a büszke címtől, hogy néhány funkció hiányzik a „dobozból” és manuálisan kell telepíteni őket. Így ennek a könyvtárnak az „előkészítésének” számos változata létezik, amelyek egyedi kereteket alkotnak. Egy kezdő számára ez egy kicsit nehéz lehet, néhány alapelv és az építési környezet meglehetősen agresszív beállítása miatt. A gyors kezdéshez azonban használhatja a „create-react-app” csomagot.
- A VueJS egy keretrendszer felhasználói felületek létrehozására. Ebből a hármasságból joggal veszi fel a legfelhasználóbarátabb keretrendszer címet, a Vue-ban való fejlesztésnél alacsonyabb a belépési korlát, mint a többi említett testvéreké. Ráadásul ő a legfiatalabb köztük.
- Az Angular ezek közül a keretrendszerek közül a legösszetettebbnek tekinthető, az egyetlen, amelyre szükség van Gépelt (kiegészítő a Javascript nyelvhez). Gyakran használják nagyvállalati alkalmazások építésére.
Összegezve a fent leírtakat, arra a következtetésre juthatunk, hogy egy alkalmazás mostani telepítése gyökeresen eltér attól, ahogy ez a folyamat korábban zajlott. Azonban senki sem akadályozza meg abban, hogy a „telepítést” a régi módon végezze. De vajon az induláskor megspórolt kevés idő megéri-e azt a rengeteg hibát, amit egy fejlesztőnek, aki ezt az utat választja, meg kell lépnie? Azt hiszem, a válasz nem. Ha kicsit több időt szán ezeknek az eszközöknek a megismerésére (és ennél több nem is kell, mert meg kell értenie, hogy szükség van-e rájuk az aktuális projektben vagy sem), kijátszhatja, jelentősen csökkentve pl. , a környezettől függő szellemhibák esetei, amelyek csak az éles szerveren jelennek meg, éjszakai elemzés arról, hogy mi vezetett a szerver összeomlásához, és miért nem indul el, és még sok más.
Forrás: will.com