Best practice per il provisioning e la configurazione automatici di sistemi e server perimetrali e bare metal

Last reviewed 2023-02-23 UTC

Questo documento suggerisce best practice per progettare e implementare processi di provisioning e configurazione affidabili e automatizzati per i dispositivi in esecuzione ai perimetri del tuo ambiente come i seguenti:

Leggi questo documento se progetti processi di provisioning e configurazione per dispositivi Edge e IoT, oppure se vuoi saperne di più sulle best practice per il provisioning di questi tipi di dispositivi.

Questo documento fa parte di una serie di documenti che forniscono informazioni sulle architetture IoT su Google Cloud e sulla migrazione da IoT Core. Gli altri documenti di questa serie includono:

Il provisioning e la configurazione manuale di un vasto parco dispositivi è soggetto a errori umani e non vengono scalati con l'aumentare del parco dispositivi. Ad esempio, potresti dimenticare di eseguire un'attività di provisioning o configurazione critica o di fare affidamento su processi non documentati parzialmente o completamente. Processi di provisioning e configurazione completamente automatizzati e affidabili aiutano a risolvere questi problemi. Ti aiutano anche a gestire il ciclo di vita di ciascun dispositivo, dalla produzione allo smaltimento.

Terminologia

I termini seguenti sono importanti per comprendere come implementare e creare processi automatizzati di provisioning e configurazione per i tuoi dispositivi:

  • Dispositivo periferico: un dispositivo di cui esegui il deployment ai margini del tuo ambiente, in prossimità dei dati che vuoi elaborare.
  • Processo di provisioning: l'insieme di attività che devi completare per preparare un dispositivo per la configurazione.
  • Processo di configurazione: l'insieme di attività da completare per rendere un dispositivo pronto per il funzionamento in un ambiente specifico.
  • Gestione della configurazione: l'insieme di attività che esegui continuamente per gestire la configurazione dell'ambiente e dei dispositivi.
  • Immagine di base: un'immagine del firmware o del sistema operativo (OS) funzionante minimamente prodotta dalla tua azienda o prodotta da un produttore di dispositivi o sistemi operativi.
  • Immagine dorata: un'immagine immutabile del sistema operativo o del firmware che crei per i tuoi dispositivi o che prepara a partire da un'immagine di base. Le immagini Golden includono tutti i dati e le informazioni di configurazione necessari ai dispositivi per svolgere le attività assegnate. Puoi preparare varie immagini finali per svolgere diverse attività. I sinonimi di tipi di immagini dorate includono sapori, spin e archetipi.
  • Immagine argento: un'immagine del sistema operativo o del firmware che prepari per i tuoi dispositivi applicando modifiche minime a un'immagine dorata o di base. I dispositivi che eseguono un'immagine argento completano il provisioning e la configurazione al primo avvio, in base alle esigenze dei casi d'uso che devono supportare.
  • Dispositivo di origine:un dispositivo che esegue il bootstrap del tuo ambiente senza dipendenze esterne.
  • Avvio di rete: l'insieme di tecnologie che consentono a un dispositivo di ottenere il software e le eventuali informazioni di configurazione correlate dalla rete, anziché da un sistema di archiviazione collegato al dispositivo.

Best practice per i processi di provisioning e configurazione

Per impostare gli obiettivi ed evitare gli errori più comuni, applica le seguenti best practice per il provisioning e la configurazione. Ogni best practice è discussa in una sezione separata.

Automatizzare i processi di provisioning e configurazione

Durante il primo avvio o ogni volta che è necessario, i dispositivi dovrebbero essere in grado di eseguire il provisioning e la configurazione autonomamente utilizzando solo l'immagine software installata al loro interno.

Per evitare di implementare la logica necessaria durante i processi di provisioning e configurazione, puoi utilizzare strumenti che forniscono le primitive necessarie per orchestrare e implementare questi processi. Ad esempio, puoi utilizzare cloud-init e la relativa origine dati NoCloud, insieme allo scripting o a uno strumento di gestione della configurazione, come Ansible, Puppet o Chef, in esecuzione sull'host locale.

Per progettare processi di provisioning e configurazione affidabili, assicurati che tutti i passaggi e le attività eseguiti durante questi processi siano validi, possibilmente in modo automatizzato. Ad esempio, puoi utilizzare un framework di test di conformità automatizzato, come InSpec, per verificare che i processi di provisioning e configurazione funzionino come previsto.

Questa best practice consente di evitare single point of failure e la necessità di un intervento manuale quando è necessario completare il provisioning e la configurazione dei dispositivi.

Evita dispositivi per uso speciale

Quando progetti i tuoi dispositivi periferici, riduci al minimo le loro differenze in termini di finalità e specialità. Questo consiglio non significa che tutti i dispositivi periferici devono essere uguali tra loro o condividere lo stesso scopo, ma devono essere il più omogenei possibile. Ad esempio, potresti definire gli archetipi dei dispositivi in base ai tipi di carichi di lavoro che devono supportare. Poi puoi distribuire e gestire i dispositivi in base alle proprietà di questi archetipi.

Per assicurarti di seguire questa best practice, verifica di poter scegliere un dispositivo a caso tra quelli di un determinato archetipo, quindi procedi nel seguente modo:

  • Tratta il dispositivo come faresti con altri dispositivi dello stesso archetipo. Questo dimostra che hai efficienza operativa.
  • Sostituisci il dispositivo con dispositivi dello stesso archetipo senza ulteriori personalizzazioni. Questo dimostra che hai implementato correttamente questi archetipi.

Questa best practice garantisce di ridurre la varianza nel parco dispositivi, riducendo la frammentazione dell'ambiente e dei processi di provisioning e configurazione.

Utilizza dispositivi di origine per eseguire il bootstrap del tuo ambiente

Quando esegui il provisioning e la configurazione dei dispositivi, potresti incorrere in un problema di dipendenze circolari: i tuoi dispositivi hanno bisogno di un'infrastruttura di supporto per eseguire il provisioning e la configurazione autonomamente, ma l'infrastruttura non è attiva perché devi comunque eseguirne il provisioning e configurarla.

Puoi risolvere questo problema con i dispositivi di origine. I dispositivi di origine hanno uno scopo speciale temporaneo. Dopo aver completato le attività per cui è stato progettato lo scopo speciale, il dispositivo rispetta il proprio comportamento e stato all'archetipo pertinente.

Ad esempio, se utilizzi cloud-init per inizializzare automaticamente i tuoi dispositivi, potresti dover configurare un'origine dati NoCloud cloud-init nei seguenti modi:

  1. Fornisci i dati dell'origine dati NoCloud al dispositivo originale tramite un file system.
  2. Attendi che il dispositivo seed completi il proprio provisioning e configurazione con il suo scopo speciale, che prevede la fornitura dei dati dell'origine dati NoCloud ad altri dispositivi sulla rete.

    I processi di provisioning e configurazione sul dispositivo di origine attendono quindi che vengano soddisfatte le condizioni per l'eliminazione dello scopo speciale temporaneo del dispositivo di origine. Alcuni esempi di queste condizioni sono:

    • Nell'ambiente sono presenti altri dispositivi che forniscono i dati dell'origine dati NoCloud sulla rete?
    • Ci sono abbastanza nodi nel cluster?
    • Il primo backup è stato completato?
    • Il sito di ripristino di emergenza è pronto?
  3. Esegui il provisioning e la configurazione di altri dispositivi che scaricano i dati dell'origine dati NoCloud sulla rete dal dispositivo originale. Alcuni dispositivi devono essere in grado di gestire i dati dell'origine dati NoCloud attraverso la rete.

  4. I processi di provisioning e configurazione sul dispositivo di origine riprendono perché le condizioni per eliminare lo scopo speciale del dispositivo di origine vengono soddisfatte: nel parco risorse sono presenti altri dispositivi che forniscono i dati dell'origine dati NoCloud sulla rete.

  5. I processi di provisioning e configurazione sul dispositivo seed eliminano lo scopo speciale, rendendo il dispositivo di origine indistinguibile da altri dispositivi dello stesso archetipo.

Questa best practice garantisce di poter eseguire il bootstrap del tuo ambiente anche senza supportare l'infrastruttura e senza violare la best practice Evita dispositivi per scopi speciali.

Riduci al minimo lo statefulness dei dispositivi

Quando progetti i tuoi dispositivi periferici, mantieni come minimo l'archiviazione di informazioni stateful. I dispositivi periferici potrebbero avere risorse hardware limitate o essere distribuiti in ambienti difficili. Ridurre al minimo le informazioni stateful necessarie per funzionare semplifica i processi di provisioning, configurazione, backup e ripristino perché puoi trattare questi dispositivi in modo omogeneo. Se un dispositivo periferico stateless inizia a non funzionare correttamente e non è recuperabile, ad esempio, puoi scambiarlo con un altro dispositivo dello stesso archetipo con interruzioni minime o perdite di dati.

Questa best practice ti consente di evitare problemi imprevisti dovuti alla perdita di dati o a causa di processi troppo complessi. La maggior parte della complessità deriva dalla necessità di supportare un parco dispositivi eterogenei.

Crea automaticamente immagini di sistema operativo e firmware

Per evitare costose attività di provisioning e configurazione al primo avvio dei dispositivi e per risparmiare risorse, personalizza le immagini del sistema operativo e del firmware prima di renderle disponibili. Ad esempio, puoi installare le dipendenze direttamente nell'immagine anziché installarle al primo avvio di ogni dispositivo.

Quando prepari le immagini del sistema operativo e del firmware per i tuoi dispositivi, inizi da un'immagine di base. Quando personalizzi l'immagine di base, puoi:

  • Produci immagini dorate. Le immagini Golden contengono tutte le dipendenze nell'immagine, in modo che i dispositivi non debbano installarle al primo avvio. La produzione di immagini finali potrebbe essere un'attività complessa, ma consente ai dispositivi di risparmiare tempo e risorse durante il provisioning e la configurazione.
  • Produci immagini d'argento. A differenza delle immagini finali, i dispositivi che eseguono immagini argento completano tutti i processi di provisioning e configurazione durante il primo avvio. La produzione di immagini d'argento può essere meno complessa rispetto alla produzione di immagini dorate, ma i dispositivi che eseguono questa immagine impiegano più tempo e risorse durante il provisioning e la configurazione.

Puoi personalizzare le immagini del sistema operativo e del firmware nell'ambito dei processi di integrazione continua e deployment continuo (CI/CD) e rendere automaticamente disponibili per i tuoi dispositivi le immagini personalizzate dopo la convalida. I processi CI/CD che implementi con uno strumento come Cloud Build, Azioni GitHub, CI/CD GitLab o Jenkins possono eseguire la seguente sequenza di attività:

  1. Esegui una convalida automatica rispetto alle immagini personalizzate.
  2. Pubblica le immagini personalizzate in un repository in cui i tuoi dispositivi possono ottenerle.

Se il tuo ambiente CI/CD e il sistema operativo o il firmware per cui devi creare immagini utilizzano architetture hardware diverse, puoi usare strumenti come QEMU per emulare queste architetture. Ad esempio, puoi emulare l'architettura hardware della famiglia ARM su un' architettura x86_64.

Per personalizzare le immagini del sistema operativo o del firmware, devi poterle modificare e verificare le modifiche in un ambiente di test prima di installarle nei tuoi dispositivi perimetrali. Strumenti come chroot consentono di modificare virtualmente ma non modificare fisicamente la directory root prima di eseguire un comando.

Ad esempio, l'esecuzione del comando chroot /mnt/test-image apt-get install PACKAGENAME fa sì che il sistema si comporti come se /mnt/test-image fosse la directory radice del sistema operativo o l'immagine del firmware anziché / e installi PACKAGENAME in quella directory.

Questa best practice ti consente di personalizzare le immagini del sistema operativo e del firmware prima di renderle disponibili per i tuoi dispositivi.

Orchestra in modo affidabile i carichi di lavoro in esecuzione sui tuoi dispositivi

Se i tuoi dispositivi supportano carichi di lavoro eterogenei, puoi utilizzare i seguenti strumenti per orchestrarli e gestirne il ciclo di vita:

  • Un sistema di orchestrazione dei carichi di lavoro: l'utilizzo di un sistema di orchestrazione dei carichi di lavoro come Kubernetes è adatto a carichi di lavoro con requisiti di orchestrazione o gestione del ciclo di vita complessi. Inoltre, questi sistemi sono adatti a carichi di lavoro che comprendono più componenti. In entrambi i casi, significa che non devi implementare autonomamente l'orchestrazione e la logica di gestione del ciclo di vita dei carichi di lavoro. Se i tuoi dispositivi sono limitati dalle risorse, puoi installare una distribuzione Kubernetes leggera che richiede meno risorse rispetto a quella canonica, ad esempio MicroK8s, K3s o GKE su Bare Metal installato con il profilo perimetrale.
  • Un sistema init: l'uso di un sistema init, come systemd, è adatto per carichi di lavoro con le seguenti caratteristiche:

    • Semplici requisiti di orchestrazione
    • Mancanza di risorse per supportare un sistema di orchestrazione dei carichi di lavoro
    • Carichi di lavoro che non possono essere inseriti nei container

Dopo aver creato il sistema per orchestrare i carichi di lavoro, puoi utilizzarlo anche per eseguire attività che fanno parte dei processi di provisioning e configurazione. Se, ad esempio, devi eseguire uno strumento di gestione della configurazione nell'ambito dei processi di provisioning e configurazione, puoi utilizzare il sistema di orchestrazione dei carichi di lavoro come faresti con qualsiasi altro carico di lavoro. Per un esempio di questa metodologia, consulta Esegui il bootstrap automatico dei nodi GKE con DaemonSet. L'articolo descrive come utilizzare Kubernetes per eseguire attività di provisioning e configurazione con e senza privilegi sui nodi del cluster.

Questa best practice aiuta a garantire l'orchestrazione dei carichi di lavoro in esecuzione sui tuoi dispositivi.

Verificare, autenticare e connettere i dispositivi

Quando devi verificare se i tuoi dispositivi devono connettersi a sistemi esterni, ad esempio altri dispositivi o a un backend, prendi in considerazione i consigli riportati nelle sottosezioni seguenti.

Pratiche di connessione da applicare

  • Autenticare le altre parti che effettuano richieste di informazioni prima di scambiare qualsiasi informazione.
  • Verifica che le informazioni trasmesse non attraversano canali imprevisti.
  • Affidati ad ambienti di esecuzione attendibili per gestire secret come chiavi di crittografia, chiavi di autenticazione e password.
  • Verifica l'integrità e l'autenticità di qualsiasi immagine del sistema operativo o del firmware prima dell'uso.
  • Verificare la validità, l'integrità e l'autenticità di qualsiasi configurazione fornita dall'utente.
  • Limita la superficie di attacco non installando software non necessario e rimuovendo quelli già esistenti sui tuoi dispositivi.
  • Limita l'utilizzo di operazioni e account con privilegi.
  • Verifica l'integrità della cover del dispositivo se questa deve resistere alla manipolazione e alle manomissioni fisica.

Pratiche di connessione da evitare

  • Non trasmettere informazioni sensibili su canali non criptati.
  • Evita di lasciare aperto l'accesso privilegiato, ad esempio:
    • Porte seriali e console seriali virtuali o fisiche con privilegi elevati, anche se sono accessibili solo se qualcuno manomette fisicamente il dispositivo.
    • Endpoint che rispondono alle richieste provenienti dalla rete e che possono eseguire operazioni con privilegi.
  • Non fare affidamento su credenziali impostate come hardcoded nel sistema, nella configurazione o nel codice sorgente delle immagini del sistema operativo o del firmware.
  • Non rivelare alcuna informazione che possa aiutare un utente malintenzionato a raccogliere informazioni per ottenere privilegi elevati. Ad esempio, dovresti criptare i dati sui tuoi dispositivi e disattivare i sistemi di tracciamento e logging non necessari sui dispositivi di produzione.
  • Non consentire agli utenti e ai carichi di lavoro di eseguire codice arbitrario.

Questa best practice ti aiuta a:

  • Progetta canali di comunicazione sicuri per i tuoi dispositivi.
  • Evita potenziali backdoor che aggirano il perimetro di sicurezza dei tuoi dispositivi.
  • Verifica che i tuoi dispositivi non mostrino interfacce non autorizzate che un malintenzionato potrebbe sfruttare.

Monitorare i dispositivi

La raccolta di informazioni sullo stato dei dispositivi senza interventi manuali è essenziale per l'affidabilità dell'ambiente. Assicurati che i tuoi dispositivi registrino automaticamente tutti i dati necessari. Ci sono due motivi principali per raccogliere e monitorare i dati. Il primo motivo per raccogliere e monitorare i dati è assicurarti che i dispositivi funzionino come previsto. Il secondo motivo per raccogliere e monitorare i dati è individuare in modo proattivo i problemi ed eseguire la manutenzione preventiva. Ad esempio, puoi raccogliere metriche ed eventi di monitoraggio con Cloud Monitoring.

Per aiutarti a esaminare e risolvere i problemi, ti consigliamo di progettare e implementare processi per raccogliere dati diagnostici ad alta risoluzione, come informazioni dettagliate di monitoraggio, tracciamento e debug, oltre ai processi che monitorano i dispositivi durante il loro normale funzionamento. La raccolta di dati diagnostici ad alta risoluzione e il trasferimento tramite una rete può essere costosa in termini di risorse dei dispositivi, ad esempio calcolo, archiviazione dei dati e energia elettrica. Per questo motivo, ti consigliamo di consentire ai processi di raccogliere dati diagnostici ad alta risoluzione solo quando necessario e solo per i dispositivi che richiedono ulteriori indagini. Ad esempio, se uno dei tuoi dispositivi non funziona come previsto e i dati di monitoraggio regolari segnalati dal dispositivo non sono sufficienti per diagnosticare in modo approfondito il problema, puoi attivare la raccolta dei dati ad alta risoluzione per quel dispositivo in modo che riporti più informazioni che possono aiutarti a indagare sulle cause del problema.

Questa best practice garantisce di non lasciare i dispositivi in uno stato sconosciuto e di disporre di dati sufficienti per determinare se e come le prestazioni dei tuoi dispositivi.

Supporta l'avvio automatico e gli upgrade

Quando progetti i processi di provisioning e configurazione, assicurati che i tuoi dispositivi possano essere avviati in modo automatico e di disporre dell'infrastruttura necessaria. L'implementazione di un meccanismo di avvio automatico che supporta sia il primo avvio sia la distribuzione di upgrade over-the-air, aumenta la manutenibilità della tua infrastruttura. L'utilizzo dell'avvio automatico ti evita di dover accedere manualmente a ogni dispositivo durante l'avvio o l'upgrade. Partecipare manualmente a un ampio parco dispositivi è soggetto a errori perché gli operatori potrebbero sbagliare o eseguire azioni errate oppure potrebbero non avere tempo sufficiente per eseguire le azioni richieste per ogni dispositivo del parco risorse.

Inoltre, non è necessario preparare in anticipo ciascun dispositivo per avviare l'immagine del firmware o del sistema operativo corretto. Ad esempio, puoi rilasciare una nuova versione di un sistema operativo o di un'immagine firmware e rendere disponibile tale versione tra le opzioni che i tuoi dispositivi possono scegliere quando ricevono le istruzioni di avvio dalla rete.

Questa best practice ti aiuta a garantire che i tuoi dispositivi possano eseguire avvii ed upgrade automatici e inattivi.

Progetta e implementa processi resilienti

Anche con processi di configurazione e provisioning completamente automatizzati, possono verificarsi errori che impediscono il corretto completamento di tali processi, lasciando i dispositivi in uno stato incoerente. Assicurati che i tuoi dispositivi siano in grado di ripristinare questi errori implementando meccanismi di ripetizione e fallback. Quando un dispositivo non riesce a completare un'attività che fa parte dei processi di provisioning e configurazione, ad esempio, dovrebbe tentare automaticamente di recuperare l'errore. Dopo che il dispositivo si è ripreso dall'errore o è tornato a uno stato di lavoro, può riprendere i processi in esecuzione dal momento in cui i processi non sono riusciti.

Questa best practice consente di progettare e implementare processi resilienti di provisioning e configurazione.

Supportare l'intero ciclo di vita dei tuoi dispositivi

Quando progetti i processi di provisioning e configurazione, assicurati che siano in grado di gestire l'intero ciclo di vita del dispositivo. Una gestione efficace dei cicli di vita dei dispositivi include la pianificazione della terminazione e dello smaltimento, anche se i dispositivi dovrebbero funzionare per un periodo di tempo relativamente lungo.

Se non gestisci il ciclo di vita dei dispositivi, potrebbero verificarsi problemi, come i seguenti:

  • Costi elevati sostenuti: l'introduzione del supporto per la gestione del ciclo di vita dopo l'implementazione dei processi di provisioning e configurazione può comportare un aumento dei costi. Pianificando questo supporto all'inizio della progettazione, potresti ridurre questi costi. Se i tuoi processi di provisioning e configurazione non supportano l'intero ciclo di vita dei dispositivi, ad esempio, potresti dover intervenire manualmente su ciascun dispositivo per gestire correttamente ogni fase del ciclo di vita. L'intervento manuale può essere costoso e spesso non è scalabile.
  • Maggiore rigidità: il mancato supporto della gestione del ciclo di vita potrebbe portare alla fine all'impossibilità di aggiornare o gestire i dispositivi. Ad esempio, se manca un meccanismo per spegnere i dispositivi in modo sicuro ed efficiente, potrebbe essere difficile gestire la fine del ciclo di vita e il completo smaltimento.

Passaggi successivi