Fase 1: Ottenere una chiave API per distribuire l'infrastruttura sul proprio account

Seguite i passi di questo documento per creare una chiave API e annotatela per il passo 2.

Passo 2: clonare il repo e fare un cd nella directory di Terraform

git clone https://github.com/IBM-Cloud/truck-tracker.git
cd truck-tracker/terraform

Creare un documento chiamato terraform.tfvars con i seguenti campi:

ibmcloud_api_key = "<YOUR_API_KEY_FROM_STEP_1>"
region = "eu-gb"
redis_password  = "<MAKE_UP_A_PASSWORD>"

Il documento terraform.tfvars contiene variabili che si desidera mantenere segrete, in modo che siano ignorate dal repository GitHub.

Fase 3: creare l'infrastruttura

In parole povere: eseguire lo script Terraform:

terraform init
terraform apply --auto-approve

La cartella Terraform contiene una serie di semplici script:

• main.tf tells Terraform to use the IBM Cloud.
• variables.tf contains the variable definitions whose values will be populated from terraform.tfvars.
• cloudant.tf creates a standard Cloudant DB and some credentials that we will use later to access it.
• redis.tf creates the Redis instance and some credentials that we will use later to access it.
• eventstreams.tf creates the Event Streams instance and some credentials that we will use later to access it.
• registry.tf creates the Container Registry that will hold your container images.
• iam.tf creates the access key that is needed to interact with the Container Registry.
• vpc.tf creates the VPC (Virtual Private Cloud) infrastructure that will be needed to deploy an OpenShift cluster. Questo include una VPC, sottoreti e gateway pubblici in tre diverse zone di disponibilità.
• cos.tf create a single Cloud Object Storage instance that is needed by OpenShift to manage the cluster.
• openshift.tf creates a cluster of virtual machines inside your VPC, where you will deploy your applications.

Ci vorranno alcuni minuti perché i database e le altre risorse siano pronti, ma ora si dovrebbero avere alcune risorse VPC, un cluster di macchine virtuali, un'istanza IBM Cloud® Databases for Redis, un database Cloudant e un'istanza Event Streams nel proprio account, oltre a uno spazio dei nomi del Container Registry per le immagini dei container. È possibile verificare visitando la sezione Risorse del proprio account IBM Cloud.

Passo 4: Creare le immagini dei container e distribuirle su OpenShift

A questo punto, tutta l'infrastruttura è pronta a ricevere i dati. Ora dobbiamo costruire e distribuire i diversi moduli che produrranno e consumeranno i dati, nonché l'applicazione che visualizzerà la posizione del camion su una mappa.

Eseguite lo script di compilazione, ma prima di farlo, avete effettuato l'accesso a IBM Cloud CLI e a Docker?

Entrate nella radice del progetto e digitate quanto segue:

./build.sh

Fase 5: Osservare i camion

Alla fine dello script verrà emesso un URL, qualcosa come https:// some.thing.eu-gb.appdomain.cloud.

Se visitate l'URL generato, dovreste essere in grado di vedere una mappa degli Stati Uniti e, dopo qualche secondo, diversi marcatori sulla mappa che rappresentano i vostri camion:

Se si ingrandisce uno di questi indicatori, lo si vedrà muoversi lungo la strada. In qualità di gestore della flotta, ora sapete dove si trovano tutti i vostri camion.

Lo script build.sh

Lo script build.sh esegue una serie di operazioni:

1. Crea un'immagine docker per ciascuno dei servizi necessari. Il produttore, i consumatori e l'applicazione web si trovano tutti in cartelle diverse. Ogni cartella ha il suo semplice file Dockerfile che viene utilizzato dallo script per creare un'immagine del contenitore, che viene poi caricata nel Container Registry IBM.
2. Crea un gruppo di segreti kubernetes con tutte le credenziali necessarie per accedere ai diversi servizi IBMIBM Cloudant, Redis e Event Streams).
3. Distribuisce il codice dell'applicazione (e i segreti) nel cluster Red Hat OpenShift on IBM Cloud usando le istruzioni contenute nello deployment.yml script.

Lo script deployment.yml

Questo script indica a Openshift cosa distribuire alle macchine del cluster Openshift. Nel nostro caso si tratta di:

1. Produttori di dati trucktrackerproducer*).
2. Consumatori di dati trucktrackerredisconsumer e trucktrackercloudantconsumer)
3. Applicazione web trucktrackerweb)

In tutti i casi, estraggono un'immagine dal registro dei container e ricevono alcune variabili d'ambiente con le credenziali necessarie per accedere ai servizi esterni.

Il sistema Truck Tracker

Il sistema Truck Tracker è un insieme di semplici script Node.js che utilizzano quattro pacchetti principali:

1. @ibm-cloud/cloudant per connettersi a IBM Cloudant e leggere/scrivere dati.
2. Redis per connettersi all'istanza di Redis e leggere/scrivere i dati.
3. kafkajs per connettersi all'istanza di Event Streams.
4. Express per abilitare un semplice server web che permetta l'interazione con i dati.

Ci sono cinque file principali:

1. server.js: This runs the web server and communicates with Redis. Riceve chiamate regolari dal front-end al percorso /data. Si connette a Redis, scarica un oggetto con l'ID e la posizione di ogni camion e lo restituisce al front-end.
2. index.html: This is the one and only page of the front end application. Quando viene caricata, viene mostrata una mappa degli Stati Uniti dal fantastico servizio Open Street Map. Quindi esegue un ciclo di cinque secondi in cui effettua una richiesta HTTP al backend server.js), recupera tutti i camion e le loro posizioni e li esamina per tracciare la loro ultima posizione sulla mappa. Ogni camion ha un indicatore sulla mappa la cui latitudine/longitudine viene aggiornata a ogni ciclo.
3. producer.js: This takes in a location file and a truck_id from the script invocation and then loops through all the data points in the location file. Ogni punto dati viene trasformato in un messaggio con l'ID del carrello e la latitudine/longhezza e inviato una volta al secondo agli Event Streams. Per un maggiore divertimento, sceglie un punto di partenza casuale lungo il percorso e torna indietro quando raggiunge la fine del file di localizzazione.
4. cloudantConsumer.js: This script creates a trucktracker database in Cloudant if it does not already exist and then polls Event Streams at regular intervals for more data. Quando i dati arrivano, vengono scritti in blocco su Cloudant.
5. redisConsumer.js: This script polls Event Streams at regular intervals for data. Quando i dati arrivano, vengono scritti in un "hash" Redis dove la chiave dell'hash è l'ID del carrello e il valore è il dato del carrello (lat/long). Questa disposizione di hash consente a tutti i dati del carrello di essere estratti dallo script server.js in un'unica soluzione. Il bello è che se per qualche motivo uno dei consumatori si blocca, riprenderà da dove si era interrotto senza perdere alcun dato, perché Event Streams conosce l'ultimo punto di dati che ha servito a ciascun consumatore. Disaccoppiare in questo modo i sistemi che producono dati da quelli che li consumano è una buona pratica di progettazione che aumenta la resilienza e la tolleranza ai guasti.

Riepilogo

In questa esercitazione, abbiamo combinato una serie di servizi IBM per modellare un modello IoT realistico in cui i dispositivi abilitati a Internet sui camion producono dati che vengono consumati da varie applicazioni per scopi diversi.

Grazie alla natura gestita di tutti questi servizi, come sviluppatori di applicazioni potete concentrarvi sulla soluzione dei vostri problemi aziendali e lasciare a noi il compito di gestire l'infrastruttura al posto vostro, risparmiando così potenzialmente mesi di lavoro su attività non essenziali come il provisioning dei server, la distribuzione del software, le patch, la sicurezza e altro.

Se avete seguito questa esercitazione, ricordatevi di de-provisionare l'infrastruttura per non incorrere più in addebiti. Sul terminale, procedere come segue:

cd terraform/
terraform destroy

Se volete fare il passo successivo nel vostro percorso di sviluppatori, date un'occhiata alle nostre offerte di prova.