Integrazione del servizio Ubuntu Snapshot negli strumenti di gestione e aggiornamento dei sistemi

 

In un blog precedente abbiamo annunciato il nostro nuovo servizio snapshot e come Microsoft Azure lo stava utilizzando per gli aggiornamenti. Di recente abbiamo pubblicato informazioni per aiutare le persone a utilizzare il servizio oltre a Microsoft Azure.

Oggi vorrei mostrare un esempio semplificato di come integrare il servizio snapshot negli strumenti di gestione dei sistemi. Ciò può consentire agli utenti di controllare il rollout degli aggiornamenti in una flotta Ubuntu e migliorare l'esperienza di aggiornamento per gli utenti. L'obiettivo è ispirare coloro che creano strumenti di gestione dei sistemi, in particolare strumenti multi-OS, a esaminare il servizio snapshot di Ubuntu.

Se sei un utente finale o un'azienda che desidera utilizzare gli snapshot, dai un'occhiata a Landscape . Questo è lo strumento di gestione dei sistemi consigliato da Canonical e ha recentemente aggiunto il supporto per il servizio snapshot .

Una versione video di questo post del blog è disponibile qui:

Panoramica video dell'integrazione del servizio snapshot di Ubuntu negli strumenti di gestione dei sistemi

Utilizzo del servizio snapshot

Ad esempio, su un sistema Ubuntu 24.04 (Noble) pronto all'uso, puoi passare un argomento snapshot a diversi aptcomandi e aptquesto agirà come se avessi eseguito quei comandi in quella data e ora (in qualsiasi momento dopo il 1° marzo 2023):

apt update --snapshot 20240423T230000Z
apt policy hello -S 20240423T230000Z
apt install hello --snapshot 20240423T230000Z

Questi comandi dovrebbero funzionare anche per Ubuntu sui nostri partner cloud pubblici (AWS, Azure, GCP, Oracle o IBM Cloud).

Devi assicurarti che l'indice sia aggiornato prima di eseguire quegli altri aptcomandi (nota quanto sopra apt updatecon l' --snapshotargomento prima degli altri comandi). C'è un nuovo aptcomando che rende tutto un po' più semplice, consentendoti di aggiornare i tuoi indici e poi di installarli in un unico comando:

apt remove hello
apt install hello --update --snapshot 20240423T230000Z

Per una guida più dettagliata su come usare il servizio, consulta la documentazione . Gli snapshot funzionano anche su versioni precedenti di Ubuntu con configurazione aggiuntiva. Ci sono diverse applicazioni utili di questo, tra cui la riproducibilità, il debug dei problemi dei clienti e simili.

Integrazione del servizio snapshot nella gestione degli aggiornamenti

Abbiamo scritto una serie di blog precedenti su come bilanciare sicurezza e stabilità negli aggiornamenti di Ubuntu. Nella Parte 3 di quella serie, abbiamo parlato di diversi modi per creare uno "snapshot" point-in-time degli aggiornamenti. Questa può essere una tecnica utile quando si aggiornano più istanze. Ubuntu adotta una serie di misure per ridurre il rischio di regressioni negli aggiornamenti di sicurezza. C'è sempre la possibilità, tuttavia, che un aggiornamento abbia una conseguenza negativa nel tuo ambiente specifico.

L'utilizzo di snapshot consente un set coerente di aggiornamenti che puoi testare e spostare progressivamente nei tuoi ambienti di produzione. Ciò potrebbe limitare il "raggio di esplosione" di eventuali effetti negativi di un aggiornamento, forse a un'istanza nel tuo set ad alta disponibilità anziché a tutte e tre. Qualsiasi implementazione progressiva di aggiornamenti di sicurezza significa che le macchine alla fine dell'implementazione non sono patchate finché non è stata completata (come spiegato più avanti).

Dimostrazione di un rollout di snapshot con istanze di esempio

Possiamo dimostrare come uno strumento di gestione o aggiornamento dei sistemi potrebbe integrare il servizio snapshot eseguendo manualmente i comandi. Possiamo farlo su quattro istanze per simulare diversi livelli di rischio, domini di disponibilità o aggiornamento, regioni o simili. Ognuna di queste istanze demo rappresenta un set arbitrariamente ampio di istanze in quel dominio di aggiornamento o livello di rischio.

Userò istanze 24.04 appena lanciate. Gli snapshot funzionano su versioni precedenti di Ubuntu, ma richiedono passaggi aggiuntivi (descritti in dettaglio nella documentazione ). Pubblichiamo regolarmente nuove versioni delle nostre immagini sui cloud pubblici che incorporano correzioni di sicurezza. Ciò significa che se usassi un'immagine aggiornata, non avrebbe molti aggiornamenti di sicurezza. Pertanto specificheremo una vecchia build dell'immagine, in modo da avere più aggiornamenti disponibili.

Possiamo vedere quando è stata creata l'immagine in build.info:

$ cat /etc/cloud/build.info
build_name: server
serial: 20240423

Il “seriale” ci mostra che questa immagine è stata creata il 23 aprile 2024.

Prevenire gli aggiornamenti incontrollati

Di default, impostiamo le istanze di Ubuntu in modo che si aggiornino una volta al giorno con gli aggiornamenti di sicurezza tramite unattended-upgrades. Possiamo impedire a questi sistemi di aggiornarsi automaticamente impostando uno snapshot che corrisponda alla data di build dell'immagine. In questo caso, possiamo impostare tutti i sistemi in modo che utilizzino lo snapshot dell'archivio così com'era il 23 aprile 2024 alle 23:00 UTC. Ciò significa che nessuno dei sistemi dovrebbe vedere alcun aggiornamento rilasciato dopo quella data e ora.

echo 'APT::Snapshot "20240423T230000Z";' | sudo tee /etc/apt/apt.conf.d/50snapshot

Ora, nessun normale comando apt dovrebbe installare nulla di nuovo, perché le istanze vedono l'archivio così com'era il 23 aprile 2024.

$ sudo apt update
[...]
All packages are up to date.

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

unattended-upgradesinoltre non installerà nulla perché, ancora una volta, vede l'archivio così com'era il 23 aprile:

$ sudo unattended-upgrade -d
[...]
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
                          	 
fetch.run() result: 0
Packages blacklist due to conffile prompts: []
No packages found that can be upgraded unattended and no pending auto-removals

Creazione di un set di aggiornamento

Ora vogliamo iniziare a distribuire gli aggiornamenti in tutta la tenuta. Iniziamo scegliendo un ID snapshot, che sarà probabilmente la data e l'ora in cui iniziamo il processo. Useremo 20240617T120000Z, ovvero le 12:00 UTC del 17 giugno 2024. Il nostro primo "set di aggiornamenti" è quindi costituito dagli aggiornamenti tra la data di build dell'immagine e questo snapshot del 17 giugno 2024.

Inizieremo con questa prima istanza, che potrebbe essere il nostro ambiente di sviluppo o di staging. Per prima cosa eseguiamo il comando eseguito prima, ma con l'ID snapshot del 17 giugno:

echo 'APT::Snapshot "20240617T120000Z";' | sudo tee /etc/apt/apt.conf.d/50snapshot

Ora possiamo aggiornare gli indici dei nostri pacchetti e l'istanza vede gli aggiornamenti disponibili:

$ sudo apt update
[...]
80 packages can be upgraded. Run 'apt list --upgradable' to see them.

Dopo aver impostato lo snapshot, possiamo usare tutti i normali comandi apt per aggiornare i nostri pacchetti a quello snapshot, oppure lasciarlo unattended-upgradeseseguire e aggiornerà solo gli aggiornamenti di sicurezza (o qualsiasi altra cosa abbiamo impostato per unattended-upgradesfare).

Le altre istanze non installeranno nessuno di questi aggiornamenti, perché le abbiamo impostate per usare il vecchio snapshot. Ciò significa che possiamo testare le istanze aggiornate e verificare che tutto sembri funzionare correttamente. Se ci sono problemi, possiamo mettere in pausa il rollout e risolverli prima di distribuire l'aggiornamento in modo più ampio.

Stiamo lanciando il nostro set di aggiornamenti

Supponendo che tutto sembri a posto nel nostro ambiente di sviluppo/test, possiamo eseguire il roll degli aggiornamenti al livello successivo. Utilizziamo il processo sopra per impostare il gruppo successivo sullo stesso snapshot che abbiamo appena convalidato. Forse si tratta di server interni o solo di istanze in una zona di disponibilità di configurazioni ad alta disponibilità.

Forse lasciamo quindi che gli aggiornamenti vengano eseguiti con carichi di lavoro di produzione per un giorno. Quindi possiamo passare al gruppo successivo e ripetere il processo, impostando di nuovo lo snapshot sullo stesso ID. E così via, attraverso ciascuno degli anelli o livelli di rischio nel nostro piano di distribuzione.

A questo punto del rollout potrebbe essere passata una settimana, ma continueremo a usare lo snapshot di mezzogiorno del 17 giugno. Questo perché abbiamo convalidato quel set di aggiornamenti nei test e nei precedenti anelli di distribuzione. Se dovessimo riscontrare problemi durante il rollout degli aggiornamenti, possiamo sospendere il rollout. Questo ci dà il tempo di risolvere i problemi (tenendo sempre a mente le implicazioni di sicurezza del ritardo degli aggiornamenti).

Questi rollout potrebbero anche sovrapporsi. Se il team di sicurezza di Ubuntu rilascia un nuovo aggiornamento, possiamo dare il via a un nuovo aggiornamento. Possiamo creare un nuovo set di aggiornamenti basato su un ID snapshot che include quell'aggiornamento. Quindi possiamo convalidarlo nei test e nei livelli iniziali mentre il set di aggiornamenti precedente viene distribuito.

Equilibrio tra sicurezza e stabilità

Come abbiamo accennato in alcuni dei nostri contenuti precedenti , dovresti mantenere il rollout dell'aggiornamento il più breve possibile. La tua proprietà avrà istanze non protette per tutto il tempo in cui stai distribuendo gli aggiornamenti di sicurezza. Per impostazione predefinita, impostiamo le istanze del server Ubuntu per installare gli aggiornamenti di sicurezza ogni giorno. Devi bilanciare qualsiasi estensione di questo con l'aumento del rischio di sicurezza. Un approccio è quello di controllare la gravità di eventuali vulnerabilità non corrette, ad esempio nei nostri feed di sicurezza . Quindi gli utenti potrebbero accelerare i rollout per affrontare vulnerabilità di elevata gravità. Se stai creando un'interfaccia per gli utenti finali, esporre queste informazioni consente loro di fare scelte più consapevoli.

Le diverse organizzazioni devono bilanciare stabilità e sicurezza in modi diversi. Gli snapshot sono un altro modo in cui diamo agli utenti di Ubuntu più opzioni su come raggiungere tale equilibrio. Distribuendo set di aggiornamenti progressivamente tra i livelli di rischio, è possibile bilanciare la sicurezza con qualsiasi potenziale interruzione.

fonte: https://ubuntu.com/blog/integrating-the-ubuntu-snapshot-service-into-systems-management-and-update-tools