Examen 3: 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#
Note
Todos estos videos están en una lista de reproducción dedicada a los temas de HTTP y SSL 📹
- Protocolo DNS 📼
- Configuración de OpenSSH y autenticación con llaves 📼
- Configuración de Apache HTTPD en Debian 📼
- Directivas de configuración de Apache HTTPD 📼
- Configuración de VirtualHosts de Apache HTTPD 2.4 utilizando /etc/hosts 📼
- Configuración de VirtualHosts de Apache HTTPD 2.4 con registros DNS 📼
- Certificados SSL x509 📼
- Certificados SSL con OpenSSL y VirtualHost HTTPS en Apache HTTPD 📼
- Trámite de un certificado SSL con Let's Encrypt utilizando certbot 📼
Páginas de manual de Apache HTTPD
Restricciones#
Danger
- La evaluación de esta actividad corresponderá al tercer examen parcial del curso
Warning
- Esta actividad depende de los recursos implementados en la práctica 8 y práctica 9
- Se recomienda que se realicen las actividades previas siguiendo la calendarización con el objeto de dejar suficiente tiempo para la elaboración de este proyecto
- 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
- Utilizar la carpeta
-
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 |
---|
![]() |
-
Elegir una aplicación de la tabla en la hoja de cálculo compartida
-
Instalar y configurar la aplicación web elegida que se conecte a la base de datos y al motor de caché
-
Montar la aplicación elegida en el directorio
/opt
-
Crear un VirtualHost para que la aplicación responda en los dominios
proyecto.example.com
yaplicacion.example.com
sobre HTTP y HTTPSNote
Algunas aplicaciones únicamente responden en un nombre de dominio, si este es el caso habilitar la redirección del dominio
proyecto.example.com
haciahttps://aplicacion.example.com/
# Redirecciona "el otro nombre de dominio" al dominio de la aplicacion por HTTPS
<VirtualHost *:80>
ServerName proyecto.tonejito.cf
# Usa Redirect al vhost de la aplicación o pon la configuracion de HSTS
Redirect / https://aplicacion.tonejito.cf/
</VirtualHost>
# Redirecciona "el otro nombre de dominio" al dominio de la aplicacion por HTTPS
<VirtualHost *:443>
ServerName proyecto.tonejito.cf
Redirect / https://aplicacion.tonejito.cf/
# FIXME agregarDocumentRoot LogLevel, ErrorLog, CustomLog, certificado y llave
</VirtualHost>
# Redirecciona la aplicación de HTTP a HTTPS
<VirtualHost *:80>
ServerName aplicacion.tonejito.cf
# Usa Redirect al vhost de la aplicación o pon la configuracion de HSTS
Redirect / https://aplicacion.tonejito.cf/
</VirtualHost>
# Este VHOST tiene la configuraion de la apliacion
<VirtualHost *:443>
ServerName aplicacion.tonejito.cf
# FIXME agregar DocumentRoot, LogLevel, ErrorLog, CustomLog, certificado y llave
# TODO: Config apliacion
</VirtualHost>
-
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
-
Proteger la sección administrativa o sección de usuarios autenticados del sitio utilizando autenticación de tipo
digest
Note
Cada sitio tiene su propia ruta de la sección administrativa o la sección donde inician sesión los usuarios, consultar la documentación de cada software. Ejemplo:
https://proyecto.example.com/login
https://aplicacion.example.com/admin
https://proyecto.example.com/user
https://aplicacion.example.com/manage
Al configurar la autenticación digest el usuario tendrá que introducir las credenciales digest en el navegador para siquiera poder visualizar la página de inicio de sesión y ahí introducir sus credenciales para acceder a la aplicación.
-
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
y302
de HTTP -
Utilizar la directiva
Redirect
o la configuración demod_rewrite
(pero no ambas porque son excluyentes entre si)
-
-
Habilitar el soporte de
userdir
donde cada usuario tenga en su directorioHOME
una carpeta llamadapublic_html
opublic_tomcat
que sirva para que el usuario suba sus archivos y que estén disponibles en/~usuario
en el servidor
$ echo '<html><body>Carpeta userdir</body></html>' > /home/redes/public_html/index.html
- Ej. `/home/redes/public_html` ⇨ `https://example.com/~redes`
!!! note
Configurar el módulo `userdir` para que **únicamente** sirva los directorios `public_html` (o `public_tomcat`) en el VirtualHost `default_ssl` (`_default_:443`) del dominio principal `example.com` que transmite los datos utilizando HTTPS
Envío de correo electrónico a través de un relay#
Se utilizará el relay de correo de AWS SES para el envío de correo electrónico a través del protocolo SMTP
-
Seguir el procedimiento para configurar el MTA local con Postfix y que utilize el relay SMTP de AWS SES
-
Otra opción es configurar el remitente y las credenciales SMTP directamente en la aplicación web.
Danger
Las credenciales de SMTP se proporcionarán por un mecanismo alterno
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 dedate '+%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 congzip
que tenga los archivos que hayan subido los usuarios de la aplicación que hayan elegido, 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 congzip
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
.-
Tener cuidado con los permisos que se dan a la aplicación y seleccionar el modo de acceso
drive.file
para dar acceso ÚNICAMENTE a los archivos y directorios querclone
haya creado. -
Establecer un folder como la raíz que puede ver
rclone
para limitar aún mas el acceso a Google Drive.
-
$ 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 ⬅ ⬅ ⬅ ⬅ ⬅ ⬅
...
Verificación del caché en RAM#
Es posible verificar el estado de los servicios MemCache y Redis utilizando los scripts de shell:
MemCache#
MemCache
Puedes probar el servicio de MemCache utilizando el script de shell test-memcache.sh
root@example:~# chmod -c +x test-memcache.sh
root@example:~# ./test-memcache.sh
...
Redis#
Redis
Puedes probar el servicio de Redis utilizando el script de shell test-redis.sh
root@example:~# chmod -c +x test-redis.sh
root@example:~# ./test-redis.sh
...
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
(archivosequipo_redes_rsa
yequipo_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
)
-
- 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 HTTP Strict Transport Security (HSTS) en las cabeceras del sitio para forzar a que se pida el contenido del sitio a través de HTTPS
-
Establecer estas configuraciones en los VirtualHosts de la aplicación para evitar conflictos con la configuración de los otros VirtualHosts de los demás sitios implementados en las prácticas anteriores
-
Establecer un timeout bajo de entre
60
y300
segundos para probar que HSTS funciona -
Probar esta configuración en el VirtualHost de HTTP y HTTPS para ver la configuración que se debe dejar
-
Deshabilitar la redirección de HTTP a HTTPS si se está habilitando HTTP Strict Transport Security (HSTS)
-
-
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