Saltar a contenido

6. Infraestructura híbrida Windows + Linux

En muchos entornos reales, Windows Server y Linux conviven: uno centraliza usuarios y políticas, y el otro aloja aplicaciones web. En este capítulo diseñamos un escenario híbrido similar al que usarás en el reto del módulo.

6.1. Arquitectura del laboratorio híbrido

6.1.1. Componentes principales

En el laboratorio trabajaremos con, al menos, tres "piezas":

  • Controlador de dominio Windows Server (DC)
  • Rol de Active Directory Domain Services (AD DS).
  • Servicio DNS integrado en el dominio.

  • Posibles GPO aplicadas a equipos y usuarios.

  • Servidor Linux (LAMP)

  • Sistema operativo Linux (por ejemplo, Ubuntu Server, Rocky, Debian…).
  • Pila LAMP o similar:
    • Servidor web (Apache/Nginx).
    • PHP (para Laravel).
    • Base de datos (MySQL/MariaDB/PostgreSQL).

  • Aplicación web desarrollada en Laravel + Vue.js + Tailwind.

  • Zona de backup

  • Puede ser:
    • Un segundo disco/partición en el servidor Linux.
    • Una máquina de backup separada (ideal en entornos reales).
  • Objetivo: centralizar las copias de Windows y Linux en un punto común.

Ejemplo de visión lógica (simplificada):

  • Red interna del laboratorio.
  • DC1 (Windows Server): dc1.empresa.local → AD + DNS.
  • WEB1 (Linux): web1.empresa.local → LAMP + app Laravel.
  • BACKUP (puede ser el propio WEB1 con un segundo disco, o un tercer servidor): almacena copias.

6.1.2. Flujo básico de trabajo

  1. Los usuarios existen en Active Directory.
  2. Cuentas de alumnado y profesorado.

  3. Grupos específicos (por ejemplo, WEBDEV, USUARIOS_APP, etc.).

  4. Los equipos Windows del dominio se autentican contra el DC como en los capítulos anteriores.

  5. El servidor Linux se integra con el dominio para poder:

  6. Permitir login SSH a ciertos usuarios/grupos de AD.

  7. Dar permisos sobre directorios de la aplicación web utilizando usuarios/grupos de AD.

  8. Los backups se organizan con una política común (RPO/RTO) pero herramientas distintas:

  9. Windows Server usa Windows Server Backup.
  10. Linux usa rsync/tar/Borg/Restic.
  11. El destino de las copias se centraliza (normalmente en Linux o en un servidor de backup dedicado).

En la práctica de laboratorio, esta arquitectura se puede montar en máquinas virtuales locales o en AWS Academy (EC2 Windows + EC2 Linux).

6.2. Gestión de identidades con Active Directory

La idea central es que Active Directory sea la fuente única de identidades (usuarios y grupos) tanto para Windows como, en la medida de lo posible, para Linux.

6.2.1. AD como "verdad" de usuarios y grupos

En capítulos anteriores ya has visto cómo:

  • Crear usuarios y grupos en AD.
  • Organizar las cuentas en OU.
  • Aplicar GPO según OU, grupos, etc.

En un entorno híbrido añadimos un objetivo más: que esos usuarios/grupos también sirvan para controlar acceso en Linux (SSH, permisos sobre la app, etc.).

Ventajas de este enfoque:

  • Un único lugar donde crear, modificar o desactivar cuentas.
  • Menos errores de "usuarios duplicados" entre sistemas.
  • Políticas coherentes: la baja de un usuario en AD implica que deja de poder acceder también al servidor Linux.

6.2.2. Requisitos para integrar Linux en el dominio

A nivel conceptual, Linux necesita:

  • Resolver nombres del dominio (DNS del DC).
  • Conocer el realm y la configuración de Kerberos/LDAP del dominio (por ejemplo, EMPRESA.LOCAL).
  • Un servicio en Linux que haga de "puente" con AD:
  • sssd + realmd (en muchas distros modernas) o
  • winbind (paquetes de Samba).

Pasos típicos (a alto nivel, sin entrar en comandos específicos todavía):

  1. Configurar la resolución DNS en Linux para que use como servidor DNS al DC (dc1.empresa.local).
  2. Comprobar conectividad:
  3. ping dc1.empresa.local
  4. dig empresa.local o herramientas equivalentes.
  5. Instalar los paquetes necesarios para unirse al dominio (según distro: realmd, sssd, adcli, etc.).
  6. Unir el servidor Linux al dominio con un comando tipo:
  7. realm join EMPRESA.LOCAL -U Administrador (ejemplo genérico).
  8. Verificar que ahora se pueden ver usuarios y grupos de AD desde Linux (ej. id usuario@EMPRESA.LOCAL).

6.2.3. Uso práctico en el laboratorio

Una vez unido al dominio, puedes decidir qué roles tendrá AD en Linux:

  • Acceso SSH controlado por grupo de AD
  • Definir un grupo en AD (por ejemplo, GRP_WEBDEV).

  • Configurar Linux para que solo los miembros de ese grupo puedan acceder por SSH.

  • Permisos sobre la app Laravel

  • Asignar permisos de lectura/escritura en /var/www/empresa-app a un grupo de AD.
  • Hacer que el proceso de despliegue de la app (git pull, artisan, etc.) lo ejecute una cuenta de servicio o miembros del grupo GRP_WEBDEV.

En el resto del capítulo (6.3 y siguientes) verás cómo encaja esta gestión de identidades con el despliegue de la app y la estrategia de backups.

6.3. Servidor LAMP para la aplicación web

En el servidor Linux se desplegará una aplicación web basada en Laravel + Vue.js + Tailwind, usando una pila tipo LAMP (o LEMP si usas Nginx).

6.3.1. Componentes de la pila

  • Servidor web: Apache o Nginx.
  • PHP: versión compatible con Laravel (según la versión del framework).
  • Base de datos: MySQL/MariaDB/PostgreSQL.
  • Node.js + npm/yarn: para compilar los assets de Vue.js + Tailwind.

En el laboratorio no entraremos en todos los detalles de instalación de cada componente, pero sí debes tener claro dónde vive qué para poder hacer copias y restauraciones.

6.3.2. Rutas críticas de la aplicación

Un despliegue típico de Laravel en Linux podría tener:

  • Código de la aplicación: /var/www/empresa-app.
  • Incluye el código PHP de Laravel, componentes de Vue, ficheros de configuración, etc.
  • Directorios de datos de la app:
  • storage/ → logs, ficheros generados por la app, cachés, etc.
  • public/ → recursos públicos (CSS/JS compilados, imágenes públicas…).
  • Ficheros subidos por usuarios:
  • A menudo se guardan dentro de storage/app o en rutas configuradas específicas.
  • Fichero .env:
  • Contiene configuración sensible (conexión a BD, claves, etc.).

Además, la base de datos de la aplicación (por ejemplo, empresa_db) estará en el motor de BD configurado. Para las copias, suele ser más cómodo hacer dumps lógicos (SQL) en lugar de copiar directamente los ficheros de datos del motor.

6.3.3. Implicaciones para backups y restauración

Desde el punto de vista de copias de seguridad, lo importante es que identifiques:

  • Qué carpetas y ficheros necesitas guardar para poder reconstruir la app:
  • Código + .env + storage/ + ficheros subidos.
  • Cómo vas a guardar la base de datos:
  • Scripts de mysqldump/pg_dump que generen ficheros .sql o .sql.gz.
  • Cómo vas a probar una restauración:
  • Crear una VM/clon y restaurar código + dumps de BD.

En el reto final, el servidor LAMP y el dominio Windows trabajarán juntos: usuarios en AD, app en Linux y backups coordinados según lo definido en 6.4.

6.4. Estrategia de backups en entorno híbrido

En el capítulo 5 (Backups) ya has visto:

  • Conceptos generales: RPO/RTO, tipos de copia, regla 3-2-1 (5.1).
  • Cómo hacer copias en Windows Server con Windows Server Backup (5.2).
  • Cómo hacer copias en Linux con rsync, tar, Borg/Restic, etc. (5.3).

En este apartado 6.4 no repetimos toda la teoría, sino que la aplicamos al escenario híbrido definido en 6.1.

6.4.1. Copias desde Windows Server

  • Origen principal de las copias:
  • Estado del sistema (System State): AD, GPO, registro, configuración crítica.
  • Carpetas compartidas y perfiles que dependan del DC.
  • Herramienta: Windows Server Backup, como en el tema 5.2.
  • Destino recomendado en entorno híbrido:
  • Carpeta de red en el servidor Linux o en un servidor de backup dedicado.
  • Ejemplo: \\backup-linux\\wsb o similar.

6.4.2. Copias desde Linux

  • Origen principal de las copias:
  • Código de la app Laravel + Vue (/var/www/empresa-app).
  • Directorios de storage y ficheros subidos por usuarios.
  • Base de datos (dumps periódicos con mysqldump/pg_dump, etc.).
  • Herramientas posibles (ya vistas en 5.3):
  • rsync hacia /mnt/backup/host1/ o carpeta similar.
  • tar para empaquetar y comprimir copias completas.
  • Borg/Restic si se quiere repositorio deduplicado.
  • Destino recomendado:
  • Mismo servidor de backup que usa Windows (por ejemplo, un disco dedicado en Linux).

6.4.3. Política común de RPO/RTO

Tomando como base los ejemplos de 5.1, se puede definir para el laboratorio algo como:

  • RPO: aceptamos perder como máximo 1 día de trabajo.
  • RTO: aceptamos tardar unas horas en recuperar el servicio.

Aplicado a Windows + Linux:

  • Completo semanal de Windows (System State + datos) y de Linux (código + BD + datos).
  • Incrementales diarios (o sincronizaciones diarias con rsync) en ambos sistemas.
  • Al menos una copia en soporte distinto al de producción (segundo disco, servidor de backup, etc.).

En el despliegue en AWS Academy, estos mismos objetivos se traducirán a snapshots de EBS, AMIs y, si se utiliza, AWS Backup.

6.5. Llevar el escenario a AWS Academy

En AWS Academy podrás recrear este mismo escenario híbrido usando recursos de AWS. A alto nivel, el mapeo sería:

  • DC Windows on‑prem → Instancia EC2 Windows Server
  • Disco del sistema en EBS.
  • Snapshots de EBS para copias a nivel de bloque.

  • Posibilidad de crear AMI de la instancia para tener imágenes completas.

  • Servidor LAMP on‑prem → Instancia EC2 Linux

  • Código Laravel + Vue + Tailwind desplegado en /var/www/empresa-app.
  • Base de datos → RDS (como opción) o servidor de BD en la propia EC2.

  • Snapshots de EBS para los volúmenes.

  • Servidor de backup / NAS → varias opciones en AWS:

  • EC2 Linux con un disco grande, usando Borg/Restic/rsync para consolidar copias.
  • S3 como almacenamiento de copias de ficheros y dumps.
  • AWS Backup para orquestar copias de EBS, RDS, etc. (aunque en el laboratorio se puede usar una versión más simple).

El objetivo no es aprender todos los productos de AWS en detalle, sino ver cómo se traducen los mismos conceptos on‑prem (DC + LAMP + backups) a una infraestructura en la nube.