Per crear la teva pròpia aplicació web en els nostres dies, no n'hi ha prou amb poder-la desenvolupar. Un aspecte important és la configuració d'eines per al desplegament d'aplicacions, el seguiment, així com la gestió i l'administració de l'entorn en el qual opera. A mesura que l'era del desplegament manual s'esvaeix en l'oblit, fins i tot per a projectes petits, les eines d'automatització poden aportar beneficis tangibles. Quan es desplega "a mà", sovint podem oblidar-nos de moure alguna cosa, tenir en compte aquest o aquell matís, executar una prova oblidada, aquesta llista es pot continuar durant molt de temps.
Aquest article pot ajudar aquells que estan aprenent els conceptes bàsics de la creació d'aplicacions web i volen entendre una mica els termes i les convencions bàsiques.
Així doncs, la creació d'aplicacions encara es pot dividir en 2 parts: tot allò relacionat amb el codi de l'aplicació i tot allò relacionat amb l'entorn en què s'executa aquest codi. El codi de l'aplicació, al seu torn, també es divideix en codi de servidor (el que s'executa al servidor, sovint: lògica empresarial, autorització, emmagatzematge de dades, etc.), i codi de client (el que s'executa a la màquina de l'usuari: sovint). la interfície i la lògica relacionada amb ella).
Comencem pel dimecres.
La base per al funcionament de qualsevol codi, sistema o programari és el Sistema Operatiu, així que a continuació veurem els sistemes més populars del mercat d'allotjament i els farem una breu descripció:
Servidor de Windows - el mateix Windows, però en una variació de servidor. Algunes funcionalitats disponibles a la versió client (normal) de Windows no estan presents aquí, per exemple, alguns serveis per recopilar estadístiques i programari similar, però hi ha un conjunt d'utilitats per a l'administració de xarxes, programari bàsic per desplegar servidors (web, ftp, ...). En general, Windows Server s'assembla a Windows normal, s'assembla a Windows normal, però costa 2 vegades més que el seu homòleg habitual. Tanmateix, tenint en compte que el més probable és que implementeu l'aplicació en un servidor dedicat/virtual, el cost final per a vosaltres, tot i que pot augmentar, no és crític. Com que la plataforma Windows ocupa un lloc aclaparador al mercat del sistema operatiu de consum, la seva edició de servidor serà la més familiar per a la majoria dels usuaris.
Unix-Sistema similar. El treball tradicional en aquests sistemes no requereix la presència d'una interfície gràfica familiar, oferint a l'usuari només una consola com a element de control. Per a un usuari sense experiència, treballar en aquest format pot ser difícil, quin és el cost de sortir d'un editor de text que és força popular en dades empenta, una pregunta relacionada amb això ja ha rebut més d'6 milions de visualitzacions en 1.8 anys. Les principals distribucions (edicions) d'aquesta família són: Debian - una distribució popular, les versions de paquets que hi ha es centren principalment en LTS (Suport a llarg termini – suport durant molt de temps), que s'expressa en una fiabilitat i estabilitat bastant alta del sistema i dels paquets; Ubuntu – conté distribucions de tots els paquets en les seves últimes versions, que poden afectar l'estabilitat, però us permeten utilitzar la funcionalitat que inclou les noves versions; Red Hat Enterprise Linux - SO, posicionat per a ús comercial, és de pagament, però inclou suport de proveïdors de programari, alguns paquets propietaris i paquets de controladors; CentOS - codi obert una variació de Red Hat Enterprise Linux, caracteritzada per l'absència de paquets propietaris i suport.
Per a aquells que tot just comencen a dominar aquesta àrea, la meva recomanació seria sistemes Servidor de WindowsO Ubuntu. Si considerem Windows, això és principalment la familiaritat del sistema, Ubuntu – més tolerància a les actualitzacions i, al seu torn, per exemple, menys problemes a l'hora de llançar projectes sobre tecnologies que requereixen noves versions.
Per tant, un cop decidit pel sistema operatiu, passem a un conjunt d'eines que us permeten desplegar (instal·lar), actualitzar i supervisar l'estat de l'aplicació o les seves parts al servidor.
La següent decisió important serà la col·locació de la vostra aplicació i el servidor per a aquesta. De moment, les més habituals són 3 maneres:
- Allotjar (mantenir) un servidor pel vostre compte és l'opció més econòmica, però haureu de demanar una IP estàtica al vostre proveïdor perquè el vostre recurs no canviï la seva adreça amb el temps.
- Llogueu un servidor dedicat (VDS) i administreu-lo de manera independent i escala les càrregues
- Pagueu (sovint et donen l'oportunitat de provar la funcionalitat de la plataforma gratuïtament) per una subscripció a algun allotjament en núvol, on el model de pagament dels recursos utilitzats és força habitual. Els representants més destacats d'aquesta direcció: Amazon AWS (ofereixen un any gratuït d'ús dels serveis, però amb un límit mensual), Google Cloud (donen 300 dòlars al compte, que es poden gastar durant l'any en serveis d'allotjament al núvol) , Yandex.Cloud (ofereixen 4000 rubles durant 2 mesos), Microsoft Azure (ofereixen accés gratuït als serveis populars durant un any, + 12 rubles per a qualsevol servei durant un mes). Així, podeu provar qualsevol d'aquests proveïdors sense gastar un cèntim, però obtenint una opinió aproximada sobre la qualitat i el nivell del servei prestat.
Segons el camí escollit, l'únic que canviarà en el futur és qui és en gran part responsable d'aquesta o aquella àrea de l'administració. Si us allotgeu, haureu d'entendre que qualsevol interrupció de l'electricitat, Internet, el propi servidor, el programari desplegat en ell, tot això està a les vostres espatlles. Tanmateix, per a la formació i les proves, això és més que suficient.
Si no teniu una màquina addicional que pugui fer el paper de servidor, voldreu utilitzar la segona o la tercera manera. El segon cas és idèntic al primer, amb l'excepció que transfereix la responsabilitat de la disponibilitat del servidor i el seu poder a les espatlles de l'hoste. L'administració del servidor i del programari encara està sota el vostre control.
I finalment, l'opció de llogar la capacitat dels proveïdors de núvol. Aquí podeu configurar el control automatitzat de gairebé qualsevol cosa sense entrar en massa detalls tècnics. A més, en comptes d'una màquina, podeu tenir diverses instàncies en execució paral·lel, que poden, per exemple, ser responsables de diferents parts de l'aplicació, tot i que no difereixen gaire en el cost de tenir un servidor dedicat. I a més, hi ha eines per a l'orquestració, la contenidorització, el desplegament automàtic, la integració contínua i molt més! Veurem algunes d'aquestes coses a continuació.
En general, la infraestructura del servidor té aquest aspecte: tenim un anomenat "orquestrator" ("l'orquestració" és el procés de gestió de diverses instàncies del servidor), que gestiona els canvis ambientals en una instància del servidor, un contenidor de virtualització (opcional, però força). utilitzat sovint), que us permet dividir l'aplicació en capes lògiques aïllades i programari d'integració contínua, que permet actualitzar el codi allotjat mitjançant "scripts".
Per tant, l'orquestració us permet veure l'estat dels servidors, llançar o revertir actualitzacions a l'entorn del servidor, etc. Al principi, és poc probable que aquest aspecte t'afecti, ja que per orquestrar qualsevol cosa calen diversos servidors (en pots tenir un, però per què és necessari?), i per tenir diversos servidors en necessites. Entre les eines en aquesta direcció, la més popular és Kubernetes, desenvolupada per google.
El següent pas és la virtualització a nivell del sistema operatiu. Actualment, s'ha generalitzat el concepte de "dockerització", que prové de l'eina estibador, que proporciona la funcionalitat de contenidors aïllats entre si, però llançats en el context d'un sistema operatiu. Què vol dir això: en cadascun d'aquests contenidors es pot executar una aplicació, o fins i tot un conjunt d'aplicacions, que creuran que són les úniques de tot el sistema operatiu, sense ni tan sols sospitar de l'existència d'una altra persona en aquesta màquina. Aquesta funció és molt útil per llançar aplicacions idèntiques de diferents versions, o simplement aplicacions conflictives, així com per dividir peces d'una aplicació en capes. Aquest model de capa es pot escriure més tard en una imatge, que es pot utilitzar, per exemple, per desplegar una aplicació. És a dir, instal·lant aquesta imatge i desplegant els contenidors que conté, obtindreu un entorn preparat per executar la vostra aplicació! En els primers passos, podeu utilitzar aquesta eina tant amb finalitats informatives com per obtenir beneficis molt reals dividint la lògica de l'aplicació en diferents capes. Però val la pena dir aquí que no tothom necessita dockerització, i no sempre. La dockerització es justifica en els casos en què l'aplicació està “fragmentada”, dividida en petites parts, cadascuna responsable de la seva tasca, l'anomenada “arquitectura de microservei”.
A més, a més de proporcionar l'entorn, hem de garantir un desplegament competent de l'aplicació, que inclogui tot tipus de transformacions de codi, instal·lació de biblioteques i paquets relacionats amb l'aplicació, execució de proves, notificacions sobre aquestes operacions, etc. Aquí hem de parar atenció a un concepte com ara "integració contínua" (CI – Integració contínua). Les principals eines en aquesta àrea actualment són Jenkins (el programari CI escrit en Java pot semblar una mica complicat al principi), Travis C.I. (escrit en Rubí, subjectiu, una mica més senzill Jenkins, però, encara es requereixen alguns coneixements en l'àmbit de la configuració del desplegament), Gitlab CI (escrit a Ruby and Go).
Així doncs, després d'haver parlat de l'entorn en què funcionarà la vostra aplicació, és hora de mirar finalment quines eines ens ofereix el món modern per crear aquestes mateixes aplicacions.
Comencem per les bases: Backend (backend) - part del servidor. L'elecció de la llengua, el conjunt de funcions bàsiques i l'estructura predefinida (marc) aquí està determinada principalment per les preferències personals, però, tanmateix, val la pena esmentar-ho per a la seva consideració (l'opinió de l'autor sobre les llengües és força subjectiva, encara que amb una afirmació a una descripció imparcial):
- Python és un llenguatge bastant amigable per a un usuari sense experiència, perdona alguns errors, però també pot ser força estricte amb el desenvolupador perquè no faci res dolent. Ja és un llenguatge bastant madur i significatiu, que va aparèixer el 1991.
- Go - un llenguatge de Google, també és bastant amigable i còmode, és bastant fàcil compilar i obtenir un fitxer executable a qualsevol plataforma. Pot ser senzill i agradable, o pot ser complex i seriós. Fresc i jove, va aparèixer relativament recentment, el 2009.
- Rust és una mica més gran que el seu col·lega anterior, llançat el 2006, però encara és bastant jove en comparació amb els seus companys. Dirigit a desenvolupadors més experimentats, tot i que encara intenta resoldre moltes tasques de baix nivell per al programador.
- Java és un veterà del desenvolupament comercial, introduït l'any 1995, i és un dels llenguatges més utilitzats en el desenvolupament d'aplicacions empresarials actuals. Amb els seus conceptes bàsics i una configuració pesada, el temps d'execució pot arribar a ser força difícil per a un principiant.
- ASP.net és una plataforma de desenvolupament d'aplicacions publicada per Microsoft. Per escriure la funcionalitat, s'utilitza principalment el llenguatge C# (pronunciat C Sharp), que va aparèixer l'any 2000. La seva complexitat és comparable al nivell entre Java i Rust.
- PHP, utilitzat originalment per al preprocessament d'HTML, actualment, tot i que ostenta el lideratge absolut en el mercat de l'idioma, hi ha una tendència cap a una disminució de l'ús. Té un llindar d'entrada baix i una facilitat per escriure codi, però al mateix temps, quan es desenvolupen aplicacions bastant grans, la funcionalitat del llenguatge pot ser que no sigui suficient.
Bé, la part final de la nostra aplicació, la més tangible per a l'usuari, frontend (frontend): és la cara de la vostra aplicació, és amb aquesta part que l'usuari interactua directament.
Sense entrar en detalls, la interfície moderna es basa en tres pilars, frameworks (i no tant), per crear interfícies d'usuari. En conseqüència, els tres més populars són:
- ReactJS no és un marc, sinó una biblioteca. De fet, el marc difereix del seu títol orgullós només per l'absència d'algunes funcions "des de la caixa" i la necessitat d'instal·lar-les manualment. Així, hi ha diverses variacions de la "preparació" d'aquesta biblioteca, formant marcs únics. Pot ser una mica difícil per a un principiant, a causa d'uns principis bàsics i d'una configuració força agressiva de l'entorn de construcció. Tanmateix, per començar ràpidament, podeu utilitzar el paquet "create-react-app".
- VueJS és un marc per crear interfícies d'usuari. D'aquesta trinitat, pren amb raó el títol del marc més fàcil d'utilitzar per al desenvolupament a Vue, la barrera d'entrada és més baixa que la dels altres germans esmentats. A més, és el més jove d'ells.
- Angular es considera el més complex d'aquests marcs, l'únic que requereix TypeScript (complement per al llenguatge Javascript). Sovint s'utilitza per crear aplicacions empresarials grans.
Resumint el que s'ha escrit anteriorment, podem concloure que ara desplegar una aplicació és radicalment diferent de com es procedia aquest procés abans. Tanmateix, ningú us impedeix fer el "desplegament" de la manera antiga. Però el poc temps estalviat al principi val la pena la gran quantitat d'errors que haurà de trepitjar un desenvolupador que esculli aquest camí? Crec que la resposta és no. Si dediques una mica més de temps a familiaritzar-te amb aquestes eines (i no necessites més que això, perquè has d'entendre si les necessites en el teu projecte actual o no), pots jugar-ho, reduint-ho significativament, per exemple , casos d'errors fantasma segons l'entorn i que només apareixen al servidor de producció, anàlisi nocturna del que va provocar l'error del servidor i per què no s'inicia, i molt més.
Font: www.habr.com