I server Self Managed sono server di produzione esterni alla piattaforma Instant Developer Cloud e quindi completamente sconosciuti alla console. Rappresentano quindi una modalità di installazione e gestione delle applicazioni completamente manuale e autogestita.
Si consiglia l’utilizzo di server Self Managed solo se si ha a disposizione un sistemista esperto nella gestione dei server, della sicurezza dell’infrastruttura e delle applicazioni, della gestione dei database e dell’ambiente operativo Node.js. In mancanza di una o più di queste conoscenze potrebbe non essere possibile portare a termine l’installazione, oppure si potrebbero verificare problemi di vario tipo per l’applicazione, ad esempio interruzioni di servizio o un basso livello di sicurezza.
Essendo questi server completamente esterni alla piattaforma Instant Developer Cloud, Pro Gamma non offre alcun servizio di assistenza su eventuali problematiche riscontrate, sia a livello di server, che di installazione e gestione delle applicazioni. Se si desidera sottoporre al servizio di assistenza una problematica riscontrata, sarà necessario prima riprodurla nell’ambiente di sviluppo o in un server di produzione interno alla piattaforma.
I server Self Managed, tuttavia, possono risultare una scelta obbligata quando l’applicazione deve essere utilizzata all’interno di una rete aziendale chiusa, senza accesso ad internet.
Preparazione di un server Self Managed #
La preparazione di un server Self Managed è analoga a quella dei server My Cloud. Si consiglia di accedere al repository instant-developer-platform per scaricare i sorgenti del framework e quindi seguire la procedura di installazione contenuta nel file readme, sostanzialmente analoga a quella dei server My Cloud. Gli eventuali pacchetti aggiuntivi di Node.js dovranno essere gestiti manualmente.
Configurazione dei database #
La configurazione dipende dal tipo di database utilizzato dall’applicazione. Se l’applicazione utilizza un database di tipo Postgres, è possibile indicare i parametri di connessione nel file config.json specificando le proprietà:
"dbPort": "db server port",
"dbAddress": "db server host",
"dbUser": "postgres user",
"dbPassword": "postgres password",Altri tipi di database #
Se invece l’applicazione utilizza un database MySQL, SQLServer oppure Oracle, è necessario impostare le opzioni di connessione nel codice dell’applicazione prima della connessione all’istanza.
A tal fine, è necessario reperire l’istanza di default del database tramite l’istruzione App.<Nome DB>.getDefaultInstance() e successivamente impostare su di essa i parametri di connessione con il metodo setOptions(). Vediamo un esempio:
let db = App.<DataModelName>.getDefaultInstance(app);
db.setOptions(connectionOptions);Il contenuto di connectionOptions varia in relazione del tipo di database da utilizzare e, di conseguenza, al driver specifico.
MySQL #
Per la connessione ai database di tipo MySQL viene utilizzato il driver Node.js mysql che viene installato insieme agli altri pacchetti del framework.
Il parametro connectionOptions in questo caso deve essere impostato come segue:
let connectionOptions = {
host : "hostname",
database : "database name",
user : "username",
password : "password",
connectionLimit : 10
});Per l’elenco completo dei parametri di connessione ad un database MySQL tramite il driver node, è possibile consultare la documentazione completa.
SQL Server #
Per la connessione ai database di tipo SQL Server viene utilizzato il driver Node.js mssql che viene installato insieme agli altri pacchetti del framework.
Il parametro connectionOptions in questo caso deve essere impostato come segue:
let connectionOptions = {
server : "hostname\\instance",
database : "database",
user : "username",
password : "password",
options : {
useUTC : false
}
});Per l’elenco completo dei parametri di connessione ad un database SQL Server tramite il driver node, è possibile consultare la documentazione completa.
Oracle #
Per la connessione ai database di tipo Oracle viene utilizzato il driver oracledb, non installato di default insieme agli altri pacchetti del framework.
Per eseguire l’installazione del driver e delle componenti necessarie che dipendono dal sistema operativo del server, è possibile consultare la documentazione ufficiale.
Il parametro connectionOptions in questo caso deve essere impostato come segue:
let connectionOptions ={
connectString : "hostname/servicename",
user : "username",
password : "password"
});Gestione dei certificati #
Per attivare il protocollo https ed utilizzare i propri certificati SSL sul server, è sufficiente copiare i file sul server stesso e modificare opportunamente il file config.json.
Ipotizzando che il server risponda all’indirizzo https://mysrv.mydomain.it sulla porta default 443 e che i file dei certificati siano stati copiati nella directory /idcloud/config/cert il file config.json deve essere modificato nel seguente modo.
"domain": "mydomain.com",
"alias" : "mysrv.mydomain.it",
"protocol": "https",
"portHttps": 443,
"SSLCert": "/idcloud/config/cert/mydomain_it_certificate.crt",
"SSLKey": "/idcloud/config/cert/mydomain_it_private.key",
"SSLCABundles": [
"/idcloud/config/cert/mydomain_it_ca_bundle.crt"
],È possibile aggiungere al file di configurazione la proprietà customSSLCerts per fare in modo di utilizzare uno specifico certificato a seconda della URL di destinazione del server.
Se ad esempio il server è configurato, tramite DNS, a rispondere anche all’indirizzo https://mysrv.myotherdomain.it, modificando la proprietà alias ed aggiungendo customSSLCerts è possibile utilizzare un diverso certificato se il server è stato raggiunto utilizzando questo nome. Ad esempio:
“alias” : “mysrv.mydomain.it, mysrv.myotherdomain.it”,
…
"customSSLCerts": [{
"SSLDomain": "myotherdomain.it",
"SSLCert": "/idcloud/config/cert/myotherdomain_it_certificate.crt",
"SSLKey": "/idcloud/config/cert/myotherdomain_it_private.key",
"SSLCABundles": [
"/idcloud/config/cert/myotherdomain_it_ca_bundle.crt"
]
}],Pacchetti aggiuntivi #
Per il corretto funzionamento del framework, qualora venga usato il package GraphicsMagick, è necessario eseguire il download e l’installazione del pacchetto relativo nel server Self Managed. Si consiglia di leggere la documentazione ufficiale.
Installazione delle applicazioni #
Per installare un’applicazione per la prima volta, eseguire le seguenti operazioni:
- Configurare i database usati dall’applicazione nel file di configurazione.
- Aggiornare manualmente lo schema dei database usati dall’applicazione o ripristinare un backup aggiornato di tali database.
- Eseguire una build dell’applicazione tramite la console senza richiedere l’installazione su un server.
- Dalla pagina di App e dati del menu di progetto, scaricare il pacchetto di installazione relativo alla build effettuata.
- Decomprimere il pacchetto di installazione nella cartella:
idcloud/apps/apps/<app-name>- Modificare il file idcloud/config/config.json, aggiungendo all’array apps un oggetto contenente le seguenti proprietà:
apps = [{ "cl" : "Node.App", "name" : "app-name", "date" : "current-date in ISO string", "stopped" : false}]- Riavviare il server tramite: pm2 restart all.
L’aggiornamento di un’installazione avviene tramite i seguenti passi:
- Eseguire la build e scaricare il pacchetto.
- Arrestare il server tramite pm2.
- Aggiornare lo schema dei database manualmente.
- Spostare la sottocartella files dell’applicazione attuale in una posizione temporanea.
- Eliminare la cartella relativa all’applicazione attuale.
- Decomprimere il pacchetto di installazione nella cartella: idcloud/apps/apps/<app-name>
- Ripristinare la sottocartella files dalla posizione temporanea a quella originale.
- Riavviare il server tramite pm2.
Attivare la Server Session #
Per attivare la Server Session di un’applicazione è necessario editare il file idcloud/config/config.json impostando a true la proprietà startSS dei parametri dell’applicazione.
"cl" : "Node.App",
"name" : "app-name",
"date" : "current-date in ISO string",
"stopped" : false,
"startSS": trueImpostare l’applicazione di default #
È possibile impostare quale applicazione deve essere eseguita editando nel file idcloud/config/config.json la proprietà alias aggiungendo il nome dell’applicazione al nome del dominio o indirizzo ip preceduta dal carattere ‘|’.
Ad esempio:
"alias" : "mysrv.mydomain.it|app-name"Configurazione dei processi worker per le applicazioni #
Per configurare i valori di default per i worker delle applicazioni installate, è necessario modificare il file config.json aggiungendo i valori desiderati per le proprietà maxAppUsers, minAppUsersPerWorker e maxAppWorkers, come nel seguente esempio:
"maxAppUsers": 1000,
"minAppUsersPerWorker": 50,
"maxAppWorkers": 4,La corrispondenza fra queste proprietà e quelle descritte nel capitolo Configurazione dei worker è la seguente:
- maxAppUsers = Numero massimo di utenti per app
- minAppUsersPerWorker = Numero minimo di utenti per worker
- maxAppWorkers = Numero massimo di worker per app
Per definire le politiche di gestione dei processi worker per una singola applicazione installata è necessario aggiungere, all’interno della configurazione dell’applicazione, contenuta nella sezione apps del file config.json, la proprietà customWorkerConf.
In questa proprietà di tipo array è possibile specificare le configurazioni dei parametri per ogni tipo di sessione, come mostrato nel seguente esempio:
"apps": [ {
"cl": "Node.App",
"name": "app-name",
"date" : "2021-10-11T10:41:06.039Z"
"stopped": false,
"customWorkerConf": [{
"type": "web",
"query": null,
"priority": 0,
"idleTimeout": null,
"maxAppUsers": 200,
"minAppUsersPerWorker": 50,
"maxAppWorkers": 2
}, {
"type": "rest",
"query": null,
"priority": 0,
"idleTimeout": 10000,
"maxAppUsers": 100,
"minAppUsersPerWorker": 10,
"maxAppWorkers": 1
}]
}]La corrispondenza fra queste proprietà e quelle descritte nel capitolo Configurazione dei processi worker è la seguente:
- type = Tipo di sessione
- query = Query string
- priority = Priorità
- idleTimeout = Timeout inattività
- maxAppUsers = Numero totale utenti complessivi
- minAppUsersPerWorker = Numero minimo di utenti per processo
- maxAppWorkers = Numero massimo di processi
Limitazioni #
I server Self Managed sono soggetti alle seguenti limitazioni:
- Quelle già esistenti per i server My Cloud.
- Non possono ospitare il servizio Cloud Connector.
- Non possono ospitare il servizio Analytics e Feedback.
- Non possono ospitare il servizio di sincronizzazione dei database locali delle applicazioni. È invece possibile utilizzare l’accesso ai dati del server tramite Document Orientation Remota.