Sito web Classifiche Fantacitorio nato dai Google Sheet
gestiti da @rosyilcapo per gestire i dati in un database SQL ed visualizzare le classifiche (generale, per lega, politici, punteggi).
In particolare la base dati è stata creata partendo dal Google Sheet
* Fantacitorio 2022 - classifica generale PROVVISORIA.
Fantacitorio è un fanta game ideato dalla trasmissione Propaganda Live di La7 nel 2021.
Info disponibili:
Il sito web realizzato dai sorgenti di questo progetto GitHub è raggiungibile al seguente indirizzo: https://classifiche-fantacitorio.adessospiana.it
Il progetto è composto da:
-
un sito pubblico dove sono visualizzate la
classifica generale
, leclassifiche per lega
, laclassifica politico
ed ipunteggi
.Inoltre, cliccando su una squadra, è mostrato il suo
dettaglio
costituito dallaformazione
, ifanfani
utilizzati, il posizionamento in classifica generale e nelle leghe nonchè ipunteggi
acquisiti dai politici in formazione. -
un'area riservata di
amministrazione
protetta da autenticazione, per gestire, importare, esportare i contenuti:cariche
politici
squadre
leghe
associazioni lega-squadra
punteggi
puntate
E' disponibile una demo dell'area riservata nell'ambiente di stage https://stage-classifiche-fantacitorio.adessospiana.it/admin autenticandosi con le credenziali:
- login:
fantautente
- password:
fantacitorio
In questa sezione viene descritto nel dettaglio lo sviluppo, il popolamento del database e il deploy sul cloud AWS. Prerequisito per approcciare questa sezione è di avere una conoscenza almeno base dei seguenti strumenti:
- il linguaggio di programmazione
Python
- il framework
Django
- il framework
Zappa
- il database
CockroachDb
(PostgreSql) esqlite
- il cloud
AWS
(Amazon Web Services
) e nello specifico:AWS S3
: l'object storage di AWSAWS Api Gateway
AWS Lambda
l'infrastrutturaServerless/FaaS
(Function as a Service
)AWS RDS
il servizio cloud dei DBMSAWS CloudFront
laCDN
(Content Delivery Network
) di AWSAWS Route53
il servizio di gestioneDNS
dei domini in AWSAWS Certificate
il servizio per creare certificati SSL validi
Il progetto è basato sul framework Django
caricato sul Cloud AWS tramite Zappa
. La lista dei package python
utilizzati dal progetto sono:
-
django: storico framework CMS in
python
che, tra i tanti, ha dato i natali adInstagram
-
zappa: tool per il rilascio
serverless
su cloud AWS -
django_s3_storage: modulo django per la gestione dalle risorse statiche su
AWS S3
-
django-dynamodb-cache: bachend cache django per
AWS DynamoDB
-
django-tables2: modulo django che implementa una datagrid avanzata
-
django-filter: modulo django che implementa filtri avanzati
-
django-bootstrap5: modulo django per utilizzare
bootstrap 3
nei template -
django-import-export: modulo Django per importazione ed espostazione dei dati
-
django-admin-autocomplete-filter: modulo Django che implementa i filtri autocomplete nell'admin
-
django-debug-toolbar: modulo Django mostra metriche delle query, template utilizzati, messaggi di log, variabili di sistema, insomma tutto ciò che serve per fare debugging e tuning del sistema
Django supporta diversi backend:
-
supporto ufficiale per
MariaDB
,MySQL
,Oracle
ePostgreSQL
(di conseguenza supportaAWS RDS PostgreSQL
eAWS Aurora
) -
backend di terze parti
CockroachDB
,Firebird
,Google Cloud Spanner
,Microsoft SQL Server
,Snowflake
,TiDB
,YugabyteDB
Per i dettaglio fare rifermimento alla documentaziond del Backend Django
Questo progetto utilizza come database di principale per la gestione dei contenuti dalla sezione riservata CockroachDB un servizio serverless basato su PostgreSQL
, mentre per le classifiche e la parte pubblicà è utilizzato il backend Sqlite su AWS S3
. Di seguito i moduli Django:
-
django-cockroachdb: backend database django per
CockroachDB
-
psycopg2: sorgenti driver di
PostgreSQL
perpython
-
psycopg2-binary: binary del driver di
PostgreSQL
perpython
-
django-s3-sqlite: backend database django per
sqlite
suAWS S3
La struttura del progetto è costituita da un Django project
a due Django app
:
fc_project
: il project che contiene isettings
eurl resolver
fc_gestione_app
: app dedicata alla gestione delle squadre, le leghe i politici, le puntate e i punteggi tramite l'admin
di Djangofc_classifiche_app
: app per la generazione/visualizzazione delle classifiche
Linux
oWSL
suWindows
python3.9
(è attualmente la versione massima supportata dallaAWS Lambda
in python. Attenzionepython3.10
attualmente non è supportato daAWS Lambda
)
L'ambiente in locale è necessario sia per lo sviluppo dell'applicazione che per il deploy su AWS
. Di seguito le istruzioni per configurare l'ambiente locale:
-
creazione del virtualenv che ospiterà Django in locale
sudo apt install virtualenv virtualenv venv --python python3.9 --pip 23.1.2
-
rinominare
zappa_settings.json.template
inzappa_settings.json
. Nella sezionelocal
contiene già le impostazioni per utilizzare il database localesqlite3
mentre bisogna creare un database di stage su su Cockroach Labs e impostare le credenziali -
Attivazione del virtualenv creato
source venv/bin/activate
-
Installazione di Django e delle dipendenze contenute in requirements.txt
pip install -r requirements.txt
-
generazione delle tabelle di sistema della applicazione fc_gestione_app. Si utilizza il
database routing
per gestire il database di principale e quello delle classifiche. Per il database classifiche si esegue una migrazione fake in quanto la tabelle sono generate tramite il comando di refresh classifichepython manage.py migrate fc_gestione_app --database default python manage.py migrate fc_classifiche_app --fake
-
creazione super utente da utilizzare per autenticarsi al sito (es:
admin
)python manage.py createsuperuser --username <SUPER UTENTE>
-
caricamento dei dati (
fixture
) aggiornati all'ultima puntatapython manage.py loaddata fc_gestione_app
-
generazione delle viste e refresh dei dati di fc_classifiche_app
python manage.py create_classifiche_views python manage.py sqlite_refresh_classifiche
-
esecuzione in locale di Django
python manage.py runserver
-
accedere a http://localhost:8000, saranno mostrate le classifiche, mentre par accedere all'
admin
cliccare sulla rotellina in alto a destra, quindi autenticarsi tramite il super user creato
Per generare una fixture
del database e per migrarlo presso un nuovo ambiente si utilizza il comando Django dumpdata
python manage.py dumpdata fc_gestione_app -o fc_gestione_app/fixtures/fc_gestione_app.json.bz2
Per caricare la fixture
utilizzare il comando load data (in automatico cerca le fixture dentro l'app0)
python manage.py loaddata fc_gestione_app
Le fixture
sono agnostiche rispetto al database utilizzato, quindi possono essere utilizzate per migrare i data verso qualsiasi backend supportato da Django.
Zappa
è lo strumento che permette di deployare Django
, gestendo ambienti separati, ad esempip stage
e production
.
Nel dettaglio l'architettura del sito sul Cloud:
-
Django distribuito sul cloud
AWS
in modalità -
CDN:
AWS Cloudfront
è il punto di ingresso dalla applicazione. Si occupa della distribuzione dei contenuti effettuando il routing delle richieste verso la parte staticaS3
oppureDjango
servito dalleAWS Api Gateway
-
DNS: gestito da
AWS Route53
e certificati di dominio HTTPS generati e gestiti daAWS Certificate
e configurati sia sulAWS Cloudfront
cheAWS Api Gateway
-
Django: servito in modalità serverless da
Zappa
che effettua il deploy di Django sul cloudAWS
mediante serviziserverless
tramiteAWS Lambda
eAWS Api Gateway
-
Database: l'architettura sia per l'ambiente di
stage
cheproduction
ricalca quella dell'ambiente di sviluppolocal
-
database
default
: servito esternamente daCockroachDB
-
database
classifiche
: databasesqlite
caricato in unAWS S3 bucket
e acceduto dallaAWS Lambda
(dove è installatoDjango
) per le letture e le scritture, tramite il pacchettodjango-s3-sqlite
-
-
Cache: la Cache
Django
attiva su backedAWS DynamoDB
sia per lesession
che lapagine
tramite il pacchettodjango-dynamodb-cache
Di seguito lo schema architturale su AWS
La configurazione di Zappa
per il rilascio su AWS è nella sezione stage
di zappa_settings.json
Come pre-requisito è necessario un account AWS personale con le chiavi configurate in locale per l'accesso all'infartruttura. Di seguito i comandi Zappa
per il rilascio dell'ambiente di stage:
-
deploy dell'ambiente (solo la prima volta)
zappa deploy stage
per aggiornare l'ambiente le volte successive
zappa update stage
Al termine dell'esecuzione di
deploy
eupdate
, se non vi sono errori, viene mostrato il URL del sito rilasciato all'interno della proprio cloud AWS. -
generazione delle tabelle di sistema della applicazione
fc_gestione_app
efc_classifiche_app
zappa manage stage migrate fc_gestione_app "--database default" zappa manage stage migrate fc_classifiche_app "--database db_classifiche --fake"
-
creazione dell'utente superuser di amministrazione
zappa invoke stage "from django.contrib.auth.models import User; User.objects. create_superuser('<SUPER USER>', '', '<PASSWORD>')" --raw
-
la prima volta: creazione della tabella di caching
AWS DynamoDB
zappa manage stage createcachetable
-
la prima volta: caricamento dei dati presenti nella fixture di fc_gestiona_app
zappa manage stage loaddata fc_gestione_app
-
creazione delle viste per popolare in database classifiche
zappa manage stage create_classifiche_views
-
refresh delle classifiche con la creazione e popolamento del database classifiche
zappa manage stage sqlite_refresh_classifiche
Al termine del deploy e update zappa
mostra l'endopoint esposto sulle AWS API Gateway
del nostro ambiente, che risulta già navigabile accedendo ad un URL tipo:
https://<STRINGA-RANDOM>.execute-api.<AWS Region>.amazonaws.com/stage
Se si ha a disposizione un dominio gestito su AWS Route53
, è possibile generare un certificato valido HTTPS sul nostro dominio. I certificati creati AWS Certificate
possono essere utilizzati nelle risorse AWS
sono gratis e AWS
si occupa di rinnorarli in automatico dopo la scadenza annuale.
Quindi dopo aver generato e validato il certificato HTTPS sul dominio, si copia il suo ARN
dentro zappa_setting.json
nel campo "certificate_arn"
e si valorizza il dominio nel campo domain
. Tramite il comando:
zappa certify stage
Questo comando di Zappa
si occupa di:
- creare un
Custom Domain
mappandolo allo stage delleAWS API Gateway
- associa il certificato HTTPS il cui
ARN
è configurato nei settings - creare le entry sul DNS del dominio
AWS Route53
che puntano alleAWS API Gateway
del nostro ambiente
Al termine dell'esecuzione il comando mostra l'URL in HTTP del nostro domino che punta all'ambiente deployato: https://miodominio.com
CloudFront
è la CDN (Content Delivery Network
) di AWS
per ottimizzare la distribuzione dei contenuti utilizzando i CloudFront Edge
ossia mirror dei contenuti distribuiti in modo capillare nel mondo minimizzando latenza e massimizzando la velocità di fornitura dei contenuti agli utenti finali.
CloudFront
inoltre gestisce anche come fornire i contenuti in base a dove sono localizzati nelle Origin
ossia le applicazioni o i contenuti esporti. Nel caso particolare di un progetto Django, a fronte di una richiesta di una pagine, CloudFront
interroga:
- le
AWS API Gateway
per i contenuti dinamici, ossia le pagine generate da Django - l'
AWS S3 Bucket
per i contenuti statici di Django (immagini, CSS, JavaScript)
La configurazione di CloudFront
per le applicazioni Django
deployate con zappa
è particolare e ha richiesto diversi tentativi prima di arrivare ad una soluzione soddisfacente:
-
definito il dominio
fc-project-api-stage.adessospiana.it
per leAWS API Gateway
che ospitano laAWS Lambda
diDjango
, configurandozappa_setting.json
ed eseguentozappa certify stage
-
creato la distribution
CloudFront
con le due origin:- l'origin Custon
fc-project-api-stage.adessospiana.it
- l'origin S3
fc-zappa-static
- l'origin Custon
-
configurati i
beaviour
ossia le regole di distribuzione come segue:- tutte le richieste
/static/*
sono indirizzate all'originfc-zappa-static
- tutto il resto
Default (*)
viene indirizzato alla origin custonfc-project-api-stage.adessospiana.it
- tutte le richieste
-
Per il
beaviour
Default (*)
la cache è disabilitata e vengono trasmessi tutti liHTTP Header
eccetto l'HeaderHost
. Di seguito la configurazione delbeaviour
Dato che nell'ambiente AWS settings.DEBUG
è False
, gli amministratori ricevono gli errori server (errori 500
) via email tramite la configurazione del server SMTP
e la configurazione di settings.ADMINS
, array di tuple (nome,email)
Mentre errori 404
sono notificate agli indirizzi specificati in settings.MANAGERS
. Prima è necessario aggiungere ai settings.MIDDLEWARE
django.middleware.common.BrokenLinkEmailsMiddleware
. Da notare che vengono notificati solo gli errori 404 con Refers
valorizzato con un url del sito, quindi sono notificate le pagine non trovate clicando i link presenti nel sito. Se generiamo l'errore modificando a mano l'url del browser, otterremo un errore 404
ma non verrà inviata ai managers alcuna mail.
Sempre nell'ambiente AWS gli errori 400 403 404 e 500 sono indirizzate su pagine specifiche personalizzata, rispettivamente:
templates/400.html
richiesta non validatemplates/403.html
richiesta non autorizzatatemplates/404.html
pagina non trovatatemplates/500.html
errore server
L'ambiente di produzione ribattezzato zappa_settings.json
ribatezzato production
ha la stessa architettura di stage
solo una diversa instanza dei backend, CloudFront, Zappa, certificati e nome a dominio.
Di seguito le sequenza del comandi da eseguire dopo aver configurato la sezione production
del file zappa_settings.json
:
zappa deploy production
zappa certify production
zappa manage production "migrate fc_classifiche_app --fake"
zappa manage production migrate
zappa manage production createcachetable
zappa invoke production "from django.contrib.auth.models import User; User.objects.create_superuser('<SUPER USER>', '', '<PASSWORD>')" --raw
zappa manage production loaddata fc_gestione_app
zappa manage production create_classifiche_views
zappa manage production refresh_classifiche
In questa sezione è mostrata la genesi del progetto descrivendo i comandi utilizzati per crearlo e il modo in cui è stata disegnata la base dati.
Di seguito i comandi iniziali con cui sono stati creati il progetto e le due app django:
django-admin startproject fc_project .
django-admin startapp fc_gestione_app
django-admin startapp fc_classifiche_app
Per comodità il database principale fc_gestione_app
è stato creato graficamente con PgAdmin ERD
poi generato nel postgres locale.
Di seguito gli schema ER generati con python manage.py graph_models
, comando di django-extension
:
-
fc_gestione_app
: generato conpython manage.py graph_models fc_gestione_app -o images/fc_gestione_app__model.png
-
fc_classifiche_app
generato conpython manage.py graph_models fc_classifiche_app -o images/fc_classifiche_app__model.png
Quindi i models di Django sono stati creati tramite il comando inspectdb
che genera i models partendo da un database esistente
python manage.py inspectdb > fc_gestione_app/models.py
I models Django di fc_classifiche_app
sono stati creati manualmente sulle tre viste materializzate per PostgreSQL
e tre tabelle per Sqlite
La configurazione inziale di Zappa
è stata generata eseguendo il comando zappa init
eseguito dentro il virtualenv del progetto. In questo modo riconosce l'ambiente Django installato nel virtualenv e crea il file zappa_setting.json
tramite un wizard.
Puoi contribuire:
-
aprendo una segnalazione per
- segnalare malfunzionamenti
- suggerire nuove funzionalità
-
eseguendo un
fork
del progetto e contribuendo allo sviluppo.