🚢 42-Inception

Bienvenid@ a la guía definitiva para validar y defender tu proyecto de Docker. Aquí encontrarás teoría detallada, comandos prácticos, ejemplos y esquemas visuales para cada fase de la evaluación[...]

• 🛡️ 0. Preliminares y Seguridad
• 🗂️ 1. Estructura y Entrega
• 🧹 2. Limpieza y Preparación del Entorno
• 🛠 3. docker-compose.yml y Makefile
• 📚 4. Explicación Teórica para la Defensa
• 🧩 5. Validación de Servicios
• ♻️ 6. Persistencia
• ☑️ 7. Checklist Rápido
• 🎯 Esquema Global del Proyecto

Guardar credenciales (contraseñas, claves API, etc.) en archivos de configuración o el propio código fuente supone un grave riesgo de seguridad. El archivo .env es el estándar para centralizar variables sensibles y evitar su exposición en el repositorio, permitiendo cambiar credenciales sin modificar el código y facilitando el despliegue en distintos entornos.

Ejemplo de archivo .env de prueba (NO subir nunca al repo):

MYSQL_DATABASE=wordpress
MYSQL_USER=wpuser
MYSQL_PASSWORD=wpsecretpassword
MYSQL_ROOT_PASSWORD=superrootpassword
WORDPRESS_DB_HOST=mariadb
WORDPRESS_DB_USER=wpuser
WORDPRESS_DB_PASSWORD=wpsecretpassword
WORDPRESS_DB_NAME=wordpress

¿Cómo validar?

grep -r 'PASSWORD\|SECRET\|KEY' .
ls -la | grep .env
grep -r 'password\|secret\|key' srcs/

✅ Solo .env tiene secretos y NO está en el repo.

Ejemplo de validación:

• Si haces grep -r 'PASSWORD\|SECRET\|KEY' . y la única coincidencia relevante está en el archivo .env (que tampoco debe estar subido al repositorio), ¡cumples la norma!
• Si haces ls -la | grep .env y ves el archivo, asegúrate de que está en tu .gitignore.
• Un resultado vacío en grep -r 'password\|secret\|key' srcs/ significa que no hay secretos duros en el código fuente.

Una estructura clara y estándar facilita la colaboración, el mantenimiento y la automatización de despliegues y pruebas. Hace el proyecto comprensible para cualquier equipo técnico.

Estructura real del proyecto:

> tree -a 42-Inception 
📦 42-Inception/
├── 🛡️ inception_validator.sh
├── 🛠️ Makefile
├── 📄 README.md
└── 📂 srcs
    ├── 🧾 docker-compose.yml
    ├── 📝 .env
    └── 📦 requirements
        ├── 🐬 mariadb
        │   ├── 🐳 Dockerfile
        │   └── 🧰 tools
        │       ├── ▶️ entrypoint.sh
        │       └── ⚙️ my_conf.cnf
        ├── 🌐 nginx
        │   ├── 🐳 Dockerfile
        │   └── 🧰 tools
        │       ├── 🗂️ default.conf
        │       ├── ▶️ entrypoint.sh
        │       ├── ⚙️ nginx.conf
        │       ├── 📜 server.crt
        │       └── 🔒 server.key
        └── 📝 wordpress
            ├── 🐳 Dockerfile
            └── 🧰 tools
                └── ▶️ entrypoint.sh

Utiliza tree -a o ls -R explora visualmente tu repo para comprobar que la estructura y los nombres coinciden. Asegúrate de que los ficheros sensibles (contraseñas, claves SSL) estén en la carpeta adecuada y nunca subidos al repositorio.

Un entorno limpio elimina posibles interferencias de pruebas anteriores, asegurando que la evaluación sea reproducible y libre de residuos de instalaciones previas.

Comandos recomendado:

docker stop $(docker ps -qa)
docker rm $(docker ps -qa)
docker rmi -f $(docker images -qa)
docker volume rm $(docker volume ls -q)
docker network rm $(docker network ls -q) 2>/dev/null
docker ps -a
docker images -a
docker volume ls
docker network ls

✅ No quedan contenedores, imágenes, volúmenes ni redes extra.

• Al ejecutar docker ps -a, docker images -a, docker volume ls y docker network ls, las listas deben estar vacías o solo contener recursos creados al volver a levantar el proyecto.

Docker Compose permite definir redes internas para que los servicios se comuniquen de forma segura, sin exponer todos los puertos al exterior. Por ejemplo, solo NGINX expone el puerto 443 y el resto de servicios quedan aislados. network: host y links: son prácticas obsoletas o inseguras.

¿Cómo validar?

grep 'network: host' srcs/docker-compose.yml
grep 'links:' srcs/docker-compose.yml
grep 'networks:' srcs/docker-compose.yml

• Si los dos primeros comandos (network: host y links:) no devuelven nada, ¡vas bien!
• El comando grep 'networks:' srcs/docker-compose.yml debe devolver al menos una línea mostrando la definición de redes propias.

Usar --link, procesos en background (tail -f, sleep infinity, etc.) o bucles infinitos es mala práctica porque el proceso principal debe ser gestionado por Docker.

Así se asegura que el contenedor se detiene correctamente y los recursos se liberan.

grep -- '--link' Makefile srcs/*
grep 'tail -f' srcs/*/Dockerfile
grep '&' srcs/*/Dockerfile
grep 'sleep infinity' srcs/*
grep 'tail -f /dev/null' srcs/*

• Todos los comandos deben devolver vacío (sin resultados). Si alguno devuelve una línea, revisa y corrige el script o Dockerfile en cuestión.

El Makefile automatiza la construcción y despliegue, garantizando que cualquier persona pueda levantar el entorno con un solo comando.

make
docker ps

✅ Todos los servicios en estado Up.

• Debes ver todos tus servicios (nginx, wordpress, mariadb) con el estado "Up".
• Si alguno está "Exited" o "Restarting", revisa los logs con docker-compose logs <servicio>.

Docker es una plataforma que permite empaquetar aplicaciones y sus dependencias en contenedores ligeros y portables, facilitando la reproducibilidad y la portabilidad entre sistemas. Docker Compose es una herramienta que permite definir y orquestar múltiples contenedores (servicios) en un solo archivo YAML, y levantar toda la infraestructura con un solo comando.

Sin Compose, debes lanzar manualmente cada contenedor, definir parámetros, redes y volúmenes individualmente, lo que es más propenso a errores. Con Compose, todo se define en docker-compose.yml y solo necesitas un comando para gestionar toda la infraestructura y sus dependencias.

Docker es más eficiente y rápido para aplicaciones modernas, mientras que las VMs son preferibles para aislamiento total o sistemas legados.

Una buena estrucutra ayuda a mantener el proyecto organizado, permite a otros colaboradores entender rápidamente la arquitectura, y facilita la automatización de despliegues y pruebas.

NGINX actúa como puerta de entrada, gestionando el tráfico y garantizando la seguridad mediante HTTPS. SSL/TLS cifra la información y protege la comunicación entre cliente y servidor, siendo obligatorio en toda web moderna.

Pasos a validar y ejemplos:

1. Solo debe estar accesible por el puerto 443 (HTTPS).

   ss -tulpn | grep 443

   Verifica que solo NGINX está escuchando en ese puerto.
2. Accede a https://login.42.fr (ajusta login), verifica que carga la web (aunque el certificado sea autofirmado).
3. Accede a http://login.42.fr (debe fallar: redirección o error), ya que al intentar entrar por HTTP, debe redirigirte a HTTPS o mostrar error.
4. Inspecciona el certificado: aunque sea autofirmado, debe ser TLS v1.2/v1.3, haciendo clic en el candado en el navegador y revisa la versión TLS.

php-fpm es una forma eficiente de ejecutar PHP, separando la lógica del servidor web. El volumen asegura que los datos se mantengan tras reinicios o actualizaciones. WordPress debe ser seguro y persistente.

Pasos a validar y ejemplos:

1. El Dockerfile NO debe contener NGINX.
   • cat srcs/requirements/wordpress/Dockerfile | grep nginx debe devolver vacío.
2. El sitio debe estar instalado (no debe mostrar el instalador).
   • Accede a la web https://login.42.fr:4443/wp-login, si muestra la página principal y permite login, está instalado.
3. Solo debe ser accesible por HTTPS.
4. El usuario admin NO debe contener "admin" ni variantes, ingresa al panel y verifica el nombre del usuario administrador.
5. Haz login y comprueba que se permite añadir comentarios y editar páginas.
6. Usar volumen persistente en /home/login/data/.
   • Por ejemplo con docker inspect <container_wordpress> tiene que aparecer el volumen montado.

El volumen mantiene los datos entre reinicios. MariaDB es una base de datos robusta y compatible con MySQL, ideal para aplicaciones como WordPress.

Pasos a validar y ejemplos:

1. El Dockerfile NO debe contener NGINX.
   -cat srcs/requirements/mariadb/Dockerfile | grep nginx debe devolver vacío.
2. Usar volumen persistente en /home/login/data/.
   • Por ejemplo con docker inspect <container_wordpress> tiene que aparecer el volumen montado.
3. La base de datos NO debe estar vacía tras la instalación de WordPress, para ello podemos acceder al contenedor de MariaDB:

docker exec -it <nombre_contenedor_mariadb> bash

Reemplaza <nombre_contenedor_mariadb> por el nombre real de tu contenedor, por ejemplo: inception-mariadb-1.

Conéctate a MariaDB como el usuario definido en tu .env:

mysql -u $MYSQL_USER -p$MYSQL_PASSWORD

Si has definido la password como variable de entorno, puedes usarla directamente; si no, simplemente escribe la contraseña cuando lo solicite.

Comprueba que existen las bases de datos:

SHOW DATABASES;

Debes ver la base de datos de WordPress, por ejemplo: wordpress.

Prueba a ver los usuarios existentes en la base de datos

MariaDB [(none)]> SELECT User, Host FROM mysql.user;
+----------------+--------------+
| User           | Host         |
+----------------+--------------+
| PUBLIC         |              |
| mysqlsuperuser | %            |
| mysqluser      | %            |
|                | c420ea7f38d9 |
|                | localhost    |
| mariadb.sys    | localhost    |
| mysql          | localhost    |
| root           | localhost    |
+----------------+--------------+

Selecciona la base de datos y lista sus tablas:

USE mysqldb;
SHOW TABLES;

Deberías ver todas las tablas estándar de WordPress como wp_posts, wp_users, etc. Si aparecen, significa que WordPress está utilizando correctamente MariaDB.

La persistencia garantiza que los datos y configuraciones sobreviven a reinicios, caídas o actualizaciones, como requiere cualquier sistema real en producción.

Pasos a validar y ejemplos:

1. Reinicia la máquina/VM, ejecutando sudo reboot y tras el arranque, sigue los pasos siguientes.
2. Lanza de nuevo los servicios con Docker Compose con make o docker compose up -d.
3. Confirma que WordPress y MariaDB siguen configurados, y los cambios persisten, accediendo a la web, verificando que los posts/comentarios siguen ahí y que la base de datos no se ha perdido.

• 🔏 Credenciales solo en .env
• 📁 Estructura correcta del repo
• 🧹 Entorno Docker limpio
• 🚫 Sin network: host, links:, --link, ni procesos en background
• 🛠️ Makefile levanta todos los servicios
• 🔐 NGINX solo por HTTPS y con SSL
• 📝 WordPress configurado, admin seguro, volumen persistente
• 🐬 MariaDB funcional, volumen persistente
• 📚 Explicación teórica preparada
• ♻️ Persistencia tras reinicio

+-------------------+
|      🌐 NGINX      |  <-- HTTPS (443)
|  (Proxy inverso)  |
+-------------------+
         |
         v
+-------------------+
| 📝 WordPress      |  <-- php-fpm
| (con Volumen)     |
+-------------------+
         |
         v
+-------------------+
|   🐬 MariaDB      |  <-- Volumen Persistente
+-------------------+

📂 srcs/
├── 🧾 docker-compose.yml
├── 📝 env
└── 📦 requirements
    ├── 🐬 mariadb
    │   ├── 🐳 Dockerfile
    │   └── 🧰 tools
    ├── 🌐 nginx
    │   ├── 🐳 Dockerfile
    │   └── 🧰 tools
    └── 📝 wordpress
        ├── 🐳 Dockerfile
        └── 🧰 tools

_{Javier Fernández Correa}

Este proyecto está bajo la licencia MIT.