Ottobre 2017

Volume 32 Numero 10

Il presente articolo è stato tradotto automaticamente.

Sviluppo cloud - Creazione di distribuzioni cloud migliori: 5 passaggi per ottenere l'immutabilità

Da Martin Albisetti | Ottobre 2017

Recapito cloud è apparsa come standard accettati per la distribuzione del servizio Web, se tali servizi si trovano in infrastrutture di cloud pubblico o privato. Mentre il cloud offre una flessibilità, automazione e la disponibilità su richiesta, non tutti i servizi Web sono progettati per sfruttare appieno le promesse. Infrastruttura cloud imprevedibili e cicli DevOps agili hanno creato la necessità di componenti software isolata, che consentono lo spostamento rapido tramite un test, sviluppo e produzione dei servizi Web nel cloud.

Bitnami, abbiamo stato vive e sperimentare l'evoluzione di distribuzione software per un periodo di tempo, e sono stati fatti investimenti frequentemente rendendo più semplice per gli sviluppatori di adottare le procedure tecniche di distribuzione disponibili. Una tecnica consiste il concetto di infrastruttura non modificabile che è un approccio per la gestione dei servizi e le distribuzioni software in modo che i componenti vengono sostituiti anziché essere modificati. In effetti, un'applicazione o un servizio viene ridistribuito ogni volta che si verificano modifiche.

Animali rispetto bovini

Randy Bias, fondatore della Fondazione, OpenStack ha coniato l'analogia di animali rispetto bovini per rappresentare questa situazione. Server tradizionale vengono considerati come animali domestici. Dispongono di propri personalità, e se ne ricevono malattia li si nurse allo stato di. Bovini, d'altra parte, tutti lo stesso aspetto. Se la loro funzione malattia è semplicemente eliminarle. Sarà il costo è più da trattare bovini di to sostituirli. Inoltre, è scalabile bovini. Un farmer aggiungerà il genealogico man mano che aumenta l'operazione, basato su richiesta e di budget.

Cloud funzionalità sufficiente per consentire di continuare trattare i server come animali domestici. È il problema, ma sono animale pesce rosso. È un'operazione noiosa. Se il pet Ottiene malattia, potrebbe essere in grado di gestire, ma vets verranno in genere divertirsi si se si tenta. Pesce sarà spesso non rispondono e verrà annullamento in qualsiasi momento senza preavviso.

È per questo motivo le distribuzioni non modificabile (o basata su immagini) e l'utilizzo di cloud pubblici o privati in genere essere combinati. Se si desidera eseguire tutta sicurezza a livello di produzione servizi Web nel cloud, è necessario riservare proprietà pet e distribuire l'infrastruttura e il software che può essere riprodotta o sostituito facilmente. Ad esempio bovini.

Per comprendere le sfumature con questo approccio, si prendano in considerazione i vantaggi e svantaggi dell'utilizzo del servizio cloud. Cloud offrono i vantaggi che consentono di essere proibitivo ottenere con privata dell'infrastruttura. Oltre a tutto il mondo ridondanza e il recapito rapido, è necessario gestire contenuto geograficamente vicino agli utenti, le distribuzioni di cloud abilitare elasticità. Le organizzazioni IT possono chiamare le risorse come sono necessari, pagare solo ciò che usa in qualsiasi momento. Questo modello su richiesta consente inoltre di sperimentare le nuove tecnologie e topologie senza investimenti iniziali, ripida.

È anche il vantaggio che viene fornito con la "tutto" - di - un-modello di servizio. Cloud offrono la maggior parte dei servizi comuni desiderato nel software Web moderno, tra cui database (SQL e NoSQL), HTTP front-end, servizi di bilanciamento del carico, DNS, l'archiviazione a blocchi, archiviazione di oggetti, analisi dei log, monitoraggio, code, AI e altro ancora. L'elenco aumenta con ogni mese. E cloud consentono di focalizzare l'attenzione sull'azienda principale, ripartendo servizi comuni a un provider.

Naturalmente, tutto ciò che comporta un costo. L'adozione dell'infrastruttura su richiesta, significa che rinunciare garanzie di affidabilità. Un'istanza nel cloud potrebbe scomparire o riavviare il computer in qualsiasi momento senza preavviso. Analogamente, le modalità di errore possono essere impossibili da riprodurre. Potrebbe verificarsi un comportamento può verificarsi anche. Ad esempio, una nuova istanza potrebbe non riuscire per l'avvio o i server possono verificarsi IO disco lenta o picco carichi della CPU, non deselezionare causa.

Sopra il cloud

I vantaggi e i problemi delle distribuzioni di cloud, servizi non modificabili sono perfetti. Tra i vantaggi principali:

• Distribuire in modo prevedibile esattamente gli stessi byte ovunque nel mondo.
• Avviare decine, centinaia o migliaia di nuove istanze in risposta alla richiesta, senza alcuna preparazione.
• Nelle distribuzioni di compilazione recupero da errori automatico. Crearne istanze possono essere automaticamente arrestato o rimosso da gestisce le richieste e sinistra per poterle analizzare e nuovi attivati, che ogni volta che è utile invece che all'interno di un'interruzione può avvenire modalità debug.
• Automatizzare le distribuzioni, è necessario distribuire le immagini che non devono essere trasformati dopo l'avvio.

Oltre a lavorare con i cloud, esistono numerosi vantaggi per la distribuzione dei servizi immutably, dalla complessità ridotta e distribuzioni più rapido per migliorare la sicurezza e conformità.

Ridotta complessità se si dispone di un set di tre servizi, ognuno con una media di quattro istanze, base rapidamente alla fine si 12 animali. Che vengono sottoposti a numerose di animali al feed. Si potrebbe sostenere che le quattro istanze sono uguali e che di probabilmente come iniziato, ma è possibile vedere come il periodo di sei mesi in ogni istanza verrà è stato aggiornato, eseguire il debug e ripristinata in modi diversi, non è più garantendo che stanno effettivamente lo stesso più.

Al contrario, un approccio non modificabile significa che esattamente un'immagine. Ognuno dei quattro istanze conterrà esattamente lo stesso codice in fase di distribuzione configurati nello stesso modo esatto. A meno che non si modifica un elemento in un secondo momento, è necessario solo tre varianti diverse delle immagini per comprendere e preoccuparsi. Inoltre, qualsiasi deviazione che si verifica anche se nell'ambiente di produzione verrà reimpostato a ogni distribuzione successiva.

Distribuzione intensificherà distribuzioni non modificabile shift molta il pesante (incluso il download, la compilazione e convalida) per la fase di compilazione, aggiunta ora questa fase della distribuzione, ma la protezione contro errori nell'ambiente di produzione.

Una volta le immagini vengono create, le distribuzioni con la stessa velocità come un server in un particolare cloud, è possibile visualizzare includono rollback di una modifica problematica. Inoltre, le distribuzioni più efficacemente atomiche, consentendo di eseguire le distribuzioni di cluster in scala o in sequenza assicurando che stati non metà presente su un server particolare.

Più semplice la sperimentazione e rollback una singola immagine per la distribuzione, è possibile creare un esperimento di breve durato ed eliminarlo al termine. Gli esperimenti sono anche più economici perché si prevede che si inizia dalla stessa base che sono in esecuzione nell'ambiente di produzione, fino all'ultimo byte. Questo rende più semplice tenere traccia delle modifiche che si sta tentando di eseguire.

Migliore riproducibilità immutabilità assicura che lo stesso codice restituisce lo stesso output in ogni computer portatile, ogni integrazione continua (CI) e in ogni server. Non sussiste alcun dubbi su quale combinazione di codice e la configurazione è in uso. Se è necessario apportare modifiche alle immagini di ambiente o in esecuzione, è possibile ridistribuire facilmente dalla stessa immagine per tornare a uno stato funzionante. In questo modo il più simile a "ambiente di produzione", dato che le immagini vengono prodotti ogni volta che si apporta una modifica.

Maggiore sicurezza e conformità incorporando ogni volta a un'immagine, si conosce esattamente ciò che è in esecuzione in qualsiasi server in qualsiasi punto nel tempo, consentendo di un singolo elemento di controllo e verificare che sia in esecuzione ovunque. In casi estremi, è possibile utilizzare le risorse come la modalità di sola lettura di Docker per garantire che successive apportata alcuna modifica alle istanze quando si eseguono.

Ripristino di emergenza migliorate per creare l'infrastruttura non modificabile, è necessario disporre di un livello minimo di automazione nelle distribuzioni. Quando (se non) comprime l'infrastruttura, questo miglioramento consente di ripristinare in minuti, ore, giorni o settimane.

Salire della scala non modificabile

Creazione di servizi non modificabili non è sempre facile, soprattutto se è stato compilato il progetto su presupposti comuni per i Data Center legacy come in grado di scrivere in un punto qualsiasi nel file system o sovrascrivere i file esistenti per l'aggiornamento rapido sul posto. Tuttavia, è possibile adottare un servizio non modificabile in soli cinque passaggi, come illustrato nella figura 1, a ogni passaggio fornendo concreti.

Figura 1, 5 procedura immutabilità

Un salita completamente la scala non modificabile richiede investimenti e pazienza, ma vedrai anticipate vantaggi anche con alcune piccole modifiche. Esaminiamo i passaggi nel tentativo di servizi non modificabile.

Passaggio 0: Disentanglement iniziale

Questo passaggio è in cui viene eseguita molte disentangling. Creando uno ora per vedere come corrente dei processi, script e i modelli sono eccessivamente collegati tra loro, consente di sfruttare molti dei vantaggi di immutabilità richiedendo una strategia di distribuzione più riproducibile:

• Le distribuzioni non modificabile impediscono gli aggiornamenti sul posto del codice.
• Scegliere il percorso più veloce che consenta le distribuzioni basate su immagine anziché gli aggiornamenti sul posto. Esistono diversi modi per affrontare questo: È possibile creare uno snapshot la macchina virtuale corrente e l'utilizzo come immagine di base e sostituire il codice in ogni distribuzione, ad esempio, oppure è possibile modificare il software di Gestione configurazione per configurare completamente un'immagine di vaniglia.
• Con il nuovo modello di ogni istanza verrà distribuita come una nuova immagine. Pertanto, che è necessario essere in grado di passare il traffico alle nuove istanze a livello di DNS o nel front-end HTTP, sia esso un bilanciamento del carico, i server HTTP, la memorizzazione nella cache i livelli o simili.
• Dati critici devono essere archiviati all'esterno del file system di immagine, esternamente o in un volume montato. Questa operazione continuerà a essere un requisito in tutti i passaggi successivi.

In questa fase, è possono eseguire molte operazioni, ad esempio, potrebbe essere in grado di scaricare una dipendenza pacchetto del sistema o il sistema potrebbe non riuscire configurare correttamente a causa di una condizione di competizione o una versione imprevista di inclinazione. La ricompilazione dell'intera immagine ogni volta che in qualche modo richiede in genere una quantità significativa di tempo.

Passaggio 1: Isolare dal sistema operativo

Dopo aver completato il passaggio 0, la destinazione successiva è interfoliati manualmente dal livello del sistema operativo. Questa operazione consente di avviare molti diversi servizi e le distribuzioni dall'immagine cabinet stesso, noto. Anche possibile ridurre il numero di messaggi immediati-età viene mantenuta e velocizzare il processo di compilazione. Tra aspetti da tenere presenti:

• Avviare lo spostamento di tutte le dipendenze dalla directory di sistema.
• Framework e linguaggi di programmazione sono particolarmente adatte per la separazione necessaria in questo passaggio. Per utilizzare come campione esame, Virtualenv di Python, Gemfiles del Ruby e PHP Composer sono semplici modi per isolare le dipendenze dal resto del sistema utilizzando i percorsi relativi per l'archiviazione per impostazione predefinita.
• Dipendenze compilate possono essere più difficile da gestire, perché sono spesso prevede di trovare le dipendenze per i percorsi di sistema specifico.
• In questa fase si sarà sostituendo l'intero server in ogni distribuzione, pertanto è necessario assicurarsi di che non eliminare dati importanti. È importante che il log a livello di sistema archiviati esternamente all'istanza.

Passaggio 2: Isolare dalla fase di esecuzione

È stato pertanto untangled il servizio dal sistema operativo sottostante. È necessario assicurarsi che il runtime del linguaggio è prevedibili e affidabili. Distribuire il runtime del linguaggio nell'immagine di base, incluse eventuali opzioni di configurazione della lingua potrebbe essere necessario impostare per impostazione predefinita, e si saprà che è possibile utilizzare lo stesso comportamento da esso in ogni istanza:

• I runtime sono semplici da aggiornare. Che non cambiano spesso e sono facili da mantenere aggiornati anche quando il rollback in immagini di base.
• Runtime in sequenza in base immagini consente di controllare quando gli aggiornamenti vengono eseguiti, che è importante perché gli aggiornamenti possono interromperanno la compatibilità con e forza la porting di applicazioni.
• Un runtime isolato può eliminare prodotte da differenze di configurazione di piccole dimensioni, ad esempio tra un 8MB e 64MB memory_limit sconcertante sfide di produzione.
• Non modificabilità in questo passaggio è ancora facile raggiungere dato che il sistema operativo e il runtime del linguaggio sono adatti all'isolamento da tutto il resto del sistema.

Passaggio 3: Isolare da Framework

Se è arrivati a questo passaggio, si disporrà probabilmente il blocco di questo aspetto immutabilità. È possibile iniziare a vedere perché la scala non modificabile è vale la pena progressivamente. Con il passaggio 3, l'impegno verrà ottenere testato, come una serie di problematiche iniziale mostrare stessi quando si lavora con Framework. tra cui:

• Framework di modificare un po' più spesso di runtime, pertanto sarà necessario aggiornare le immagini di base più spesso. Ciò premesso, la possibilità di gestire gli aggiornamenti di framework in una pianificazione è importante, perché gli aggiornamenti anche secondari possono interrompere la compatibilità.
• Framework presentano spesso ulteriori problemi di sicurezza, in quanto la superficie di attacco è più ampio e in genere esposti a Internet. Ad esempio Python produce 26 vulnerabilità ed exposures (CVE) rispetto a 48 CVEs comuni per Django.
• Le distribuzioni disentangling ottiene più difficile in questa fase, in quanto Framework tendono a credere che fanno parte del codice base. È necessario ulteriori informazioni sui meccanismi interni del framework per comprendere il modo migliore per gestire la separazione tra il codice e framework.

Passaggio 4: Immagine sfornato completamente per la distribuzione

Il concorrente apportate! Questa è la destinazione. Quando le immagini di avvio, pronti per l'azione. Non sussiste alcuna configurazione principali download o l'inizializzazione di qualsiasi software nell'immagine. Gli unici elementi che richiedono modifiche in questa fase sono valori di perinstance minori, ad esempio indirizzi IP o nomi di istanza:

• Il codice dell'app e i dati sono completamente distinti dal sistema operativo sottostante, runtime e framework. Dolci questi tre elementi sottostanti nell'immagine di base e può aggiornare codice e i dati in modo indipendente.
• Non è necessario ricompilare il servizio da zero per ottenere qui, ma alcune operazioni aggiuntive potrebbero essere necessario per assicurare che la scrittura solo in punti specifici.
• Dopo che hai gestito impostare tutti gli elementi per la corrispondenza di questo passaggio, è possibile utilizzare scalabilità automatica soluzioni per ruotare le immagini su o giù rapido e affidabile.

Passaggio di lato aggiuntivo: Non modificabile + senza stato

Non tutti i servizi verranno rientrano in questo modello. Tuttavia, se si dispone di un servizio senza stato, ad esempio una farm di lavoro, un sistema di memorizzazione nella cache o un sito Web statico, questo approccio consente di mantenere tutti i dati dell'immagine stessa. Ciò riduce la complessità della distribuzione, è necessario gestire direttamente dall'istanza ed è ideale per:

• Dati di sola lettura, ad esempio siti Web statici (alcuna fase di esecuzione nell'ambiente di produzione).
• Processi di lavoro che elaborano i dati e della farm out a una coda (runtime stesso, lo stato non locale).

La scala non modificabile

Ora che l'infrastruttura non è modificabile, il ciclo di sviluppo in produzione potranno essere ottimizzato, semplici e molto più semplice, come illustrato nella figura 2.

Figura 2, il ciclo di produzione ottimizzato

Cloud pubblici sono in genere progettati per essere meno affidabili rispetto a Data Center, in quanto condividono risorse sottostanti con potenziali router adiacenti rumore. In exchange, è possibile automaticamente scalare e arresto delle risorse in risposta alle modifiche nella richiesta. Ciò significa che è necessario ottimizzare per le istanze di essere arrestato e sostituito. Più l'istanza viene ridimensionata, più l'investimento in automazione paga off, poiché sarà necessario creare rapidamente istanze più frequentemente. Sono disponibili che le istanze di ottimizzazione diventa un processo molto più semplice, consentendo di concentrarsi sulle distribuzioni di sviluppo per sistemi operativi opment anziché handholding.

L'offerta Sylvester Stallone del filmato "Panamense Rocky": "Influisce negativamente adesso... ma, un giorno, e deve essere il warm backup." Come iniziare dal passaggio 0 della scala non modificabile, è necessario ricordare che il problema è importante il guadagno. Tuttavia, il miglioramento è notevole. Un approccio non modificabile consente di assicurarsi che ciò funziona anche prima che passano alla produzione, anziché l'individuazione di problemi dopo i sistemi operativi, Framework, codice di runtime e applicazione opportunità di lavoro rispetto a altro in una distribuzione di incendio in tempo reale. Ora più errori possono essere individuati e gestiti "in zero" prima della distribuzione, anziché in aereo quando l'ambiente sia attivo e in esecuzione.

I livelli di 3

Quando si produce un'immagine per la distribuzione, è opportuno considerare l'architettura del sistema come disporre di tre livelli: un livello volatile, un livello di dati e un livello di routing. In Bitnami, sono state impiegate per molto tempo a pensare questi livelli e gli effetti ogni applicazione open source, specialmente quelle che in genere utilizzata come blocchi predefiniti di origine aperti ad altri utenti, ad esempio database e Framework di lingua.

Livello 1: Volatile distribuzioni sono ora disposable immagini, ovvero ottenere eliminate in ogni distribuzione e sostituite con uno appena compilato. Il codice e tutti i dati, viene scritto in modo disposable localmente. È necessario essere pronti a eliminare e sostituire uno qualsiasi di queste istanze in qualsiasi punto nel tempo. Questi diventeranno server senza stato.

Livello 2: I dati persistenti si tratta di dove archiviare i database importanti, i file utente, lo stato della sessione e tutto ciò che è importante conservare. È opportuno archiviare i registri di sistema e di servizio a questo livello di conformità e il debug, nonché. Può essere difficile verificare l'esistenza di alcun singolo punto di errore in questo livello, pertanto le soluzioni di cloud Software-as-a-Service possono essere utile per risolvere questi problemi. Questo livello deve essere consistenti, a disponibilità elevata e completamente sottoposti a backup.

Livello 3: Routing dopo aver creato un livello volatile, è necessario un livello prevedibile e indirizzabile per gli utenti esterni e altri servizi accedere ai servizi. È necessario disporre di nomi di dominio, separati dai server volatile esecuzione del codice e in grado di inoltrare le richieste a un pool di server flessibile e stimabile gli indirizzi IP pubblici.

Conclusioni

È chiaro da ricordare per gli sviluppatori: Compilazione e l'esecuzione di servizi non modificabili fornisce un enorme vantaggio attraverso la pipeline di sviluppo e compilazione nell'ambiente di produzione. A ogni passaggio che è eseguire della scala non modificabile, i servizi esistenti ottengono vantaggi e i vantaggi aggiuntivi.

Non modificabile infrastruttura essenzialmente riguarda l'automazione completa un processo che garantisce l'applicazione e le distribuzioni, nella misura massima consentita, quali è in esecuzione nel server. Passaggio 0 è il punto di partenza. Anche se risale solo il primo passaggio, i carichi di lavoro di cloud sarà in una quantità situazione migliore rispetto a cui si trovavano prima.

Martin Albisettiè un progettista senior di Bitnami e in precedenza era direttore del reparto tecnico in Canonical (Ubuntu). Albisetti tempo libero utilizzo con il suo mani in Uruguay rural, in cui vive con familiari. È possibile trovarlo su Twitter: @beuno.

Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: James McCaffrey

Viene illustrato in questo articolo nel forum di MSDN Magazine