Installazione app su server Linux self-managed

Installare un’app compilata da Instant Developer Cloud su un server self-managed é un’operazione semplice e veloce: una volta ottenuto e trasferito sul server di destinazione il pacchetto compilato dalla console di IDC, con pochi comandi la si installa nell’application server e la si manda rapidamente in produzione.
Ma quando si è nella fase di test sul campo, queste semplici operazioni vanno compiute più e più volte il che, oltre ad essere particolarmente noioso, aumenta il rischio di errori proprio a causa della continua ripetizione delle azioni.
Personalmente, sia per liberarmi del tedioso compito, sia per ridurre gli errori in fase di installazione, ho preferito creare un semplice script bash, che presento qui, in grado di provvedere alla bisogna al posto mio.
In dettaglio, lo script riceve in input il file tar.gz prodotto dalla console di installazione IDC, ne estrae il contenuto e lo copia nella cartella corretta dell’application server, reimpostando utenze e permessi a quelli richiesti dal framework IDC. Dopodiché cancella il pacchetto .tar.gz e riavvia server.js.
Se richiesto, può anche preparare l’app per l’esecuzione offline, utile per la modalità PWA. Per questo tipo di app infatti, sembra che il pacchetto di installazione generato sia mancante di due file brevi di configurazione che ne impediscono il corretto funzionamento (il manifest invece è presente). Ho incluso la generazione di questi file nello script, così da poter avere PWA perfettamente funzionanti senza dover operare a mano le necessarie correzioni.

Prerequisiti

Lo script gira su una distribuzione Linux a piacere su cui sia stato preventivamente installato il runtime di Progamma “Instant Developer Cloud” e che utilizzi bash come shell a linea di comando.
Inoltre, l’app da installare deve essere già configurata nel config.json del server.
La cartella root dell’application server dev’essere quella standard indicata da ProGamma, ossia “/idcloud”, come pure l’organizzazione delle sottocartelle che da essa diramano. Per quanto ne so, non è possibile far funzionare il server se non a partire da una cartella con quel nome ma, nel caso in cui abbiate trovato il modo di cambiare “/idcloud” in quel che più vi piace, sappiate che lo script fa affidamento all’albero di directory ufficiale; non utilizzatelo se avete un’organizzazione delle cartelle dell’application server personalizzata.
Per installare l’application server, fate riferimento alle istruzioni sulla sua pagina ufficiale di github: GitHub - progamma/instant-developer-platform

Utilizzo

Una volta copiato ed incollato il sorgente dello script in un file sul server dove è installato IDC, dategli un nome a piacere o, se preferite, chiamatelo “idc-app-installer”, così come faccio io.
Quale che sia la vostra scelta, dategli i permessi si esecuzione e poi lanciatelo senza parametri. Vi mostrerà alcune righe di aiuto che riassumono il modo di utilizzarlo e le opzioni con cui modificare I comportamenti predefiniti che prevedono la cancellazione del file tar.gz di installazione ed il riavvio di server.js.
Le riporto qui per comodità:

idc-app-installer - Installatore app IDC su server self-managed

Uso:

    idc-app-installer [-n|--dontrestartnode] [-nr|--dontremovefile] [-pwa|--ispwa] <packagefile>

    -n    --dontrestart      Non riavvia il server.js durante il processo di installazione
    -nr   --dontremovefile   Non cancella l'archivio tar/gzip dell'app dopo l'installazione
    -pwa  --ispwa            Installa in modalità pwa

Per un’installazione “standard”, è sufficente passare allo script il nome del file *tar.gz scaricato dopo aver compilato l’app nella console di IDC.
Come già detto, di default lo script cancella il pacchetto *tar.gz dopo l’installazione; se volete conservarlo, utilizzate lo switch -nr (o --dontremovefile).
Se non volete riavviare nodejs durante il processo di installazione, utilizzate lo switch -n (o il suo equivalente “verboso”); personalmente faccio sempre eseguire il riavvio di server.js ad ogni (re)installazione di app, anche se non dovrebbe essere necessario. Meglio essere prudenti, se potete permettervelo.
L’ultima opzione genera i due file necessari per il funzionamento in modalità PWA. Come accennato prima, questi file non sono essere presenti (almeno nei pacchetti generati dalla versione 21.0.5 di IDC) quando si compila un’app che include un manifest (e che quindi verrà usata con ottime probabilità come PWA); con lo switch -pwa lo script li creerà per voi.
Attenzione che nel caso di un’app PWA, il nome dell’app all’interno del config.json del server deve essere scritto in minuscolo, così come pure il nome della cartella dell’app in “/idcloud/idserver/apps/apps”. Da quel che ho capito durante un intervento in teleassistenza, il framework in questo caso si aspetta il nome della cartella tutto in minuscolo ma la procedura di compilazione lo crea seguendo l’alternanza di maiuscole e minuscole eventualmente presenti nel nome del progetto, impedendo alla PWA di funzionare. Lo script si preoccupa anche di questo, cambiano il “case” del nome della cartella in minuscolo, ma a voi resta il compito di adattarlo anche nel config.json.
É un’operazione che va fatta una sola volta quando si aggiunge una nuova app all’application server, per cui è meglio farla a mano, anche perché potreste aver bisogno di configurazioni particolari che è bene seguire da vicino piuttosto che affidarle ad uno script.

Disclaimer (ossia, patti chiari ecc ecc)

Lo script qui presentato viene rilasciato senza alcuna garanzia, in formato open source, per qualsiasi tipo di utilizzo (privato, pubblico, commerciale ecc) senza alcuna restrizione.
Gli utilizzatori sono invitati a leggere il codice sorgente al fine di accertarsi della correttezza delle operazioni compiute.
In nessun caso l’autore potrà essere chiamato a rispondere di qualunque danno, di qualsiasi forma ed entità, possa essere provocato, in maniera diretta o indiretta, dal suo utilizzo.

Il codice dello script

#!/bin/bash

trap "exit" INT

REMOVE_FILE=YES
RESTART_SERVER=YES
INSTALL_AS_PWA=NO

CURR_DIR=`pwd`

POSITIONAL=()
while [[ $# -gt 0 ]]; do
  key="$1"

  case $key in
    -n|--dontrestart)
      RESTART_SERVER=NO
      shift
      ;;
    -nr|--dontremovefile)
      REMOVE_FILE=NO
      shift
      ;;
    -pwa|--ispwa)
      INSTALL_AS_PWA=YES
      shift
      ;;
    *)
      if [ ${1:0:1} = "-" ]; then
        echo "Parameter \"$1\" not recognized"
      else
        FILENAME=$1
      fi
      shift
      ;;
  esac
done

if [ "$FILENAME" = "" ]; then
  echo "idc-app-installer - Installatore app IDC su server self-managed"
  echo
  echo "Uso:"
  echo
  echo "    idc-app-installer [-n|--dontrestartnode] [-nr|--dontremovefile] [-pwa|--ispwa] <packagefile>"
  echo
  echo "    -n    --dontrestart      Non riavvia server.js durante il processo di installazione"
  echo "    -nr   --dontremovefile   Non cancella l'archivio tar/gzip dell'app dopo l'installazione"
  echo "    -pwa  --ispwa            Installa in modalità pwa"
  echo
  exit 0
fi

if [ -e "$FILENAME" ]; then
  APP_NAME=`tar -tf "$FILENAME"|head -n 1`
  APP_NAME=${APP_NAME::-1}

  if [ $INSTALL_AS_PWA = "YES" ]; then
    APP_LOWER_NAME=`echo $APP_NAME|tr '[:upper:]' '[:lower:]'`
  fi

  tar zxf "$FILENAME"

  if [ $REMOVE_FILE = "YES" ]; then
    rm "$FILENAME" 2>/dev/null
  fi

  cd /idcloud/idserver/apps/apps/

  if [ $RESTART_SERVER = "YES" ]; then
    pm2 stop server
  fi

  if [ $INSTALL_AS_PWA = "YES" ]; then
    sudo rm -r "$APP_LOWER_NAME" 2>/dev/null
    sudo mv "$CURR_DIR/$APP_NAME" ./$APP_LOWER_NAME
    sudo echo "{\"allowOffline\":\"true\"}" > /idcloud/idserver/apps/apps/$APP_LOWER_NAME/files/private/app_params.json
    sudo echo -e "{\n  \"allowOffline\": true\n}" > /idcloud/idserver/apps/apps/$APP_LOWER_NAME/files/private/${APP_NAME}_params.json
    sudo chown -R indert:indert ./$APP_LOWER_NAME
    sudo chmod -R 755 ./$APP_LOWER_NAME
  else
    sudo rm -r "$APP_NAME" 2>/dev/null
    sudo mv "$CURR_DIR/$APP_NAME" .
    sudo chown -R indert:indert ./$APP_NAME
    sudo chmod -R 755 ./$APP_NAME
  fi

  if [ $RESTART_SERVER = "YES" ]; then
    pm2 start server
  fi

  echo "All done"
else
  echo "Source file not found"
fi
1 Mi Piace

@giorba mi era sfuggito questo tuo articolo, grazie della condivisione.
Interessante lo script per installare!
Chiedo ad @alessandro.ceccoli di provarlo in una delle sue macchine di test.

1 Mi Piace

Aggiungo un’informazione che poi @giorba puoi integrare nell’argomento principale.
Se l’applicazione deve avere dei parametri di installazione, per intenderci quelli che si recuperano con l’istruzione:

let parametro = app.getParameter("mio-parametro");

è possibile impostarli anche in un server self-managed scrivendoli in un file in formato JSON di nome app_params.json da posizionare nella directory apps/apps/nome-applicazione/files/private.

1 Mi Piace

Questo è molto interessante! C’è anche un metodo per avere la lista competa dei parametri, qualcosa del tipo getParametersList()?

1 Mi Piace

Probabilmente in un vicino futuro la parte dell’installazione come pwa sarà superata, ma resterà comunque un aiuto per velocizzare il processo. Io, che utilizzo in prevalenza i server self-managed sia in casa che presso i clienti, riesco a semplificare la distribuzione delle app, soprattutto perché non perdo più un passaggio, con la conseguenza di ritrovarmi app che non funzionano per una sciocchezza commessa durante l’installazione.

1 Mi Piace

@paolo.giannelli ho fatto alcuni test su una macchina ubuntu e funziona perfettamente rispettando(giustamente) i prerequisiti dichiarati.
Grazie @giorba per la condivisione.

P.S.: Confermo che è possibile installare instant-developer-platform in una cartella diversa da “/idcloud”. Per farlo è sufficiente seguire le istruzioni della guida utilizzando il nuovo percorso(cioè nel file config.json e nei vari comandi indicati per la configurazione iniziale).

2 Mi Piace

Il mio è un commento in parte off topic ma lo faccio per il piacere di condividere.

Noi non usiamo (ancora) Cloud, ma comunque per Foundation abbiamo scelto da subito l’installazione su server Linux self-managed, senza neanche provare ad usare IDManager.

Il motivo è che in azienda abbiamo alcune figure molto specializzate in quello che viene definito qui in Friuli come “mistîr uarp” (letteralmente “mestiere orbo”, ovvero “saper fare un lavoro che sembra complicatissimo ai non addetti ai lavori e che in parte appare assimillabile a magia”), ovvero “competenze davvero avanzate nella gestione di sistemi Linux”.

Nella fattispecie, riutilizzando il know-how acquisito in un progetto molto grande nell’ambito dell’Edge Cloud in cui partecipiamo, abbiamo creato un sistema di deployment che si basa sul prerequisito che presso l’infrastruttura di ogni cliente ci sia una VM Linux da noi fornita e di cui solo noi abbiamo la password di root e l’utente finale ha un accesso amministrativo limitato, tale macchina si connette tramite una SD-WAN ad una rete privata di supporto che permette a noi di offrire supporto diretto e al cliente di esporre i servizi web sull’internet pubblico tramite un sistema di proxy sicuro, senza che abbia IP statico/pubblico o modifichi il suo firewall. Grazie appunto al suddetto “mistîr uarp” siamo in grado di comunicare in modo bidirezionale con le nostre VM (nonsotante siano aperte solo in uscita, ovvero che la VM abbia semplice accesso a internet).

Per pubblicare dal cliente una app quello che facciamo è:

  1. compilare in java su Foundation
  2. da command line lanciare il comando

uploadWebapp.bat NomeWebapp NomeCliente

dove NomeWebapp è il nome della carella di Tomcat che contiene la app e NomeCliente è il nome univoco con cui individuiamo il cliente e in particolare la sua VM.

Le applciazioni oltre ad essere installate in un Tomcat dentro la nostra VM sono anche pubblicate automaticamente in https tramite proxy gestite con NGINX.

Ci piacerebbe a regime fare un Wizard di Foundation per semplificare ulteriormente la procedura di deployment. Dobbiamo ancora gestire le modifiche remote allo schema, ci stiamo lavorando, per ora usiamo inde direttamente (lanciando il DDL su localhost ma essendo connessi in realtà al DB remoto).

In estrema sintesi abbiamo cercato di fare a meno di IDManager per realizzare un sistema completamente su misura. Io sono un utente di questo sistema di deployment ma ne so davvero poco siccome non apparetngo alla schiera dei fortunati detentori della conoscenza del “mistîr uarp”, in ogni caso mi faceva piacere raccontare questa storia, magari potrebbe essere utile a qualcuno.

Ciao.

2 Mi Piace

Bella storia, anche se non uso Foundation, la tua risposta centra perfettamente lo spirito per cui ho aderito a questa community.
Parlare delle proprie esperienze, in particolare dell’uso creativo che facciamo degli strumenti di Pro Gamma, per me è di estremo interesse.