UT1. Implantación de arquitecturas web

En este tema se estudian las arquitecturas web y los distintos modelos que permiten organizar cómo funciona una aplicación en Internet. También se ven las características de los servidores web y de aplicaciones, su instalación y configuración básica. Además, se repasan los protocolos HTTP, la estructura de una aplicación web, todo ello orientado a comprender y gestionar el despliegue de aplicaciones web de forma correcta.

Internet

Internet es una red mundial de computadoras (nodos) conectadas entre sí que permite compartir información y comunicarse a través de diferentes servicios y protocolos, como páginas web, correo electrónico o redes sociales.

Un nodo es cada dispositivo o punto de conexión dentro de una red, como un ordenador, un servidor, un router o un móvil, que puede enviar, recibir o compartir información.
Un protocolo es un conjunto de reglas y normas que permiten que dos o más dispositivos en una red se comuniquen entre sí de manera correcta y entendible.

Ejemplo

Cuando accedes a una página web, tu navegador (cliente) envía una solicitud al servidor web donde está alojada la página. El servidor responde enviando los datos de la página, que tu navegador interpreta y muestra en pantalla. Todo esto ocurre gracias a protocolos como HTTP o HTTPS, que definen cómo se deben estructurar y transmitir estos mensajes.

Protocolo TCP/IP

El protocolo TCP/IP es el conjunto de reglas que hace posible esa comunicación. Está formado principalmente por:

TCP (Transmission Control Protocol): se encarga de dividir la información en paquetes y asegurarse de que lleguen completos y en orden.
IP (Internet Protocol): se ocupa de dirigir esos paquetes hasta el dispositivo correcto mediante direcciones IP.

Protocolos mas conocidos

HTTP (HyperText Transfer Protocol): permite la comunicación entre navegadores y servidores para mostrar páginas web.
HTTPS (HTTP Secure): versión segura de HTTP que cifra la información para protegerla.
FTP (File Transfer Protocol): se usa para transferir archivos entre un cliente y un servidor.
SMTP (Simple Mail Transfer Protocol): se emplea para enviar correos electrónicos.
IMAP/POP3: protocolos para recibir y gestionar correos electrónicos desde el servidor.
DNS (Domain Name System): traduce los nombres de dominio (ej. google.com) en direcciones IP.
TCP (Transmission Control Protocol): garantiza que los datos lleguen completos y en orden.
IP (Internet Protocol): se encarga de dirigir los datos a la dirección correcta en la red.

URL

Una URL (Uniform Resource Locator) es la dirección única que identifica un recurso en Internet, como una página web, una imagen o un archivo, y permite acceder a él a través del navegador.

Ejemplo

En la URL https://www.ejemplo.com/carpeta/pagina.html:

https es el protocolo que indica cómo se accede al recurso (en este caso, de forma segura).
www.ejemplo.com es el nombre de dominio que identifica el servidor donde se encuentra el recurso.
/carpeta/pagina.html es la ruta específica dentro del servidor que lleva al recurso solicitado.

La estructura básica de una URL es:

Dominio: el nombre principal que identifica un sitio web en Internet. Ejemplo: ejemplo.com
Subdominio: una división dentro del dominio que organiza el contenido. Ejemplo: blog.ejemplo.com (blog es el subdominio).
TDL (Top Level Domain / Dominio de nivel superior): la parte final del dominio, que indica el tipo u origen. Ejemplo: .com, .org, .es
Puerto: número que indica el canal de comunicación que se usa entre cliente y servidor. Ejemplo: :80 (HTTP) o :443 (HTTPS).
Slug: el texto que identifica una página o recurso dentro de la web, normalmente después del dominio o carpeta. Ejemplo: ejemplo.com/articulos/servidores-web → servidores-web es el slug.
Parámetros: información extra que se añade a la URL después de un ?, y se separan con &. Se usan para búsquedas, filtros o identificadores. Ejemplo: ejemplo.com/buscar?producto=libro&id=25

Servidores web

Un servidor web es un programa (y también el equipo donde se ejecuta) que almacena, procesa y entrega páginas web a los navegadores de los usuarios mediante el protocolo HTTP/HTTPS.

Características generales de un servidor web:

Atiende peticiones de clientes (navegadores) y envía respuestas.
Funciona con protocolos web (principalmente HTTP y HTTPS).
Almacena recursos como páginas HTML, imágenes, vídeos, CSS, JavaScript, etc.
Es configurable, permitiendo definir seguridad, puertos, permisos y directorios.
Soporta concurrencia, es decir, atiende a muchos usuarios al mismo tiempo.
Es multiplataforma, ya que puede ejecutarse en distintos sistemas operativos.

Ejemplos comunes: Apache, Nginx, Microsoft IIS.

Protocolo HTTP

El protocolo de transferencia de hipertexto (HTTP, Hypertext Transfer Protocol) es el motor que da vida a Internet, ya que es la base para la web (www, world wide web).

1991 – Nace HTTP/0.9: la primera versión creada por Tim Berners-Lee. Muy simple, solo permitía transferir documentos de texto en HTML.
1996 – HTTP/1.0: se añade el soporte para más tipos de contenido (imágenes, audio, etc.), cabeceras y códigos de estado.
1997 – HTTP/1.1: la versión más usada durante muchos años. Introduce mejoras como conexiones persistentes y mayor eficiencia en el uso de recursos.
2015 – HTTP/2: pensado para acelerar la web. Permite enviar varios recursos a la vez en una sola conexión y comprime las cabeceras.
2022 – HTTP/3: la versión más moderna. Usa un protocolo llamado QUIC (basado en UDP) para hacer la comunicación más rápida y segura, especialmente en móviles.

¿HTTP/3 es HTTPS?

No, HTTP/3 y HTTPS no son lo mismo, aunque suelen ir juntos:

HTTP/3: es la nueva versión del protocolo HTTP, que funciona sobre QUIC (en lugar de TCP), lo que lo hace más rápido y eficiente.
HTTPS es la versión segura de HTTP, que cifra los datos con TLS para proteger la comunicación entre cliente y servidor.

En la práctica, HTTP/3 siempre se usa con HTTPS, porque QUIC está diseñado para funcionar con TLS 1.3 integrado. Es decir, en Internet lo verás como HTTPS/3 aunque técnicamente sean cosas diferentes.

Funcionamiento del protocolo HTTP

Gráficamente podemos resumir el proceso de comunicación HTTP como sigue:

Un usuario accede a una URL, seleccionando un enlace de un documento HTML.
Se abre una conexión TCP/IP con el servidor. En ese momento, se realiza la petición HTTP. Para ello, se envía el comando necesario (GET, POST, HEAD,...), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada y un conjunto variable de información, que incluye datos sobre las capacidades del navegador (browser), datos opcionales para el servidor, etc.
El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información.
Se cierra la conexión TCP. Este proceso se repite en cada acceso al servidor HTTP.

Ejemplo

Por ejemplo, si se recoge un documento HTML en cuyo interior están insertadas 2 imágenes y 1 vídeo, el proceso anterior se repite cuatro veces, una para el documento HTML y tres más para los recursos (la dos imágenes y el vídeo).

Métodos HTTP

HTTP define un conjunto de métodos de petición para indicar la acción que se desea realizar para un recurso determinado.

GET: se utiliza para solicitar cualquier tipo de recurso al servidor. Cada vez que se pulsa sobre un enlace o se teclea directamente a una URL se usa este comando. Como resultado, el servidor HTTP enviará el recurso correspondiente.
HEAD: se utiliza para solicitar información sobre el recurso: su tamaño, su tipo, su fecha de modificación… Es usado por los gestores de cachés de páginas o los servidores proxy, para conocer cuándo es necesario actualizar la copia que se mantiene del recurso. Con HEAD se podrá comprobar la última fecha de modificación de un recurso antes de traer una nueva copia del mismo.
POST: sirve para enviar información al servidor, por ejemplo, los datos contenidos en un formulario. El servidor pasará esta información a un proceso encargado de su tratamiento.

La versión 1.1 del protocolo incorpora unos pocos comandos más como son: OPTIONS, PUT, DELETE, TRACE y CONNECT. Veamos algunos de ellos:

OPTIONS: Devuelve los métodos HTTP que el servidor soporta para una URL específica. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico.
DELETE: Sirve para eliminar un recurso especificado en la URL, aunque pocas veces sera permitido por un servidor web.
TRACE: Comando que permite hacer un sondeo para saber todos los dispositivos de la red por los que pasa nuestra petición. Así podremos descubrir si la petición pasa a través dispositivos intermedios o proxys antes de llegar al servidor Web.
PUT: Puede verse como el comando inverso a GET. Nos permite escribir datos en el servidor o, lo que es lo mismo, poner un recurso en la URL que se especifique. Si el recurso no existe lo crea sino lo reemplaza. La diferencia con POST puede ser algo confusa; mientras que POST está orientado a la creación de nuevos contenidos, PUT está más orientado a la actualización de recursos (aunque también podría crearlos).

Ejemplo de petición y respuesta

Una petición HTTP es un conjunto de líneas que el navegador envía al servidor. Incluye:

El recurso solicitado, el método que se aplicará y la versión del protocolo utilizada.
Los campos del encabezado de solicitud: es un conjunto de líneas opcionales que permiten aportar información adicional sobre la solicitud y/o el cliente (navegador, sistema operativo, etc.). Cada una de estas líneas está formada por un nombre que describe el tipo de encabezado, seguido de dos puntos (:) y el valor del encabezado.
El cuerpo de la solicitud: es un conjunto de líneas opcionales que deben estar separadas de las líneas precedentes por una línea en blanco y que, por ejemplo, permiten la transmisión de datos al servidor de un formulario a través del método POST.

La sintaxis de una respuesta HTTP es un conjunto de líneas que el servidor envía al navegador. Incluye:

Una línea de estado donde figura el versión del protocolo usada, un código de estado/error y un texto con el significado de dicho código.
- Los posibles códigos de estado se identifican con números de tres cifras y se clasifican en cinco grupos.
  
  Códigos de estado HTTP.
Los campos del encabezado de la respuesta: Conjunto de líneas opcionales que aportan información adicional sobre la respuesta y/o el servidor.
El cuerpo de la respuesta: que contiene el recurso (objeto) solicitado

Cabeceras HTTP

Las cabeceras HTTP son información adicional que acompaña a cada petición o respuesta HTTP, y que indican detalles sobre la comunicación (tipo de contenido, idioma, caché, seguridad, etc.).

Tipos principales de cabeceras

Cabeceras de petición (Request Headers): las envía el cliente al servidor.
- Host: indica el dominio al que se conecta.
- User-Agent: información sobre el navegador o cliente.
- Accept: formatos que el cliente acepta (ej. text/html, application/json).
- Authorization: credenciales de acceso.
Cabeceras de respuesta (Response Headers): las envía el servidor al cliente.
- Content-Type: tipo de contenido devuelto (ej. text/html, image/png).
- Set-Cookie: envía cookies al cliente.
- Cache-Control: controla el almacenamiento en caché.
- Location: redirección a otra URL.
Cabeceras generales: pueden aparecer en peticiones o respuestas.
- Date: fecha y hora de la comunicación.
- Connection: cómo se gestiona la conexión (ej. keep-alive).

Tipos MIME

Un tipo MIME (Multipurpose Internet Mail Extensions) es una etiqueta que indica el tipo de contenido de un archivo o recurso que se transmite por Internet, para que el navegador o aplicación sepa cómo manejarlo.

Estructura: tipo/subtipo

Ejemplo

Ejemplo: text/html

Tipos MIME más comunes:

text/	image/	audio/	video/	application/
text/plain	image/jpeg	audio/mpeg	video/mp4	application/json
text/html	image/png	audio/ogg	video/webm	application/pdf
text/css	image/gif			application/zip

Los tipos MIME son esenciales porque dicen al navegador “esto es un HTML, esto es una imagen, esto un PDF” y así lo interpreta correctamente.

Arquitecturas web

La arquitectura web es la organización estructural y funcional de los componentes que conforman una aplicación accesible por la web: clientes (navegadores, apps móviles), servidores (aplicación, APIs), almacenamiento, redes y servicios externos. Incluye decisiones sobre:

Distribución de responsabilidades (qué hace cada componente).
Protocolos y formatos de comunicación (HTTP, WebSocket, gRPC, JSON, etc.).
Estrategias de rendimiento, seguridad y disponibilidad.
Despliegue e infraestructura (contenerización, orquestación, serverless).

Una buena arquitectura busca un equilibrio entre rendimiento, coste, complejidad y facilidad de mantenimiento.

Componentes comunes en arquitecturas web

Los componentes comunes en arquitecturas web son las partes fundamentales que interactúan para proporcionar la funcionalidad de la aplicación. Estos incluyen:

Cliente: navegador, app móvil, cliente IoT. Realiza peticiones y presenta la interfaz.
Capa de presentación: HTML/CSS/JS o apps nativas, SPAs (React/Angular/Vue).
API / Servidor de aplicaciones: expone lógica de negocio mediante APIs REST, GraphQL, gRPC.
Base de datos: relacional (Postgres, MySQL), NoSQL (MongoDB, Cassandra), time-series, buscadores (Elasticsearch).
Cachés: Redis, Memcached — reducen latencia y carga de BD.
Colas y brokers de mensajes: RabbitMQ, Kafka — desacoplo y procesamiento asíncrono.
CDN: entrega de contenido estático y multimedia cerca del usuario.
Balanceadores de carga (LB): distribuyen tráfico (HAProxy, Nginx, LB cloud).
API Gateway / BFF: punto de entrada para APIs, adaptación a clientes.
Servicios externos: pago, notificaciones, identity providers.
Observability: logs centralizados, métricas (Prometheus), trazas distribuidas (Jaeger).
Seguridad: firewalls, WAF, autenticación y autorización, TLS.

Modelos

Cliente–Servidor (classic)

El modelo cliente–servidor clásico es la arquitectura más sencilla y una de las más antiguas en el ámbito de los sistemas distribuidos. En ella, se establece una separación clara entre dos roles principales:

Cliente: la entidad que solicita un servicio o recurso (por ejemplo, un navegador web que pide una página).
Servidor: la entidad que provee dicho servicio o recurso (por ejemplo, un servidor web que envía la página solicitada).

La comunicación se realiza habitualmente mediante protocolos bien definidos, como HTTP, FTP, SMTP, entre otros, dependiendo del tipo de servicio. El servidor se encarga de procesar las peticiones y devolver respuestas adecuadas, mientras que el cliente se limita a consumir lo que el servidor ofrece.

El modelo cliente–servidor clásico se emplea en escenarios relativamente simples, donde no se requiere una gran capacidad de distribución o complejidad en el procesamiento. Ejemplos típicos incluyen:

Aplicaciones web básicas con páginas estáticas o dinámicas simples.
Servicios monolíticos en los que toda la lógica de negocio se encuentra en un único servidor.
Aplicaciones de red tradicionales, como servidores de archivos o bases de datos que responden directamente a solicitudes de clientes.

Ventajas

Posee varias ventajas que lo hacen adecuado para ciertos contextos como:

Simplicidad: es fácil de entender e implementar, ya que se basa en un flujo claro de petición–respuesta.
Bajo coste inicial: no requiere una infraestructura compleja para funcionar.
Madurez tecnológica: existen numerosos estándares, herramientas y protocolos que lo respaldan.
Facilidad de mantenimiento en entornos pequeños: con pocos clientes, el modelo resulta estable y suficiente.

Limitaciones

En cuanto a sus limitaciones, el modelo cliente–servidor clásico presenta varios desafíos:

Escalabilidad limitada: el crecimiento depende del escalado vertical del servidor (más CPU, más memoria, más disco), lo que tiene un límite físico y económico.
Punto único de fallo: si el servidor principal deja de funcionar y no existe un sistema de replicación o respaldo, todos los clientes pierden acceso al servicio.
Dependencia fuerte del servidor: la carga de trabajo recae en un único nodo central, lo que lo convierte en un cuello de botella.
Flexibilidad reducida: no es el modelo ideal para aplicaciones modernas que requieren alta disponibilidad, distribución geográfica o microservicios.

Arquitectura en capas (Layered / N-tier)

La arquitectura en capas, también conocida como arquitectura en n capas, es un patrón de diseño de software que organiza una aplicación en múltiples capas o niveles, cada una con responsabilidades específicas. Este enfoque facilita la separación de preocupaciones, mejora la mantenibilidad y permite una mayor flexibilidad en el desarrollo y despliegue de aplicaciones. Cada capa interactúa únicamente con la capa adyacente, lo que reduce las dependencias y facilita las pruebas unitarias.

Debemos distinguir entre un concepto de capas lógicas (layered) y físicas (n-tier) donde las capas pueden estar distribuidas en diferentes servidores o máquinas.

Tier

Capa física de una arquitectura. Supone un nuevo elemento hardware separado físicamente. Las capas físicas más alejadas del cliente están más protegidas, tanto por firewalls como por VPN.

Ejemplo de arquitectura en tres capas físicas (3 tier):

Servidor Web
Servidor de Aplicaciones
Servidor de base de datos

Layer

Capa lógica de una arquitectura. No supone un nuevo elemento hardware separado físicamente. Las capas lógicas pueden estar implementadas en el mismo servidor físico.

Ejemplo de arquitectura en tres capas lógicas (3 layer):

Capa de presentación (interfaz de usuario)
Capa de lógica de negocio (procesamiento de datos)
Capa de datos (acceso y almacenamiento de datos)

Como se observa, cada una de las capas se puede implementar con diferentes lenguajes de programación y/o herramientas.

Arquitectura de tres capas físicas en tres lógicas.

MVC (Model-View-Controller)

El patrón de arquitectura MVC (Model-View-Controller) es un enfoque ampliamente utilizado en el desarrollo de aplicaciones web y de software en general. Este patrón divide una aplicación en tres componentes principales, cada uno con responsabilidades específicas:

Modelo (Model): representa la estructura de datos y la lógica de negocio de la aplicación. El modelo es responsable de gestionar el estado de la aplicación, interactuar con la base de datos y realizar operaciones relacionadas con los datos. No tiene conocimiento directo de la interfaz de usuario.
Vista (View): es la capa de presentación que se encarga de mostrar los datos al usuario. La vista recibe información del modelo y la presenta en un formato adecuado, como HTML, CSS y JavaScript en aplicaciones web. La vista no contiene lógica de negocio y no interactúa directamente con el modelo.
Controlador (Controller): actúa como intermediario entre el modelo y la vista. El controlador recibe las entradas del usuario (como clics o envíos de formularios), procesa esas entradas, actualiza el modelo según sea necesario y selecciona la vista adecuada para mostrar los resultados. El controlador contiene la lógica de flujo de la aplicación.

MVC es un patrón arquitectónico que separa los elementos conceptuales, lo que facilita el mantenimiento, la escalabilidad y la colaboración entre desarrolladores. Además, permite reutilizar componentes y mejorar la organización del código.

Página web estática y dinámica

Una página web estática es aquella que se entrega al usuario tal cual está almacenada en el servidor, sin modificaciones ni procesamiento adicional. Estas páginas suelen estar compuestas por archivos HTML, CSS y JavaScript que se cargan directamente en el navegador del usuario. Las páginas estáticas son rápidas de cargar, fáciles de implementar y mantener, y son ideales para contenido que no cambia con frecuencia, como blogs, portafolios, páginas de información y sitios web corporativos.

Por otro lado, una página web dinámica es aquella que se genera en tiempo real en función de las solicitudes del usuario o de otros factores. Estas páginas suelen utilizar lenguajes de programación del lado del servidor, como PHP, Python o Node.js, para crear contenido personalizado y interactivo. Las páginas dinámicas son más complejas de implementar y mantener, pero ofrecen una experiencia de usuario más rica y personalizada, ya que pueden adaptarse a las necesidades y preferencias de cada visitante.

Diferencia entre servidor web y servidor de aplicaciones

Servidor Web

Entrega contenido estático (HTML, CSS, imágenes, JS). También puede recibir solicitudes HTTP y pasarlas a otro sistema que ejecute la lógica.

Ejemplos: Apache HTTP Server, Nginx, Microsoft IIS.

Analogía

Es como el camarero que lleva la comida (HTML) a tu mesa pero no cocina nada.

Servidor de Aplicaciones

Ejecuta la lógica de negocio (procesos, cálculos, reglas, acceso a base de datos). Puede generar contenido dinámico (ej.: páginas construidas con datos de usuarios).

Suele correr sobre un servidor web, o integrarse con él.

Ejemplos: Tomcat, JBoss/WildFly, WebLogic, GlassFish, WebSphere.

Analogía

Es como el cocinero en la cocina: recibe la orden del mesero (petición), prepara el plato (procesa lógica de negocio) y se lo pasa al mesero para que lo entregue al cliente.

Tecnologías de virtualización de servidores y en contenedores.

La virtualización de servidores es una tecnología que permite crear múltiples entornos virtuales independientes en un solo servidor físico. Esto se logra mediante el uso de software de virtualización, que abstrae los recursos del hardware y los asigna a las máquinas virtuales (VMs). Cada VM funciona como un servidor completo con su propio sistema operativo, aplicaciones y configuraciones.

Si quisiéramos ejecutar varias aplicaciones aisladas, el primer enfoque sería usar varias máquinas físicas:

Pero esto es costoso y poco eficiente. La virtualización permite ejecutar múltiples aplicaciones en un solo servidor físico, cada una en su propia VM, lo que mejora la utilización de recursos y reduce costes.

Tecnologías de virtualización

VMware vSphere/ESXi: una plataforma de virtualización líder en la industria que permite crear y gestionar múltiples VMs en un entorno empresarial.
Microsoft Hyper-V: una solución de virtualización integrada en Windows Server que permite crear y administrar VMs.
KVM (Kernel-based Virtual Machine): una solución de virtualización de código abierto para Linux que convierte el kernel de Linux en un hipervisor.
VirtualBox: una herramienta de virtualización de código abierto y multiplataforma que permite crear y ejecutar VMs en sistemas Windows, macOS y Linux.

Contenedores

Los contenedores son una forma de virtualización a nivel de sistema operativo que permite empaquetar una aplicación y sus dependencias en un entorno aislado y portátil. A diferencia de las VMs, los contenedores comparten el mismo kernel del sistema operativo, lo que los hace más ligeros y rápidos de iniciar.

Mientras que una VM incluye un sistema operativo complet:

Un contenedor solo incluye la aplicación y sus dependencias, lo que reduce significativamente el tamaño y el consumo de recursos:

Tecnologías de contenedores

Docker: la plataforma de contenedores más popular que permite crear, desplegar y gestionar contenedores de manera sencilla.
Kubernetes: un sistema de orquestación de contenedores que automatiza la implementación, el escalado y la gestión de aplicaciones en contenedores.
Podman: una alternativa a Docker que permite gestionar contenedores sin necesidad de un demonio centralizado.

Diferencias clave entre VMs y contenedores

Característica	Máquinas Virtuales (VMs)	Contenedores
Aislamiento	Completo, cada VM tiene su propio SO	Parcial, comparten el mismo kernel del SO
Tamaño	Más grandes, incluyen un SO completo	Más pequeños, solo incluyen la aplicación y sus dependencias
Tiempo de inicio	Más lento, puede tardar minutos	Muy rápido, generalmente en segundos
Uso de recursos	Mayor, cada VM consume más recursos	Menor, más eficientes en el uso de recursos
Portabilidad	Menos portátil, depende del hipervisor	Muy portátil, pueden ejecutarse en cualquier entorno con el mismo SO base

Estructura y recursos que componen una aplicación web

Una aplicación web está formada por distintos componentes que colaboran entre sí:

Cliente (Front-end):
- Interfaz visible por el usuario (HTML, CSS, JavaScript).
- Frameworks comunes: React, Vue.js, Angular, Bootstrap.
Servidor (Back-end):
- Procesa peticiones, gestiona lógica de negocio y bases de datos.
Lenguajes y entornos: PHP, Node.js, Python (Django/Flask), Java (Spring), Ruby on Rails.
Base de datos:
- Almacena información persistente.
- Sistemas más usados: MySQL, PostgreSQL, MongoDB, SQLite.
Servidor web / de aplicaciones:
- Intermedia entre el cliente y la lógica de la aplicación.
Recursos adicionales:
- Archivos estáticos (imágenes, hojas de estilo, scripts).
- Configuraciones (variables de entorno, claves API, rutas).
- Logs de sistema, copias de seguridad, certificados SSL.

Una estructura típica de una aplicación web podría ser:

│├── public/                 # Archivos accesibles públicamente
│   ├── index.html
│   ├── styles.css
│   └── app.js
│├── src/                    # Código fuente del back-end
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   └── app.js
│├── config/                 # Configuraciones
│   └── db.js
│├── tests/                  # Pruebas unitarias e integración
│   ├── .env                 # Variables de entorno
│   ├── package.json         # Dependencias y scripts (Node.js)
│   └── README.md            # Documentación del proyecto

Documentación de los procesos realizados

La documentación técnica es esencial para asegurar la reproducibilidad, mantenimiento y transparencia del proceso de despliegue.

Tipos de documentación:

Documentación de instalación: detalla los pasos seguidos para instalar y configurar servidores y servicios.
Documentación de despliegue: describe cómo se publica una aplicación (entornos, rutas, versiones, dependencias).
Documentación de incidencias: recoge problemas encontrados y soluciones aplicadas.
Manual de administración: explica cómo mantener y monitorizar los servicios.
Documentación del entorno: versiones de software, puertos usados, estructura de red, volúmenes de datos.

Buenas prácticas:

Usar archivos README.md con instrucciones claras.
Mantener un control de versiones (Git) con commits descriptivos.
Documentar scripts de automatización (por ejemplo, Dockerfile, docker-compose.yml).
Incorporar diagramas de arquitectura (red, flujo de datos, despliegue).

Actividades

Todas las actividades deben justificarse con capturas de pantalla y explicaciones concisas de los pasos realizados.

A1.1 Instalación de Ubuntu Server en VirtualBox

Sigue la guía en el siguiente enlace para instalar Ubuntu Server en una máquina virtual utilizando VirtualBox Instalación de Ubuntu Server en VirtualBox.

A1.2 Acceso remoto a la máquina virtual

Configura el acceso remoto a la máquina virtual utilizando SSH. Asegúrate de que puedes conectarte a la máquina virtual desde tu sistema host utilizando un cliente SSH.

Realiza las las configuraciones necesarias en la máquina virtual para poder conectarte remotamente al servidor de un compañero de clase. Crea una archivo de texto dentro de la carpeta home del usuario con tu nombre y apellidos.

A1.3 Reenvio de puertos en VirtualBox

Configura la red de la maquina virtual en modo NAT y realiza el reenvío de puertos para poder acceder a tu servidor Ubuntu desde el host.

A1.4 Instalación de un servidor web Apache

Realiza la instalación y configuración básica de un servidor web Apache en Ubuntu Server. Asegúrate de que el servidor esté funcionando correctamente y pueda servir páginas web estáticas.

A1.5 Despliegue de una aplicación web simple

Desarrolla una aplicación web simple (por ejemplo, una página HTML con CSS y JavaScript) y despliega esta aplicación en el servidor web Apache que has configurado en la actividad A1.4. Verifica que la aplicación sea accesible desde un navegador web.