Anteriormente: Flask 19. Usar Flask Blueprint para estructurar aplicaciones. 2ª parte.
Desplegar una aplicación Flask con Nginx y Gunicorn en una Rapsberry Pi
En este capítulo, lo que vamos a hacer es desplegar nuestra aplicación Flask en una Rapsberry Pi que actuará como servidor, para que cualquiera pueda acceder a ella desde cualquier parte del mundo. Para ello utilizaremos los programas Nginx y Gunicorn. Gunicorn se encargará de traducir nuestro programa de Flask a Nginx para que este se encargue de servir nuestras plantillas web como respuesta a las peticiones que se realicen.
Paso 1: Requisitos previos
A) Actualizar los repositorios del sistema.
El sistema operativo que utilizaré en mi Rapsberry Pi es el suyo propio, Raspbian Pi Os, que es un derivado linux de Debian. En él, ya viene instalado Python3 con lo que empezaremos actualizando los paquetes del sistema con los siguientes comandos:
$ sudo apt-get update
$ sudo apt-get full-upgrade
B) IP interna fija.
Es necesario que nuestra Raspberry Pi tenga una IP estática, que no varíe nunca cuando se reinicie, dentro de nuestra red local.
Cada router es un mundo. Para configurar una IP estática debemos asegurarnos que esté fuera del rango DHCP (tendréis que verificarlo en la configuración de vuestro router) y que ningún otro dispositivo tiene asignada la misma IP. En el mío, se empiezan a asignar direcciones desde 192.168.1.1 hasta 192.1.168.199 por lo que no haya problemas de asignación, la Rapsberry Pi estará estática en la dirección 192.168.1.200
Para asignar una IP estática en Rapsberry Pi Os seguimos los siguientes pasos. Debemos editar el fichero /etc/dhcpcd.conf con el comando:
sudo nano /etc/dhcpcd.conf
En este fichero hay unas líneas comentadas, que empiezan por #. Buscamos la que tiene un ejemplo de configuración de IP estática (Example static IP configuratión) y añadimos la dirección estática que queramos (en mi caso 192.168.1.200/24, con el /24 al final) y la dirección de nuestro router, en el mío 192.168.1.1
Mi Rapsberry Pi esta conectada directamente al router (eth0), si la tienes conectada por wifi debes utilizar entonces "interface wlan0"
Guardamos y Cerramos.
ACTUALIZACION.!!! A fecha de hoy 20/03/2024 con las sucesivas actualizaciones del sistema operativo de la pi, esto ya no funciona, concretamente desde la versión Bookworm. Ahora hay que hacerlo a nivel de router que es lo recomendado. No obstante se puede seguir haciendo a nivel de host de forma sencilla. Sigue las instrucciones de este enlace https://access.redhat.com/documentation ... connection.
Si no eres root acuérdate de usar sudo delante. Se resume en dos pasos:
1.- Si no conocemos el nombre del dispositivo de red que estamos usando para la conexión, podemos mostrarlo con:
# nmcli device status
eth0 ethernet connected Wired connection 1
lo loopback connected (externally) lo
wlan0 wifi disconnected --
p2p-dev-wlan0 wifi-p2p disconnected -- 2.- Ejecutamos nmtui:
# nmtui
De forma visual, escogemos "Edit a conexion", seleccionamos la conexión activa por su nombre, en mi caso "Wired connection 1" y le damos a "Edit". Vamos al apartado "IPv4 CONFIGURATION" y en "Addresses" ponemos la ip fija que queremos utilizar y en "Gateway" la dirección de acceso al router. Le damos a OK, guardamos y salimos.
Puedes encontrar más información en el forum de rapsberri pi "Static IP con Bookworm".
C) Un poco de seguridad.
Como norma básica de seguridad sería conveniente seguir una serie de pautas como cambiar el nombre del usuario por defecto, el nombre de la máquina, configurar un Firewall etc.
NOTA: Por razones prácticas en el resto del capítulo (todo lo que no es este apartado de seguridad) he seguido usando el usuario pi y rapsberry como nombre del host, pero lo suyo seria cambiarlos.
Cuando el servidor este en modo de producción tendríamos que haber seguido al menos las normas más básicas de seguridad que os paso a enumerar. Puedes encontrar más información aquí.
1) Root desactivado.
En el sistema operativo que utilizo en la Raspberry Pi, Raspberry Pi OS o Raspbian antiguamente, el usuario Root ya viene desactivado por defecto. No obstante si utilizas otra distribución Linux que no ocurra esto deberías definir un usuario con permisos de Root y luego desactivarlo.
2) Cambiar la contraseña por defecto del usuario pi.
Aunque lo mejor es utilizar otro usuario que no se pi, lo que haremos en el próximo paso, si vas a seguir con el usuario "pi" por lo menos cámbiale la contraseña que viene por defecto. Para ello desde el terminal puedes utilizar la aplicación de configuración:
sudo raspi-configy ya de paso cambiar también el nombre de la máquina o host que por defecto es "raspberrypi" o puedes usar este comando de linux aunque solamente para cambiar la contraseña por defecto "raspberry"
passwd
3) Eliminar el usuario pi y crear uno nuevo con permisos.
Como los principales ataques por fuerza bruta que vas a recibir en tu servidor van a intentar conectarse al usuario "pi" que saben que es el que viene por defecto al menos vamos a intentar complicarles algo las cosas. Para ello seguimos el ejemplo que viene en el manual de seguridad de la fundación Rapsberry creando un nuevo usuario con privilegios y eliminando finalmente al usuario pi.
Empezaremos creando un nuevo usuario, usa el nombre que quieras, en el ejemplo utilizaremos alice.
sudo adduser aliceAquí nos pedirá que introduzcamos la contraseña para este nuevo usuario. Este usuario tendrá su directorio base en /home/alice
Luego le daremos los permisos necesarios para poder funcionar:
sudo usermod -a -G adm,dialout,cdrom,sudo,audio,video,plugdev,games,users,input,netdev,gpio,i2c,spi alicePara ver si todos los permisos estan correctos utiliza:
sudo su - aliceSi no te sale ningún error es que todo está bien.
Una vez hecho esto cierra la sesión que teníamos abierta con el usuario pi o reinicia el sistema y vuelve a entrar en el mismo, en este caso usando el nuevo usuario creado "alice". Ahora por si queda algún proceso que utilice el usuario "pi" antes de borrarlo paramos sus procesos con:
sudo pkill -u piy finalmente podemos optar por:
- borrar al usuario pi pero dejando todos sus directorios intactos para lo cual tecleamos:
sudo deluser pio si es una instalación limpia nos cargamos al usuario pi y también todos sus directorios que no nos sirven para nada con:
sudo deluser -remove-home piSi utilizas este último comando, te saldrá un mensaje de advertencia diciéndote que el grupo pi no tiene más usuarios. El comando deluser ha borrado tanto al usuario pi como el grupo pi así que puedes ignorar esta advertencia tranquilamente y seguir para adelante.
4) Hacer que el comando "sudo" requiera contraseña.
Poner sudo delante de un comando hace que ese comando se ejecute como si fueras un superusuario, y en esta distribución por defecto no hace falta contraseña. Esto generalmente no es un problema, pero imagina que como la pi va a estar conectada a internet alguien logra entrar y pueda ejecutar comandos que requieran credenciales de superusuario. Pues tenemos un problema. Para evitar esto forzaremos al sistema a que cada vez que usemos "sudo" nos pida la contraseña.
Entramos en el terminal y tecleamos:
sudo visudo /etc/sudoers.d/010_pi-nopasswdTe encontraras una línea para el usuario pi, parecida que no igual que la de abajo, que tenemos que cambiar por nuestro nombre de usuario y la siguiente configuración:
alice ALL=(ALL) PASSWD: ALLSi tuviésemos otros usuarios con permisos de superusuario también tendríamos que cambiarles la configuracion a ALL=(ALL) PASSWD: ALL. lo cual no es el caso si has seguido el ejemplo con una instalación limpia. Solo tenemos a alice. Guardamos y salimos.
Para que el cambio surja efecto reinicia el sistema.
5) Tener el sistema actualizado.
Básico en todos los sistemas operativos para tener los últimos parches que surjan para tapar agujeros de seguridad.
Esto conviene hacerlo regularmente y son los comandos:
sudo apt-get updatesudo apt-get full-upgradeComo esto en un servidor no es muy práctico el hacerlo a mano todos los días seria conveniente el hacerlo de manera automática. Puedes usar para ello la aplicación cron de linux que permitirá ejecutar estos comandos el día y a la hora que los programes o utilizar soluciones de terceros como unattended-upgrades
Como yo en mi caso además me conecto con la raspberry no directamente sino desde mi pc a través de ssh, conviene también tener siempre al día este protocolo con:
sudo apt install openssh-server
6) Mejorando la seguridad de la conexión SSH
Si como es mi caso, no os estáis tecleando directamente en la raspberry sino que lo hacéis remotamente a través de una conexión ssh desde un pc es muy importante seguir las siguientes normas para intentar evitar que alguien se nos cuele en el sistema por esta vía.
Lo más importante que debes hacer es asegurarte de tener una contraseña muy sólida. Si tu raspberry va a estar conectada a internet, haciendo de servidor, lo lógico es que tu contraseña de acceso sea lo más robusta posible. Esto te ayudará a evitar los ataques por fuerza bruta que por ejemplo usan un diccionario de palabras para intentar encontrar tu contraseña.
Existen muchas páginas online donde puedes comprobar la robustez de una contraseña. Unas de ellas es por ejemplo https://password.kaspersky.com/es/
Si tecleas por ejemplo 1234, verás lo siguiente:
Si queremos añadir un poquito más de seguridad también podemos permitir o denegar a determinados usuarios su conexión a la raspberry por sshd. Como en mi caso, solo voy a querer entrar yo en la raspberry, me permitiré solamente el acceso a mi usuario mismamente :-)
sudo nano /etc/ssh/sshd_configAllowUsers alice DenyUsers mihermano hackermaligno loqueseteocurraDespués de guardar los cambios y salir del archivo si queremos que estos entren ya mismo en funcionamiento tenemos que reiniciar el servicio con:
sudo systemctl restart ssh
o también reiniciar la raspberry valdría para que los cambios tuvieran efecto.
AUNQUE LO MEJOR Y LO MÁS SEGURO, que la gente que sabe de esto recomienda para acceder a la raspberry por ssh es que te olvides de la contraseña y utilices la autentificación basada en claves criptográficas (Key-based authentication)
Vamos con ello.
En el cliente, es decir en el ordenador que estas usando para conectarte a la raspberry hay que teclear desde el terminal:
>> ssh-keygen
Esto nos generará dos claves criptográficamente seguras, una privada y una pública que utilizaremos para autenticar nuestro ordenador (cliente) en un servidor (nuestra pi) a través del prótocolo ssh.
Al ejecutar el comando nos saldrá la opción de poner contraseña aunque por el momento lo dejaremos en blanco. Creará un directorio oculto .ssh con la clave privada id_rsa y pública id_rsa.pub. La clave privada la mantendremos a buen recaudo mientras que la clave pública la tenemos que copiar a la raspberry pi con el siguiente comando, que tecleamos en la terminal de nuestro pc:
>>> ssh-copy-id <USERNAME>@<IP-ADDRESS><USERNAME> es el usuario de tu raspberry (alice en mi caso) y <IP_ADDRESS> la dirección de red que corresponde a tu raspberry (192.168.1.200 en mi caso)
Nota. Como lo que estamos haciendo es enviar la clave pública desde nuestro ordenador al fichero de claves autorizadas en la raspberry pi (authorized-keys) necesitaras teclear cuando te lo pida la contraseña de tu usario en la pi.
Yo lo estoy haciendo en una máquina con ubuntu 20.04 pero si este comando no estuviera disponible en vuestra distribución puedes copiarla directamente usando:
cat ~/.ssh/id_rsa.pub | ssh <USERNAME>@<IP-ADDRESS> 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
También podrías enviarla manualmente a través de ssh con el comando scp. Puedes ver este link para obtener más información sobre como enviar archivos mediante el comando scp.
Para finalizar como nos vamos a conectar usando las claves criptográficas ya no necesitamos que la rapsberry nos pida contraseña al conectarnos mediante ssh. Entonces para finalizar desactivamos que se requiera contraseña para conectarnos a la raspberry. ESTO lo tecleamos ya en la raspberry, para editar el archivo de configuración de la conexión ssh:
sudo nano /etc/ssh/sshd_configHay 3 líneas que necesitamos cambiar a no, si aún no están configuradas de esta manera.
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM noGuardamos y salimos.
Como siempre para que vuelva a funcionar reiniciamos el servicio con:
sudo service ssh reload
o reiniciamos el sistema.
7) Desabilitar el acceso como Root.
Aunque en Raspberry Os el root está deshabilitado por defecto no está de mas impedir el acceso como root al sistema. Solo nos llevará un momento y se hace en el mismo archivo de configuración que hemos usado antes:
sudo nano /etc/ssh/sshd_configBuscamos la línea y la cambiamos a no, o si no existe lo tecleamos directamente:
PermitRootLogin no
Guardamos y salimos.
Igual que en el punto anterior reiniciamos el servicio con:
sudo service ssh reload
o reiniciamos el sistema.
8) Configurar un Firewall Básico.
Como nuestro servidor va a estar abierto al mundo exterior es conveniente que tengamos algún tipo de Firewall UFW. Rapsberry Pi no tiene ninguno instalado con lo que procedemos a instalarlo con:
alice@raspberrypi:~ $ sudo apt-get install -y ufw
Cuando usamos un sistema en remoto hay que tener cuidado ya que es muy fácil bloquearse a uno mismo y no poder entrar en el sistema. Por ejemplo porque usemos la conexión ssh y hayamos configurado el firewall para que lo bloquee.
Por ello lo primero que vamos a ver es como resetear el firewall a su configuración original por si algo sale mal. Lo que tendrías que teclear, que ahora no hace falta es:
alice@raspberrypi:~ $ sudo ufw reset
Si como yo, no tienes monitor y estás accediendo a la rapsberry pi a través del protocolo ssh, necesitamos asegurarnos de que el cortafuegos permita conexiones ssh para que podamos conectarnos o iniciar sesión con ella la próxima vez. Podemos permitir esas conexiones tecleando:
alice@raspberrypi:~ $ sudo ufw allow OpenSSH
o también podríamos utilizar otra forma alternativa que hace los mismo:
alice@raspberrypi:~ $ sudo ufw allow ssh
o tambien alice@raspberrypi:~ $ sudo ufw allow 22
¿Por qué es lo mismo? Pues porque el servicio ssh utiliza por defecto el puerto 22. Si por más seguridad hubiéramos configurado el puerto por defecto que usa el servicio ssh a otro puerto distinto tendrías que abrir ese puerto para poder usar el servicio.
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)$ sudo apt-get install -y ufw
$ sudo ufw allow OpenSSH
$ sudo ufw --force enable
$ sudo ufw limit ssh/tcp
# niega la conexion si una ip ha intentado conectarse 6 o más
# veces en los últimos 30 segundos.
$ sudo ufw status8) Protegerse de ataques por fuerza bruta con Fail2ban
Para terminar con el apartado de "seguridad" vamos a ver como funciona muy resumidamente Fail2bin.
De la wikipedia:
Fail2ban es una aplicación escrita en Python para la prevención de intrusos en un sistema, que actúa penalizando o bloqueando las conexiones remotas que intentan accesos por fuerza bruta
Lo primero como siempre es instalar el programa:
sudo apt install fail2banBásicamente vamos a instalar el programa con las opciones por defecto, pero añadiendo unas reglas básicas para ssh. Como vamos a usar unos parámetros diferentes crearemos el archivo /etc/fail2ban/jail.local para este propósito e introduciremos ahí los parámetros deseados. Estos sobrescriben los valores respectivos de jail.conf que no se deben tocar.
Teclearemos:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.localUna vez en el editor añadimos la siguiente regla:
[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = -1Guardamos y salimos.
Nota:
maxretry son los intentos máximos de conexión erróneos que permitimos. En nuestro caso 3. OJO si te conectas a la pi por ssh mediante contraseña que si te confundes tres veces serás baneado y si encima tienes bantime con un número negativo, como en nuestro ejemplo, lo hace para siempre.
Podemos quitar bantime y el programa usará el tiempo por baneo por defecto del programa o si queremos podemos poner un tiempo determinado por nosotros en segundos. Por ejemplo un baneo de una hora sería bantime=60000 o si queremos una semana también podemos poner bantime=1w
Si hacemos un cambio en el archivo de configuración, o bien reiniciamos el sistema o bien usamos:
sudo service fail2ban restartPodemos ver la actividad de fail2ban con:
sudo fail2ban-client status ssh
o editando el siguiente archivo:
cat /var/log/fail2ban.log
D) IP Pública Dinámica y obtención de nombre de Dominio apuntando a nuestro servidor.
Otro requisito previo es que necesitamos acceder a la Raspsberry Pi desde fuera de nuestra red local (DNS DINAMICA) y tenemos que obtener un nombre de dominio que apunte a nuestro servidor. Ambas cosas las conseguiremos con lo siguiente.
Hasta ahora todo lo que hemos realizado es para acceder a la aplicación desde nuestra red local, para que nuestra Pi tenga siempre una dirección fija en nuestra red. Pero para acceder desde fuera de ella, el primer problema que se nos plantea es que normalmente solemos tener una dirección IP Pública variable, que no siempre es la misma, que puede cambiar. Es como si fuéramos a visitar a un amigo en el extranjero que hace tiempo que no vemos y cada vez que vamos a verle nos cambian el nombre y número de la calle.
Puedes saber cual es tu ip pública en un momento concreto buscando en cualquier buscador ¿Cuál es mi ip?
Para solventar esto y que aunque cambie nuestra ip pública el que busque nuestra página siempre sea redirigido a nuestra raspberry vamos a utilizar un servicio gratuito de una página muy conocida llamada https://www.noip.com/, aunque existen otras muchas (Freenom, Ducks Dns, DNS Exit, dynu, freedns.afraid.org etc)
La filosofía a groso modo es la siguiente. Instalaremos un programa en nuestra Rapsberry que le dirá a este proveedor cada poco tiempo (pej 5 minutos) cual es nuestra ip pública. Este proveedor nos facilita de forma gratuita hasta 3 dominios. Cuando nosotros, o el que sea los visite, será redirigido a nuestra ip pública actual automáticamente. Así ya no nos importa que esta haya cambiado, porque el dominio siempre hará referencia a nuestra ip actual.
Lo primero de todo es que en tu red local la Rapsberry Pi tenga asignada una dirección Ip Estática, que sea siempre la misma, tal como se supone que hiciste si seguiste esta guía, esta concretamente en el paso 1.
Luego nos registraremos en la página de NO-IP y crearemos una cuenta (Sign up).
En el menú de la izquierda, seleccionamos donde pone Dynamic DNS y creamos el hostname que queramos.
Para este proyecto imagina que escogimos miproyecto.hopeto.org (este dominio es ficticio, lo uso solo a modo de ejemplo, tu puedes escoger el quieras que este disponible)
Clicamos en donde pone Dynamic Update Cliente y seleccionamos el sistema operativo donde correrá el cliente de actualización de nuestra IP. En mi caso como estoy desplegando el proyecto en una Rapsberry pi 4 escogeré la opción de Linux. Hacemos click derecho en la pestaña "Download DUC" y seleccionamos la opción "Copiar dirección de enlace".
Volvemos al terminal y teleamos wget y le damos a pegar para que nos pegue la dirección del enlace de la descarga.
A la fecha de este tutorial la instrucción sería:
pi@raspberrypi:~ $ wget https://www.noip.com/client/linux/noip-duc-linux.tar.gz
Nos habrá descargado el archivo noip-duc-linux.tar.gz. Ya solo nos queda seguir las instrucciones de instalación.
- Extraemos el archivo comprimido con:
pi@raspberrypi:~ $ tar -zxvf noip-duc-linux.tar.gz
Ahora tenemos un directorio llamado noip-2.1.9-1. Entramos dentro con:
pi@raspberrypi:~ $ cd noip-2.1.9-1/
pi@raspberrypi:~/noip-2.1.9-1 $ sudo make
pi@raspberrypi:~/noip-2.1.9-1 $ sudo make install
Hecho esto, el instalador nos preguntará el usuario con el que nos hemos registrado y la contraseña.
También nos preguntará con que intervalo actualizar nuestra Ip. Por defecto te aparece 30 minutos pero es más practico ponerlo en 5. Con esto ya tenemos el archivo de configuración creado.
Lo próximo es configurar el servicio del cliente de NO-IP para que arranque automáticamente cuando lo haga la raspberry. Para ello creamos el siguiente archivo:
pi@raspberrypi:~ $ sudo nano /etc/init.d/noip2
Dentro ponemos la siguiente instrucción:
sudo /usr/local/bin/noip2
Paso 2: Crear un entorno virtual en Python e instalar la aplicación.
Aunque el paquete básico de Python ya esta instalado en Raspbian Pi Os, puede que algunos paquetes adicionales no lo estén o no estén actualizados para lo cual vamos a empezar con ello:
$ sudo apt-get -y update
$ sudo apt-get -y install python3 python3-venv python3-devA continuación crearemos un entorno virtual donde pondremos un programa Flask que nos servirá de muestra. En Rapsberry Pi OS lo necesario para crear un entorno virtual ya está instalado por defecto, pero si no lo tuvieras lo puedes hacer con:
sudo apt install python3-venv
A continuación creamos el directorio que contendrá la aplicación, yo lo llamaré "miproyecto".
$ mkdir ~/miproyecto
y entramos en el:
$ cd ~/miproyecto
Vamos a utilizar git para descargar y usar el código del capítulo anterior desde mi repositorio de GitHub. El problema es que no podemos usar directamente git clone https://github.com/chema-hg/CURSO-DE-FLASK.git porque nos descargaría todas las carpetas de todos los capítulos que ya hemos visto a parte del que nos interesa.
Por ello para clonar solamente el directorio que nos interesa, que es el 'POST 19', vamos a seguir los siguientes pasos:
- Inicializamos el proyecto con:
~/miproyecto $ git init
- Procedemos a indicar el repositorio remoto en donde se encuentra el proyecto:
~/miproyecto $ git remote add origin https://github.com/chema-hg/CURSO-DE-FLASK.git
~/miproyecto $ git config core.sparsecheckout true
- Para clonar solamente un subdirectorio necesitamos definir que archivo o carpeta es la que queremos clonar dentro de la estructura del directorio (tenemos que teclear su nombre exactamente), lo cual hacemos de la siguiente manera:
~/miproyecto $ echo /POST 19/ >> .git/info/sparse-checkout
~/miproyecto $ git pull --depth=1 origin master
~/miproyecto $ cd 'POST 19'/
~/miproyecto/POST 19 $ mv ~/miproyecto/'POST 19'/* ~/miproyecto/
~/miproyecto/POST 19 $ cd ..
~/miproyecto $ rmdir 'POST 19'/
Bien ahora que ya tenemos todos los archivos y capetas necesarios creamos nuestro entorno virtual, para lo cual tecleamos:
pi@raspberrypi:~/miproyecto $ python3 -m venv miEntorno
La vista del directorio debe ser la siguiente:
Antes de instalar las aplicaciones necesarias en el entorno virtual tenemos que activarlo. Esto se consigue con el siguiente comando:
pi@raspberrypi:~/miproyecto $ source miEntorno/bin/activate
(miEntorno) pi@raspberrypi:~/miproyecto $
Lo que indica que ya estamos dentro del entorno virtual. El usuario que tengo para todo el proyecto es el que viene por defecto, el usuario "pi".
Paso 3: Configurar una aplicación de Flask.
Ahora que estamos dentro del entorno virtual es el momento de instalar Flask, todos los paquetes requeridos y Gunicorn y empezar a desarrollar la aplicación.
Nota: Independientemente de la versión de Python que uses, cuando uses el entorno virtual deberás usar el comando pip (no pip3)
Pero antes de empezar, tenemos que configurar nuestra aplicación de Flask para que funcione en un entorno de producción. Para ello lo primero de todo es instalar los paquetes requeridos por la aplicación. Dentro de nuestro entorno virtual escribimos:
~/miproyecto $ pip install -r requirements.txtLo que hará que se instalen todos los paquetes necesarios que hemos usado previamente para que el programa funcione que están en el archivo requirements.txt de nuestro directorio. (en el capitulo correspondiente los habíamos guardado usando $ pip freeze > requirements.txt)
IMPORTANTE: Ten en cuenta que ya estamos en un proceso de producción con lo que tendremos que desactivar el debug de flask ya que sino lo hiciéramos estaríamos permitiendo el ejecutar código arbitrariamente desde el navegador, lo cual estarás conmigo en que no es una buena práctica.
Tendremos que modificar el archivo config.py, en el cual están las configuraciones de nuestro programa. Entramos en el directorio "config" y allí editamos el archivo config.py del siguiente modo:
# depurador off para modo producción o eliminamos la línea ya que por defecto # el depurador esta desactivado. DEBUG = False
Instalamos Gunicorn (porque flask ya estaba instalado con los requirements)
Ahora, crearemos también un archivo que servirá como punto de entrada para la aplicación. Este archivo le va a indicar a nuestro servidor Gunicorn como interactuar con la aplicación.
Podemos llamar al archivo como queramos. Yo lo llamara wsgi.py.
(miEntorno) pi@raspberrypi:~/miproyecto $ sudo nano wsgi.py
En él, importamos la instancia de Flask desde nuestra aplicación y luego la ejecutaremos:
Guarda y cierra el archivo.
La estructura del directorio tiene que ser la siguiente:
miproyecto
|_ inicio.py
|_ wsgi.py
|_ miEntorno/
Paso 4: Configurar Gunicorn
Antes de continuar tenemos que comprobar que Gunicorn puede proveer correctamente la aplicación.
Podemos hacerlo pasándole el nombre de nuestro punto de entrada. Se hace con el nombre del archivo que hace de punto de entrada a la aplicación (wsgi menos la extensión py) más el nombre del elemento invocable dentro de la aplicación principal (app en nuestro caso).
También especificaremos la interfaz y el puerto al que se vinculará para que la aplicación se inicie de forma que este disponible públicamente.
Como al principio instalamos el firewall y ahora ya esta activado, tenemos que abrir el puerto 8000 para que funcione la aplicación ya que es el que voy a utilizar para comunicarme con gunicorn y con la pi desde mi ordenador.
Lo haremos con la instrucción:
(miEntorno) pi@raspberrypi:~/miproyecto $ sudo ufw allow 8000
Ahora activamos el servidor con:
(miEntorno) pi@raspberrypi:~/miproyecto $ gunicorn --bind 0.0.0.0:8000 wsgi:app
o también mejor con:
(miEntorno) pi@raspberrypi:~/miproyecto $ gunicorn -b 0.0.0.0:8000 -w 4 wsgi:app
Deberías ver algo como esto:
[2021-04-28 10:14:09 +0200] [5866] [INFO] Starting gunicorn 20.1.0
[2021-04-28 10:14:09 +0200] [5866] [INFO] Listening at: http://0.0.0.0:8000 (5866)
[2021-04-28 10:14:09 +0200] [5866] [INFO] Using worker: sync
[2021-04-28 10:14:09 +0200] [5869] [INFO] Booting worker with pid: 5869
[2021-04-28 10:14:09 +0200] [5870] [INFO] Booting worker with pid: 5870
[2021-04-28 10:14:09 +0200] [5871] [INFO] Booting worker with pid: 5871
[2021-04-28 10:14:09 +0200] [5872] [INFO] Booting worker with pid: 5872http://192.168.1.200:8000Deberías ver la página de entrada:
Cuando veas que funciona correctamente, pulsa Crtl-C en la ventana del terminal para cerrar la aplicación.
Expliquemos un poco el comando.
La Opción -b le dice a gunicorn donde escuchar las solicitudes. Le he dicho que escuche cualquier petición que se le haga en el puerto 8000. Por lo general, sería una buena idea ejecutar aplicaciones web de Python solo con acceso local y luego tener un servidor web muy rápido que esté optimizado para servir archivos estáticos aceptando todas las solicitudes de los clientes. Este servidor web si que servirá los archivos estáticos directamente aceptando todas las solicitudes de los clientes. En este ejemplo para ver que todo funciona correctamente la aplicación esta configurada con "0.0.0.0" aunque más adelante la dejaremos como localhost.
La opción -w configura cuantos usuarios de forma simultánea atenderá gunicorn. Tenerla configurada en 4 permite que la aplicación maneje hasta cuatro clientes simultáneamente, lo que para una aplicación web suele ser suficiente para manejar una cantidad decente de clientes, ya que no todos los que estén conectados (que pueden ser más) están pidiendo contenido constantemente. Dependiendo de la cantidad de ram de tu Raspberry Pi es posible que tengas que ajustar este número para que no te quedes sin memoria.
El argumento wsgi:app le dice a gunicorn de donde cargar la aplicación.
De ahora en adelante ya no necesitaremos más el entorno virtual con lo que podemos desactivarlo.
(miEntorno) pi@raspberrypi:~/miproyecto $ deactivate
En adelante todos los comandos de Python usarán de nuevo el entorno de Python del sistema.
Paso 5: Ejecutar automaticamente Gunicorn.
Si bien como has visto Gunicorn es muy fácil de configurar, ejecutarlo manualmente desde una línea de comandos no parece una buena solución para un servidor en producción. Lo que necesitamos es tener el servidor ejecutándose en segundo plano y que se ejecute cada vez que se reinicie el sistema.
A continuación voy a explicar dos opciones de hacerlo. Ambas son excluyentes es decir o utilizas una u la otra.
La primera me parece mucho más sencilla y funcional que la segunda porque nos aporta más ventajas. Pero por ver formas distintas de hacer lo mismo pondré las dos.
1) Opción.
Supervisor.
Lo último que hemos hecho es instalar Gunicorn y ver que funciona desde el terminal. Vamos ahora a hacer que todo lo anterior este monitorizado constantemente, porque si por alguna razón el servidor falla y se cierra, quiero asegúrame de que un nuevo servidor se ejecute en su lugar. Y también me quiero asegurar de que si la Raspberry Pi se reinicia, el servidor se ejecuta automáticamente al iniciarse, sin que tenga que iniciar sesión y teclear todos los comandos yo mismo.
Esto se consigue utilizando "Supervisor". Como dice en su documentación este programa es un sistema cliente servidor que permite monitorizar y controlar procesos en sistemas basados en Unix.
Para empezar instalémoslo.
$ sudo apt-get -y install supervisorEn el archivo de configuración que utiliza supervisor tenemos que indicarle que programas debe monitorizar y como reiniciarlos cuando sea necesario. Los archivos de configuración deben guardarse en /etc/supervisor/conf.d. Abajo te dejo el archivo de configuración que utilizaremos para nuestro programa, al que llamaré miproyecto.conf
/etc/supervisor/conf.d/miproyecto.conf: Configuración de Supervisor.
[program:miproyecto] command=/home/pi/miproyecto/miEntorno/bin/gunicorn -b localhost:8000 -w 4 directory=/home/pi/miproyecto user=pi autostart=true autorestart=true stopasgroup=true killasgroup=true
$ sudo supervisorctl reloadY ya está, ¡el servicio web que nos proporciona gunicorn debería estar funcionando y estar supervisado!
2) Opción.
Crea un archivo de unidad de servicio systemd
Un archivo en systemd te permitirá que al iniciar la Rapsberry Pi automáticamente se ejecute Gunicorn y sirva nuestra aplicación Flask siempre que se inicie el servidor. (pero OJO, no la monitoriza como en la opción anterior)
Empezaremos por crear un archivo con extensión .service dentro del directorio /etc/systemd/system. Para que todo sea acorde al proyecto se llamará miproyecto.service
$ sudo nano /etc/systemd/system/miproyecto.service
El archivo de forma genérica debe tener el siguiente contenido:
[Unit]# especifica metadatos y dependenciasDescription=Instancia de Gunicorn para mi proyecto
After=network.target# Le decimos al sistema de inicio que comience tras haberse conectado a una red.[Service]# Especificamos el usuario y el grupo con los cuales deseamos que se ejecute el proceso. # Le damos a nuestra cuenta habitual de usuario la propiedad del proceso, ya que posee todos los archivos relevantes.
User=tu_nombre_de_usuario# También otorgamos la propiedad del grupo al grupo www-data para que posteriormente Nginx (nuestro servidor) pueda comunicarse fácilmente con los procesos de Gunicorn.Group=www-data# A continuación especificamos los detalles del directorio de trabajo y estableceremos las variables de entorno en el PATH para que el sistema Init sepa que los ejecutables para el proceso, o sea nuestra aplicación, están ubicados dentro de nuestro entorno virtual.WorkingDirectory=/home/nombre_usuario/directorio_proyecto
Environment="PATH=/home/nombre_usuario/directorio_proyecto/entorno_virtual/bin"Luego le decimos cual es el comando para iniciar el servicioExecStart=/home/nombre_usuario/directorio_proyecto/entorno_virtual/bin/gunicorn --workers 4 --bind unix:miproyecto.sock -m 007 wsgi:app# Este comando hará lo siguiente:# Le decimos que inicie 4 procesos workers (esto se podría ajustar si es necesario)# Además especificamos una mascara 007 para que se cree el archivo de socket, se proporcione acceso al propietario y al mismo tiempo se restrinjan otros accesos.# Le especificamos el nombre del archivo del punto de acceso a WSGI junto con el elemento invocable de Python dentro de ese archivo (wsgi:app)# Si justo al final de toda la instrucción le añadimos el símbolo & ejecutaríamos el servidor en segundo plano.# Esto indicará a systemd a qué deberá vincular este servicio si lo habilitamos para que se cargue en el inicio. Queremos que este servicio se inicie cuando el sistema multiusuario normal esté en funcionamiento:[Install]
WantedBy=multi-user.target
En la práctica lo que debemos copiar a nuestro archivo miproyecto.service es:
[Unit] Description=Instancia de Gunicorn para mi proyecto After=network.target [Service] User=pi Group=www-data WorkingDirectory=/home/pi/miproyecto Environment="PATH=/home/pi/miproyecto/miEntorno/bin" ExecStart=/home/pi/miproyecto/miEntorno/bin/gunicorn --workers 4 --bind unix:miproyecto.sock -m 007 wsgi:app [Install] WantedBy=multi-user.target
Guardamos y cerramos el archivo.
Con esto ya lo tenemos completo y podemos iniciar el servicio Gunicorn y activarlo para que se cargue al iniciar el sistema.
- sudo systemctl start miproyecto
- sudo systemctl enable miproyecto
Y si comprobamos su estado con el siguiente comando:
sudo systemctl status miproyecto
Deberías ver el siguiente resultado:
Control + C para finalizar el proceso.
Además un nuevo archivo llamado miproyecto.sock se habrá creado en el directorio de nuestro proyecto automáticamente.
La estructura del directorio quedaría como sigue:
miproyecto
|____ miproyecto.py
|____ wsgi.py
|____ miEntorno
|____ miproyecto.sock
En este punto si detectas algún error es mejor que intentes resolverlos antes de continuar con el resto del tutorial.
Paso 6: Instalar y configurar Nginx para solicitudes de proxy.
Ahora que ya tenemos Gunicorn funcionando tenemos que configurar e instalar Nginx para que trasmita las peticiones web al socket. Si has optado anteriormente por la opción 1 el servidor de mi proyecto que está utilizando gunicorn se esta ejecutando de forma privativa en el puerto 8000. Si por el contrario has utilizado la opción 2 estará utilizando miproyecto.sock.
Lo que necesitamos hacer ahora para conectar la Pi al mundo exterior es instalar Nginx, abrir los puertos del router en las direcciones 80 y 443, que son los puertos que vamos a abrir en el firewall para manejar el tráfico web de la aplicación.
Primeramente instalamos Nginx
pi@raspberrypi:~/miproyecto $ sudo apt-get install nginx
Antes de probar Nginx debemos saber que este programa, en relación con el cortafuegos, se registra a si mismo como un servicio con ufw en el momento de la instalación lo que permite el acceso al servicio.
Vemos como Nginx está en la lista de las aplicaciones con las que ufw sabe trabajar en conjunto.
Teclea:
pi@raspberrypi:~ $ sudo ufw app list
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSHComo puedes ver hay tres perfiles disponibles para Nginx.
Nginx Full - Este perfil abre el puerto 80 (tráfico web normal sin cifrar) y el puerto 443 (tráfico cifrado TLS/SSL)
Nginx HTTP - Este perfil solo abre el puerto 80 (el del trafico normal web sin cifrar)
Nginx HTTPS - Este perfil solo abre el puerto 443 (tráfico cifrado TLS/SSL)
Luego, permitimos el acceso total al servidor de Nginx:
- $ sudo ufw allow 'Nginx Full' o también (que es lo que he usado yo) podemos abrir los puertos directamente con estas 2 instrucciones en vez de la anterior : $ sudo ufw allow http $ sudo ufw allow 443/tcp
/home/pi/miproyecto
$ mkdir certs $ openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \ -keyout certs/key.pem -out certs/cert.pem
$ sudo rm /etc/nginx/sites-enabled/defaultAhora tenemos que enseñarle a Nginx donde esta nuestra app y como tiene que servirla.
/etc/nginx/sites-available/miproyecto: Configuración de Nginx.
server {
# listen on port 80 (http)
listen 80;
server_name _;
location / {
# redirect any requests to the same URL but on https
return 301 https://$host$request_uri;
}
}
server {
# listen on port 443 (https)
listen 443 ssl;
server_name _;
# location of the self-signed SSL certificate
ssl_certificate /home/pi/miproyecto/certs/cert.pem;
ssl_certificate_key /home/pi/miproyecto/certs/key.pem;
# write access and error logs to /var/log
access_log /var/log/miproyecto_access.log;
error_log /var/log/miproyecto_error.log;
location / {
# forward application requests to the gunicorn server
proxy_pass http://127.0.0.1:8000;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /static {
# handle static files directly, without forwarding to the application
alias /home/pi/miproyecto/static;
expires 30d;
}
}IMPORTANTE: Este archivo de configuración esta preparado para usarse con la opción 1 del punto anterior, si has usado la opción 2 es lo mismo pero tienes que sustituir lo rojo, el proxy pass por este:
proxy_pass http://unix:/home/pi/miproyecto/miproyecto.sock;
Para habilitar la configuración del bloque server que acabamos de crear, tenemos que vincular el archivo al directorio sites-enabled:
pi@raspberrypi:~ $ sudo nginx -t
Si no hay ningún problema, reiniciamos el proceso Nginx para que tenga en cuenta la nueva configuración.
pi@raspberrypi:~/miproyecto $ sudo systemctl restart nginx
o
pi@raspberrypi:~/miproyecto $ sudo service nginx reload
Y finalmente ya deberíamos tener corriendo la aplicación. En tu navegador web puedes teclear la dirección IP de su servidor, (192.168.1.200 es la dirección de red de mi Pi) y se conectará al servidor. Como estamos utilizando un certificado autorfirmado verás una advertencia del navegador web
que deberás descartar para finalmente ver el resultado de todo el trabajo:
Nota: si usamos la opcion 1, ajustamos el firewall de nuevo. Ya no necesitamos el acceso a través del puerto 8000, por lo que podemos eliminar esta regla.
- sudo ufw delete allow 8000
- Apertura de Puertos.
Para que todo pueda funcionar correctamente necesitamos abrir el puerto 80 y el 433 en nuestro router. ¿Por que? Pues porque cuando tecleas el nombre de dominio en un navegador (pej miproyecto.hopeto.org) NO-IP redirige la petición a nuestra IP-publica. Pero claro, el router como debe de ser, no deja entrar a cualquiera a nuestro sistema. Por ello tenemos que decirle que las peticiones web que reciba, las derive a la dirección ip de la Pi en nuestra red interna (en el ejemplo 192.1.1.200) y a través del puerto 80 o el 443, ya lo veremos.
Cada router es un mundo, así que tendrás que ver como se hace en el tuyo. En el mío entras en la dirección del router, tecleas la contraseña de acceso y entras en una sección que pone "puertos". Allí creas una nueva regla, abriendo tanto para el puerto 80, como el 443 ya que posteriormente lo necesitaremos para proteger nuestra aplicación usando HTTPS.
Probamos nuevamente que todo funciona correctamente accediendo al nombre del dominio que escogiste en NO-IP (En mi caso miproyecto.hopeto.org) desde un equipo que no este conectado a la red local (por ejemplo desde el móvil sin que este conectado a la red local claro) y que apunta a nuestro servidor, que es la Rapsberry, desde nuestro navegador.
Paso 7: Proteger la aplicación.
server {
# listen on port 80 (http)
listen 80;
server_name miproyecto.hopeto.org;
location / {
# redirect any requests to the same URL but on https
return 301 https://$host$request_uri;
}
}
server {
# listen on port 443 (https)
listen 443 ssl;
server_name miproyecto.hopeto.org;
# location of the self-signed SSL certificate
ssl_certificate /home/pi/miproyecto/certs/cert.pem;
ssl_certificate_key /home/pi/miproyecto/certs/key.pem;
# write access and error logs to /var/log
access_log /var/log/miproyecto_access.log;
error_log /var/log/miproyecto_error.log;
location / {
# forward application requests to the gunicorn server
proxy_pass http://127.0.0.1:8000;
# o proxy_pass http://unix:/home/pi/miproyecto/miproyecto.sock;
# si usas la opcion 2
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /static {
# handle static files directly, without forwarding to the application
alias /home/pi/miproyecto/static;
expires 30d;
}
}Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): # location of the self-signed SSL certificate
ssl_certificate /home/pi/miproyecto/certs/cert.pem;
ssl_certificate_key /home/pi/miproyecto/certs/key.pem;/etc/nginx/sites-available/miproyecto: Nginx configuracion de claves let´s encrypt.
...
# location of the self-signed SSL certificate
ssl_certificate /etc/letsencrypt/live/miproyecto.hopto.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/miproyecto.hopto.org/privkey.pem; # managed by Certbot
...sudo certbot renew
$ crontab -e 15 3 * * * /usr/bin/certbot renew --renew-hook "service nginx reload"
ssl_protocols TLSv1.2 TLSv1.3;
Tambien puedes comprobar y obtener más recomendaciones de seguridad de tu servidor en la página de mozilla observatory.
cd /etc/ssl/certs sudo openssl dhparam -out dhparam.pem 4096
ssl_dhparam /etc/ssl/certs/dhparam.pem;
/etc/nginx/sites-available/miproyecto: archivo de configuración de Nginx.
server {
listen 443 ssl;
server_name miproyecto.hopeto.org;
....
ssl_dhparam /etc/ssl/certs/dhparam.pem;
...
/etc/nginx/sites-available/miproyecto: archivo de configuración de Nginx.
server {
listen 443 ssl;
server_name miproyecto.hopeto.org;
....
# intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
No hay comentarios:
Publicar un comentario