Gestione della configurazione: topologia basata su push contro pull

I sistemi di gestione della configurazione (CM) più consolidati come Puppet e Chef utilizzano un approccio basato su pull: i client eseguono periodicamente il polling di un master centralizzato per gli aggiornamenti. Alcuni di essi offrono anche un approccio senza master (quindi basato su push), ma affermano che non è "per la produzione" (Saltstack) o "meno scalabile" (Puppet). L'unico sistema che conosco è basato su push fin dall'inizio è il secondo classificato Ansible.

Qual è il vantaggio specifico della scalabilità di un sistema basato su pull? Perché è presumibilmente più facile aggiungere più pull-master che push-agent?

Ad esempio, agiletesting.blogspot.nl scrive:

in un sistema "pull", i client contattano il server indipendentemente l'uno dall'altro, quindi il sistema nel suo insieme è più scalabile di un sistema "push"

D'altra parte, Rackspace dimostra di essere in grado di gestire sistemi 15K con un modello push-based.

infastructures.org scrive:

Giuriamo con una metodologia pull per mantenere le infrastrutture, usando uno strumento come SUP, CVSup, un server rsync o cfengine. Invece di inviare le modifiche ai client, ogni singola macchina client deve essere responsabile del polling del server gold all'avvio e periodicamente in seguito, per mantenere il proprio livello di giri. Prima di adottare questo punto di vista, abbiamo sviluppato ampi script basati su push basati su ssh, rsh, rcp e rdist. Il problema che abbiamo riscontrato con i comandi r (o ssh) è stato questo: quando esegui uno script basato su r-command per inviare una modifica ai tuoi computer di destinazione, le probabilità sono che se hai più di 30 host di destinazione uno di loro essere giù in qualsiasi momento. Mantenere l'elenco delle macchine commissionate diventa un incubo. Nel corso della scrittura del codice per correggere ciò, si finirà con un elaborato codice wrapper per gestire: timeout da host morti; registrazione e riprovare host morti; biforcando ed eseguendo lavori paralleli per cercare di colpire molti host in un ragionevole lasso di tempo; e infine rilevare e prevenire il caso di utilizzare tutti i socket TCP disponibili sul computer di origine con tutte le sessioni rsh in uscita. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. biforcando ed eseguendo lavori paralleli per cercare di colpire molti host in un ragionevole lasso di tempo; e infine rilevare e prevenire il caso di utilizzare tutti i socket TCP disponibili sul computer di origine con tutte le sessioni rsh in uscita. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. biforcando ed eseguendo lavori paralleli per cercare di colpire molti host in un ragionevole lasso di tempo; e infine rilevare e prevenire il caso di utilizzare tutti i socket TCP disponibili sul computer di origine con tutte le sessioni rsh in uscita. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. e infine rilevare e prevenire il caso di utilizzare tutti i socket TCP disponibili sul computer di origine con tutte le sessioni rsh in uscita. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. e infine rilevare e prevenire il caso di utilizzare tutti i socket TCP disponibili sul computer di origine con tutte le sessioni rsh in uscita. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, oltre a ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. Quindi hai ancora il problema di ottenere tutto ciò che hai appena fatto nelle immagini di installazione per tutti i nuovi host da installare in futuro, così come ripeterlo per tutti gli host che muoiono e devono essere ricostruiti domani. Dopo il problema che abbiamo riscontrato per implementare la replica basata su r-command, abbiamo scoperto che non ne valeva la pena. Non prevediamo di gestire nuovamente un'infrastruttura con r-command o con qualsiasi altro meccanismo push. Non si adattano così come i metodi basati su pull. o con qualsiasi altro meccanismo push per quella materia. Non si adattano così come i metodi basati su pull. o con qualsiasi altro meccanismo push per quella materia. Non si adattano così come i metodi basati su pull.

Non è un problema di implementazione invece che architettonico? Perché è più difficile scrivere un client push threaded rispetto a un server pull thread?

Il problema con i sistemi basati su push è che è necessario disporre di un modello completo dell'intera architettura sul nodo push centrale. Non puoi spingere verso una macchina che non conosci.

Ovviamente può funzionare, ma ci vuole molto lavoro per mantenerlo sincronizzato.

Usando cose come Mcollective, puoi convertire Puppet e altri CM in un sistema basato su push. In generale, è banale convertire un sistema pull in uno push, ma non è sempre semplice andare dall'altra parte.

C'è anche la questione della politica organizzativa. Un sistema basato su push mette tutte le mani di controllo degli amministratori centrali. In questo modo può essere molto difficile gestire la complessità. Penso che il problema del ridimensionamento sia un'aringa rossa, entrambi gli approcci si ridimensionano se si guarda solo il numero di client. Per molti versi è più facile ridimensionare la spinta. Tuttavia, la configurazione dinamica implica più o meno la presenza di almeno una versione pull della registrazione client.

In definitiva, si tratta di quale sistema corrisponde al flusso di lavoro e alla proprietà nella tua organizzazione. Come regola generale, i sistemi pull sono più flessibili.

Nel caso in cui sia di interesse per chiunque, suppongo di poter fornire almeno un report sull'esperienza utente dopo aver fatto il mio primo utilizzo della funzionalità di push out of the box di Ansible nel contesto della gestione delle patch delle configurazioni multihost di sistemi mission-critical nel cloud di Amazon. Per comprendere i miei preconcetti o pregiudizi, dovrei spiegare che ho una preferenza per Ruby a livello di script di automazione e ho impostato progetti per utilizzare la configurazione fantoccio master-agent per progetto-Vpc in passato. Quindi la mia esperienza smentisce i pregiudizi del passato, se ce ne fossero.

La mia recente esperienza è stata molto favorevole alla spinta dinamica su una proprietà che varia da dozzine a molte centinaia di server che possono essere ridimensionati, ridimensionati e aggiornati. Nella mia situazione un semplice comando Ansible 1.7 ad hoc era tutto ciò di cui avevo bisogno per creare la patch. Tuttavia, vista l'efficacia della configurazione di un AnsibleController (su un t2.micro) per Vpc allo scopo, in futuro intendo espandere la tecnica per requisiti più complessi.

Vorrei quindi tornare alla domanda posta in questo thread: pro e contro della spinta in una proprietà che cambia dinamicamente.

I presupposti del tipo di server server che ho preso di mira erano:

• Non si suppone che gli indirizzi IP o i nomi host locali generati da Amazon sarebbero di lunga durata: possono andare e venire
• Tutte le istanze sono state create da immagini di macchine che avevano già la possibilità di rendere possibile l'accesso ssh da un singolo utente amministrativo privilegiato
• Individuare i server e potenzialmente suddividerli in gruppi, in base alla funzione o in base alla fase di sviluppo (ad esempio test o prod), ciò avverrebbe attraverso il lancio di specifici tag Amazon di nomi convenzionali concordati
• Che avrei gestito le patch amministrando i server Linux e Windows separatamente, con diversi comandi ad hoc, consentendo semplicemente il fallimento degli accessi specifici di Linux quando si contatta un server Windows era perfettamente accettabile

Tenendo conto di queste condizioni, creare un'immagine macchina di un AnsibleController da inserire in numerosi Vpcs e configurarli (con credenziali) in situ all'interno degli account server esistenti è molto semplice. È automatizzato all'interno di ogni istanza creata dall'immagine

1. Un processo cron per inviare la patch ai server in esecuzione a intervalli regolari in modo tale da accedere continuamente alla proprietà richiesta a intervalli
2. Un modo per calcolare l'inventario Ansible ad ogni intervallo.

Il secondo oggetto può essere reso relativamente sofisticato se necessario (tramite la struttura Informazioni dell'inventario Ansible). Ma se non è necessaria la raffinatezza, ecco un esempio molto semplice di uno script per calcolare tutte le istanze Amazon EC2 ad ogni intervallo cron e indirizzare i risultati in un file di inventario appropriato (ad es. / Etc / ansible / hosts) ...

#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute 
# path, to which the list is written

function list-of-ips {
    /usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk  '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
 }

if [ -n "$1" ]; then
   list-of-ips > "$1"
else
   list-of-ips
fi

L'unica avvertenza per il caso d'uso è che il comando patch dovrebbe essere idempotente. È preferibile effettuare un pre-test per assicurarsi che ciò sia soddisfatto, al fine di assicurarsi che la patch faccia esattamente ciò che è previsto.

Quindi, per riassumere, ho illustrato un caso d'uso in cui la spinta dinamica è efficace rispetto agli obiettivi che mi ero prefissato. È una soluzione ripetibile (nel senso di essere incapsulata in un'immagine che può essere implementata in più account e regioni). Nella mia esperienza fino ad oggi, la tecnica di spinta dinamica è molto più facile da fornire --- e mettersi in azione --- rispetto alle alternative disponibili dai set di strumenti disponibili al momento.