I server di Instant Developer Cloud

I server di produzione di Instant Developer Cloud sono server integrati nella piattaforma e gestiti completamente tramite la console.

Per creare un nuovo server di produzione, è possibile accedere alla pagina server della propria organizzazione e poi utilizzare il pulsante Aggiungi server di produzione.

A questo punto si apre una schermata per la selezione della taglia del server, in cui è possibile selezionarne una tra le seguenti:

• Taglia S: 1 CPU condivisa, 1,7 GB di RAM, 10 GB disco SSD, 50 GB Egress mensile, fino a tre applicazioni installabili.
• Taglia M: 1 CPU dedicata, 3,75 GB di RAM, 20 GB disco SSD, 100 GB Egress mensile, fino a sei applicazioni installabili.
• Taglia L: 2 CPU dedicate, 7,5 GB di RAM, 40 GB disco SSD, 200 GB Egress mensile, fino a dieci applicazioni installabili.
• Taglia XL: 4 CPU dedicate, 15 GB di RAM, 80 GB disco SSD, 400 GB Egress mensile, fino a venti applicazioni installabili.
• Taglia XXL: 8 CPU dedicate, 30 GB di RAM, 160 GB disco SSD, 800 GB Egress mensile, fino a quaranta applicazioni installabili.
• Taglia XXXL: 16 CPU dedicate, 60 GB di RAM, 320 GB disco SSD, 1600 GB Egress mensile, fino a ottanta applicazioni installabili.

Per proseguire è necessario anche indicare la carta di credito su cui effettuare gli addebiti mensili. Se non è possibile selezionarla, occorre prima definire un profilo di fatturazione nella console.

Dopo aver selezionato la taglia è possibile cliccare il pulsante Continua in fondo alla pagina per accedere alla pagina dei servizi aggiuntivi. Sono presenti i seguenti servizi:

• Sincronizzazione: permette al server di funzionare come sistema di sincronizzazione per i database locali delle applicazioni mobile.
• Cloud Connector: permette al server di integrare dati e servizi provenienti da risorse on premise.
• Analytics & Feedback: permette di installare sul server i servizi di raccolta dati analitici e di feedback dei clienti.
• Backup Giornaliero / Backup orario: permette di mantenere automaticamente uno snapshot dell’intero server per ogni giorno o ogni ora degli ultimi 30 giorni.

Dopo aver selezionato gli eventuali servizi aggiuntivi, è possibile cliccare il pulsante Verifica il tuo ordine in fondo alla pagina per accedere al riepilogo e poi concludere l’acquisto.

Struttura di un server di produzione di Instant Developer Cloud #

Un server di produzione è basato su un’istanza di macchina virtuale del servizio Compute Engine di Google Cloud Platform, in un datacenter situato nell’Unione Europea.

Il sistema operativo è di tipo linux gestito direttamente da Google e ottimizzato per l’utilizzo di container. In ogni istanza viene caricata un’immagine container che dipende dalla versione di Instant Developer Cloud in uso.

Nella versione 22.0, ad esempio, l’immagine contiene un sistema operativo Linux Alpine 3.13 in configurazione minima, Node.js 16.4, Postgres 13.3, Let’s encrypt, ImageMagick, e Puppettier.

Le uniche porte aperte sono la 80 (http) e la 443 (https). La porta 80 serve solo per la redirezione http/https.

Tutti i server di Instant Developer Cloud sono dotati di due dischi. Il primo è il disco del sistema operativo, che contiene anche l’immagine container. Il secondo, di dimensione variabile in base alla taglia e di tipo SSD, contiene i dati, cioè:

• I database Postgres.
• Le applicazioni installate.
• Il file system di ogni applicazione installata.

I dischi presenti sui server sono nativamente crittografati tramite Google Cloud Platform.

Il database Postgres presente nel container accetta solo connessioni locali e l’elenco degli account è gestito automaticamente dal sistema. Non è quindi possibile conoscere le password degli utenti.

Installazione di un’applicazione #

Vediamo ora come funziona il processo di installazione delle applicazioni su un server di produzione di Instant Developer Cloud.

Per installare una nuova applicazione su un server di produzione è necessario cliccare il pulsante +Installa nella pagina Installazioni del menu di progetto.

Dopo aver iniziato il processo di installazione apparirà una serie di tre popup. Nel primo occorre selezionare l’applicazione da installare; in un progetto, infatti, possono essere presenti più applicazioni. Prima di continuare si potrà scegliere se pubblicare in un server o in un launcher. In questo caso occorre selezionare l’opzione Server.

Nel popup successivo sarà possibile dare un nome alla nuova build che verrà compilata al volo in base allo stato attuale dell’applicazione nel progetto, oppure selezionare una build esistente.

Nel caso di nuova build, il popup presenta anche le seguenti opzioni:

• Compila la build senza installarla: la build verrà solo compilata ma non verrà installata.
• Abilita il debug a runtime: la build verrà compilata aggiungendo il supporto al debug a runtime dell’applicazione nel server.
• Salta il controllo delle traduzioni: in caso di build di test, non verrà effettuato il controllo della traduzione completa dell’applicazione nelle lingue dichiarate. Questa opzione è disabilitata se il server non è stato marcato come server di test.

Infine nell’ultimo popup sarà possibile dare un nome all’applicazione installata e selezionare uno o più server in cui installarla. Cliccando infine il pulsante Installa nel terzo popup verrà iniziato il processo di installazione vero e proprio.

Aggiornamento di un’installazione #

Se si desidera allineare un’installazione esistente allo stato attuale dell’applicazione nel progetto, è possibile cliccare il pulsante refresh evidenziato nell’immagine precedente che appare quando si visualizzano i dettagli di un’installazione della lista. In questo modo apparirà solo un popup di conferma in cui è possibile solamente cambiare il nome della build e modificare le opzioni di compilazione viste in precedenza.

Si noti, tuttavia, che in questo caso è presente un’ulteriore opzione attiva per default: Sovrascrivi build esistente. L’aggiornamento dell’installazione, infatti, per default sovrascrive la build precedente, che in questo modo viene persa. Se si desidera mantenere anche la build precedente, è possibile deselezionare l’opzione.

Processo di installazione #

Il processo di installazione inizia con la compilazione dell’applicazione e la creazione di una nuova build. La nuova build viene poi caricata in un bucket di Google Cloud così da poterla mantenere come backup e passarla al server per l’installazione.

Quando la build è stata creata senza errori e caricata nel bucket, inizia l’operazione di installazione vera e propria che è fatta dai seguenti passaggi:

1. L’applicazione corrente viene messa in modalità manutenzione, cioè non si accettano più nuove sessioni e in quelle attuali viene visualizzato un messaggio che comunica all’utente di concludere il lavoro prima possibile.
2. Nel frattempo viene scaricata dal bucket la build da installare.
3. Dopo un tempo pari a 15 secondi le sessioni attuali vengono interrotte e l’applicazione viene messa in pausa.
4. Prima di iniziare le operazioni di modifica del server, viene effettuato uno snapshot dell’intero server in modo da poter ripristinare la situazione precedente all’installazione stessa.
5. Il sistema di installazione estrae i file della nuova build in una cartella temporanea. La build viene validata come applicazione Node.js.
6. Se richiesto, vengono aggiornati gli schemi dei database utilizzati dall’applicazione.
7. In caso di aggiornamento, il file system dell’applicazione attuale viene spostato nella nuova directory. La vecchia copia viene rinominata e alla nuova viene dato il nome giusto.
8. Se tutto ha funzionato come previsto, le modifiche agli schemi dei database vengono confermate e tutti i file temporanei vengono cancellati.
9. Se ci sono stati problemi in anche solo uno dei passaggi precedenti, tutte le modifiche al file system e ai database del server vengono annullate, ovvero tutto torna come prima.
10. L’applicazione viene riavviata e gli utenti ancora collegati possono rientrare automaticamente.

A parte i tempi di compilazione e di gestione delle sessioni esistenti, tutto il processo di installazione richiede solamente qualche secondo o al massimo qualche decina di secondi. In questo modo gli utenti dell’applicazione non avranno la percezione di un servizio interrotto, ma solo di una pausa momentanea.

Aggiornamento del database #

Quando una build viene compilata, essa contiene anche le informazioni per la creazione e l’aggiornamento degli schemi dei database Postgres da essa utilizzati. Nel momento in cui la build è in fase di installazione, la console verifica se i database presenti nel server devono essere aggiornati o meno. Nel caso in cui sia richiesto un aggiornamento, nel popup di selezione del server sarà presente anche l’opzione Aggiorna database, come mostrato nell’immagine seguente:

L’opzione può apparire pre-selezionata se su quel server il database è effettivamente da aggiornare e se l’applicazione che ha aggiornato il database l’ultima volta è la stessa. Un database, infatti, può essere utilizzato da più di un’applicazione, ma normalmente solo una di esse ne mantiene aggiornato lo schema.

Se si seleziona l’opzione, l’aggiornamento dello schema dei database è parte del processo di installazione. Per ogni database le istruzioni di modifica vengono eseguite tutte in una stessa transazione in modo da poter essere completamente annullate se anche solo una di esse non ha successo.

Se l’aggiornamento del database del server non ha successo, si consiglia di effettuare un backup e un restore del medesimo nell’ambiente IDE e poi testare l’aggiornamento in tale ambiente.

Gestione delle build #

L’elenco delle build di una determinata applicazione è disponibile dal sotto-menu di progetto App e dati, come si vede nell’immagine seguente.

Per ogni build viene riportato su quali server è installata. Inoltre è possibile installarla su altri server, eliminarla oppure scaricarla per l’installazione su un proprio server in modalità self managed.

Il pulsante Rimuovi vecchie build è in grado di cancellare automaticamente tutte le build più vecchie di 30 giorni che non sono installate da nessuna parte. Si consiglia di utilizzarlo di tanto in tanto per eliminare lo spazio occupato dalle build, sia nel server IDE che nei bucket di backup della propria organizzazione.

Configurazione dell’applicazione #

Dopo aver installato un’applicazione, essa diventa disponibile per la configurazione dal menu Installazioni nella sezione relativa al server in cui è stata installata.

Il menu relativo alla singola installazione presenta le seguenti voci:

• Parametri runtime: apre la videata per la configurazione dei parametri di runtime dell’applicazione, descritta in seguito.
• Configurazione worker: apre la videata per la configurazione dei processi worker dell’applicazione, descritta in seguito.
• Naviga tra i file: apre la videata per la gestione del file system dell’applicazione. È equivalente al pulsante Sfoglia nella riga Spazio usato sottostante.
• Condividi: permette di condividere un’installazione disponibile su un launcher con altri utenti.
• Installa su un launcher: rende l’applicazione disponibile all’interno di un launcher anche se essa è di tipo online, cioè installata sul server.
• Allinea database: forza l’allineamento dei database del server usati dalla build. Attenzione: prima di usare questo comando si consiglia di eseguire uno snapshot del server per poter annullare il comando in caso di bisogno.
• Disinstalla: rimuove l’applicazione installata.

Espandendo la riga relativa ad un’installazione è possibile accedere a diverse opzioni di configurazione.

Tramite il pulsante con l’icona ad impulso è possibile accedere alla pagina del log strutturato che verrà descritta in seguito. Il pulsante con l’icona pausa, infine, mette in pausa l’applicazione e impedisce l’accesso da parte di browser, client API, o dispositivi mobile. Le sessioni esistenti non vengono interrotte.

Attivando il flag Server session, viene lanciata una ulteriore sessione dell’applicazione senza interfaccia utente. Questa sessione può eseguire processi batch, rimanere in ascolto di eventi o di modifiche al database, o altri task di backend. Attivando il flag viene garantito che ci sarà sempre una sessione batch in esecuzione. Il codice dell’applicazione può distinguere se l’applicazione è in esecuzione in una sessione browser o in una sessione server (batch) utilizzando la funzione app.isServerSession() che restituisce true in questo caso.

Il flag Modalità offline permette di eseguire l’applicazione come PWA. Per una trattazione più estesa di questo argomento, è possibile leggere il relativo libro nella documentazione.

Si noti infine il pulsante Riavvia Node.js in alto nella lista delle installazioni, che permette di riavviare l’intero sistema applicativo nel server selezionato. Tutte le sessioni di tutte le applicazioni verranno interrotte.

Parametri di runtime #

La videata dei parametri di runtime permette di definire delle coppie chiave-valore che l’applicazione è in grado di leggere o scrivere tramite i metodi app.getParameter e app.setParameter.

Il vantaggio di poter inserire tramite la console dei parametri che l’applicazione può leggere consiste nel poter comunicare chiavi segrete senza doverle inserire nel codice del progetto, o dati che possono variare senza dover aggiornare l’applicazione.

I parametri di runtime sono relativi alla singola installazione, tuttavia è possibile definire parametri di runtime anche a livello di server, tramite il menu Parametri runtime della pagina server. Se un parametro viene definito a livello di applicazione esso prevale su quelli definiti a livello di server, altrimenti viene usato quello di server come default per tutte le installazioni.

Quando l’applicazione scrive il valore di un parametro, esso sarà sempre definito a livello di applicazione. I parametri di runtime definiti a livello di server, quindi, sono scrivibili solamente tramite la console.

Si noti che a livello di applicazione è possibile gestire l’evento app.onParameterChange che comunica la variazione dei parametri anche alle sessioni già avviate.

Esistono alcuni parametri che vengono gestiti direttamente dal framework:

• trackCodeLine: valore booleano (true/false), con default false. Abilita un tracciamento più preciso delle righe di codice che generano eccezione; viene utilizzato in Analytics per aprire il progetto direttamente al punto che ha generato il problema; in alternativa viene riportato solo il numero di riga del file JavaScript. Impostandolo a true ci sarà una piccola penalizzazione nelle performance di esecuzione del codice applicazione.
• allowOffline: valore booleano (true/false), con default false. Deve essere impostato a true per consentire ad un’applicazione di essere eseguita anche in modalità PWA.
• sendGridKey: valore della chiave da utilizzare per inviare mail tramite l’oggetto App.Mailer del framework di Instant Developer Cloud. Esso utilizza a sua volta il servizio SendGrid a cui ci si deve registrare per ottenere le chiavi di invio mail.
• stripeKey: valore della chiave da utilizzare per la libreria per la gestione dei pagamenti elettronici App.Stripe del framework di Instant Developer Cloud.
• gcmKey: valore del parametro gcmKey per l’invio delle notifiche a dispositivi Android.
• apnKey: contenuto del file del certificato per l’invio delle notifica a dispositivi Apple.
• apnKeyId, apnTeamId: valori dei parametri per l’invio delle notifica a dispositivi Apple.
• gmapKey: valore della chiave per l’utilizzo del componente Google Maps. Non deve cominciare per “key=” e deve contenere solo il valore della chiave così come configurato nella console di Google Cloud. 

Configurazione dei processi worker #

Ogni applicazione installata su un server utilizza uno o più processi worker per gestire le sessioni. La pagina di configurazione dei worker serve per definire le politiche di gestione dei processi dell’applicazione. La configurazione standard è definita a livello di server ed è accessibile dal menu Configurazione worker della pagina del server.

La pagina Configurazione worker di un’installazione è accessibile dal menu corrispondente nella lista delle installazioni dell’applicazione da configurare.

Per aggiungere una nuova configurazione, cliccare il pulsante +Aggiungi configurazione nella testata della videata.

Una configurazione è definita dai seguenti parametri:

• Nome: identifica la configurazione.
• Tipo di sessione: indica per quali tipi di sessione è valida questa configurazione. I possibili valori sono: web, sync, rest, server, all.
• Query string: indica se questa configurazione entra in gioco solamente se sono presenti alcuni parametri sulla query string del browser che attiva la sessione.
• Priorità: priorità di esecuzione del processo worker. Anche se è possibile indicare qualunque valore ammesso (max, high, normal, low, min) si consiglia di utilizzare solo normal e low. Un processo con priorità min funzionerà solo quando tutti gli altri non sono impegnati; un processo con priorità high può interferire con il comportamento del server; un processo con priorità max può addirittura bloccare il server se esso non si comporta correttamente.
• Timeout inattività: indica dopo quanto tempo un worker che non ospita più alcuna sessione deve essere eliminato.
• Numero totale utenti complessivi: è il numero massimo di sessioni contemporanee ammesse per il tipo selezionato. Se, ad esempio, viene impostato a 100 ed il tipo è rest, significa che il server può gestire al massimo 100 richieste API contemporanee. Alle ulteriori richieste verrà restituito un codice di errore.
• Numero massimo di processi: è il numero massimo di processi worker che verranno generati per gestire le sessioni. Il sistema bilancia il numero di sessioni in modo che tutti i processi ne contengano un numero simile.
• Numero minimo di utenti per processo: è il numero minimo di sessioni che un processo worker deve contenere prima di aggiungere un nuovo processo worker. Se, ad esempio, lo si imposta a 20 ed il tipo è web, le prime 20 sessioni browser contemporanee verranno gestite da un solo processo worker. Se viene attivata un’ulteriore sessione, essa verrà gestita da un nuovo worker, se non si è ancora arrivati al numero massimo di processi worker.

Si consiglia di aggiungere una sola configurazione per tipo di sessione / query string.

Per decidere quanti processi worker dedicare ad ogni tipo di sessione, occorre tenere presente i seguenti parametri:

• Definire una politica per un determinato tipo di sessione determina la generazione di almeno un processo worker dedicato a quel tipo di sessione. Se, ad esempio, si aggiunge una configurazione per le sessioni sync, tutte le sessioni di sincronizzazione verranno gestite con processi diversi da quelli delle sessioni web.
• Nel caso di applicazioni che necessitano di una server session, mantenerla su un worker separato può avere il vantaggio di tenere i processi batch indipendenti dal carico di lavoro delle funzioni interattive.
• A parte il caso di applicazioni con calcoli intensivi, il collo di bottiglia delle applicazioni è sempre l’accesso al database. Non è quindi utile aumentare il numero di processi worker a più del numero di processori del server. La miglior strategia per gestire la scalabilità è quella di ottimizzare il numero e la qualità delle query.
• Ogni worker può indirizzare al massimo 1,7 GB di memoria. All’aumentare del numero di sessioni contemporanee può essere utile suddividere il carico su più worker anche per poter utilizzare più memoria.
• Occorre tenere presente la natura di Node.js come processo single threaded dotato di event loop. Se un thread di codice JavaScript non utilizza funzioni asincrone ma, ad esempio, esegue calcoli intensivi di durata maggiore ai 100 ms, il processo worker che li esegue potrebbe non riuscire a gestire tutte le altre sessioni in maniera puntuale. In questi casi si consiglia di spezzare i calcoli complessi introducendo funzioni asincrone, oppure di isolarli in processi worker dedicati.

Log strutturato #

Il log strutturato è un potente sistema di debug e controllo delle applicazioni in produzione. Attivando il log strutturato per un’installazione, tutte le sessioni applicative verranno loggate in maniera separata e sarà possibile identificare errori, warning o log di console specifici. 

A richiesta ogni sessione può eseguire il log di tutte le query effettuate sul database e, se l’applicazione è stata compilata con il flag di debug a runtime attivo, per ogni sessione online sarà possibile attivare la modalità di debug interattivo.

Per utilizzare il log strutturato, è necessario far sì che il codice dell’applicazione imposti la proprietà app.sessionName per ogni sessione di cui interessa effettuare il log. Il nome della sessione può contenere qualunque stringa. Nella pratica è comodo inserire il tipo di sessione, ad esempio (W) per le sessioni web, (S) per quelle sync e (R) per le sessioni rest. Nel rispetto delle regole sulla privacy è anche possibile indicare il nome dell’utente collegato alla sessione, in modo da avere immediatamente un legame fra gli eventuali feedback riportati e l’analisi “dietro le quinte” di quanto è successo. Se una sessione non imposta app.sessionName, non verrà loggata nel log strutturato.

L’attivazione del log strutturato avviene dalla pagina che si apre cliccando il pulsante con l’icona ad impulso presente nella sezione relativa ad un’installazione. Cliccando il pulsante Configura nella testata della videata, sarà possibile attivare il log strutturato, attivare anche i log del database, cancellare le sessioni di log salvate ed infine selezionare un filtro per salvare solo le sessioni che hanno un determinato nome o parte di esso.

Cliccando il pulsante Aggiorna, sempre nella parte alta della videata, è possibile reperire immediatamente le ultime informazioni sulle sessioni, che, altrimenti, vengono estratte solo ogni 15-30 minuti.

Per ogni sessione in cui è presente un log, esso può essere visualizzato cliccando sulla riga della sessione stessa. Il pulsante sulla destra, invece, apre il progetto. Se l’applicazione è stata compilata con il debug a runtime attivo, il progetto sarà proprio quello che ha dato origine alla build, che in questo caso viene mantenuto in un backup apposito. Se la sessione è online, sarà possibile interagire con la sessione utilizzando il debugger dell’IDE.

Per ogni sessione viene loggata ogni chiamata alle funzioni console.log, console.warn e console.error, sia da parte del codice dell’applicazione che a livello di framework. I warning e gli errori vengono anche comunicati alla console, così da poterne visualizzare il numero nella lista prima ancora di aprire il log della sessione. Si tenga presente, infatti, che la console conosce i dati della sessione, ma il log rimane presente nel file system dell’applicazione sul server di produzione.

Tramite il pulsante con l’icona filtro in alto nella pagina ed il relativo campo di ricerca dal lato opposto sarà possibile filtrare la lista per visualizzare subito le sessioni che hanno generato errori o warning, oppure modificare il periodo di visualizzazione che, per default, riguarda le ultime 24 ore.

Gestione dello spazio relativo al log strutturato #

Il sistema di log strutturato raccoglie l’output di tutti i comandi di logging che sono stati inseriti nell’applicazione e, se configurato, i testi di tutte le query eseguite. Lo spazio richiesto per memorizzare queste informazioni può crescere rapidamente se ci sono molte sessioni oppure se sono stati lasciati attivi log di oggetti molto corposi.

Dalla versione 22, il sistema possiede una protezione che disabilita il log strutturato se nel server rimangono meno di 500 MB di spazio libero. Si consiglia tuttavia di mantenere il log delle query normalmente disattivato e di evitare il log di oggetti complessi per non sovraccaricare inutilmente questo sistema.

Si segnala infine che i log strutturati delle sessioni vengono cancellati definitivamente dopo trenta giorni per motivi di privacy.

Gestione dei database di produzione #

I database di produzione sono collocati nello stesso server delle applicazioni che li devono usare. È possibile accedere alle pagine di gestione dei database del server in due modi:

• Tramite il sottomenu App e dati del menu Dati di progetto, oppure
• Tramite il sottomenu Database di produzione del menu Installazioni del server.

La pagina di gestione mostra la lista di ogni database del server. Per ognuno di essi è possibile eseguire le seguenti operazioni tramite il menu di lista:

• Backup
• Restore
• Download di un backup
• Eliminazione

È possibile inoltre accedere ad un query editor, come mostrato nell’immagine seguente.

Le operazioni di backup e restore possono essere utili per spostare un database di produzione nell’ambiente di sviluppo o viceversa, ma anche per preparare i dati per i test di non regressione o di carico.

Il sistema di backup periodico dei dati dei database viene invece implementato a livello dell’intero server, come illustrato nei paragrafi seguenti.

Configurazione del server #

La configurazione del server avviene attraverso le pagine a cui si accede dal menu del server. Vediamole una per una.

Impostazioni #

La pagina delle impostazioni contiene le impostazioni generali del server, ed è divisa in varie card. Nella prima è possibile tenere sotto controllo i parametri più importanti (%CPU, RAM, storage e traffico), oltre a poter effettuare l’upgrade del server e la condivisione nel gruppo di lavoro.

Nella seconda card è possibile modificare il nome del server, così come è conosciuto nella console, mentre il codice univoco viene assegnato dalla console al momento della creazione e non è modificabile.

È inoltre possibile sapere quale versione della piattaforma è installata nel server ed eventualmente aggiornarla. Nei paragrafi seguenti illustreremo la procedura migliore per aggiornare la piattaforma dei propri server.

Nella zona seguente si possono attivare o meno alcuni servizi, fra i quali il test automatico, che permette di utilizzare il server come target di esecuzione di test automatici, e il servizio feedback e issue, che, appunto, permette di raccogliere feedback dagli utenti e gestire le issue sui server di sviluppo.

La gestione delle issue è attiva per default nei server di sviluppo, mentre quella dei feedback deve essere attivata in quanto il servizio di raccolta feedback è un servizio aggiuntivo contenuto nel pacchetto analytics.

Nell’ultima zona infine è possibile configurare un’applicazione come default per il server. In questo caso sarà sufficiente digitare il nome completo del server per entrare nell’applicazione. 

È infine possibile aggiungere pacchetti Node.js personalizzati, inserendone il nome e la versione nel campo Pacchetti npm personalizzati. I pacchetti devono essere separati da virgola. Ad esempio, questa è una stringa valida per inserire il pacchetto ftps e image-size: ftps@1.1.1,image-size@1.0.0.

Dopo ogni modifica occorre cliccare il pulsante verde Salva in alto a destra per confermare l’operazione. 

Monitoraggio delle attività #

La pagina di monitoraggio delle attività permette di conoscere l’allocazione delle risorse del server in tempo reale. Oltre ai grafici relativi alla CPU, alla RAM e al numero di sessioni, è possibile conoscere lo stato di tutti i processi in esecuzione. Per ogni processo viene riportata la RAM allocata totale ed in percentuale, l’affinità con le CPU del server, la percentuale di CPU attualmente utilizzata e il codice di stato del processo.

I processi sono classificati nelle seguenti categorie:

1. Processi di sistema (System).
2. Processi del framework di Instant Developer Cloud (Framework).
3. Processi per le connessioni ai database (Connections).
4. Processi per la gestione del database (DB).

Infine ogni worker di ogni applicazione verrà riportato in un gruppo separato indicando il tipo di worker, il numero delle sessioni applicative nel worker e i restanti dati del processo.

Tutti i dati relativi ai processi vengono raccolti analizzando il risultato del comando top eseguito dal sistema operativo del server. 

Se il periodo scelto nel filtro delle date contiene il momento attuale, il grafico delle risorse si aggiornerà ogni 30 secondi, mentre la lista dei processi si aggiornerà ogni 10 secondi. I dati vengono mantenuti solo per gli ultimi 60 giorni.

La pagina si chiude mostrando il grafico dell’utilizzo dello storage, cioè del disco dati e del traffico di rete.

Questa pagina fornisce informazioni molto importanti per comprendere se:

• La capacità del server è adeguata al carico di lavoro che varia nel tempo.
• Esistono processi bloccati o che assorbono una quantità eccessiva di risorse.
• Quali tipi di attività sono in corso.

Configurazione dei worker #

Questa pagina permette di configurare i valori di default per la configurazione dei worker delle applicazioni installate. 

In particolare, specificando il Numero massimo di worker per app è possibile definire il numero di processi worker che verranno creati dal server per gestire le sessioni di ogni applicazione. Il Numero minimo di utenti per worker indica qual è il numero di sessioni che ogni worker gestirà prima che venga avviato un nuovo processo che prenda in carico nuove sessioni client. Il Numero massimo di utenti per app indica il numero massimo di sessioni gestite contemporaneamente da un’applicazione prima che questa rifiuti l’avvio di una nuova sessione. In questo caso il valore tiene conto della somma di tutte le sessioni dei worker della stessa app.

Parametri di runtime #

Questa pagina permette di aggiungere parametri di runtime che rappresentano valori di default per tutte le applicazioni installate nel server.

Installazioni #

La pagina delle installazioni contiene la lista delle applicazioni installate e permette di gestirle. Si ricorda che la stessa build può essere installata più volte nello stesso server, per dare luogo a più installazioni a partire dalla medesima base di codice.

Domini #

La pagina dei domini permette di configurare i nomi di dominio internet che devono essere associati al server. Per ogni nome di dominio configurato è possibile specificare l’eventuale certificato SSL da utilizzare e un’applicazione predefinita da avviare automaticamente.

Esistono due tipi di domini: gli alias e i domini personalizzati.

Alias #

Gli alias sono i domini più semplici da configurare; per crearne uno è sufficiente cliccare il pulsante +Alias. Apparirà una nuova riga nella lista dei domini, all’interno della quale è possibile specificare un nome e l’app predefinita da associare al dominio.

Il valore inserito nel campo del nome verrà usato per calcolare un dominio con il pattern [nome]-[codice della propria organizzazione].instantdevelopercloud.com. Ad esempio, usando come nome myapp su un server dell’organizzazione myorg, il dominio personalizzato diventa myapp-myorg.instantdevelopercloud.com. Lo scopo è quello di fornire un modo semplice per personalizzare l’accesso alle proprie applicazioni da parte degli utenti finali, senza dover necessariamente acquistare un proprio dominio.

Il pulsante Salva permette di salvare i dati nel database della console, mentre il pulsante Carica sul server configura effettivamente il server di riferimento per l’uso del certificato. 

Per quanto riguarda i certificati HTTPS, Il dominio di tipo Alias viene sempre gestito automaticamente da Instant Developer Cloud, attraverso il sistema let’s encrypt.

Il pulsante Ripristina l’ultima configurazione caricata permette di riallineare i dati della console di uno specifico Alias all’ultima configurazione effettivamente caricata sul server.

Siccome i certificati sono caricati all’avvio di Node.js, dopo aver modificato e salvato i dati di questa pagina occorre riavviarlo per rendere effettiva la modifica. A tal fine, è possibile utilizzare il comando Riavvia Node.js disponibile nella pagina Impostazioni.

Dominio personalizzato #

I domini personalizzati permettono di utilizzare un qualsiasi dominio che sia puntato sull’IP del server. Questo dato è disponibile nel box in alto a sinistra nella pagina di gestione del server, sotto al nome, come mostrato nell’immagine alla pagina seguente.

Per creare un dominio personalizzato è sufficiente cliccare il pulsante +Dominio. Apparirà una nuova riga nella lista dei domini, all’interno della quale è possibile specificare un nome, i dati relativi al certificato SSL da utilizzare e l’app predefinita da associare al dominio.

Per configurare il certificato SSL ci sono due possibilità: usare il proprio certificato SSL oppure farne creare uno al sistema tramite Let’s Encrypt.

Per poter utilizzare il proprio certificato SSL è necessario caricare sul server tre file in formato PEM:

• Certificato SSL: è un file di testo che contiene la catena del certificato.
• Chiave del certificato: è un file di testo che contiene la chiave privata relativa al certificato.
• Bundle: è un file di testo che contiene gli eventuali certificati delle Autorità di Certificazione (AC) da utilizzare al posto della lista predefinita curata da Mozilla. Il file può essere vuoto, ma se il certificato è autofirmato è obbligatorio indicare la propria autorità di certificazione.

Per maggiori informazioni sul formato dei certificati è possibile far riferimento alla documentazione di node.js.

È possibile chiedere ad Instant Developer Cloud di generare i file del certificato in automatico, tramite il sistema Let’s Encrypt. A tal fine è sufficiente abilitare la casella di controllo Usa un certificato automatico. 

Il pulsante Salva permette di salvare i dati nel database della console, mentre il pulsante Carica sul server configura effettivamente il server di riferimento per l’uso del certificato.

Il pulsante Ripristina l’ultima configurazione caricata permette di riallineare i dati della console di uno specifico Dominio all’ultima configurazione effettivamente caricata sul server.

Siccome i certificati sono caricati all’avvio di Node.js, dopo aver modificato e salvato i dati di questa pagina occorre riavviarlo per rendere effettiva la modifica. A tal fine, è possibile utilizzare il comando Riavvia Node.js disponibile nella pagina Impostazioni.

Let’s Encrypt con proprio nome di dominio #

Non appena si carica sul server un dominio basato su certificato Let’s Encrypt, il server effettua le operazioni di verifica e di creazione del dominio. Qualora si manifestassero errori nella registrazione del dominio, su Let’s Encrypt comparirà un messaggio di errore associato al dominio che lo ha generato.

La causa principale di errori di creazione del certificato risiede nella configurazione dei puntamenti del dominio al server. Infatti, il puntamento del dominio al server deve essere effettuato tramite IPv4, inoltre il dominio non deve avere un puntamento IPv6. 

Molti registrar creano i domini con due puntamenti di default: IPv4 e IPv6. Modificando solo quello IPv4 per puntare all’IP del server e non cancellando il puntamento IPv6 si otterrà un errore nella fase di verifica effettuata da Let’s Encrypt.

Analytics #

Questa pagina permette di installare il servizio Analytics sul server di produzione e di configurarlo. Per poter installare Analytics è richiesto l’acquisto del relativo pacchetto.

Una volta installato il servizio Analytics, il server potrà essere utilizzato come punto di raccolta delle informazioni provenienti dalle applicazioni.

Backup #

La pagina dei backup contiene la lista degli snapshot del server effettuati dalla console tramite i servizi di Google Cloud Platform.

I backup del server vengono effettuati nelle seguenti condizioni:

• Subito prima dell’installazione o della disinstallazione di un’applicazione. 
• Se si clicca il pulsante Backup in alto nella pagina.
• Se è attivo il servizio Backup giornaliero o Backup orario per il server.
• Subito prima di effettuare un ripristino del server.

Verranno mantenuti i backup degli ultimi 30 giorni indipendentemente dal motivo per cui sono stati creati.

Siccome il backup è uno snapshot coerente del disco dati dell’intero server, esso contiene tutti i database, tutto il file system e tutto il codice di tutte le applicazioni in esso installate. 

Nel caso in cui un server risulti irraggiungibile o compromesso, la procedura di ripristino permette di ricreare completamente il server usando come disco dati il backup desiderato. La procedura di ripristino richiede qualche minuto di tempo e riporta lo stato dell’intero server al momento in cui il backup è stato effettuato. Il ripristino del disco di sistema è invece sempre totale. Il disco di sistema viene ricostruito a partire dalla versione originale relativa alla versione di piattaforma installata nel server.

L’uso degli snapshot coerenti è un ottimo sistema di disaster recovery in quanto permette di ripristinare lo stato del server ad un qualunque momento in cui è avvenuto il backup con una semplice operazione di console, richiedendo solo qualche minuto.

Log #

La pagina dei log, infine, permette di accedere ai log dell’intero server. In particolare ai dati di console.log e console.error non catturati dai log strutturati e al log del server vero e proprio.

Si consiglia di utilizzare il pulsante di download per ottenere il contenuto del log come file di testo. Il contenuto dei file di log è spesso utile per ottenere informazioni sulle operazioni del server e su eventuali anomalie di funzionamento.

Aggiornamento della piattaforma #

La piattaforma Instant Developer Cloud è in continua evoluzione: ogni anno sono previste due release maggiori, la prima a fine gennaio e la seconda a fine luglio. Fra queste due release maggiori possono essere rilasciate delle release minori, a seconda della necessità di correggere malfunzionamenti o regressioni.

L’aggiornamento dei propri server di sviluppo e di produzione alle release maggiori deve essere accuratamente pianificato. 

L’aggiornamento alla release minori, invece, può essere tranquillamente demandato alla console attivando per il server il flag Installa gli aggiornamenti automaticamente, contenuto nella pagina delle impostazioni del server. In questo caso i server di sviluppo verranno automaticamente aggiornati. I server di  produzione verranno invece aggiornati automaticamente al primo riavvio, oppure è possibile eseguire l’operazione manualmente.

L’aggiornamento di un server ad una nuova release avviene dalla pagina delle impostazioni del server, cliccando il pulsante Cambia versione. In questa fase verranno presentate anche le note di rilascio della nuova versione: si consiglia di leggerle accuratamente prima di continuare.

Aggiornamento alla release maggiore successiva #

Il passaggio ad una release maggiore successiva dei propri server di sviluppo e di produzione è un’operazione normalmente non invertibile, fatta eccezione per i server di produzione, per i quali è possibile ritornare alla versione precedente ripristinando un backup del server eseguito tramite la console subito prima del passaggio.

La ragione consiste nel fatto che le nuove versioni possono contenere versioni successive dell’intero sistema operativo, a tutti i livelli. La versione 22.1, ad esempio, ha aggiornato il database server a Postgres 13.3 e questa operazione non è invertibile. Il codice stesso del framework di Instant Developer Cloud si adatta alle nuove versioni dei sistemi operativi e delle centinaia di pacchetti base che ogni volta vengono aggiornati per garantire la massima sicurezza.

Inoltre le migliaia di punti di modifica che ogni versione maggiore contiene, non permettono di garantire a priori al 100% che non ci saranno breaking change nei propri progetti. In questo caso la protezione dalle breaking change avviene a posteriori: ogni regressione segnalata al servizio di assistenza viene prontamente corretta, ripristinando esattamente il comportamento precedente o quello più vicino ad esso tecnicamente possibile.

Per queste ragioni è necessario pianificare la fase di passaggio alla release maggiore successiva come segue:

1. Evitare i periodi critici in cui sarà necessario effettuare rilasci delle proprie applicazioni. Si consiglia di mantenere una finestra temporale di due settimane.
2. Effettuare l’aggiornamento del solo server di sviluppo e del server dedicato ai test, se disponibile.
3. Testare prontamente i propri progetti per verificare che essi compilino ancora, possano essere installati su un server di test e che i test di non regressione abbiano successo.
4. Segnalare prontamente al servizio di assistenza eventuali regressioni. Le segnalazioni di regressione vengono sempre considerate urgenti, sebbene si tenga conto anche degli effetti della regressione per valutare la priorità.
5. Solo quando tutti i test avranno avuto successo sarà possibile aggiornare i server di produzione alla nuova release e di conseguenza aggiornare le applicazioni, se necessario.

Nel caso in cui non sia possibile pianificare una finestra temporale di almeno due settimane in cui eseguire i test di passaggio, si consiglia di operare come segue:

1. Nella console di Instant Developer Cloud, creare una seconda organizzazione dedicata ai test.
2. Acquistare una licenza di sviluppo per una sola mensilità.
3. Aggiornare il server di produzione alla nuova release.
4. Trasferire una copia dei progetti alla seconda organizzazione.
5. Effettuare il test dei progetti nella seconda organizzazione. Quando tutti i test hanno successo, sarà possibile aggiornare tutti i server dell’organizzazione principale.