Proyecto 1: Implementación de un servicio de producción#

Objetivos#

  • Instalación y configuración de un servidor de aplicaciones
  • Creación del VirtualHost para la aplicación web
  • Instalación de una aplicación web y configuración de ambiente productivo
  • Instalación y configuración de la base de datos y motor de caché

Elementos de apoyo#

Páginas de manual de Apache HTTPD

Restricciones#

Danger

  • La evaluación de este proyecto final corresponderá al tercer examen parcial del curso

Warning

  • La fecha límite de entrega es el lunes 05 de diciembre de 2022 a las 23:59 horas

  • Esta actividad debe ser entregada en equipo de acuerdo al flujo de trabajo para la entrega de tareas y prácticas

    • Utilizar la carpeta docs/proyectos/proyecto-web/Equipo-ABCD-EFGH-IJKL-MNOP para entregar la práctica
    • Donde Equipo-ABCD-EFGH-IJKL-MNOP representa el nombre del equipo que debió anotarse previamente en la lista del grupo
    • Hacer un merge request a la rama proyecto-web del repositorio de tareas para entregar la actividad

  • Cada equipo tendrá que configurar uno de los servicios de red que se describen a continuación y anotar su elección en la hoja de cálculo compartida

  • No se permite tener proyectos repetidos. Revisar los requerimientos de la aplicación o sistema elegido para seleccionar la base de datos y motor de caché en memoria (si aplica).

Implementación de un stack web#

Lista de proyectos
Proyecto web

  • Elegir una aplicación de la tabla en la hoja de cálculo compartida

  • Proteger la sección administrativa del sitio utilizando autenticación de tipo digest

  • El sitio debe tener un certificado wildcard SSL emitido por Let's Encrypt y se debe utilizar el mismo nombre de dominio que en la práctica 9

  • El sitio debe hacer redirección de todas las peticiones HTTP hacía su versión en HTTPS

    • Se pueden usar redirecciones estándar 301 y 302 de HTTP

    • Utilizar la directiva Redirect o la configuración de mod_rewrite (pero no ambas porque son excluyentes entre si)

  • Habilitar el soporte de userdir donde cada usuario tenga en su directorio HOME una carpeta llamada public_html o public_tomcat que sirva para que el usuario suba sus archivos y que estén disponibles en /~usuario en el servidor

    • Ej. /home/andres-hernandez/public_html ⇨ https://example.com/~andres-hernandez

  • Instalar y configurar una aplicación web simple que se conecte al motor de caché y a la base de datos

  • Montar la aplicación elegida en el directorio /opt

  • Crear un VirtualHost para que la aplicación responda en los dominios proyecto.example.com y aplicacion.example.com sobre HTTP y HTTPS

  • No utilizar los VirtualHosts predeterminados ni ningún otro que se haya creado en la práctica 9 para HTTP ni HTTPS

    • Los sitios estáticos creados en la práctica 9 deben seguir funcionando

Configuración de respaldos#

Automatizar el respaldo de la base de datos en "esquema" y "contenido"

  • Script y configuración de la tarea programada para respaldar la base de datos cada 12 horas (medio día y media noche)

  • Definir un prefijo para que indique la fecha (YYYY-MM-DD-HH-MM) o marca de tiempo UNIX epoch (ver salida de date '+%s')

  • Definir si los archivos respaldo se guardan el prefijo en el nombre o si se crearán carpetas con el prefijo para contener los archivos de cada respaldo

  • recursos.tar.gz: Crear un archivo TAR comprimido con gzip que tenga los archivos que hayan subido los usuarios, cada aplicación tiene una carpeta que no forma parte del código donde guarda estos archivos

  • esquema.sql.gz: Generar un archivo SQL comprimido con gzip con el esquema de la base de datos (definición de tablas)

  • datos.sql.gz: Generar otro archivo SQL con los datos de todas las tablas de la base de datos

  • Subir los archivos resultantes a Google Drive utilizando rclone.

$ rclone config

    ...

Scope that rclone should use when requesting access from drive.
Choose a number from below, or type in your own value
 1 / Full access all files, excluding Application Data Folder.
   \ "drive"
 2 / Read-only access to file metadata and file contents.
   \ "drive.readonly"
   / Access to files created by rclone only.    ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅
 3 | These are visible in the drive website.    ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅
   | File authorization is revoked when the user deauthorizes the app.  ⬅   ⬅
   \ "drive.file"   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅
   / Allows read and write access to the Application Data folder.
 4 | This is not visible in the drive website.
   \ "drive.appfolder"
   / Allows read-only access to file metadata but
 5 | does not allow any access to read or download file content.
   \ "drive.metadata.readonly"

scope> 3    ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅

    ...

ID of the root folder - leave blank normally.  Fill in to access "Computers" folders. (see docs).
root_folder_id> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   ⬅   ⬅   ⬅   ⬅   ⬅   ⬅

    ...

Entregables#

  • Ver el siguiente video y emitir un comentario sobre la relación del contenido presentado y los conceptos utilizados en este proyecto

  • Subir a la carpeta compartida de Google Drive los siguientes archivos de respaldo que sustentan el trabajo elaborado en el desarrollo del proyecto:

    • Par de llaves SSH con las que se accedió al servidor en un archivo TAR (archivos equipo_redes_rsa y equipo_redes_rsa.pub)

    • Lista de usuarios y contraseñas para acceder a la aplicación web, base de datos y demás, en un archivo de texto llamado accesos.txt

    • Certificado y llave privada utilizados en el sitio web en un archivo TAR (directorio /etc/letsencrypt)

    • Respaldo de configuraciones del servidor en un archivo TAR (directorio /etc)

    • Respaldo de bitácoras del sistema en un archivo TAR (directorio /var/log)

  • Subir adicionalmente a la carpeta compartida:

    • Respaldo de la aplicación web en un archivo TAR (directorio /opt)

    • Respaldo de la base de datos utilizada en formato SQL

      • Puede ser comprimido con gzip, bzip2 o 7zip

Extra#

  • Implementar HSTS en las cabeceras del sitio para forzar a que se pida el contenido del sitio a través de HTTPS

    • Establecer un timeout bajo de entre 60 y 300 segundos para probar que HSTS funciona

  • Implementar la cabecera X-Robots-Tag para evitar que los motores de búsqueda indexen el sitio

Notas adicionales#

  • No se aceptan instalaciones que provengan de scripts que automaticen el proceso, ni de soluciones todo en uno (one click install)

  • Redacte un reporte por equipo, en el que consigne los pasos que considere necesarios para explicar cómo realizó el proyecto, incluya capturas de pantalla que justifiquen su trabajo

  • Incluya en su reporte un apartado de conclusiones referentes al trabajo realizado

  • Puede agregar posibles errores, complicaciones, opiniones, críticas de el proyecto, o cualquier comentario relacionado

  • Entregue su reporte de acuerdo a la forma de entrega de tareas y prácticas definida al inicio del curso