1. Introducción y Contexto del Laboratorio [0]

thumbnail

1.1. Continuación del Challenge de SysOps [0]

  • Este laboratorio es una continuación del video anterior sobre la introducción a Amazon CloudFormation. [1]
  • El objetivo es desplegar una aplicación de tres capas utilizando CloudFormation. [1]

1.2. Evolución de la Complejidad [2]

  • A diferencia del video anterior, donde se desplegó un solo servidor, este laboratorio aumenta la complejidad de la arquitectura. [2]
  • Se utilizará infraestructura como código a través de Amazon CloudFormation para desplegar una arquitectura más grande y compleja. [2]

1.3. Beneficios de la Automatización [24]

  • El objetivo principal de trabajar con AWS CloudFormation es la automatización completa de la creación de infraestructuras. [26]
  • Esto permite crear arquitecturas repetibles y replicables sin errores humanos, desplegándolas múltiples veces y en distintos ambientes (desarrollo, calidad, producción) con solo un clic. [27]
  • La automatización reduce la carga operativa para los desarrolladores, permitiéndoles enfocarse en la aplicación, que es lo que genera valor. [31]

2. Arquitectura de Tres Capas [2]

thumbnail

2.1. Definición y Componentes [2]

  • Una arquitectura de tres capas divide las aplicaciones en tres partes:
    1. Capa de presentación: La interfaz con el usuario. [3]
    2. Capa de aplicación: La lógica del negocio. [3]
    3. Capa de datos: Donde se almacena la información. [3]
  • AWS proporciona documentación y herramientas para visualizar estas arquitecturas. [2]

2.2. Buenas Prácticas [20]

  • Las arquitecturas de tres capas son una forma recomendada de crear aplicaciones para mantener todo segmentado. [20]
  • Facilitan el despliegue en entornos de desarrollo, pruebas y producción. [24]

3. Despliegue de la Arquitectura con CloudFormation [7]

thumbnail

3.1. Creación del Stack [7]

  • Para desplegar la arquitectura, se accede a la consola de AWS y se selecciona CloudFormation. [8]
  • Se crea un stack, especificando que el template se encuentra en Amazon S3. [8]
  • Se proporciona la URL del archivo JSON del template, en este caso, Multitier WFIX. [11]

3.2. Visualización con Infrastructure Composer [15]

  • La opción "Ver en el Infrastructure Composer" permite visualizar la arquitectura de forma más gráfica. [15]
  • El Infrastructure Composer es una herramienta visual para crear arquitecturas de CloudFormation arrastrando componentes. [17]

3.3. Componentes de la Arquitectura Desplegada [17]

  • La plantilla JSON carga los siguientes componentes:
    • Un bucket de S3 para almacenar información. [17]
    • Una instancia EC2 para la aplicación web. [17]
    • Una base de datos RDS para la capa de datos. [17]

3.4. Configuración de Parámetros [34]

  • La plantilla requiere la configuración de varios parámetros que el usuario debe proporcionar al desplegar el stack:
    • KeyName: El nombre del KeyPair para la instancia EC2. [43]
    • DBName: El nombre de la base de datos (por defecto: web DB). [44]
    • DBUser: El nombre de usuario para la base de datos (por defecto: admin). [47]
    • DBPassword: La contraseña para la base de datos.
      • Se configura no_echo: true para que la contraseña no se muestre al escribirla. [51]
      • Se establece una longitud mínima de ocho caracteres. [54]
    • BucketName: El nombre deseado para el bucket de S3. [55]

3.5. Definición de Recursos en la Plantilla [55]

  • La sección Resources define los componentes de la infraestructura:
    • Bucket de S3:
      • Su nombre se toma del parámetro BucketName. [56]
    • Security Group (Web App Security Group):
      • Permite tráfico en el puerto 22 (SSH) y el puerto 80 (HTTP) desde cualquier origen. [57]
    • Instancia EC2 (web instance):
      • Tipo de instancia: t3.micro. [59]
      • Utiliza el KeyPair especificado en el parámetro KeyName. [60]
      • Asocia el Security Group llamado Web App Security Group. [61]
      • Incluye un AMI ID (Image ID) que debe ser válido en la región seleccionada. [62]
      • User Data Script: Se ejecuta al iniciar la instancia para:
        • Actualizar paquetes. [64]
        • Instalar httpd (servidor Apache), php, y php-mysql. [65]
        • Reiniciar y activar el servicio httpd. [66]
        • Crear un archivo index.html con el mensaje "servidor Apache funcionando en Amazon Linux 2023". [66]
    • Base de Datos RDS:
      • Tipo: Base de datos RDS. [74]
      • Almacenamiento: 20 GB. [75]
      • Clase de instancia: db.t3.micro. [75]
      • Motor: MySQL. [76]
      • Usuario maestro: Tomado del parámetro DBUser. [76]
      • Contraseña maestra: Tomada del parámetro DBPassword. [77]
      • Configuración de Security Group. [77]
      • Acceso público: true. [78]
      • Periodo de retención de backups: Configurado a cero (sin retención de backups). [80]
      • Protección de eliminación: false. [82]

3.6. Definición de Outputs (Salidas) [83]

  • La sección Outputs define la información que se mostrará al finalizar el despliegue del stack:
    • La IP pública de la instancia EC2. [85]
    • La URL del servidor web. [85]
    • El nombre del bucket S3 creado. [85]

3.7. Configuración de Tags [114]

  • Se pueden añadir tags para organizar y categorizar los recursos:
    • proyecto: web app multicapas [114]
    • environment: desarrollo [116]
    • CloudFormation: Indica que el despliegue se realizó con CloudFormation. [117]

3.8. Proceso de Despliegue y Eventos [126]

  • Tras configurar los parámetros y tags, se da clic en "Submit" para iniciar el despliegue. [121]
  • La sección "Events" en CloudFormation muestra el progreso de la creación de cada recurso. [127]
  • Se observan los eventos de creación del Security Group, Bucket S3, Instancia EC2 y Base de Datos RDS. [128]

4. Verificación de Recursos Desplegados [136]

thumbnail

4.1. Bucket S3 [148]

  • Se verifica que el bucket S3 se creó con el nombre proporcionado en el parámetro BucketName (ej: webapp multicapas 03052025). [150]

4.2. Instancia EC2 [139]

  • Se confirma la creación de una instancia t3.micro. [142]
  • Se verifica que el Security Group asociado (Web App Security Group) permite los puertos 22 y 80. [144]

4.3. Base de Datos RDS [160]

  • Se confirma la creación de la base de datos RDS con las especificaciones definidas en la plantilla (clase db.t3.micro, motor MySQL). [161]

5. Concepto de Drift en Infraestructura como Código [130]

thumbnail

5.1. Definición de Drift [130]

  • Drift ocurre cuando hay una discrepancia entre la infraestructura que CloudFormation conoce (definida en el template) y la infraestructura que está realmente desplegada en AWS. [131]
  • Esto sucede si se realizan cambios manuales en los recursos desplegados sin actualizar el template de CloudFormation. [131]

5.2. Detección de Drift [190]

  • CloudFormation permite detectar estos drifts. [132]
  • Se accede a la opción "Detectar Drift" desde el stack en la consola de CloudFormation. [193]
  • Inicialmente, la detección puede indicar "in sync" hasta que los cambios se propaguen. [195]

5.3. Simulación de Cambio Manual [170]

  • Se realiza un cambio manual en la configuración de la base de datos RDS:
    • Se modifica el periodo de retención de backups de cero a dos. [177]
  • Se aplica el cambio inmediatamente. [187]

5.4. Verificación de Drift Detectado [201]

  • Tras esperar un tiempo para que los cambios se reflejen, se vuelve a ejecutar la detección de drift. [201]
  • CloudFormation detecta el drift y muestra una advertencia. [233]
  • Se puede seleccionar el componente con drift (la base de datos) para ver los detalles del cambio. [234]
  • Se observa que el backup retention period cambió de 0 a 2. [237]
  • El drift indica que la infraestructura desplegada no coincide con la definición en el código. [241]

5.5. Importancia y Corrección del Drift [242]

  • Es crucial identificar y corregir los drifts, especialmente en entornos de CI/CD, para evitar la pérdida de cambios manuales. [243]
  • Los drifts se corrigen actualizando el template de CloudFormation o realizando cambios manuales para alinearlos con el código. [244]

6. Validación de la Arquitectura [209]

thumbnail

6.1. Verificación de Outputs [209]

  • La sección "Outputs" del stack proporciona información útil:
    • IP pública de la instancia. [209]
    • Nombre del bucket S3. [209]
    • URL del servidor web. [209]

6.2. Prueba del Servidor Web [211]

  • Al acceder a la URL del servidor web en un navegador, se muestra el mensaje "servidor Apache funcionando en Amazon Linux 2023". [212]
  • Esto confirma que el servidor Apache, PHP y MySQL se instalaron correctamente y que la página web básica está funcionando. [214]

6.3. Verificación de la Instancia EC2 [217]

  • Se valida la IP pública de la instancia en la consola EC2. [217]
  • Se puede conectar a la instancia vía SSH (Instance Connect) para verificar el estado del servicio Apache (systemctl status httpd), confirmando que está activo y corriendo. [221]

6.4. Verificación de la Base de Datos RDS [226]

  • Se confirma que la base de datos RDS está disponible. [226]
  • Se puede obtener el endpoint de la base de datos para conectarse a ella a través de una aplicación compatible (puerto 3306). [227]

7. Eliminación de Recursos [246]

thumbnail

7.1. Eliminación del Stack [249]

  • Después de probar la arquitectura, se procede a eliminar los componentes para evitar cobros innecesarios. [249]
  • La eliminación se realiza seleccionando el stack y eligiendo la opción "Eliminar". [250]
  • CloudFormation se encarga de eliminar todos los recursos creados como parte del stack. [252]
  • Los recursos creados manualmente fuera del stack no serán eliminados por este proceso. [253]

7.2. Proceso de Eliminación [255]

  • Se observa el progreso de la eliminación en la sección "Events" del stack. [255]
  • Los recursos como la instancia EC2 y el bucket S3 se eliminan rápidamente. [255]
  • La eliminación de la base de datos RDS puede tomar más tiempo. [268]
  • Finalmente, el stack se marca como "borrado completo". [318]
  • Se verifica que la base de datos también ha sido eliminada, ya que no se encuentra en la consola RDS. [321]

8. Recursos Adicionales y Comunidad [278]

thumbnail

8.1. Repositorio y Canal de YouTube [278]

  • Se menciona un repositorio de GitHub (challengop) que contiene videos y laboratorios del challenge. [278]
  • Los laboratorios pregrabados se subirán al canal de YouTube para que los usuarios puedan seguirlos. [283]
  • Se invita a revisar el repositorio de GitHub para encontrar más laboratorios y recursos. [286]

8.2. Serie "Cloud Experimentos Reales" [301]

  • Existe una serie de videos llamada "Cloud Experimentos Reales" en el repositorio, que incluye instrucciones paso a paso y videos de laboratorios. [301]
  • Se sube un video semanalmente, y los que están en negrita ya han sido publicados. [303]

8.3. Invitación a la Comunidad [306]

  • Se anima a compartir y recomendar el video a personas interesadas en aprender AWS, certificarse en SysOps Administrator Associate, o que trabajen en roles de AWS Cloud. [307]
  • Se enfatiza que los laboratorios son valiosos para adquirir habilidades técnicas y reforzar el conocimiento teórico, lo cual es importante para roles y entrevistas. [317]