Vai al contenuto

Installazione dei Componenti

Nota sull'ambiente di Installazione

I suggerimenti per l'installazione dei componenti che costituiscono i prerequisiti del Sistema Data Analytics vengono descritti con comandi e sintassi validi per l'utilizzo da un terminale Linux con shell BASH.

In particolare, si utilizzeranno i comandi kubectl ed helm senza esplicitare il parametro --kubeconfig, assumendo quindi che il kubeconfig file del cluster sia puntato dalla variabile d'ambiente $KUBECONFIG (o che una sua copia sia salvata nel file $HOME/.kube/config).

Inoltre, si assume che l'host dal cui terminale si lanciano tali comandi possa raggiungere il cluster stesso all'URL del server contenuto nel kubeconfig.

Su tale host dovranno essere disponibili anche i seguenti programmi:

  • jq
  • yq
  • base64
  • curl
  • wget
  • xxd

Le versioni utilizzate per client e server sono:

  • kubectl v1.33.5
  • helm v3.19.0
  • kubernetes v1.33.5

La distribuzione di Kubernetes utilizzata come riferimento è la K3s v1.33.5+k3s1 (https://k3s-io.github.io/).

Premessa

Per una specifica installazione del Sistema Data Analytics bisognerà utilizzare diverse risorse (template, manifest, dump, directory) che andranno personalizzate ed aggiornate al momento dell'installazione stessa.

Inoltre, in un apposito file (p.es. .env.sh) andranno preimpostate alcune variabili d'ambiente finalizzate al supporto ed alla semplificazione della procedura di installazione. Per rendere disponibili tali variabili nel terminale con cui si eseguiranno i comandi, sarà necessario includerlo nella shell con il comando source.

I componenti sono installati usando differenti metodologie (helm chart, operator, manifest, ...) ed in genere utilizzando per ognuno alcuni parametri specifici tipicamente strutturati come segue:

HELM_URL                                URL dei charts
HELM_REPO                               Nome dello specifico repo
RELEASE_NAME                            Nome della specifica applicazione
HELM_VER                                Versione del chart per la specifica applicazione
NAMESPACE                               Namespace in cui installare i componenti il chart
VALUES_FILE_NAME                        File dei values da usare
HELM_CHART="$HELM_REPO/$RELEASE_NAME"   Valore calcolato

Note

  • È opportuno prendere visione dell'output prodotto dall'esecuzione del comando helm install in quanto - oltre a fornire l'esito dell'operazione stessa - può contenere informazioni utili a supporto dell'uso e/o del test dei componenti deployati.

  • In generale è sempre opportuno verificare il completamento ed il buon esito di ogni passaggio effettuato (anche di quelli che implicano istruzioni diverse da helm) prima di procedere con il successivo; a tale scopo si possono usare comandi tipo kubectl -n $NAMESPACE get all e/o kubectl get pod -A o altri simili.

Esposizione dei Servizi

Le interfacce utente che necessitano di essere accedute al di fuori del cluster sono configurate mediante servizi Kubernetes in modalità NodePort al fine di consentirne l'esposizione attraverso un Reverse Proxy (esterno al cluster stesso) che funziona eventualmente anche da bilanciatore di carico.

A solo scopo esemplificativo, si riporta qui di seguito lo snippet di una configurazione minimale basata su server Apache:

<VirtualHost <PUBLIC_IP>:443>
  ServerName <SERVICE_NAME>.<TENANT_DOMAIN>

  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/<SERVICE_NAME_CERT>/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/<SERVICE_NAME_CERT>/privkey.pem

  Header set Content-Security-Policy "..."

  RequestHeader set ...
  ProxyRequests Off
  ProxyPreserveHost on

  <Proxy balancer://<SERVICE_NAME>>
    BalancerMember http://<NODE_1_IP>:<NODEPORT> route=u1
    ...
    BalancerMember http://<NODE_X_IP>:<NODEPORT> route=u<X>
  </Proxy>

  ProxyPass / balancer://<SERVICE_NAME>/
  ProxyPassReverse / balancer://<SERVICE_NAME>/
</VirtualHost>

Tale approccio non è vincolante per il funzionamento della piattaforma e l'amministratore di sistema può valutare autonomamente le alternative preferite (p.es. uso di Traefik e di load balancer implementati all'interno del cluster stesso).

Indipendente dall'approccio scelto, è comunque necessario registrare dei nomi a dominio (cfr. Tabella 2) e dotarsi di certificati TLS al fine di accedere i servizi in HTTPS.