---

Settembre 2015

Volume 30 Numero 9

Il presente articolo è stato tradotto automaticamente.

Azure Insider - Creazione di flussi di lavoro unificati in stile Heroku nelle diverse piattaforme cloud

Da Bruno Terkaly | Settembre 2015

Alcuni anni fa, Microsoft Azure è alle prime armi con il piede giusto ed è stata poco copertura di supporti. Negli ultimi anni che è stato modificato in modo significativo. I team di ingegneri Microsoft e l'intera community hanno contribuito in modo significativo. Con questa puntata di Azure Insider, la serie si sposta una visualizzazione più incentrato sui clienti, case study del mondo.

Per questo primo case study Azure, ho parlato con Gabriel Monroy. Ha visto un'opportunità e rapidamente lo stato sviluppato in una tecnologia e una società denominata Deis. La sua società è stata acquisita rapidamente e Monroy è diventato CTO della nuova società. Quando si prima soddisfatti Monroy e ha iniziato a lavorare con la tecnologia a un hackathon, mi è detto, "Non sarà lungo prima che il metodo di acquisizione." Questo accadeva nel gennaio 2015. Non più di pochi mesi, la sua azienda di essere stata acquisita da EngineYard.

Ingegno

Si continua a essere un'esplosione di piattaforme di elaborazione distribuite che si estendono in locale e nel cloud pubblico. Queste piattaforme sono alimentate da sistemi operativi abilitato al contenitore, ad esempio Linux e Windows, contenitori Docker e abilitato cluster le versioni di Linux, ad esempio CoreOS.

Progetti open source più efficace sono nata dalla necessità. Si ipotizzi un architetto aiutare la Comunità finanziaria configurare cluster di grandi dimensioni delle macchine virtuali, si tenta di supportare lo sviluppo, test e sviluppo di prodotti. Prima di long, si rende conto che mantenere la risoluzione del problema stesso ripetutamente.

È sufficiente Dov'è Monroy, che è stato lo sviluppo di Linux per la community finanziario nel 2005 e 2006. Si avvale alcune delle tecnologie meno recenti intorno containerization, probabilmente allo stesso tempo che Solomon Hykes avviato intrusione per creare Docker. Gran parte del lavoro del Monroy, in effetti, finito nel Docker.

A quel tempo che molte aziende sono state lottato con lo stesso necessario semplificare la pipeline di sviluppo/test o produzione. È stata l'ideale per ottenere la fase di continuous integration, tale stato con privilegi elevato che ottiene il software per gli utenti in modo automatico e tempestivo.

Le aziende voluto un processo ripetibile, ma si sono strumenti senza alcuna. Le aziende era inoltre developer self-service. Non ha desiderano sviluppatori rallentati dalla mancanza di hardware o tyranny delle operazioni IT. Gli sviluppatori non desiderano effettuare il pull in ops solo per l'iterazione su un nuovo concetto o un progetto.

Quindi, invece gli sviluppatori ha iniziato a lavorare in un mondo nefandi dell'ombreggiatura IT, segretamente provisioning dell'infrastruttura e la liberazione autonomamente da dipendenze di altri utenti. Gli sviluppatori desideravano inoltre in grado di operare su qualsiasi cloud pubblico, se Amazon Web Services, Icean digitale, Google o Azure. Desiderano inoltre avere l'esecuzione su bare metal nei propri Data Center, se necessario.

Problemi di opportunità

Nella fine del 2007 e all'inizio del 2008, Heroku offerto un nuovo approccio all'elaborazione distribuita, con particolare attenzione per gli sviluppatori Ruby che desideravano un unico ambiente per sviluppare, testare e distribuire le applicazioni. Gli sviluppatori siamo concentrati sulle applicazioni, non su infrastrutture sottostanti. Volendo un'unica interfaccia della riga di comando con la piattaforma sottostante che consentisse loro di dedicare solo l'applicazione e i relativi dati. Non ha desiderano preoccuparsi di disponibilità, tempi di inattività, il ripristino di emergenza, distribuzione, produzione, la scalabilità verticale in base alle esigenze, controllo della versione e tutti i problemi tipici. Allo stesso tempo, non desiderano dipendono esterno agli amministratori IT di supportare il carico di lavoro. Questa è la Monroy visto prima opportunità.

Una serie di tecnologie correlate sono stati assemblati che ha attivato una scintilla da ricordare di Monroy. Egli potrebbe consentire a flussi di lavoro di sviluppatore stile Heroku su più piattaforme cloud. Prima di entrare nel tutte le tecnologie che abilitato idea del Monroy, di seguito viene illustrato in questo mondo comuni in cui gli sviluppatori possono sfruttare i flussi di lavoro Heroku stile su qualsiasi cloud pubblico con Deis.

Nell'esempio di codice consente di installare la piattaforma Deis. Ciò presuppone che vi sia un cluster di computer CoreOS Linux da utilizzare (ospitato in locale o nel cloud):

# Install Deis tooling
$ deisctl install platform
# Deis platform is running on a cluster
$ deisctl start platform
$ deis register http://deis.example.com

Fatta eccezione per alcuni comandi relative all'account di accesso e i certificati SSH, è possibile sfruttare il team di sviluppo Deis e avviare la distribuzione di applicazioni. Una volta Deis è installato, gli sviluppatori di distribuire applicazioni per lo sviluppo, test e quindi spostarli nell'ambiente di produzione con solo un numero limitato di comandi.

Utilizzo delle tecnologie

Altre tecnologie fuoriesca alla luce dello sdoganamento allo stesso tempo, che ha contribuito a Deis flourish, come illustrato nella Figura 1.

Figura 1 tecnologie convergenti supporto Deis

Containerization è una tecnologia fondamentale presente in sistemi operativi moderni di sul lato server. È stato in Linux per qualche tempo. Mentre non è attualmente presente in Windows Server, deve essere breve. Il concetto di containerization è si utilizza un sistema operativo host e partizionamento in più dimensioni, memoria, CPU e disco. È possibile interrompere un solo computer fisico che esegue un sistema operativo fisico in più contenitori. Ogni contenitore verrà ripartiti in modo che le applicazioni vengano eseguiti isolate da altro durante la condivisione dell'host di base del sistema operativo.

Questo aumenta l'utilizzo efficiente dell'hardware, poiché possono essere eseguita in parallelo contenitori senza alterare una da altra. Isolare i contenitori di Linux (LXC) della CPU, memoria, i/o file e risorse di rete. LXC include spazi dei nomi, isolare l'applicazione dal sistema operativo e separare il alberi dei processi, l'accesso alla rete, gli ID utente e il file System.

Monroy era stato sfruttando le radici, anche prima che fosse una parte fondamentale di Docker LXC. Quindi Docker venisse inventata e democratized containerization attraverso la standardizzazione, tra le distribuzioni Linux. La reale svolta è arrivata quando Solomon creato un archivio centrale delle immagini Docker. Ciò è reso disponibile sarà un ecosistema dei contenitori disponibili pubblicamente che riutilizzare in altri sviluppatori. Sono disponibili più di 14.000 immagini disponibili in registry.hub.docker.com.

È possibile trovare quasi ogni modello di applicazione prevedibile per accelerare il prossimo progetto. È anche possibile rendere disponibili le proprie immagini tramite il Registro di sistema. Pertanto se si desidera utilizzare Nginx o Kafka nell'applicazione, non occorre preoccuparsi di download e installazione di applicazioni, la configurazione delle impostazioni di sistema e in genere la necessità di conoscere peculiarità di singole applicazioni. Deis curates le applicazioni come immagini Docker e quindi distribuisce tra il cluster come contenitori Docker. È facile creare applicazioni personalizzate in un contenitore utilizzando un file Docker:

FROM centos:latest
COPY . /app
WORKDIR /app
CMD python -m SimpleHTTPServer 5000
EXPOSE 5000

Dopo aver definito i file Docker e il provisioning Deis nel cluster, la gestione e distribuzione dell'applicazione diventa più semplice e potente. Quando si combina questo con il repository del codice sorgente Git, è meglio dei due mondi. È possibile utilizzare il controllo delle versioni per sia codice sorgente dell'applicazione, nonché l'infrastruttura (contenitore Docker) stesso.

Questo stile di sviluppo e distribuzione delle applicazioni è ripetibile e prevedibile. Accelera notevolmente la possibilità di spostare tra lo sviluppo, test e produzione. Un file Docker consente di distribuire un agente semplice al server di sviluppo, test o produzione:

# Assume the current folder contains Docker files
$ git add .
$ git commit -m "notes by a developer"
$ git push deis master

Al Heroku

Monroy notato Heroku che enorme impegnarsi nella community di sviluppatori poiché semplifica notevolmente la distribuzione di applicazioni, l'esecuzione e gestione, soprattutto applicazioni Ruby e Node. js.

Gli sviluppatori in genere risiedono in un prompt dei comandi ospitato che consente di eseguire praticamente tutti gli aspetti di sviluppo di applicazioni, il provisioning dell'infrastruttura e scalabilità e le attività. Monroy rilevato brillante, ovvero un singolo posizionare per uno sviluppatore ottenere tutto il suo lavoro e ridurre al minimo la vasta gamma di strumenti di sviluppo.

Molti problemi di gestione dell'esecuzione di un cluster sono stati automatizzata, backup e ripristino, configurazione del DNS, la definizione di un bilanciamento del carico, il monitoraggio del disco l'utilizzo, la gestione utenti, la registrazione della piattaforma e monitoraggio e così via. Aggiunta di nodi è un caso semplice di modifica di un URL in un file di configurazione cloud tramite un'interfaccia della riga di comando. Forse l'aspetto più importante dell'esecuzione di un cluster è per renderlo riparazione automatica, in modo che il failover e ripristino di emergenza vengono inclusi automaticamente.

CoreOS

Mentre Heroku aveva il finanziamento e il tempo necessario per creare questa piattaforma personalizzata, una soluzione commerciale Monroy necessaria per la gestione dei cluster inclusi parti, ad esempio il bilanciamento del carico, monitoraggio e illuminazione, failover e così via. Nello stesso momento tra le distribuzioni di Linux, note come CoreOS è stato inoltre ad acquisire mindshare developer.

CoreOS portato la combinazione di tecnologie per facilitare il mondo che monroy concepito perfetta. CoreOS è una open source del sistema operativo Linux è progettato per le distribuzioni cluster. Ed è incentrato sull'automazione, distribuzione, protezione, affidabilità e scalabilità. Si trattava con precisione le caratteristiche con cui Heroku ha attirato gli sviluppatori.

CoreOS ha fornito effettivamente infallibile per cui era alla ricerca Monroy. CoreOS non è un sistema operativo basato su Linux normale. È interessante notare che il tentativo di pioniere la propria versione di un contenitore Docker denominato runtime Rocket contenitore.

L'innovazione che coreos apporta è significativo. Monroy e il suo team più interessata etcd, flotta e flannel. Etcd è un archivio distribuito il valore di chiave che fornisce un modo affidabile per archiviare i dati in un cluster di computer da gestire normalmente elezioni master durante le partizioni di rete che tollerano guasto del computer, incluso il database master. L'archivio del valore della chiave etcd che archivia le informazioni di configurazione del cluster viene distribuito anche in modo intelligente in tutto il cluster.

Un'API di facile utilizzo consente di modificare i valori nel file di configurazione, che viene replicata automaticamente in altri nodi del cluster. Flannel fornisce una rete virtuale che fornisce una subnet per ogni post da utilizzare con ogni contenitore runtime. Ogni contenitore fornisce un indirizzo IP instradabile, univoco all'interno del cluster. Ciò riduce notevolmente la complessità di mapping della porta.

Flotta consente di considerare come un sistema singolo init, di doversi preoccupare di singoli computer in cui sono in esecuzione i contenitori del cluster. Flotta garantisce automaticamente che il contenitore verrà eseguito in un punto nel cluster. Pertanto se il computer non riesce o richiede l'aggiornamento, il software della flotta passerà automaticamente il carico di lavoro a una macchina completo del cluster.

Si noti che nella Figura 2 è possibile inviare una richiesta put per indicare lo stato desiderato di un determinato servizio flotta al cluster. Ovvero plumbing sottostante che rende i servizi della flotta. La richiesta put per conto dell'utente si evita di doversi preoccupare i dettagli del cluster.

Figura 2 diagramma concettuale di CoreOS

Monroy iniziava a tutto ciò che avrebbe dovuto compilare Deis: un modello standardizzato containerization da Docker e un'implementazione compatibile con cluster versione di Linux denominata CoreOS. Egli potrebbe offrire ora Heroku nello sviluppo di massa, non solo quelle che potrebbero permettersi tasse pesante richieste da Salesforce.com, la società che ora offre Heroku come servizio.

Tre componenti di base sono un piano di controllo, un registro Docker e un piano di dati. Questi tutti utilizzati insieme. Inizia con lo sviluppatore che utilizza Git push in una nuova versione, che può includere sia codice sorgente per l'applicazione e un file di compilazione Docker.

Questa nuova build, insieme alla configurazione esistente, genera una nuova versione. Questo viene quindi inviato fino al Registro di sistema Docker. L'utilità di pianificazione in esecuzione nel piano di dati, quindi estrae le immagini rilasciate in sviluppo, test o produzione.

In questa fase, i contenitori sono gestiti da CoreOS e da Deis, fornire la tolleranza di errore, scalabilità e le altre funzionalità di piattaforma come servizio. Anche nei dati del piano è il router, che accetta rifiuto inviato mediante l'utilizzo di app e "Invia" utenti sul contenitore appropriato per soddisfare la richiesta. Figura 3 illustra queste tecnologie interagiscono.

Figura 3 Deis architettura

Avvolgendo

Alcuni dei successo progetti open source disponibili non partire da zero. Sono richiedere componenti preesistenti, portarli insieme in un singolo ombrello e applicare la tecnologia in modo univoco. Monroy e il team Deis ha appena fatto. Essi harnessed la potenza di contenitori Docker, CoreOS e lo stile Heroku flussi di lavoro. Il team potrebbe implementare Deis non solo in Azure, ma anche in altri cloud pubblico, per non parlare in locale, nonché.

Nella prossima puntata di Azure Insider case study, verrà preso in esame Docker. Che cos'è Docker? Come diventati una società di miliardi di dollari in pochi anni e come sta modificando il modo applicazioni vengono sviluppate, testate e il rollback nell'ambiente di produzione?

---

Bruno Terkaly* è un principal software engineer presso Microsoft con l'obiettivo di abilitazione di sviluppo di applicazioni e servizi leader nel settore per dispositivi. È responsabile per la Guida di cloud superiore e opportunità mobile tutti gli Stati Uniti e oltre da una prospettiva di abilitazione di tecnologia. Aiuta i partner portare le applicazioni sul mercato fornendo indicazioni relative all'architettura e tecnica approfondita impegno durante la valutazione, sviluppo e distribuzione dell'ISV. Terkaly collabora con il cloud e mobili gruppi engineering, fornire commenti e suggerimenti e che influenzano la Guida di orientamento.*

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Gabriel Monroy (EngineYard)