[[start|Nivel superior]]

|[[Flask app 3|Parte 3]]|[[Flask app 5|Parte 5]]|

====== Flask - 4 - Mi entorno ======

Instalación nueva aplicación flask en mi entorno

===== Introduction =====

Tutorial de Desarrollo de una Aplicación con Flask y Gestión con systemd

Referencias: [[https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world|Flask mega tutorial]]

Flask + Gunicorn + **Reverse proxy** + nginx


===== Previo =====

Procedimiento Detallado para la Instalación y Configuración en Producción usando
el software mostrado en el título.

Se asume que la máquina ''gimli'' hace de reverse proxy para ''boromir'' que es la
máquina de producción donde instalaremos la aplicación.

Se asume que la máquina ''arwen'' es la de desarrollo.

Se asume que el dominio a servir es ''example.com''.


===== Configuración del DNS =====

Modificar la IP asociada al nombre de dominio que hemos comprado para que apunte
al la dirección IP externa de nuestra máquina reverse proxy, en este caso es
''gimli'', con la IP ''143.47.54.66''.

Esto se debe hacer con el usuario y password que nos haya proporcionado nuestro
proveedor de dominio.


===== Configurar sitio simple en gimli por http =====

==== Index.html ====

Crear el fichero ''/var/www/example/index.html'' a partir del existente en
''Dropbox/Archive/Software/index-en-construccion.html''.


==== Configuración ====

Se crea el nuevo fichero de configuración de nginx en el directorio
''/etc/nginx/sites-available/example'', similar al que sigue, con el nombre del
dominio a atender.

<code ini>
server {
    listen 80;                               # Puerto de escucha
    server_name example.com www.example.com; # Nombre del dominio
    root /var/www/example;               # Directorio raíz del sitio web
    index index.html index.htm;              # Archivos de índice
    location / {
        try_files $uri $uri/ =404;           # Sirve archivos estáticos y
    }                                        # muestra un error 404 si no están
}
</code>

Nos situamos en el directorio ''/etc/nginx/sites-enabled'' y creamos el enlace
para activar el sitio:

<code bash>
ln -s ../sites-available/example .
</code>

Confirmamos que la configuración es correcta. Damos ''reload'' al servidor.

<code bash>
nginx -t
systemctl reload nginx
</code>

==== Test desde internet ====

En ''gimli'' usamos el siguiente comando para supervisar la prueba de acceso.

<code bash>
tail -f /var/log/nginx/*.log
</code>

Entrar con el navegador al dominio ''http://example.com''. También al subdominio
''http://www.example.com''. Si muestra la página de **en construcción**, pues
estupendo.

===== Configurar https =====

==== Obtener certificado de letsencrypt ====

Para usar ''https'' debemos tener un certificado y configurar el servidor nginx
para usarlo.

Esto se hace en un sólo paso con la utilidad de ''letsencrypt''.

<code bash>
certbot -d example.com --nginx
</code>

Con esto se habrá modificado el de configuración de nginx para redirigir el
tráfico por el puerto 80 al puerto 443. ''http'' a ''https''.

Hay que confirmar que el certificado se renueva automráZZZZticamente.

==== Test desde internet ====

Ahora podemos probar con el navegador nuevamente las direcciones del sitio de
ejemplo por ambos protocolos.

===== Configurar sitio simple en boromir por http =====

==== Index.html ====

Crear el directorio ''/var/www/example''. Poner permiso de ''rwx'' al grupo, para
que el usuario ''ubuntu'' pueda actualizar.

Crear el fichero ''/var/www/example/index.html'' a partir del existente en
''Dropbox/Archive/Software/index-en-construccion.html''.

Poner alguna nota diferenciadora para que se distinga del de ''gimli''.


==== Configuración ====

Se crea el nuevo fichero de configuración de nginx en el directorio
''/etc/nginx/sites-available/example'', similar al que sigue, con el nombre del
dominio a atender.

<code ini>
server {
    listen 80;                               # Puerto de escucha
    server_name example.com www.example.com; # Nombre del dominio
    root /var/www/example;               # Directorio raíz del sitio web
    index index.html index.htm;              # Archivos de índice
    location / {
        try_files $uri $uri/ =404;           # Sirve archivos estáticos y
    }                                        # muestra un error 404 si no están
}
</code>

Nos situamos en el directorio ''/etc/nginx/sites-enabled'' y creamos el enlace
para activar el sitio:

<code bash>
ln -s ../sites-available/example .
</code>

Confirmamos que la configuración es correcta. Damos ''reload'' al servidor.

<code bash>
nginx -t
systemctl reload nginx
</code>

==== Modificar /etc/hosts en gimli ====

Incluir en la configuración la dirección **interna** de ''boromir'' para que
''gimli'' pueda redirigirle el tráfico. Es también necesario porque ''boromir''
atiende muchas peticiones de muchos dominios distintos, así que las peticiones
no pueden venir por ip, sino por dominio.

<code ini>
10.0.0.210  example.com
</code>

==== Test desde la red local ====

En ''gimli'' usamos el siguiente comando para supervisar la prueba de acceso.

<code bash>
tail -f /var/log/nginx/*.log
</code>

Desde ''gimli'' (en otra terminal) usar wget para descargar la página ''index.html''
de nuestro nuevo sitio web desde ''boromir''.

<code bash>
wget http://example.com
wget http://www.example.com
</code>
===== Redirigir trafico que llega por https a gimli hacia boromir por http =====

==== Modificar la configuración de nginx ====

Básicamente consiste en sustituir la sección ''location /'' por las sentencias
que siguen, para reenviar todo el tráfico que llegue por el dominio en cuestión
hacia la máquina ''boromir'' (en conjunción con el fichero ''/etc/hosts'').

<code ini>
location / {
    limit_except GET HEAD POST {deny all;}
    expires -1;
    proxy_set_header X-Real-IP  $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $host;
    proxy_pass http://example.com;
}
</code>

Confirmamos que la configuración es correcta. Damos ''reload'' al servidor.

<code bash>
nginx -t
systemctl reload nginx
</code>

==== Test desde internet. ====

Volvemos al navegador y accedemos a ''http://example.com'' o ''https://example.com''
y debería salirnos la página de indice que hemos preparado en ''boromir''.
===== Configurar aplicación flask de test en boromir =====

==== Crear aplicación de test ====

Crear el fichero ''app.py'' en el directorio ''/var/www/example/'' de ''boromir'', con
el siguiente contenido.

<code python>
====== app.py ======
from flask import Flask
app = Flask(__name__)
@app.route('/')
def index():
    return 'Hello, World! This is a test Flask application.'
if __name__ == '__main__':
    app.run()
</code>

Crear el fichero ''wsgi.py'' en el mismo directorio, con este contenido:

<code python>
====== wsgi.py ======
from app import app as application
application.config['ENV'] = 'production'
application.config['DEBUG'] = False
</code>

==== Preparar entorno ====

Instalar ''venv'' y crear el directorio ''venv'' donde se instalarán las librerías y
los binarios del entorno.

<code bash>
apt-get install python3-venv
cd /var/www/example
python3 -m venv venv
</code>

==== Instalar las librerías python básicas ====

<code bash>
source venv/bin/activate
pip install Flask gunicorn
</code>

==== Prueba simple ====

Vamos a comprobar que funciona la aplicación con ''gunicorn'', antes del siguiente
paso.

<code bash>
source venv/bin/activate
gunicorn -w 4 -b 127.0.0.1:8000 app:app
gunicorn -w 4 -b 127.0.0.1:8000 wsgi:application
</code>

==== Ajuste ====

Pasa todo el directorio al usuario ''www-data''. Además hay que asegurarse que el
directorio ''/var/www/example'' tiene permisos de escritura y ejecución para el
grupo.

<code bash>
chown www-data:www-data -R * 
chmod g+rwx /var/www/example
</code>

==== Crear el servicio para systemd usando Gunicorn ====


Editamos el fichero ''/etc/systemd/system/example.service'' y le añadimos el
siguiente contenido, cambiando ''example'' por el nombre de nuestro dominio.

<code conf>
[Unit]
====== specifies metadata and dependencies ======
Description=Gunicorn instance to serve example
After=network.target
====== tells the init system to only start this after the networking target has been ======
====== reached. We will give our regular user account ownership of the process since ======
====== it owns all of the relevant files ======
[Service]
====== Service specify the user and group under which our process will run. ======
User=www-data
====== give group ownership to the www-data group so that Nginx can communicate ======
====== easily with the Gunicorn processes. ======
Group=www-data
====== We'll then map out the working directory and set the PATH environmental ======
====== variable so that the init system knows where our the executables for the ======
====== process are located (within our virtual environment). ======
WorkingDirectory=/var/www/example/
Environment="PATH=/var/www/example/venv/bin"
====== Environment="CONFIG=config-example" ======
====== We'll then specify the commanded to start the service ======
ExecStart=/var/www/example/venv/bin/gunicorn --workers 3 --bind unix:/var/www/example/example.sock -m 007 wsgi:application
====== This will tell systemd what to link this service to if we enable it to start ======
====== at boot. We want this service to start when the regular multi-user system is ======
====== up and running: ======
[Install]
WantedBy=multi-user.target
</code>

==== Habilitar y iniciar el servicio ====

<code bash>
sudo systemctl enable example.service
sudo systemctl start example.service
</code>

===== Instalar app buena =====

Usar el script ''deploy'' de las otras aplicaciones. También se encuentra en
''Dropbox/Attic/Software''. Adaptarlo a las necesidades del proyecto en curso.

Después de ejecutar el ''deploy'' se debe poder probar con el navegador.

===== Crear test de aplicación (se ejecuta en gandalf) =====

Usar uno de los scripts ''check//ewe'', ''check//arocha'' etc. Crear uno nuevo y
adaptarlo al proyecto en curso. Debe configurarse en el ''crontab'' para ejecutar
cada hora en modo normal y una vez al día en modo Diario.

El modo normal solo envía mensaje a ''ntfy'' si hay errores. El modo Diario envía
mensaje siempre, para que al menos una vez al día llegue un mensaje de que el
sistema está funcionando.

===== Revisión scripts de backup =====

Revisar el script ''backup-data'' del directorio ''/home/ubuntu/copias'', para
que se incluya la información del proyecto en curso.