Ellenőrzőlista webes alkalmazások létrehozásához és közzétételéhez

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:

Windows Server - pont az az egy Windows, de szerveroldali verzióban. Bizonyos funkciók elérhetők a kliens (normál) verzióban. Windows Például néhány statisztikai gyűjtő szolgáltatás és hasonló szoftver nem található meg itt, de van egy sor segédprogram a hálózati adminisztrációhoz, alapvető szoftver a telepítéshez szervereket (web, ftp, …). Általánosságban elmondható, Windows Server úgy néz ki, mint egy normális Windows, úgy hápog, mint egy normális Windows, azonban kétszer annyiba kerül, mint a standard megfelelője. Figyelembe véve azonban, hogy valószínűleg egy dedikált/virtuális szerveren fogod telepíteni az alkalmazást, a végső költség emelkedhet, de ez nem lesz kritikus. Mivel a platform Windows domináns pozíciót foglal el a fogyasztói operációs rendszerek piacán, és szerverkiadása lesz a legtöbb felhasználó számára 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 kapcsolódó kérdés már több mint 1.8 millió megtekintést kapott az elmúlt hat évben. A család főbb terjesztései (kiadásai) a következők: Debian — egy népszerű disztribúció, a benne található csomagok verziói főként LTS-orientáltak (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 - Operációs rendszer, 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 egy változata Linux, megkülönbözteti a saját csomagok és támogatás hiánya.

Azoknak, akik most kezdik elsajátítani ezt a területet, a rendszereket ajánlom Windows ServerVagy UbuntuHa figyelembe vesszük Windows, akkor ez mindenekelőtt a rendszer szokása, 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
  • Fizetés (gyakran a platform funkcióinak ingyenes kipróbálásával) egy felhőtárhely-szolgáltatás előfizetéséért, ahol a használatalapú fizetési modell meglehetősen gyakori. Ennek a megközelítésnek a legkiemelkedőbb képviselői az Amazon AWS (amely egy év ingyenes szolgáltatást kínál, de havi limittel), a Google Cloud (amely 300 dolláros kreditet kínál, amelyet egész évben felhőszolgáltatásokra lehet elkölteni). hosting), Yandex.Cloud (4000 rubel két hónapra) és Microsoft Azure (ingyenes hozzáférés népszerű szolgáltatásokhoz egy évig, plusz 12 500 rubel bármely szolgáltatásért egy hónapra). Így bármelyik szolgáltatót kipróbálhatja anélkül, hogy egy fillért is költene, de mégis durva képet kaphat a szolgáltatás minőségéről és szintjé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

Vásároljon megbízható tárhelyet DDoS védelemmel, VPS VDS szerverekkel rendelkező webhelyekhez 🔥 Vásároljon megbízható weboldal tárhelyet DDoS védelemmel, VPS VDS szerverekkel | ProHoster