UT00 · De una URL a una aplicación en producción

Qué significa implantar una aplicación web, qué piezas intervienen y cómo razona un administrador cuando algo falla.

Introducción

Idea clave: una aplicación no está implantada porque exista su código. Debe poder desplegarse, ejecutarse, conectarse, protegerse, comprobarse, diagnosticarse, actualizarse y recuperarse.

Esta unidad es la entrada a IAW. Usaremos un laboratorio que simula decisiones propias de una implantación real, pero no pretende reproducir toda la complejidad de un entorno empresarial de producción: alta disponibilidad, monitorización continua, gestión avanzada de secretos, balanceo, capacidad, continuidad de negocio, etc.

1. RA y CE que trabajamos

RA1

RA1. Prepara el entorno de desarrollo y los servidores de aplicaciones Web instalando e integrando las funcionalidades necesarias.

En UT00 empezamos el RA1, pero no lo cerramos. La evidencia principal se completará en UT01.

CE trabajados directamente en UT00

CE	Qué demostramos en esta unidad
RA1.a	identificar el software que necesita una aplicación para funcionar
RA1.b	reconocer las tecnologías que intervienen y la función de cada una
RA1.d	diferenciar qué se procesa en cliente y qué se procesa en servidor
RA1.i	documentar un procedimiento y aportar evidencias comprensibles

CE que dejamos preparados para UT01

CE	Qué aparecerá después
RA1.c	instalación/configuración de servidor web y base de datos
RA1.e	módulos y componentes para procesar código en servidor
RA1.f	acceso de la aplicación a la base de datos
RA1.g	establecimiento y verificación de seguridad de acceso
RA1.h	uso de plataformas integradas de prueba y desarrollo

Regla para todo el módulo: que un concepto aparezca en una explicación no significa que el CE esté superado. Para considerarlo adquirido necesitaremos una evidencia observable.

Currículo oficial: Decreto 210/2010 de Extremadura · Real Decreto 1629/2009

2. ¿Qué es Implantación de Aplicaciones Web?

Una aplicación web puede estar perfectamente programada y, aun así, no prestar ningún servicio real.

Para que una persona pueda utilizarla alguien debe decidir y configurar, entre otras cosas:

dónde se ejecutará;
qué servidor web recibirá las peticiones;
qué runtime o servidor de aplicaciones necesita;
dónde se guardarán los datos;
cómo llegará la aplicación a la base de datos;
qué permisos tendrá cada proceso y cada cuenta;
qué nombre utilizarán los usuarios;
qué accesos deben estar permitidos o denegados;
qué logs miraremos ante una incidencia;
qué evidencia demostrará que el sistema completo funciona;
cómo volveremos a un estado anterior si un cambio sale mal.

Eso es implantación.

Desarrollo e implantación no son lo mismo

Desarrollo	Implantación / operación
¿Cómo programo la funcionalidad?	¿Qué necesita para ejecutarse?
¿Qué clases o funciones creo?	¿Qué proceso las ejecuta?
¿Cómo implemento el login?	¿Cómo llegan el navegador, el runtime y la BBDD a trabajar juntos?
¿Cómo guardo los datos desde código?	¿Dónde está el SGBD y con qué usuario puede conectarse la aplicación?
¿Mi código funciona localmente?	¿Funciona desde un cliente en el entorno desplegado?

IAW puede tocar código cuando el currículo lo requiere, pero su objetivo no es convertirse en DWES. Aquí nos interesa poner aplicaciones en servicio y administrarlas.

3. Una URL atraviesa varias capas

Recorrido de una petición

Figura 1. Una petición puede depender de resolución de nombres, servidor web, runtime, aplicación y datos.

Un administrador debe poder responder siempre:

¿Qué componentes existen?
¿Dónde se ejecuta cada uno?
¿Cómo se comunican?
¿Cómo demostraría cuál de ellos está fallando?

Lo observable y lo inferido

Si inspeccionamos una web pública podemos observar, por ejemplo, una URL, cabeceras HTTP, código de estado o recursos cargados.

No podemos concluir automáticamente qué base de datos usa, cuántos servidores existen o qué topología privada tiene.

Regla profesional: separa siempre hechos observables de hipótesis.

4. Cliente, servidor web, runtime, aplicación y datos

Cliente

Normalmente será el navegador. Envía una petición y recibe una respuesta.

GET /tickets/42 HTTP/1.1
Host: desk07.iaw.test

El navegador no ejecuta el PHP del servidor. Recibe el resultado generado: HTML, JSON, imágenes, CSS, JavaScript, etc.

Servidor web

Apache o NGINX pueden escuchar puertos, seleccionar un sitio, servir contenido estático, delegar procesamiento, registrar accesos y aplicar controles.

Runtime / servidor de aplicación

Depende de la tecnología: PHP-FPM, Tomcat, Node.js, Gunicorn/Uvicorn, etc.

Aplicación

Es el software que aporta la lógica: CMS, portal, API, herramienta colaborativa, aplicación propia…

Base de datos

Almacena información persistente. En nuestro laboratorio aparecerá principalmente MariaDB.

5. Estático y dinámico

Estático frente a dinámico

Figura 2. Un recurso estático puede terminar en Apache; una respuesta dinámica incorpora más capas.

Caso resuelto 1 · HTML sí, PHP no

Situación:

/index.html  → funciona
/info.php    → se descarga como texto

Qué sabemos: red y servidor web son capaces de entregar contenido.

Hipótesis prioritaria: la integración del procesamiento PHP no está configurada correctamente.

Qué no haríamos primero: reinstalar MariaDB. Todavía no hay evidencia que apunte a la base de datos.

6. Tres arquitecturas que debes reconocer

Tres arquitecturas

Figura 3. Todo en uno, dos niveles y multinivel separan responsabilidades de forma distinta.

Todo en uno

Apache, runtime, aplicación y BBDD comparten máquina. Es sencillo, pero oculta dependencias y mezcla responsabilidades.

Dos niveles

La aplicación se separa del SGBD. Nos obliga a comprender que:

MariaDB funciona localmente

no equivale a:

la aplicación puede conectarse a MariaDB por la red

Multinivel

Aparecen proxy/balanceo, varios nodos de aplicación y capa de datos. No la desplegaremos completa en UT00, pero debemos reconocerla.

Caso resuelto 2 · BBDD local sí, aplicación no

IAW-DB01: mariadb local → OK
IAW-WEB01: conexión TCP a 3306 → Connection refused

La prueba local demuestra que el SGBD funciona en DB01. No demuestra que escuche en la interfaz adecuada ni que sea accesible desde WEB01.

Siguiente pregunta: ¿hay un socket escuchando en la dirección/puerto esperados?

7. Laboratorio tipo

Topología IAW

Figura 4. Topología de referencia para separar cliente, aplicación y datos.

IAW-CLI01  192.168.60.30
IAW-WEB01  192.168.60.10
IAW-DB01   192.168.60.20

En WEB01 situaremos habitualmente Apache, PHP-FPM y la aplicación. En DB01, MariaDB. CLI01 actuará como cliente.

No siempre necesitaremos tres VM, pero pensar en tres roles nos ayuda a separar capas.

Convención por puesto

Cada alumno utilizará un número NN asignado por el profesor.

Ejemplo NN = 07:

desk07.iaw.test
portal07.iaw.test
cloud07.iaw.test
iawdesk_07
iawapp_07

La regla es pública; los datos personales del alumnado no lo son.

8. Caja de herramientas mínima

No tienes que memorizar hoy todas estas órdenes. Son un mapa de herramientas que iremos utilizando cuando exista una pregunta técnica concreta.

Pregunta	Herramienta típica
¿La máquina tiene la IP esperada?	`ip -br a`
¿Qué ruta usaría?	`ip route get DESTINO`
¿Qué puertos están escuchando?	`ss -lntp`
¿El servicio está activo?	`systemctl status SERVICIO`
¿Qué devuelve HTTP?	`curl -i URL` / `curl -I URL`
¿Qué registró Apache?	`access.log` / `error.log`
¿PHP está disponible?	`php -v`
¿Qué módulos PHP existen?	`php -m`
¿MariaDB responde?	cliente `mariadb` + prueba de red
¿Qué ocurrió en el sistema?	`journalctl` + logs del servicio

9. “Funciona” no significa que funcione todo

Funciona no basta

Figura 5. Una comprobación positiva de una capa no acredita toda la pila.

La frase:

«Apache está activo»

solo demuestra una parte.

Una aplicación dinámica puede necesitar además:

puerto accesible
+ VirtualHost correcto
+ runtime operativo
+ módulos necesarios
+ archivos y permisos
+ conexión a BBDD
+ credenciales y privilegios
+ lógica de aplicación

10. Diagnóstico por capas

Escalera de diagnóstico

Figura 6. El diagnóstico reduce el problema capa a capa.

Nuestro método será:

SÍNTOMA
  ↓
ALCANCE
  ↓
HIPÓTESIS
  ↓
PRUEBA DISCRIMINANTE
  ↓
CAUSA
  ↓
CAMBIO MÍNIMO
  ↓
VERIFICACIÓN
  ↓
DOCUMENTACIÓN

Caso resuelto 3 · por IP funciona, por nombre no

curl http://192.168.60.10/  → OK
curl http://desk07.iaw.test → no resuelve

Lo más razonable: priorizar resolución de nombres.

No empezaríamos reinstalando Apache porque ya tenemos evidencia de que responde por IP.

Caso resuelto 4 · `could not find driver`

La aplicación llega a ejecutar PHP, pero PHP informa de que no encuentra un controlador.

Eso orienta primero hacia extensión/controlador del runtime (por ejemplo el driver de acceso a MariaDB), no hacia DNS.

Caso resuelto 5 · `Access denied`

La red llega al SGBD y el servidor responde, pero rechaza la autenticación/autorización.

Prioridad: usuario, host permitido, contraseña y privilegios.

Un mensaje de error no es “el problema”. Es una evidencia que debemos interpretar.

11. Actividad 00.A · Radiografía de una petición

Sin instalar nada nuevo:

abre las herramientas de desarrollo del navegador;
visita una web pública;
localiza la petición del documento HTML;
anota método, URL, código de estado, tipo de contenido y una cabecera;
observa qué recursos adicionales se cargan;
dibuja dos columnas: observable / inferido.

Evidencia mínima

Una captura comentada y un esquema propio de máximo una página.

No se pide descubrir infraestructura privada. Se evalúa distinguir hechos de suposiciones.

12. Actividad 00.B · Puesta a punto del laboratorio

En la VM indicada por el profesor:

identifica hostname e interfaces;
anota IP y puerta de enlace;
comprueba conectividad básica;
localiza cómo consultarías servicios activos;
crea un snapshot/punto de retorno si el entorno lo permite;
documenta el estado inicial.

Al terminar deberás poder demostrar

hostname e IP identificados;
conectividad comprobada;
herramienta para consultar servicios;
punto de retorno creado o justificado;
evidencias legibles y explicadas.

13. Actividad 00.C · ¿Quién tiene la culpa?

Para cada caso indica:

capa prioritaria → primera prueba → qué resultado esperas observar

Los tres primeros se han trabajado como ejemplos resueltos. Resuelve ahora los restantes:

ping funciona, pero curl http://servidor devuelve conexión rechazada.
Apache sirve HTML, pero .php se descarga como texto.
La aplicación abre, pero muestra could not find driver.
PHP funciona y se llega a MariaDB, pero aparece Access denied.
Un VirtualHost funciona por IP, pero no usando su nombre.
Solo falla una URL concreta y el resto de la aplicación funciona.
Apache está activo pero ss no muestra escucha en 443.
HTTPS responde, pero el navegador advierte que el nombre no coincide con el certificado.
Desde WEB01 hay conexión a DB01:3306, pero la aplicación sigue diciendo que no puede conectarse.
Tras un cambio, la aplicación funciona, pero otro VirtualHost que antes funcionaba deja de responder.

El objetivo no es acertar una “receta”. Es reducir el espacio de búsqueda antes de modificar la configuración.

14. ¿Tiene esto salida profesional?

Sí. Los nombres de producto cambian, pero el patrón se repite:

Linux
+ servidores web
+ aplicaciones
+ datos
+ seguridad
+ incidencias
+ cambios
+ documentación

En las ofertas profesionales aparecen con frecuencia tareas de administración Linux, servidores web, resolución de incidencias, rendimiento, seguridad, SQL y soporte de aplicaciones.

Las ofertas cambian y pueden expirar; por eso se utilizan como contexto profesional, no como fuente curricular.

Ejemplos consultados en septiembre de 2026:

15. Mapa del módulo

UT00  Entiendo qué significa implantar una aplicación web
  ↓
UT01  Preparo la infraestructura y despliego una aplicación
  ↓
UT02  Aprendo PHP desde los fundamentos
  ↓
UT03  Añado persistencia con MariaDB y PDO
  ↓
UT04  Selecciono e implanto un CMS
  ↓
UT05  Administro, personalizo y aseguro el CMS
  ↓
UT06  Implanto aplicaciones web colaborativas / ofimáticas
  ↓
UT07  Integro, adapto y amplío soluciones web

17. Recursos oficiales y de referencia

Currículo

Tecnologías

En documentación técnica, acostúmbrate a priorizar la documentación oficial, comprobar la versión y desconfiar de soluciones copiadas sin contexto.

Siguiente paso

UT01 · Entorno de implantación y pila web

En la siguiente unidad recibiremos una aplicación ya desarrollada y tendremos que ponerla realmente en servicio sin modificar su lógica de negocio.