UT01 · Entorno de implantación, arquitectura y pila web

De un artefacto entregado por desarrollo a una aplicación web realmente operativa y administrable.

Idea de la unidad: en esta primera UT no vamos a desarrollar una aplicación desde cero. Recibiremos una aplicación web ya preparada y aprenderemos a ponerla en servicio de forma reproducible, segura y diagnosticable.

Antes de empezar

Esta unidad parte del laboratorio preparado en la UT00. Cada alumno dispone de tres nodos virtuales diferenciados y una red interna propia.

Rol	Nombre	IP interna
Cliente	`IAW-CLINN`	`192.168.60.30/24`
Web / aplicación	`IAW-WEBNN`	`192.168.60.10/24`
Base de datos	`IAW-DBNN`	`192.168.60.20/24`

Las tres máquinas representan roles separados. El número NN del puesto se utiliza para personalizar nombres, bases de datos, usuarios y evidencias sin alterar la dificultad.

Antes de empezar crea o comprueba un snapshot/punto de retorno llamado UT00_LAB_LISTO. Si durante esta unidad destruyes el laboratorio, tienes un punto de retorno conocido.

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

El módulo de Implantación de Aplicaciones Web (IAW) prepara para administrar el entorno en el que se ejecutan aplicaciones web. Nuestro trabajo no se limita a instalar un servidor y comprobar que aparece una página en el navegador.

Implantar una aplicación web significa preparar la infraestructura y el software necesarios para que una aplicación ya construida pueda:

ejecutarse en un servidor;
recibir peticiones de clientes;
ejecutar código del lado servidor;
acceder a una base de datos;
mantener sus secretos fuera de la zona pública;
registrar errores y actividad;
recuperarse de fallos;
operar con permisos razonables;
ser verificada y documentada.

IAW sí es…

preparar servidores y dependencias;
desplegar aplicaciones;
configurar Apache, PHP-FPM, permisos, rutas y secretos;
integrar la aplicación con MariaDB;
verificar, diagnosticar y asegurar;
documentar un procedimiento reproducible.

IAW no es, principalmente…

programar desde cero la lógica de negocio de una aplicación;
convertir cada error de infraestructura en una excusa para modificar código;
usar root para todo porque “así funciona”;
seguir un tutorial de siguiente → siguiente → instalar sin saber qué ocurre.

Regla de esta UT: el código de la aplicación se trata como un artefacto suministrado. Podemos configurar el entorno en el que se ejecuta, pero no se evalúa desarrollar nuevas funcionalidades PHP. Eso llegará más adelante.

2. Resultado de aprendizaje y criterios de evaluación

RA1

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

Ver los criterios de evaluación del RA1

| CE | En esta unidad significa… | |---|---| | RA1.a | Identificar el software necesario para que la aplicación funcione. | | RA1.b | Reconocer las tecnologías que intervienen. | | RA1.c | Instalar y configurar servidor web y servidor de base de datos. | | RA1.d | Distinguir procesamiento en cliente y servidor. | | RA1.e | Añadir y configurar los componentes necesarios para ejecutar código en servidor. | | RA1.f | Instalar y configurar el acceso a bases de datos. | | RA1.g | Establecer y verificar medidas de seguridad en los accesos. | | RA1.h | Utilizar y comparar plataformas integradas orientadas a prueba/desarrollo. | | RA1.i | Documentar los procedimientos realizados. |

No necesitas memorizar las letras de los CE. Sí debes saber qué RA estás demostrando y qué pruebas permiten comprobarlo.

3. Arquitectura web: qué estamos mirando

Arquitectura base

Figura 1. Cliente, nodo web y nodo de datos son responsabilidades distintas.

Una arquitectura web describe los componentes que intervienen, la responsabilidad de cada uno, dónde se ejecutan y cómo circulan peticiones y datos.

En esta UT nos interesa especialmente la arquitectura de despliegue.

No debe confundirse con la arquitectura interna del código. Por ejemplo, MVC describe cómo puede organizarse una aplicación. En cambio, decidir que Apache y PHP se ejecutan en una máquina y MariaDB en otra describe dónde viven realmente los componentes.

Capas de nuestro escenario

Capa	Responsabilidad	Ejemplo
Cliente	Solicita recursos y ejecuta código de cliente.	Navegador, `curl`, HTML, CSS y JavaScript.
Servidor web	Recibe HTTP y decide qué sitio/recurso debe atender.	Apache HTTP Server.
Runtime	Ejecuta código del lado servidor.	PHP-FPM.
Aplicación	Aplica la lógica ya desarrollada y genera respuesta.	`iaw-demo`.
Datos	Persiste información y controla acceso.	MariaDB.
Operación	Logs, permisos, secretos, cambios y comprobaciones.	`systemd`, `journalctl`, `/var/log`, `/etc`.

Recorrido de una petición dinámica

Recorrido de petición

CLIENTE
   │ HTTP
   ▼
APACHE
   │ FastCGI
   ▼
PHP-FPM
   │
   ▼
APLICACIÓN iaw-demo
   │ PDO / TCP 3306
   ▼
MARIADB
   │
   └──────────────► respuesta al cliente

Cada flecha es también un punto de fallo. Por eso, para diagnosticar bien, necesitamos poder probar cada tramo de forma independiente.

4. Patrones de despliegue

4.1 Todo en uno

┌────────────────────────────┐
│ SERVIDOR                   │
│ Apache + PHP + aplicación  │
│ MariaDB                    │
└────────────────────────────┘

Ventaja: sencillo para demos y laboratorios mínimos.
Limitación: oculta muchos problemas de conectividad, exposición y origen de usuarios SQL.

4.2 Dos niveles: la arquitectura base de UT01

CLIENTE
   │
   ▼
IAW-WEBNN
Apache + PHP-FPM + aplicación
   │
   │ TCP 3306
   ▼
IAW-DBNN
MariaDB

Esta es nuestra opción porque obliga a entender:

qué servicio escucha en cada puerto;
qué IP usa cada máquina;
cómo se conecta PHP a una base remota;
qué significa 'usuario'@'origen' en MariaDB;
qué puertos deben o no exponerse;
cómo distinguir un problema HTTP de un problema SQL.

4.3 Tres o más niveles

Cliente
   ↓
Proxy / frontal web
   ↓
Servidor(es) de aplicación
   ↓
Base de datos

Es habitual en entornos de mayor escala, pero introducir balanceo, alta disponibilidad o clústeres en la primera unidad ocultaría el objetivo principal: entender bien el despliegue básico.

5. Desarrollo, preproducción y producción

No todos los entornos persiguen lo mismo.

Entorno	Objetivo	Características habituales
Desarrollo	Cambiar y probar rápido.	Más depuración, datos de prueba, comodidad para el desarrollador.
Preproducción	Verificar que el despliegue es reproducible.	Configuración parecida a producción y pruebas de integración.
Producción	Dar servicio real.	Mínimo privilegio, continuidad, monitorización, copias y cambios controlados.

Nuestro laboratorio se parece más a una preproducción didáctica que a un servidor de desarrollo personal.

6. Arquitectura del laboratorio

Para el alumno NN:

IAW-CLINN      192.168.60.30
     │
     │ HTTP
     ▼
IAW-WEBNN      192.168.60.10
Apache 2.4
PHP-FPM
iaw-demo
     │
     │ TCP 3306
     ▼
IAW-DBNN       192.168.60.20
MariaDB

En el cliente añadiremos además un nombre específico para la aplicación:

192.168.60.10   appNN.iaw.test

Así distinguimos el nombre del servidor (webNN.iaw.test) del nombre del sitio/aplicación (appNN.iaw.test).

7. Antes de instalar: inventario

Un administrador no debería cambiar una máquina sin saber primero en qué estado se encuentra.

Guarda como línea base:

hostnamectl
ip -br a
ip route
cat /etc/os-release
ss -lntup
apt policy apache2 php-fpm mariadb-server

Preguntas que debes poder contestar:

¿Qué versión de Debian estoy usando?
¿Qué interfaces tiene la máquina y qué IP usa cada una?
¿Cuál es la ruta por defecto?
¿Hay ya algún proceso escuchando en 80, 443 o 3306?
¿Hay paquetes instalados previamente que puedan alterar el laboratorio?

Si después aparece un conflicto, el inventario inicial permite comparar el antes y el después.

7.1. Inspeccionar el artefacto antes de desplegarlo

Antes de copiar archivos a /var/www, un administrador debe saber qué está recibiendo. En esta UT el artefacto será iaw-demo-1.0.zip, suministrado a través del aula virtual.

Primero comprobamos su integridad y contenido sin ejecutarlo:

sha256sum iaw-demo-1.0.zip
unzip -l iaw-demo-1.0.zip

Después identificamos, como mínimo:

Pregunta	Qué debemos localizar
¿Cuál es la zona pública?	El `DocumentRoot`, en nuestro caso `public/`.
¿Qué runtime necesita?	PHP y las extensiones requeridas.
¿Dónde se configura?	Plantilla de configuración y variables esperadas.
¿Dónde están los secretos?	Nunca dentro del `DocumentRoot`.
¿Necesita base de datos?	Host, puerto, nombre, usuario y esquema.
¿Hay una prueba de salud?	`health.php` y respuesta HTTP esperada.
¿Qué debe poder escribir?	Solo los directorios que realmente lo necesiten.

Patrón profesional: inventariar → desplegar → configurar → validar → observar. Copiar archivos y “probar a ver” no es un procedimiento de implantación.

8. Nodo web: Apache + PHP-FPM

En iaw-webNN instalaremos el servidor HTTP, PHP-FPM y el driver que permite a PDO hablar con MariaDB.

sudo apt update
sudo apt install apache2 php-fpm php-cli php-mysql mariadb-client curl

En la imagen Debian 13 del curso, el servicio PHP-FPM corresponde a PHP 8.4:

sudo systemctl enable --now apache2 php8.4-fpm
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
sudo apache2ctl configtest
sudo systemctl reload apache2

Comprobaciones mínimas

systemctl --no-pager --full status apache2 php8.4-fpm
ss -lntp | grep -E ':80|:443'
php -v
php -m | grep -i pdo
php -m | grep -i mysql

¿Por qué PHP-FPM?

Apache atiende HTTP. PHP-FPM ejecuta los scripts PHP en procesos separados. Esta separación permite comprender mejor qué componente falla y se parece más a despliegues profesionales que esconder todo dentro de un único proceso.

9. Una aplicación necesita su propio VirtualHost

VirtualHost

No queremos copiar archivos al azar dentro de /var/www/html.

Creamos una estructura clara:

sudo mkdir -p /var/www/iaw-demo/public
sudo mkdir -p /etc/iaw-demo
sudo chown -R root:www-data /var/www/iaw-demo
sudo find /var/www/iaw-demo -type d -exec chmod 750 {} \;
sudo find /var/www/iaw-demo -type f -exec chmod 640 {} \;

La raíz pública será únicamente:

/var/www/iaw-demo/public

`/etc/apache2/sites-available/iaw-demo.conf`

<VirtualHost *:80>
    ServerName appNN.iaw.test
    DocumentRoot /var/www/iaw-demo/public

    <Directory /var/www/iaw-demo/public>
        Options -Indexes
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/iaw-demo-error.log
    CustomLog ${APACHE_LOG_DIR}/iaw-demo-access.log combined
</VirtualHost>

Activamos y validamos antes de recargar:

sudo a2ensite iaw-demo.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Desde iaw-cliNN, añade temporalmente a /etc/hosts:

192.168.60.10   appNN.iaw.test

Y comprueba:

curl -i http://appNN.iaw.test/

Buenas prácticas: validar sintaxis antes de recargar evita convertir un pequeño error de configuración en una caída innecesaria del servicio.

10. Nodo de datos: MariaDB con superficie mínima

En iaw-dbNN:

sudo apt update
sudo apt install mariadb-server
sudo systemctl enable --now mariadb
sudo ss -lntp | grep 3306

Por defecto, una base de datos puede estar configurada para escuchar únicamente en localhost. Eso es seguro para una aplicación local, pero nuestra aplicación está en otra máquina.

Antes de editar a ciegas, localiza la configuración efectiva:

sudo mariadbd --verbose --help 2>/dev/null | grep -A1 'Default options'
sudo grep -R "^[[:space:]]*bind-address" /etc/mysql /etc/my.cnf 2>/dev/null

Creamos, por ejemplo:

# /etc/mysql/mariadb.conf.d/60-iaw-bind.cnf
[mariadb]
bind-address = 192.168.60.20

Aplicamos y verificamos:

sudo systemctl restart mariadb
sudo ss -lntp | grep 3306

Objetivo: MariaDB debe escuchar en la interfaz interna del laboratorio, no exponerse innecesariamente por otras redes.

11. Base de datos y usuario de aplicación

Mínimo privilegio

La aplicación no se conecta como root.

Para cada alumno personalizamos el nombre de la base y la cuenta:

CREATE DATABASE iaw_demo_NN
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'iaw_app_NN'@'192.168.60.10'
  IDENTIFIED BY 'CONTRASENA_LAB';

GRANT SELECT, INSERT, UPDATE, DELETE
  ON iaw_demo_NN.*
  TO 'iaw_app_NN'@'192.168.60.10';

FLUSH PRIVILEGES;

Mínimo privilegio

La aplicación solo recibe los permisos que necesita para funcionar.

No concedemos por defecto:

privilegios globales;
GRANT OPTION;
permisos administrativos;
acceso desde cualquier origen ('%') si conocemos la IP real del servidor web.

Si una migración necesita CREATE o ALTER, podemos utilizar una cuenta de despliegue diferente y mantener la cuenta de ejecución con menos privilegios.

12. Secretos fuera del `DocumentRoot`

Público y privado

Nunca deberíamos publicar una contraseña de base de datos dentro de la raíz que Apache sirve al cliente.

Ejemplo:

/etc/iaw-demo/iaw-demo.env

Contenido de laboratorio:

DB_HOST=192.168.60.20
DB_PORT=3306
DB_NAME=iaw_demo_NN
DB_USER=iaw_app_NN
DB_PASS=CONTRASENA_LAB

Restringimos su lectura:

sudo chown root:www-data /etc/iaw-demo/iaw-demo.env
sudo chmod 640 /etc/iaw-demo/iaw-demo.env
namei -l /etc/iaw-demo/iaw-demo.env

Dos principios que debes recordar:

los secretos no se guardan en Git ni en el directorio público;
solo deben poder leerlos los procesos que realmente los necesitan.

13. Health check: probar integración sin desarrollar

La aplicación incluye un archivo health.php ya preparado. En UT01 lo desplegamos, no lo escribimos.

Su función es realizar una consulta mínima y devolver un resultado sencillo que permita saber si:

Apache atiende la petición;
PHP-FPM ejecuta PHP;
el driver PDO MySQL está disponible;
el nodo web llega a MariaDB;
las credenciales son válidas;
la base de datos responde.

Prueba:

curl -i http://appNN.iaw.test/health.php

Y revisa simultáneamente el log de error:

tail -n 30 /var/log/apache2/iaw-demo-error.log

El navegador no debe recibir trazas completas ni contraseñas. Los detalles técnicos se registran en el servidor.

14. Diagnóstico por capas

Diagnóstico

Cuando algo falla, sigue la petición de fuera hacia dentro.

Paso	Evidencia	Pregunta
1. Resolución	`getent hosts appNN.iaw.test`	¿El nombre apunta a la máquina correcta?
2. TCP/HTTP	`curl -v`, `ss -lntp`	¿Hay un proceso escuchando y llega la conexión?
3. Apache	`apache2ctl configtest`, `error.log`	¿El VirtualHost es válido?
4. PHP-FPM	`systemctl`, `journalctl`	¿PHP-FPM está activo y Apache deriva PHP?
5. Driver	`php -m`	¿PDO MySQL está cargado?
6. Red a DB	`mariadb -h ...`	¿El nodo web alcanza MariaDB?
7. Autenticación	cliente `mariadb` + `SHOW GRANTS`	¿Usuario, origen y contraseña coinciden?
8. Aplicación	petición mínima + logs	¿Falla configuración, SQL o lógica?

Regla de oro: cambia una sola variable por hipótesis. Si modificas permisos, contraseña, firewall y código a la vez, quizá consigas que funcione, pero no sabrás qué estaba mal.

15. Errores típicos y cómo leerlos

`could not find driver`

Primera hipótesis: PHP está ejecutándose, pero el SAPI que sirve la web no tiene cargado el driver PDO MySQL.

Comprobaciones:

php -m | grep -i pdo
php -m | grep -i mysql
apt policy php-mysql
systemctl status php8.4-fpm

`Access denied for user ...`

No significa necesariamente que MariaDB esté caída.

Investiga:

usuario;
contraseña;
origen permitido;
base de datos;
GRANT efectivo.

Prueba desde el propio nodo web:

mariadb -h 192.168.60.20 -u iaw_app_NN -p iaw_demo_NN

HTTP 500

Un 500 solo dice que el servidor no pudo completar correctamente la petición.

Consulta antes de “tocar cosas”:

tail -n 50 /var/log/apache2/iaw-demo-error.log
journalctl -u php8.4-fpm --since "10 minutes ago"
namei -l /etc/iaw-demo/iaw-demo.env

PHP aparece como texto o se descarga

Apache está entregando el archivo, pero no lo está enviando al runtime PHP.

Revisa:

sudo a2query -c php8.4-fpm
sudo a2query -m proxy_fcgi
sudo apache2ctl -S

16. Baseline de seguridad de UT01

En esta unidad aplicaremos como mínimo:

paquetes actualizados y versiones registradas;
aplicación sin cuenta root de base de datos;
puerto 3306 limitado a la red que lo necesita;
secretos fuera del DocumentRoot;
permisos de archivos justificados;
Options -Indexes salvo necesidad explícita;
errores técnicos en logs, no en la interfaz del usuario;
nada de chmod 777 como solución universal;
separación entre archivos públicos y configuración;
revisión de logs después del despliegue.

Cuando el escenario incorpore DNS/HTTPS trabajado en otros módulos, la aplicación deberá funcionar sin llevar secretos ni direcciones rígidas incrustadas en el código.

17. Rendimiento: medir antes de opinar

No haremos una prueba de carga profesional en UT01, pero sí aprenderemos a medir una petición de forma repetible.

curl -sS -o /dev/null \
  -w 'code=%{http_code} time=%{time_total}s\n' \
  http://appNN.iaw.test/health.php

Repite varias veces:

for i in 1 2 3 4 5; do
  curl -sS -o /dev/null -w '%{time_total}\n' \
    http://appNN.iaw.test/health.php
done

Cinco peticiones no demuestran capacidad de producción. Sí sirven para aprender una idea profesional: primero observa y mide; después cambia.

18. Plataformas integradas y contenedores

El RA1 también pide utilizar plataformas integradas orientadas a prueba/desarrollo.

Compararemos brevemente una instalación integrada o contenedorizada con nuestra instalación nativa. No para decidir que “Docker es mejor” o “Docker es peor”, sino para preguntar:

¿dónde quedan ahora los archivos de configuración?;
¿qué proceso escucha en cada puerto?;
¿cómo persisten los datos?;
¿dónde se consultan los logs?;
¿cómo se suministran los secretos?;
¿qué ganamos en reproducibilidad?;
¿qué dejamos de ver si usamos una imagen sin entender su interior?

Primero comprendemos las piezas. Después podremos automatizarlas.

19. Procedimiento profesional de despliegue

Ciclo de despliegue

Una secuencia razonable para esta UT es:

inventariar versiones, interfaces y puertos;
preparar directorios y permisos;
instalar dependencias identificables;
configurar el VirtualHost;
validar sintaxis antes de recargar;
configurar MariaDB y limitar su escucha;
crear una cuenta SQL de mínimo privilegio;
colocar secretos fuera de la raíz pública;
desplegar el artefacto suministrado;
probar desde el propio servidor;
probar desde el cliente;
revisar logs;
medir una respuesta básica;
documentar estado final, incidencias y reversión.

Actividades evaluables: las consignas, evidencias exigidas, incidencias y criterios de entrega de esta UT se publican únicamente en el aula virtual. La web mantiene la teoría, los ejemplos y los procedimientos reutilizables.

20. Checklist de salida

Puedo explicar la función de Apache, PHP-FPM, la aplicación y MariaDB sin confundir capas.
Mi aplicación tiene un VirtualHost propio.
El DocumentRoot contiene únicamente recursos públicos.
La cuenta SQL no es root y sus permisos están justificados.
Puedo demostrar conectividad web → DB sin depender del navegador.
Sé localizar los logs de Apache y PHP-FPM.
Puedo diagnosticar could not find driver y Access denied con evidencias.
Sé volver al snapshot anterior si el despliegue queda inconsistente.
Mi documentación permite que otra persona reproduzca el despliegue.

21. Glosario mínimo

DocumentRoot
Directorio que Apache expone como raíz pública de un sitio.

VirtualHost
Configuración que permite a Apache servir aplicaciones o sitios distintos.

SAPI
Interfaz mediante la que PHP se ejecuta en un contexto concreto, como CLI o FPM.

PHP-FPM
Gestor de procesos FastCGI que ejecuta PHP separado del proceso HTTP.

PDO
Abstracción de PHP para trabajar con bases de datos a través de drivers.

Secreto
Credencial o clave que no debe publicarse en código, capturas ni repositorios.

Health check
Prueba pequeña y repetible que indica si un componente esencial responde.

Mínimo privilegio
Conceder únicamente los permisos necesarios para realizar una función.

Reversión / rollback
Procedimiento para regresar a un estado conocido cuando un cambio falla.

22. ¿Dónde aparece esto en el mundo laboral?

Los perfiles de administración y soporte de aplicaciones trabajan con problemas muy parecidos a los de esta unidad: servidores Linux, Apache/Nginx, bases de datos, disponibilidad, logs, actualizaciones, despliegues y diagnóstico.

Como referencia profesional, puede consultarse una oferta de Soporte de Aplicaciones Senior en entorno LAMP de TUYÚ Technology, donde aparecen Linux, Apache, MySQL y PHP como parte del entorno de soporte:

Ver referencia de empleo en Tecnoempleo

No significa que terminar esta UT convierta a nadie en un perfil senior. Sí permite reconocer que las tecnologías y la forma de diagnosticar que usamos en clase pertenecen a entornos profesionales reales.

23. Fuentes y ampliación

Siguiente unidad

Con el entorno ya entendido, el siguiente paso será dejar de tratar PHP como una caja negra. En la UT02 · PHP del lado servidor aprenderás a generar respuestas dinámicas, procesar formularios, mantener sesiones e implementar autenticación y aislamiento de usuarios.

UT01 · Entorno de implantación, arquitectura y pila web

Antes de empezar

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

IAW sí es…

IAW no es, principalmente…

2. Resultado de aprendizaje y criterios de evaluación

RA1

3. Arquitectura web: qué estamos mirando

Capas de nuestro escenario

Recorrido de una petición dinámica

4. Patrones de despliegue

4.1 Todo en uno

4.2 Dos niveles: la arquitectura base de UT01

4.3 Tres o más niveles

5. Desarrollo, preproducción y producción

6. Arquitectura del laboratorio

7. Antes de instalar: inventario

7.1. Inspeccionar el artefacto antes de desplegarlo

8. Nodo web: Apache + PHP-FPM

Comprobaciones mínimas

¿Por qué PHP-FPM?

9. Una aplicación necesita su propio VirtualHost

/etc/apache2/sites-available/iaw-demo.conf

10. Nodo de datos: MariaDB con superficie mínima

11. Base de datos y usuario de aplicación

Mínimo privilegio

12. Secretos fuera del DocumentRoot

13. Health check: probar integración sin desarrollar

14. Diagnóstico por capas

15. Errores típicos y cómo leerlos

could not find driver

Access denied for user ...

HTTP 500

PHP aparece como texto o se descarga

16. Baseline de seguridad de UT01

17. Rendimiento: medir antes de opinar

18. Plataformas integradas y contenedores

19. Procedimiento profesional de despliegue

20. Checklist de salida

21. Glosario mínimo

22. ¿Dónde aparece esto en el mundo laboral?

23. Fuentes y ampliación

Siguiente unidad

`/etc/apache2/sites-available/iaw-demo.conf`

12. Secretos fuera del `DocumentRoot`

`could not find driver`

`Access denied for user ...`