Linux Bulk / Amministrazione remota

Oltre alla nostra infrastruttura IT interna, abbiamo circa 500 macchine Linux che ospitano i nostri servizi per il mondo online. Sono raggruppati in un gruppo di cluster come Database An, Product An, NFS, Backoffice e così via. Inoltre, sono amministrati da un fornitore esterno, secondo le nostre specifiche e requisiti.

Tuttavia, affrontiamo molti problemi durante lo sviluppo, il roll-out e l'implementazione del software (web), soprattutto perché gli ambienti di sviluppo e di gestione temporanea non hanno quasi nulla in comune con i sistemi live (ho risparmiato i dettagli sgradevoli ..) .

Quindi, ho provato a creare macchine virtuali, ho copiato i vari sistemi live nel modo più preciso possibile e li ho preparati per connettersi, ad esempio, ai database di sviluppo anziché a quelli "reali" in modo trasparente per gli sviluppatori (non lo sono root). Funziona abbastanza bene, ma ...

Mi chiedevo come si potevano amministrare quei sistemi da remoto e in blocco ? Esiste una famiglia di software di cui non sono a conoscenza? O almeno alcune tecniche o principi che dovresti conoscere?

Forniremmo a ogni sviluppatore un mucchio di immagini da eseguire localmente (VirtualBox). Il reparto QA otterrebbe cluster virtuali (XEN o Hyper-V). Se devo fornire un modulo server aggiuntivo, reindirizzare una nuova connessione al database o voglio semplicemente aggiornare tutto ciò che viene fornito dal gestore pacchetti ... come potrei eventualmente farlo senza essere costretto ad accedere a tutti i sistemi e / o chiedere ai miei colleghi di scaricare ed eseguire alcuni script di fixture?

Credo che ci siano molte soluzioni. Beh, in qualche modo sono troppo stupido per inserire le parole chiave corrette nei motori di ricerca ... O questo problema non è banale come sembra?

Per il record:

Quasi tutti i sistemi eseguono Debian GNU / Linux 6.x "squeeze"
Nessuno sviluppatore è costretto a utilizzare un determinato sistema operativo nella propria workstation
Il budget è limitato, ovviamente, ma non troppo piccolo per acquistare software proprietario
È preferita una soluzione che coinvolga il nostro fornitore di cui sopra

— mjhennig
fonte

Risposte:

Dipende esattamente da cosa hai bisogno e da cosa stai cercando. Ma in generale esistono molteplici soluzioni per "la gestione della configurazione come:

ecc. Personalmente consiglierei il burattino in quanto ha una grande comunità e molte ricette esterne fornite. Ciò consente di configurare e gestire i sistemi automaticamente. Se lo si combina con repository propri e aggiornamenti automatici tramite, ad esempio, unattended-upgradesè possibile aggiornare automaticamente il sistema.

Un'altra soluzione è solo quella di fornire i propri pacchetti come company-baseecc. Che dipendono automaticamente dal software necessario e possono configurare automaticamente il sistema.

Dovresti anche esaminare le distribuzioni automatizzate (barebone e virtualizzate). Se lo combini con la gestione della configurazione o il tuo repository, puoi automatizzare e reinstallare facilmente i tuoi sistemi. Se vuoi iniziare con l'installazione automatizzata dai un'occhiata a theforman che supporta libvirt e le installazioni bare bone e ha il supporto integrato per le marionette. Se vuoi farlo da solo puoi guardare kickstart (redhat et. Al.) O "preconfigurazione" per configurare automaticamente il tuo sistema. Per Debian puoi anche usare qualcosa come debootstrap o un wrapper chiamato grml-debootstrap che supporti immagini virtualizzate.

Per aiutare a fornire le immagini di VirtualBox per il tuo sviluppatore, dai un'occhiata a Vagrant che ti consente di automatizzare la creazione di sistemi virtualizzati con VirtualBox che supporta gli script chef, marionette e shell per personalizzare il tuo ambiente virtuale.

Se desideri utilizzare la soluzione dal tuo provider esistente, dovresti chiedere loro come gestiscono i tuoi sistemi, ma probabilmente sarà una sorta di gestione della configurazione. Potrebbe essere possibile eseguire il loro agente sui sistemi se è possibile accedere al server di configurazione.

Per Google le parole chiave guardare in devops, configuration management, it automatione server orchestration.

In breve, automatizza il più possibile e non pensare nemmeno a fare cose manuali.

— Ulrich Dangel
fonte

Grazie! È un sacco di cose da leggere, ma sembra piuttosto promettente.

— mjhennig,

@mjhennig ho appena aggiunto alcune ulteriori informazioni anche riguardo a. distribuzione. Ci sono molte risorse disponibili, ma la cosa più importante non dovresti davvero fare cose da solo tramite shell ssh / distribuite ma avere un qualche tipo di sistema per esso.

— Ulrich Dangel,

Non c'è niente di sbagliato nel fare cose da soli, specialmente se gli strumenti disponibili non si adattano allo scopo. Sistemi come Puppet sono in gran parte strumenti di amministrazione del sistema, non di gestione della configurazione, di per sé. Una grande maggioranza dei sistemi che utilizzo non è nemmeno accessibile da un server centrale, ma dai laptop degli utenti su (di tutte le cose) VPN - ha cercato di cambiarlo per tre anni. Il nostro reparto IT è suddiviso per aree poiché ciascuna regione non può accedere correttamente all'altra. Gli script di Homegrown sono necessari in alcune situazioni. È anche qui che inizia l'innovazione.

— Arcege,

@Arcege Ho appena votato il tuo commento, gli script sono necessari e non devi convertire l'intera infrastruttura in una volta. La parte più importante è automatizzare le cose e renderle ripetibili. Ma la natura descrittiva del burattino e dello chef ha alcuni aspetti unici, ad esempio puoi testare e verificare le classi di burattini cucumber-puppet. Ovviamente puoi sviluppare / far crescere il tuo framework riutilizzando componenti esistenti ma sembrava che OP non abbia nulla in atto al momento e se inizi da zero penso che sia meglio usare un framework esistente.

— Ulrich Dangel,

Sì, sono d'accordo con le operazioni automatizzate / ripetibili. Ho una serie di script cresciuti in casa automatizzati oa pulsante per l'interfaccia tra sistemi esistenti come l'integrazione Jenkins / Oc4j e Subversion / Bugzilla. Semplicemente non ero d'accordo (fortemente) con il tuo commento "non dovresti davvero fare cose da solo". A volte i quadri esistenti non sono applicabili, come nella mia situazione che ho descritto.

— Arcege,

Ulrich ha già fornito la risposta sulla distribuzione del software e sulla configurazione automatizzata del server.

I principi dietro questo sono

Definisci l'aspetto dei tuoi server: questo include software comuni installati per impostazione predefinita, lo schema di partizionamento e il layout del filesystem
I server di produzione, gestione temporanea, test e sviluppo non dovrebbero differire per quanto riguarda questi standard di base (altrimenti incontrerai problemi in seguito - come hai fatto)
Utilizzare una corretta gestione delle modifiche per documentare TUTTE le modifiche apportate (incluse minuscole modifiche di una riga in qualsiasi configurazione)
Cambia sempre prima nei test, poi nello sviluppo, poi nella messa in scena e infine nella produzione

Hai chiesto uno strumento utile per gestire masse di server: il mio preferito è cluster-ssh ( cssh). Digitare una volta e apportare modifiche su molti server contemporaneamente.

Se scopri un problema e hai una soluzione per rimuoverlo:

Applica la correzione a Test / Dev / Staging / Prod (vedi sopra) se funziona davvero
Applica la correzione ai tuoi modelli virtuali in modo che i futuri cloni VM non abbiano quel bug
Applica la correzione al tuo processo di installazione fisica (kickstart / autoyast / qualunque cosa)
Applica la correzione a TUTTI i server

Se si devono affrontare masse di server per risolvere il problema, questo è un processo che deve essere ben documentato e alla fine un team diverso dovrebbe verificare se la correzione è stata completamente applicata.

A tale scopo utilizziamo Mantis (open source, PHP).

— Nils
fonte

Gestisco circa 30 prodotti e alcune centinaia di server in più paesi. Sono il gestore della configurazione del software, quindi non ho accesso root (in base alla progettazione), non tocco i database o i loro server (di nuovo, in base alla progettazione) e devo saltare molti cerchi a causa della sicurezza aziendale. Ma gestisco le configurazioni in fase di test, gestione temporanea e produzione, inclusi collegamenti e modifiche al database. Ho una serie di script che escono a server che utilizzano combinazioni di ssh, pythone Shell script.

Le cose principali a cui pensare sono:

Che tipo di interazioni hai con i tuoi server? Solo caricamenti di file? Esecuzione di programmi da riga di comando? Esegui client X remoti?
Quale livello di sicurezza è necessario per accedere a questi server? Firewall, reti sicure, VPN? È sshsufficiente e da una posizione centrale sicura?
Quanto può essere automatizzato su ciascun server? È possibile installare un programma su ciascun server ed eseguirlo o è necessario eseguire lo streaming del programma attraverso qualcosa di simile sshper eseguirlo in remoto? Puoi copiarlo con expecto solo una chiamata alla riga di comando?

VirtualBox offre molti strumenti da riga di comando che è possibile amministrare tramite just ssho sistemi come puppetmenziona Ulrich.

— Arcege
fonte

Solo un piccolo suggerimento re. virtualbox, dai un'occhiata a vagrantup.com che può semplificare e automatizzare la creazione di immagini virtuali.

— Ulrich Dangel,

Sfortunatamente, anche ottenere un semplice accesso alla rete tra ambienti di test remoti è quasi impossibile. Configurare una virtualbox farm sarebbe ancora più difficile. Ho difficoltà a chiedere all'IT di aggiornare il software standard con ciò che è scaduto da più di un anno perché non fa parte dei repository "standard RedHat".

— Arcege,

Ciò che mi ha aiutato nella mia esperienza con software obsoleti è mostrare che il software è EOL o che ci sono problemi di sicurezza. L'impostazione / le connessioni di rete sono spesso molto più difficili da raggiungere, forse provare a sottolineare come il collegamento dei diversi ambienti di test consente di risparmiare denaro, semplificare i processi, risparmiare tempo sul QA o rendere l'ambiente di test più realistico. Potrebbe anche essere utile se si prendono a bordo persone delle diverse filiali.

— Ulrich Dangel,