Hoy en día, para crear tu propia aplicación web, no basta con saber desarrollarla. Un aspecto importante es la configuración de las herramientas para el despliegue de la aplicación, la monitorización, así como la gestión y administración del entorno en el que opera. La era del despliegue manual está quedando atrás; incluso para proyectos pequeños, las herramientas de automatización pueden ofrecer beneficios significativos. Al realizar un despliegue manualmente, a menudo podemos olvidar transferir algo, considerar algún matiz o ejecutar una prueba olvidada, y esta lista puede seguir bastante larga.
Este artículo puede ser útil para aquellos que están comenzando a aprender los fundamentos de la creación de aplicaciones web y desean comprender mejor los términos y convenciones básicos.
Así que, la construcción de aplicaciones se puede dividir en 2 partes: todo lo que se relaciona con el código de la aplicación y todo lo que se relaciona con el entorno en el que se ejecuta ese código. El código de la aplicación, a su vez, se divide en backend (el que se ejecuta en el servidor, a menudo: lógica de negocio, autorización, almacenamiento de datos, etc.) y frontend (el que se ejecuta en la máquina del usuario: a menudo interfaz y lógica asociada).
Comencemos, posiblemente, con el entorno.
La base para el funcionamiento de cualquier código, sistema o software es el sistema operativo, así que a continuación examinaremos los sistemas más populares disponibles en el mercado de hosting y ofreceremos una breve descripción de ellos:
Windows Server – la famosa Windows, pero en su versión de servidor. Algunas funcionalidades disponibles en la versión de Windows para clientes (normal) no están presentes aquí, como ciertos servicios de recopilación de estadísticas y software de este tipo; sin embargo, hay un conjunto de utilidades para la administración de redes y software básico para el despliegue (web, ftp, …). En general, Windows Server se ve y funciona como una Windows normal, pero cuesta 2 veces más que su equivalente normal. Sin embargo, dado que probablemente realizarás el despliegue de la aplicación en un servidor dedicado/virtual, el costo final para ti puede aumentar, pero no será crítico. Dado que la plataforma Windows ocupa un lugar predominante en el mercado de sistemas operativos para usuarios, su edición de servidor será la más familiar para la mayoría de los usuarios. servidores (web, ftp, ...). En general, Windows Server se presenta como una versión normal de Windows, hace los mismos sonidos que Windows, sin embargo, su costo es el doble que el de la versión estándar. Sin embargo, dado que la implementación de la aplicación probablemente se realizará en un servidor dedicado/virtual, el costo final para usted puede aumentar, pero no de manera crítica. Dado que la plataforma Windows ocupa un espacio dominante en el mercado de sistemas operativos de usuario, su edición de servidor será la más familiar para la mayoría de los usuarios.
Unix-similar system. Traditional operations in these systems do not presume the presence of a familiar graphical interface, offering the user only a console as a control element. For an inexperienced user, working in this format can pose challenges, especially considering the exit from quite a popular text editor. Vim, a question related to this has garnered over 1.8 million views in 6 years. The main distributions (editions) of this family are: Debian — a popular distribution, where package versions are primarily focused on LTS (Long Term Support – long-term support), which results in significant reliability and stability of the system and packages; Ubuntu – contains distributions of all packages in their latest versions, which may affect stability, but allows for the use of features provided with new versions; Red Hat Enterprise Linux – an OS, positioned for commercial use, is paid, however, it includes support from software suppliers, some proprietary packages, and driver packages; CentOS – an open-source variation of Red Hat Enterprise Linux, differs by the absence of proprietary packages and support.
For those who are just starting to explore this field, my recommendation would be the systems Windows Server, o Ubuntu. If we consider Windows, its primary advantage is the familiarity of the system, Ubuntu – more tolerance to updates, and in turn, for example, fewer issues when launching projects on technologies that require new versions.
So, having settled on an OS, let’s move on to the set of tools that allow deploying (installing), updating, and monitoring the application or its parts on the server.
The next important decision will be where to host your application and the server for it. Currently, the three most common options are:
- Hosting (keeping) the server yourself — the most budget-friendly option, but you will need to order a static IP from a provider, so your resource does not change its address over time.
- Renting a Dedicated Server (VDS) – and managing its administration and load scaling yourself.
- Pagar (a menudo se ofrece una prueba gratuita de las funcionalidades de la plataforma) una suscripción a algún servicio de alojamiento en la nube donde es bastante común el modelo de pago por recursos utilizados. Los representantes más destacados de esta categoría son: Amazon AWS (ofrecen un año de uso gratuito con un límite mensual), Google Cloud (ofrecen $300 en crédito que se pueden gastar durante el año en servicios de la nube de hospedaje), Yandex.Облако (ofrecen 4000 rublos por 2 meses), Microsoft Azure (ofrecen acceso gratuito a servicios populares durante un año, más 12,500 rublos para cualquier servicio durante un mes). De esta manera, se puede probar cualquiera de estos proveedores sin gastar un centavo, pero obteniendo una opinión aproximada sobre la calidad y el nivel del servicio prestado.
Dependiendo del camino elegido, solo cambiará el hecho de quién, en su mayoría, asume la responsabilidad en un área específica de la administración. Si usted aloja por sí mismo, debe entender que cualquier interrupción en el suministro eléctrico, Internet, el servidor mismo, el software desplegado en él, todo esto recae completamente sobre sus hombros. Sin embargo, para aprender y probar, esto es más que suficiente.
Si no tiene una máquina adicional que pueda funcionar como servidor, entonces querrá optar por la segunda o tercera opción. El segundo caso es idéntico al primero, salvo que traslada la responsabilidad por la disponibilidad del servidor y su capacidad a las espaldas del proveedor de alojamiento. La administración del servidor y del software aún estará bajo su control.
Y, finalmente, la opción de alquilar recursos de proveedores de nube. Aquí puede configurar la gestión automatizada de prácticamente cualquier cosa sin profundizar mucho en los matices técnicos. Además, en lugar de una sola máquina, puede tener varias instancias (ejemplares) que se ejecuten en paralelo y que, por ejemplo, pueden encargarse de diferentes partes de la aplicación, sin diferir mucho en costo de poseer un servidor dedicado. Además, aquí hay herramientas de orquestación, contenedorización, despliegue automático, integración continua y mucho más. Algunas de estas cosas las examinaremos a continuación.
En general, la infraestructura del servidor se ve de la siguiente manera: tenemos lo que se llama un "orquestador" ("orquestación" — el proceso de gestionar múltiples instancias de servidores), que gestiona los cambios del entorno en la instancia del servidor, un contenedor de virtualización (opcional, pero a menudo utilizado), que permite separar la aplicación en capas lógicas aisladas, y un software de Integración Continua que permite actualizar el código alojado a través de "scripts".
Entonces, la orquestación le permite ver el estado de los servidores, realizar "aplicaciones" o "reversiones" de las actualizaciones del entorno del servidor, y más. Al principio, este aspecto probablemente no le afectará, ya que para orquestar algo se necesitan varios servidores (puede que utilice uno, pero ¿para qué?). Y para tener varios servidores, se necesita una demanda de ellos. Entre las herramientas de esta área, Kubernetes es la más reconocida, desarrollada por Google.
El siguiente nivel es la virtualización a nivel de SO. Actualmente, el término "dockerización" se ha vuelto muy común, que proviene de la herramienta Docker, que proporciona la funcionalidad de contenedores aislados entre sí, pero que se ejecutan en el contexto de un solo sistema operativo. ¿Qué significa esto? En cada uno de estos contenedores, se puede ejecutar una aplicación, o incluso un conjunto de aplicaciones, que se comportarán como si fueran las únicas en todo el sistema operativo, sin sospechar de la existencia de otras en la misma máquina. Esta función es muy útil tanto para ejecutar las mismas aplicaciones en diferentes versiones, o simplemente aplicaciones que entran en conflicto, así como para descomponer partes de una aplicación en capas. Esta copia de capas se puede grabar en una imagen, que se puede usar, por ejemplo, para implementar la aplicación. Es decir, al instalar esta imagen y desplegar los contenedores que contiene, obtienes un entorno listo para ejecutar tu aplicación. En sus primeros pasos, puedes utilizar esta herramienta tanto con fines de familiarización como para obtener beneficios reales, distribuyendo la lógica de la aplicación en diferentes capas. Sin embargo, es importante mencionar que la dockerización no es necesaria para todos, ni siempre. La dockerización es justificable en casos donde la aplicación está 'fragmentada', dividida en partes pequeñas, cada una responsable de su tarea, lo que se conoce como 'arquitectura de microservicios'.
Además, además de asegurar el entorno, también necesitamos asegurar un despliegue adecuado de la aplicación, que incluya diversas transformaciones de código, instalación de bibliotecas y paquetes relacionados con la aplicación, ejecución de pruebas, notificaciones sobre estas operaciones, etc. Aquí, debemos prestar atención a un concepto llamado 'Integración Continua' (CI – Integración Continua). Los principales herramientas en este campo en este momento son Jenkins (una herramienta para CI, escrita en Java, que puede parecer un poco complicada al principio), Travis CI (escrita en Ruby, subjetivamente un poco más fácil que Jenkins, aunque aún requiere algunos conocimientos sobre configuración de despliegue),(escrita en Gitlab CI Ruby y Go ). Así que, después de hablar sobre el entorno en el que trabajará tu aplicación, ha llegado el momento de ver finalmente qué herramientas nos ofrece el mundo moderno para crear estas aplicaciones.).
Comencemos con lo básico:
Comencemos con lo básico: Backend (backend) - parte del servidor. La elección del lenguaje, conjunto de funciones básicas y estructura predefinida (framework) aquí se determina principalmente por preferencias personales, aunque vale la pena mencionar para su consideración (la opinión del autor sobre los lenguajes es bastante subjetiva, aunque intenta ser imparcial):
- Python es un lenguaje bastante amigable para el usuario inexperto, perdona algunos errores, pero también puede ser bastante estricto con el desarrollador para que no cometa errores graves. Es un lenguaje de programación ya bastante maduro y considerado, que apareció en 1991.
- Go es un lenguaje de la compañía Google, también es bastante amigable y conveniente, es bastante fácil compilar y obtener un archivo ejecutable en cualquier plataforma. Puede ser simple y agradable, pero también puede ser complejo y serio. Es fresco y joven, apareció relativamente recientemente, en 2009.
- Rust es un poco más viejo que su colega anterior, lanzado en 2006, sigue siendo bastante joven en comparación con sus hermanos. Está orientado a desarrolladores más experimentados, aunque todavía intenta resolver muchas tareas de bajo nivel por el programador.
- Java es un veterano del desarrollo comercial, apareció en 1995, y es uno de los lenguajes más utilizados en el desarrollo de aplicaciones empresariales en este momento. Con sus conceptos básicos y la complejidad de configurar el entorno de ejecución, puede volverse bastante complicado para los principiantes.
- ASP.net es una plataforma para el desarrollo de aplicaciones lanzada por Microsoft. Para escribir la funcionalidad, principalmente se utiliza el lenguaje C# (se pronuncia C Sharp), que apareció en 2000. En términos de complejidad, es comparable a un nivel entre Java y Rust.
- PHP, que originalmente se utilizó para preprocesar HTML, aún mantiene el liderazgo absoluto en el mercado de lenguajes, aunque se observa una tendencia a la disminución de su uso. Se caracteriza por su bajo umbral de entrada y la simplicidad en la escritura del código, pero al mismo tiempo, en el desarrollo de aplicaciones bastante grandes, la funcionalidad del lenguaje puede resultar insuficiente.
Y la parte final de nuestra aplicación - la más tangible para el usuario - Frontend (frontend) - es la cara de su aplicación, es con esta parte con la que el usuario interactúa directamente.
Sin entrar en detalles, el front-end moderno se basa en tres pilares, frameworks (y otros menos comunes), para la creación de interfaces de usuario. Por lo tanto, los tres más populares son:
- ReactJS – no es un framework, sino una biblioteca. En realidad, se diferencia del orgulloso título de framework solo por la falta de algunas funciones "listas para usar" y la necesidad de instalarlas manualmente. Así, hay varias maneras de "preparar" esta biblioteca, formando sus propios frameworks. Para un principiante puede ser un poco complicado, debido a algunos principios básicos y a la configuración agresiva del entorno de construcción. Sin embargo, para un inicio rápido, se puede utilizar el paquete "create-react-app".
- VueJS – es un framework para construir interfaces de usuario. De este trío, con razón se lleva el título del framework más amigable para el usuario, ya que el umbral de entrada para desarrollar en Vue es más bajo que el de sus otros hermanos mencionados. Además, entre ellos es el más joven.
- Angular – se considera el más complejo de los frameworks mencionados, el único que requiere la presencia de TypeScript (una extensión del lenguaje Javascript). A menudo se utiliza para construir grandes aplicaciones empresariales.
Resumiendo lo anterior, se puede concluir que hoy en día el despliegue de una aplicación difiere radicalmente de cómo se realizaba este proceso en el pasado. Sin embargo, nadie impide realizar el "deploy" a la antigua. Pero, ¿vale la pena el poco tiempo ahorrado en el inicio por la enorme cantidad de tropiezos que le esperan al desarrollador que elige este camino? Creo que la respuesta es "no". Al dedicar un poco más de tiempo a familiarizarse con estas herramientas (y no se necesita mucho más, ya que debe entender si las necesita en su proyecto actual o no), podrá recuperar ese tiempo, reduciendo significativamente, por ejemplo, los casos de errores fantasma, que dependen del entorno y se manifiestan solo en el servidor de producción, los análisis nocturnos de qué causó la caída del servidor y por qué no se inicia, y mucho más.
Fuente: habr.com
