Passa ai contenuti principali

Soluzione multi-nodo per applicazioni web

Soluzione multi-nodo per applicazioni web


Introduzione

Un servizio online se invocato da un numero molto alto di richieste sull'unità di tempo può "andare in sofferenza" e dare tempi di risposta troppo alti. In questo caso si può intervenire a livello sistemistico per ottimizzare le risorse coinvolte o aumentarle. Se ciò non dovesse bastare si possono accendere più istanze del servizio in modo che il carico di lavoro venga ripartito su queste e non su una singola istanza. Ogni istanza viene detta "nodo".


Architettura

Lo scenario con una singola istanza di una classica applicazione web composta da Gateway (GW - front-end), Servizio (SR - back-end) e Database (Db):






Lo scenario con un Servizio (SR) replicato in più nodi ma con il Database (DB) ed il Gateway (GW) in comune, quello che punto a costruire:




Implementazione

Per l'implementazione prevediamo che le componenti del sistema siano tutte dockerizzate e supponiamo che siano le seguenti:
- Gateway = Nginx
- Servizio = Pspdfkit
- Database = Postgres

Il docker-compose di questo stack sarebbe questo:

version: "3"

services:
db:
image: postgres:latest
environment:
POSTGRES_USER: pspdfkit
POSTGRES_PASSWORD: password
# ... other environment variables
pspdfkit:
image: "pspdfkit/pspdfkit:latest"

environment:
PGUSER: pspdfkit
PGPASSWORD: password
# ... other environment variables
depends_on:
- db
ports:
- "5000:5000"

Se provassimo a lanciarlo avremmo la porta 5000 che espone il servizio fornito da PdfDfKit.

Se questo servizio è utilizzato da tantissime applicazioni per unità di tempo e va in sofferenza potremmo usare l'opzione "--scale" di docker che consente di creare più istanze di un servizio "scalandolo". "Scale" prevede, a livello di sintassi il nome del servizio che si intende scalare e il numero di istanze che si intende ottenere:

$ docker-compose up --scale pspdfkit=3

Lanciando questo comando otterremmo lo start del primo nodo e poi un errore per conflitto di porta già occupata dagli altri due nodi che non partirebbero (trovando la 5000 occupata dal primo nodo).
La soluzione prevede una modifica al docker-compose con la quale dichiamo di esporre la porta 5000 interna su una porta a caso dell'host, con l'opzione "ports: - 5000":

version: "3"

services:
db:
image: postgres:latest
environment:
POSTGRES_USER: pspdfkit
POSTGRES_PASSWORD: password
# ... other environment variables
pspdfkit:
image: "pspdfkit/pspdfkit:latest"

environment:
PGUSER: pspdfkit
PGPASSWORD: password
# ... other environment variables
depends_on:
- db
ports:
- "5000"

Lanciando ora:

$ docker-compose up --scale pspdfkit=3

Si otterrà la partenza dei tre nodi. Per capire su quale porta stanno girando i servizi basterà chiederlo a docker:

$ docker ps 

Capite bene che così il servizio è difficilmente utilizzabile e quindi chiediamo aiuto al proxy-pass costituito da Nginx. Basterà creare un file "nginx.conf" , nella stessa directory del docker-compose.yml, con il quale diciamo a Nginx di dirottare tutte le richieste che arrivano alla porta 4000 verso il servizio pspdfkit sulla porta 5000:

user nginx;

events {
worker_connections 1000;
}
http {
server {
listen 4000;
location / {
proxy_pass http://pspdfkit:5000;
}
}
}


e poi chiederemo a docker di esporre la porta 4000:

version: "3"

services:
db:
image: postgres:latest
environment:
POSTGRES_USER: pspdfkit
POSTGRES_PASSWORD: password
# ... other environment variables
pspdfkit:
image: "pspdfkit/pspdfkit:latest"

environment:
PGUSER: pspdfkit
PGPASSWORD: password
# ... other environment variables
depends_on:
- db
expose:
- "5000"
nginx:
image: nginx:latest
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
depends_on:
- pspdfkit
ports:
- "4000:4000"


Nginx gestirà le richieste che arriveranno sulla porta 4000 dirottandole alle istanze di pspdfkit disponibili con una logica "round robin" e quindi potremo lanciare:

$ docker-compose up --scale pspdfkit=3

Fonti:






Commenti

Post popolari in questo blog

Telecamere Ip con accesso "nascosto"

Telecamere Ip con accesso "nascosto" Storia triste di un auto-hacking obbligato che mi ha fatto scoprire come la nostra privacy è realmente messa a rischi. Storia Ho acquistato dal mercatino/fiera del Radioamatore di Fasano quattro telecamere IP. La scatola riporta "Smart Camera" LF4810. Ne ho montata una e testata in tutte le sue funzionalità per oltre un mese. Chiaramente la manualistica scarsissima, come da tradizione in questi prodotti cinesi di costo molto concorrenziale, consiste in un "pieghevole" di 4 facciate. Chiaramente non erano documentate le impostazioni necessarie per attivare i protocolli ONVIF e RTSP che mi sono indispensabili per l'uso che ne devo fare. Nonostante questa scarsa documentazione dopo l'installazione base fatta con l'apposita app: tutto sembrava corretto. Chiaramente la prima azione che ho compiuto è stata quella di cambiare la password che di default è "123". Subito dopo h...

Dynamic DNS con Duckdns.org in HTTPS

Obiettivo Avere un dominio https con certificato valido da usare come endpoint pubblico per Homeassistant e per un WebHook per i bot telegram. Fase 1 Registrazione del dominio in un servizio di dynamic DNS come https://www.duckdns.org/   : Scegliere per quale sistema operativo installare il client che si occuperà dell'aggiornamento dell'ip: Seguire la semplice guida per la configurazione del processo cron: Fase 2 Creazione del certificato e installazione sul server. Di tutto questo si occuperà una applicazione che si chiama certbot. $ sudo add-apt-repository ppa:certbot/certbot $ sudo apt install python-certbot-apache $ sudo certbot --apache -d ol3.duckdns.org -d www.ol3.duckdns.org Fase 3 Esporre il servizio https sulla rete pubblica. Aprire o reindirizzare la porta 443 verso l'host sul quale si è fatta la configurazione di certbot dal proprio router. Il certificato di certbot è valido per novanta giorn...

Wemos D1 mini ESP8266 - Aggiornamenti OTA

Wemos D1 mini - Aggiornamenti OTA Cosa è Può risultare scomodo dover collegare con un cavo usb un ESP8266 e derivati (come in questo caso un Wemos D1 mini) ad un pc per un semplice aggiornamento software.  OTA sta per "Over The Air". Con questa tecnologia si ha la possibilità di modificare il firmware di questi microcontrollori mediante la wi-fi.  Come funziona Per ottenere questa funzionalità ci si è inventato un meccanismo molto semplice: il nostro microcontrollore, dotato della capacità di aggiornamenti OTA, ha in carico un firmware che all'avvio non fa altro che, usando la libreria ArduinoOTA, collegarsi alla wi-fi (della quale avremo fornito SSID e Password) e mediante il " Multicast DNS " dichiara la sua presenza sulla WI-FI LAN, l' Ide di Arduino rileva questa presenza e ci fornisce il supporto alla comunicazione mediante wi-fi (la porta di rete rilevata prenderà il nome del modello e l'ultima parte del suo mac-address per identificarlo, se non r...