Lista de verificación para a creación e publicación de aplicacións web

Para crear a túa propia aplicación web no noso tempo, non abonda con poder desenvolvela. Un aspecto importante é a configuración de ferramentas para a implantación, monitorización e xestión de aplicacións, así como a xestión e administración do entorno no que opera. A medida que a era do despregue manual desaparece no esquecemento, incluso para proxectos pequenos, as ferramentas de automatización poden traer beneficios tanxibles. Ao implementar "a man", moitas veces podemos esquecernos de mover algo, ter en conta este ou aquel matiz, realizar unha proba esquecida, esta lista pódese continuar durante bastante tempo.

Este artigo pode axudar a aqueles que só están aprendendo os conceptos básicos para crear aplicacións web e queren entender un pouco os termos e convencións básicas.

Así, a construción de aplicacións aínda se pode dividir en 2 partes: todo o que se relaciona co código da aplicación e todo o que se relaciona co entorno no que se executa este código. O código da aplicación, pola súa banda, tamén se divide en código de servidor (o que se executa no servidor, moitas veces: lóxica empresarial, autorización, almacenamento de datos, etc.), e código de cliente (o que se executa na máquina do usuario: moitas veces). a interface e a lóxica relacionada con ela).

Comezamos polo mércores.

A base para o funcionamento de calquera código, sistema ou software é o Sistema Operativo, polo que a continuación veremos os sistemas máis populares no mercado de hospedaxe e faremos unha breve descrición:

Servidor de Windows - o mesmo Windows, pero nunha variación do servidor. Algunhas funcionalidades dispoñibles na versión cliente (normal) de Windows non están presentes aquí, por exemplo, algúns servizos para a recollida de estatísticas e software similar, pero hai un conxunto de utilidades para a administración de rede, software básico para a implantación de servidores (web, ftp, ...). En xeral, Windows Server parece Windows normal, charlatán como Windows normal, con todo, custa 2 veces máis que o seu homólogo normal. Non obstante, dado que o máis probable é que implante a aplicación nun servidor dedicado/virtual, o custo final para vostede, aínda que pode aumentar, non é crítico. Dado que a plataforma Windows ocupa un lugar abrumador no mercado do SO de consumo, a súa edición de servidor será a máis familiar para a maioría dos usuarios.

Unix-Sistema similar. O traballo tradicional nestes sistemas non require a presenza dunha interface gráfica familiar, ofrecendo ao usuario só unha consola como elemento de control. Para un usuario inexperto, traballar neste formato pode ser difícil, só cal é o custo de saír dun editor de texto que é bastante popular en datos vitalidade, unha pregunta relacionada con isto xa recibiu máis de 6 millóns de visitas en 1.8 anos. As principais distribucións (edicións) desta familia son: Debian - unha distribución popular, as versións de paquetes nela están centradas principalmente en LTS (Soporte a longo prazo – soporte durante moito tempo), que se expresa nunha fiabilidade e estabilidade bastante altas do sistema e dos paquetes; Ubuntu – contén distribucións de todos os paquetes nas súas últimas versións, o que pode afectar á estabilidade, pero permítelle utilizar a funcionalidade que inclúe as novas versións; Red Hat Enterprise Linux – OS, posicionado para uso comercial, é de pago, con todo, inclúe soporte de provedores de software, algúns paquetes propietarios e paquetes de controladores; CentOS - código aberto unha variación de Red Hat Enterprise Linux, caracterizada pola ausencia de paquetes propietarios e soporte.

Para aqueles que están empezando a dominar esta área, a miña recomendación serían sistemas Servidor de WindowsOu Ubuntu. Se consideramos Windows, esta é principalmente a familiaridade do sistema, Ubuntu – máis tolerancia ás actualizacións, e á súa vez, por exemplo, menos problemas á hora de lanzar proxectos en tecnoloxías que requiren novas versións.

Entón, unha vez decidido o SO, pasemos a un conxunto de ferramentas que che permiten implantar (instalar), actualizar e supervisar o estado da aplicación ou das súas partes no servidor.

A seguinte decisión importante será a colocación da súa aplicación e do servidor para ela. Polo momento, as máis comúns son 3 formas:

  • Aloxar (manter) un servidor por conta propia é a opción máis económica, pero terás que solicitar unha IP estática ao teu provedor para que o teu recurso non cambie o seu enderezo co paso do tempo.
  • Alugue un servidor dedicado (VDS) e adminístreo de forma independente e escala as cargas
  • Pague (moitas veces danche a oportunidade de probar a funcionalidade da plataforma de forma gratuíta) por unha subscrición a algún hospedaxe na nube, onde o modelo de pago dos recursos utilizados é bastante común. Os representantes máis destacados desta dirección: Amazon AWS (dan un ano gratuíto de uso dos servizos, pero cun límite mensual), Google Cloud (danlle 300 dólares á conta, que se poden gastar durante o ano en servizos de hospedaxe na nube) , Yandex.Cloud (dan 4000 rublos . durante 2 meses), Microsoft Azure (dar acceso gratuíto a servizos populares durante un ano, + 12 500 rublos para calquera servizo durante un mes). Así, podes probar calquera destes provedores sen gastar un centavo, pero obtendo unha opinión aproximada sobre a calidade e o nivel do servizo prestado.

Dependendo do camiño elixido, o único que cambiará no futuro é quen é en gran parte responsable de tal ou cal área da administración. Se te hospedas, debes entender que calquera interrupción na electricidade, na Internet, no propio servidor, no software despregado nel, todo isto está completamente sobre os teus ombreiros. Non obstante, para adestrar e probar, isto é máis que suficiente.

Se non tes unha máquina adicional que poida desempeñar o papel de servidor, quererás usar a segunda ou terceira forma. O segundo caso é idéntico ao primeiro, coa excepción de que trasladas a responsabilidade da dispoñibilidade do servidor e do seu poder aos ombreiros do host. A administración do servidor e do software aínda está baixo o teu control.

E por último, a opción de alugar a capacidade dos provedores de nube. Aquí podes configurar o control automatizado de case calquera cousa sen entrar en demasiados detalles técnicos. Ademais, en lugar dunha máquina, pode ter varias instancias en execución paralela, que poden, por exemplo, ser responsables de diferentes partes da aplicación, aínda que non difiren moito en custo de ter un servidor dedicado. E ademais, hai ferramentas para a orquestración, a contenerización, o despregamento automático, a integración continua e moito máis! Veremos algunhas destas cousas a continuación.

En xeral, a infraestrutura do servidor ten o seguinte aspecto: temos un chamado "orquestrator" ("orquestración" é o proceso de xestión de varias instancias do servidor), que xestiona os cambios ambientais nunha instancia do servidor, un contedor de virtualización (opcional, pero bastante usado frecuentemente), que permite dividir a aplicación en capas lóxicas illadas e software de integración continua, que permite actualizar o código aloxado mediante "scripts".

Entón, a orquestración permítelle ver o estado dos servidores, lanzar ou retrotraer actualizacións no entorno do servidor, etc. Nun primeiro momento, é pouco probable que este aspecto che afecte, xa que para orquestrar algo fai falla varios servidores (podes ter un, pero por que é necesario?), e para ter varios servidores necesítaos. Entre as ferramentas nesta dirección, a máis popular é Kubernetes, desenvolvida por Google.

O seguinte paso é a virtualización a nivel de SO. Hoxe en día xeneralizouse o concepto de “dockerización”, que provén da ferramenta Estivador, que proporciona a funcionalidade de contedores illados entre si, pero lanzados no contexto dun sistema operativo. Que significa isto: en cada un destes contedores pódese executar unha aplicación, ou mesmo un conxunto de aplicacións, que crerán que son as únicas de todo o SO, sen sequera sospeitar da existencia doutra persoa nesta máquina. Esta función é moi útil para lanzar aplicacións idénticas de diferentes versións, ou simplemente aplicacións en conflito, así como para dividir partes dunha aplicación en capas. Este molde de capa pódese escribir posteriormente nunha imaxe, que se pode usar, por exemplo, para implementar unha aplicación. É dicir, instalando esta imaxe e despregando os contedores que contén, obtén un ambiente preparado para executar a súa aplicación. Nos primeiros pasos, pode utilizar esta ferramenta tanto con fins informativos como para obter beneficios moi reais dividindo a lóxica da aplicación en diferentes capas. Pero paga a pena dicir aquí que non todo o mundo precisa dockerización, e non sempre. A dockerización xustifícase nos casos en que a aplicación está “fragmentada”, dividida en pequenas partes, cada unha responsable da súa propia tarefa, a chamada “arquitectura de microservizos”.

Ademais, ademais de proporcionar o entorno, cómpre garantir un despregamento competente da aplicación, que inclúa todo tipo de transformacións de código, instalación de bibliotecas e paquetes relacionados coa aplicación, realización de probas, notificacións sobre estas operacións, etc. Aquí debemos prestar atención a un concepto como "integración continua" (CI – Integración Continua). As principais ferramentas nesta área neste momento son Jenkins (o software de CI escrito en Java pode parecer un pouco complicado ao principio), Travis C.I. (escrito en Ruby, subxectivo, algo máis sinxelo Jenkins, non obstante, aínda son necesarios algúns coñecementos no campo da configuración do despregue), Gitlab CI (escrito en Ruby and Go).

Entón, despois de falar sobre o entorno no que funcionará a túa aplicación, é hora de ver finalmente que ferramentas nos ofrece o mundo moderno para crear estas mesmas aplicacións.

Comecemos polo básico: motor (backend) - parte do servidor. A elección da lingua, o conxunto de funcións básicas e a estrutura predefinida (marco) aquí está determinada principalmente polas preferencias persoais, pero, con todo, paga a pena mencionar para consideración (a opinión do autor sobre as linguas é bastante subxectiva, aínda que con pretensión a unha descrición imparcial):

  • Python é unha linguaxe bastante amigable para un usuario inexperto, perdoa algúns erros, pero tamén pode ser bastante estrito co programador para que non faga nada malo. Xa é unha linguaxe bastante madura e significativa, que apareceu en 1991.
  • Go - unha linguaxe de Google, tamén é bastante amigable e cómodo, é bastante sinxelo compilar e obter un ficheiro executable en calquera plataforma. Pode ser sinxelo e agradable, ou pode ser complexo e serio. Fresco e novo, apareceu relativamente recentemente, en 2009.
  • Rust é un pouco máis vello que o seu anterior colega, lanzado en 2006, pero aínda é bastante novo en comparación cos seus compañeiros. Dirixido a desenvolvedores máis experimentados, aínda que aínda intenta resolver moitas tarefas de baixo nivel para o programador.
  • Java é un veterano do desenvolvemento comercial, introducido en 1995, e é unha das linguaxes máis utilizadas no desenvolvemento de aplicacións empresariais na actualidade. Cos seus conceptos básicos e unha configuración pesada, o tempo de execución pode chegar a ser bastante desafiante para un principiante.
  • ASP.net é unha plataforma de desenvolvemento de aplicacións lanzada por Microsoft. Para escribir a funcionalidade, úsase principalmente a linguaxe C# (pronunciado C Sharp), que apareceu en 2000. A súa complexidade é comparable ao nivel entre Java e Rust.
  • PHP, orixinalmente usado para o preprocesamento HTML, na actualidade, aínda que ocupa un liderado absoluto no mercado da lingua, hai unha tendencia a un descenso no seu uso. Ten un baixo limiar de entrada e facilidade para escribir código, pero ao mesmo tempo, cando se desenvolven aplicacións bastante grandes, a funcionalidade da linguaxe pode non ser suficiente.

Ben, a parte final da nosa aplicación - a máis tanxible para o usuario - Interface (frontend): é a cara da súa aplicación; é con esta parte coa que o usuario interactúa directamente.

Sen entrar en detalles, o frontend moderno aséntase sobre tres piares, frameworks (e non tanto), para crear interfaces de usuario. En consecuencia, os tres máis populares son:

  • ReactJS non é un framework, senón unha biblioteca. En realidade, o marco difire do seu orgulloso título só pola ausencia dalgunhas funcións "fóra da caixa" e pola necesidade de instalalas manualmente. Así, hai varias variacións da "preparación" desta biblioteca, formando marcos únicos. Pode ser un pouco difícil para un principiante, debido a algúns principios básicos e á configuración bastante agresiva do entorno de construción. Non obstante, para comezar rápido, podes usar o paquete "create-react-app".
  • VueJS é un framework para crear interfaces de usuario. Desta trinidade, leva xustamente o título do marco máis amigable para o usuario; para o desenvolvemento en Vue, a barreira de entrada é menor que a dos outros irmáns mencionados. Ademais, é o máis novo de entre eles.
  • Angular considérase o máis complexo destes cadros, o único que require TypeScript (complemento para a linguaxe Javascript). Moitas veces úsase para crear aplicacións de grandes empresas.

Resumindo o escrito anteriormente, podemos concluír que agora a implantación dunha aplicación é radicalmente diferente de como se producía este proceso antes. Non obstante, ninguén che impide facer o "despliegue" á antiga usanza. Pero o pouco tempo aforrado ao principio vale a pena a gran cantidade de erros que terá que pisar un programador que elixa este camiño? Creo que a resposta é non. Ao dedicar un pouco máis de tempo a familiarizarse con estas ferramentas (e non precisa máis que iso, porque cómpre entender se as precisas no seu proxecto actual ou non), pode xogar, reducindo significativamente, por exemplo , casos de erros fantasma segundo o entorno e que aparecen só no servidor de produción, análise nocturna do que provocou o fallo do servidor e por que non se inicia, e moito máis.

Fonte: www.habr.com

Engadir un comentario