In questa master class Alberto ci racconterà come implementare un API Manager cloud native utilizzando le funzionalità DevOps secondo i principi della Continuous Integration e Delivery. Scrivici a wso2.sales@profesia.it per fissare una sessione con un esperto e sperimentare in brevissimo tempo le potenzialità dell'integrazione agile con wso2
#6 WSO2 Masterclass Il DevOps applicato all'architettura cloud native di WSO2 API Manager
2. Iscriviti al gruppo Linkedin WSO2 Italia per entrare nella community italiana,
conoscere la tecnologia WSO2 e condividere strategie di integrazione e use cases
3. Sommario
- Architettura centralizzata tradizionale e suoi limiti
- Architettura decentralizzata e suoi vantaggi chiave
- Come gestire il routing del traffico del gateway Ingress
gateway
- Raggruppamento di API per la creazione di flussi CI/CD
- Ridimensionamento e gestione delle API
6. Pro e Contro
Architettura Decentralizzata
Architettura Centralizzata
PRO CONTRO
- server difficilmente scalabile
- configurazioni scalabilità su tutte api
- punti di accesso
da controllare
failover su tutte api
PRO CONTRO *
altamente scalabile + server
scalabilità puntuale per
api
+ configurazioni
failover assente (pod
dinamici K8s)
+ punti di accesso
da controllare
*superabili con tool automatici
esempio Ansible
7. Cosa vogliono le aziende
Le aziende al giorno d’oggi tendono ad evolversi secondo le esigenze degli
utenti, di conseguenza prediligono un’architettura più flessibile, dinamica e
che risponda velocemente al cambio dei requisiti.
Per questo motivo un’architettura centralizzata NON sposa la filosofia
desiderata.
8. Pro e Contro
Architettura Decentralizzata
Architettura Centralizzata
PRO CONTRO
- server difficilmente scalabile
- configurazioni scalabilità su tutte api
- punti di accesso
da controllare
failover su tutte api
PRO CONTRO *
altamente scalabile + server
scalabilità puntuale per
api
+ configurazioni
failover assente (pod
dinamici K8s)
+ punti di accesso
da controllare
*superabili con tool automatici
esempio Ansible
9. Cosa vogliono gli utenti
Gli Utenti sono gli utilizzatori finali delle API, richiedono quindi caratteristiche
a loro utili:
● Utilizzo diverso delle risorse delle API
● Diversi requisiti di applicazione della sicurezza delle API
● Necessità di routing dinamico dei backend API
● Mediazione e trasformazione del messaggio
● Modellazione API basata su diversi consumatori come utenti mobili,
utenti desktop, ecc.
● Requisiti per la memorizzazione nella cache delle risposte API
● API private e API pubbliche
● Gateway API per reparto/unità
14. Ingress Gateway
G
a
t
e
w
a
y
L’Ingress Gateway è il punto di accesso ai client.
Deve quindi instradare le chiamate api verso i Microgateway corretti,
secondo le configurazioni impostate.
Software:
- Nginx
- ALB in Amazon
15. Ingress Gateway - Food
G
a
t
e
w
a
y
● Microgateway Food
○ /food/menu
○ /food/prenotazione
○ /food/pagamento
○ /food/annullaPrenotazione
○ /food/dovesiamo
16. Ingress Gateway - Shopping
G
a
t
e
w
a
y
● Microgateway Shopping
○ /shopping/offerte
○ /shopping/confronta
○ /shopping/carrello
○ /shopping/compra
○ /shopping/paga
○ /shopping/restituisci
17. Ingress Gateway - Social
G
a
t
e
w
a
y
● Microgateway Social
○ /social/post
○ /social/tweet
○ /social/retweet
○ /social/reply
○ /social/like
○ /social/chat
18. Ingress Gateway - Video Music
G
a
t
e
w
a
y
● Microgateway Video and Music
○ /video/play
○ /video/save
○ /video/search
○ /music/play
○ /music/download
○ /music/myplaylist
19. Raggruppamento API
G
a
t
e
w
a
y
Per un buon funzionamento ed ottimizzazione delle risorse è
opportuno scegliere dei criteri di suddivisione dei Gateway e API:
● Funzionalità (il Microgateway food contiene solo api food)
● Aree geografiche (Gateway Italia Nord, Italia Centro, Italia
Sud)
20. Fasi API
Le 3 principali fasi di
un’ API sono:
● Creazione
● Approvazione
● Deploy
21. 1. Creazione API
- L’API viene creata con l’apposita
interfaccia utente.
- Tramite il tool “apictl” si esporta l’API
“apictl export-api -n FoodApi -v 1.0.0 -e development”
- Si committa su repository
“git commit -a -m "Adding FoodAPI”
“git push origin store-apis”
- Si richiede approvazione per pubblicare
API
22. 2. Approvazione API
- L’API viene valutata secondo il gruppo di
appartenenza
-L’API viene pubblicata e resa disponibile
nel Devportal
23. 3. Deploy con Kubernetes
Fasi Principali API - Deploy con operatori API per Kubernetes
L'operatore API per Kubernetes rende le API consumabili nell'ecosistema Kubernetes.
Si può usare questo operatore per distribuire API per singoli microservizi o comporre
diversi microservizi in singole API.
In questo modo, fornendo una definizione swagger delle API, gli utenti saranno in grado
di esporre il proprio microservizio come API gestita nell'ambiente Kubernetes senza alcun
lavoro aggiuntivo.
Quindi l'operatore API distribuisce un’ API sul Microgateway tramite la definizione
swagger data. Distribuisce inoltre le risorse Ingress per il routing del traffico e la policy di
scalabilità automatica del pod orizzontale per la scalabilità automatica del Microgateway
API in base all'utilizzo della CPU.
24. 3. Deploy API Github/Jenkins
La fase di distribuzione è completamente automatizzata ed è progettata integrando
Github con Jenkins. Possiamo creare un webhook su Github che esegue una pipeline in
Jenkins. Una volta che API Product Manager approva l’API, viene attivata la pipeline
Jenkins.
L'utilizzo della pipeline Jenkins segue il percorso seguente:
● Crea una versione di Github nel rispettivo ramo (es: food-apis-v1.0.0). Questo viene
fatto per tenere traccia delle modifiche che si verificano nella pipeline.
● Il processo Jenkins si attiva per il rilascio di food-apis-v1.0.0
● Utilizzando “apictl” (visto prima), si aggiunge un'API in Kubernetes utilizzando
l'operatore API per Kubernetes. Se l'API esiste in Kubernetes, aggiorna l'API.
● L'operatore API per K8s distribuisce il Microgateway API e le risorse Ingress pertinenti
per l'instradamento del traffico. Si utilizzano 3 deploy pattern.
29. Scaling e gestione delle API
Un'architettura di gestione delle API decentralizzata ha tre opzioni di distribuzione
principali per le API:
● Modalità Private Jet
● Modalità Sidecar
● Modalità Shared
30. 1. Private Jet
La modalità Private Jet ha un
Microgateway API dedicato per l'API e
i microservizi di backend dell'API
vengono eseguiti separatamente.
Il ridimensionamento avviene per un
pod in Kubernetes.
Quando si verifica la scalabilità
automatica del pod, puoi
ridimensionare l'API e i microservizi di
backend separatamente in base al
carico.
31. 2. Sidecar
In modalità Sidecar, sia l'API
Microgateway che il contenitore di
microservizi risiedono in un singolo
pod in Kubernetes. Nei casi di volume
traffico maggiore per un particolare
microservizio di backend, è necessario
ridimensionare il gateway API e il
microservizio di backend per gestire il
carico crescente. La modalità sidecar
può essere utilizzata per soddisfare
tale requisito.
32. 3. Shared
Nella modalità Shared si possono
distribuire più API in un singolo
microgateway in modalità condivisa.
I microservizi di backend vengono
eseguiti separatamente.
Quando si esegue il
ridimensionamento per il pod, si
ridimensionano tutte le API che
vengono distribuite nell'API
Microgateway.
33. Scalabilità Food a fasce orarie
Food
Music
Social
Video
G
a
t
e
w
a
y
High Security
Medium Security
Low Security
Low Security
Video
Low Security
Mobile
Desktop
Shopping
High Security
Mobile
Shopping
High Security
Desktop
Mobile
Video
High Security
Tablet
All
All
G
w
V
i
d
e
o
Gw Shopping
Ore 5 - 24
34. Scalabilità Food a fasce orarie
Food
Medium Security
Ore punta: 7-9 + 12-14 + 21-23
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
5
4
3
2
1
R
ic
hi
e
st
e
Ore
35. Scalabilità Food a fasce orarie
Food
Medium Security
Ore punta: 7-9 + 12-14 + 21-23
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
5
4
3
2
1
P
o
d
Ore
37. Scalabilità Video Zone Geografiche
.. .. .. .. .. D F I P E .. .. .. .. .. .. .. ..
Stati: Italia - Spagna
38. Scalabilità Video Zone Geografiche
.. .. .. .. .. D F I P E .. .. .. .. .. .. .. ..
Stati: Italia - Spagna
Fasce orarie : 21 - 23
39. Scalabilità Architettura Decentralizzata
Food
Music
Social
Video
G
a
t
e
w
a
y
High Security
Medium Security
Low Security
Low Security
Video
Low Security
Mobile
Desktop
Shopping
High Security
Mobile
Shopping
High Security
Desktop
Mobile
Video
High Security
Tablet
All
All
M
G
W
V
i
d
e
o
MGW Shopping
S
c
a
l
a
b
i
l
i
t
y
s
c
a
l
s
c
a
l
s
c
a
l
s
c
a
l
40. Sommario
Sono state illustrate la gestione centralizzata delle API e le sue limitazioni.
Un'architettura di gestione API decentralizzata risolve i limiti attuali nella gestione API
centralizzata.
Il routing del traffico in ingresso, il raggruppamento delle API e il ridimensionamento e la
gestione delle API sono 3 aspetti principali da considerare nell'architettura di gestione
delle API decentralizzata.
Possiamo raggruppare le API in base alla funzionalità o in base a data center o regioni. La
modalità Private Jet, la modalità Sidecar e la modalità Shared sono tre principali opzioni di
distribuzione per le API.