{"id":33504,"date":"2019-10-31T21:52:58","date_gmt":"2019-10-31T18:52:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom\/"},"modified":"2019-10-31T21:52:58","modified_gmt":"2019-10-31T18:52:58","slug":"rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","title":{"rendered":"Guida per principianti: creazione di catene DevOps con strumenti open source","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Guida
\nCreare la prima catena DevOps in cinque semplici passi per principianti.<\/em><\/p>\n

<\/p>\n

DevOps \u00e8 diventato la soluzione per processi di sviluppo troppo lenti, disconnessi e problematici. Tuttavia, servono conoscenze minime di DevOps. Qui si discuteranno concetti come la catena DevOps e come crearla in cinque passi. Questa non \u00e8 una guida completa, ma solo una 'bozza' che pu\u00f2 essere ampliata. Iniziamo con una storia.<\/p>\n

<\/p>\n

La mia introduzione a DevOps<\/h3>\n

<\/p>\n

Un tempo lavoravo con il cloud in Citi Group e sviluppavo un'applicazione web IaaS per gestire l'infrastruttura cloud di Citi, ma sono sempre stato curioso di scoprire come ottimizzare la catena di sviluppo e migliorare la cultura tra gli sviluppatori. Greg Lavender, il nostro CTO per architettura cloud e infrastruttura, mi ha consigliato un libro Il Progetto 'Phoenix'<\/a><\/noindex>. Spiega magnificamente i principi di DevOps, leggendo come un romanzo.<\/p>\n

<\/a><\/noindex><\/p>\n

Nella tabella sul retro \u00e8 mostrato quanto spesso le aziende rilasciano nuove versioni:<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Come fa Amazon, Google e Netflix a rilasciare cos\u00ec tanto? \u00c8 semplice: hanno capito come creare una catena DevOps quasi perfetta.<\/p>\n

<\/p>\n

Da noi in Citi le cose erano molto diverse, fino a quando non siamo passati al DevOps. All'epoca, il mio team aveva ambienti diversi, ma il deploy sul server di sviluppo veniva effettuato manualmente. Tutti gli sviluppatori avevano accesso a un solo server di sviluppo basato su IBM WebSphere Application Server Community Edition. Quando pi\u00f9 di noi tentava di effettuare il deploy contemporaneamente, il server si \u201cbloccava\u201d e dovevamo sempre \u201cnegotiare\u201d con fatica. Inoltre, avevamo una copertura di codice test insufficienti, un processo di deploy manuale laborioso e nessuna possibilit\u00e0 di tracciare il deploy del codice in relazione a qualche requisito o richiesta del cliente.<\/p>\n

<\/p>\n

\u00c8 stato chiaro che era necessario agire rapidamente e ho trovato un collega con cui condividere la stessa visione. Abbiamo deciso di creare insieme il nostro primo flusso DevOps: lui ha configurato la macchina virtuale e il server applicativo Tomcat, mentre io mi sono occupato di Jenkins, dell'integrazione con Atlassian Jira e BitBucket, oltre che della copertura del codice con i test. Il progetto \u00e8 stato un successo: abbiamo completamente automatizzato il flusso di sviluppo, raggiunto quasi il 100% di uptime del server di sviluppo, potuto monitorare e migliorare la copertura del codice con i test, e il ramo Git \u00e8 stato associato a una consegna e a un task Jira. E quasi tutti gli strumenti con cui abbiamo costruito il flusso DevOps erano open source.<\/p>\n

<\/p>\n

In realt\u00e0, il flusso era semplificato, poich\u00e9 non abbiamo nemmeno utilizzato configurazioni avanzate con Jenkins o Ansible. Ma siamo riusciti a portarlo a termine. Forse \u00e8 il risultato del principio Pareto<\/a><\/noindex> (noto anche come regola 80\/20).<\/p>\n

<\/p>\n

Breve descrizione del flusso DevOps e CI\/CD<\/h3>\n

<\/p>\n

In DevOps esistono diverse definizioni. Come Agile, DevOps comprende diverse discipline. Tuttavia, la maggior parte delle persone concorderebbe su questa definizione: DevOps \u00e8 un metodo, o ciclo di vita, per lo sviluppo del software, il cui principio fondamentale \u00e8 la creazione di una cultura in cui sviluppatori e altri membri del team sono \"sulla stessa lunghezza d'onda\", il lavoro manuale \u00e8 automatizzato, ognuno si dedica a quello che sa fare meglio, aumentando la frequenza delle consegne, migliorando la produttivit\u00e0 e aumentando la flessibilit\u00e0.<\/p>\n

<\/p>\n

E sebbene gli strumenti da soli non siano sufficienti per creare un ambiente DevOps, sono essenziali. Il pi\u00f9 importante di questi \u00e8 l'integrazione continua e la consegna continua (CI\/CD). Nel flusso di lavoro per ciascun ambiente ci sono diverse fasi (ad esempio, DEV (sviluppo), INT (integrazione), TST (test), QA (controllo qualit\u00e0), UAT (test da parte degli utenti), STG (preparazione), PROD (produzione)), le attivit\u00e0 manuali sono automatizzate, gli sviluppatori possono scrivere codice di qualit\u00e0, effettuare le consegne e adattarsi facilmente.<\/p>\n

<\/p>\n

Questa nota descrive come creare una catena DevOps in cinque passaggi, come mostrato nell'immagine qui sotto, utilizzando strumenti open source.<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Andiamo al sodo.<\/p>\n

<\/p>\n

Passo 1: Piattaforma CI\/CD<\/h3>\n

<\/p>\n

Per iniziare, hai bisogno di uno strumento CI\/CD. Jenkins \u00e8 uno strumento CI\/CD open source scritto in Java con licenza MIT, il quale ha avviato la popolarit\u00e0 del movimento DevOps ed \u00e8 di fatto diventato lo standard per il CI\/CD.<\/p>\n

<\/p>\n

Ma cos'\u00e8 Jenkins? Immagina di avere un telecomando magico per svariati servizi e strumenti. Di per s\u00e9, uno strumento CI\/CD come Jenkins \u00e8 inutile, ma con vari strumenti e servizi diventa onnipotente.<\/p>\n

<\/p>\n

Oltre a Jenkins, ci sono molti altri strumenti open source, scegli quello che preferisci. <\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Ecco come appare il processo DevOps con uno strumento CI\/CD<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Hai uno strumento CI\/CD in localhost, ma per ora non c'\u00e8 molto da fare. Passiamo al passo successivo.<\/p>\n

<\/p>\n

Passo 2: gestione delle versioni<\/h3>\n

<\/p>\n

Il modo migliore (e probabilmente pi\u00f9 semplice) per testare la magia dello strumento CI\/CD \u00e8 integrarlo con uno strumento di controllo versione (source control management, SCM). Perch\u00e9 \u00e8 necessario il controllo versione? Supponiamo che tu stia sviluppando un'applicazione. La scrivi in Java, Python, C++, Go, Ruby, JavaScript o in qualsiasi altro linguaggio, ne esistono numerosi. Quello che stai scrivendo \u00e8 chiamato codice sorgente. Inizialmente, soprattutto se lavori da solo, puoi tenere tutto in una cartella locale. Ma quando il progetto si espande e pi\u00f9 persone si uniscono, hai bisogno di un modo per condividere le modifiche del codice, evitando conflitti durante le fusioni. Inoltre, hai bisogno di un metodo per recuperare versioni precedenti senza usare backup e senza dover fare copia-incolla dei file di codice.<\/p>\n

<\/p>\n

E qui entra in gioco lo SCM. Lo SCM salva il codice nei repository, gestisce le sue versioni e coordina il lavoro tra gli sviluppatori.<\/p>\n

<\/p>\n

Ci sono molteplici strumenti SCM, ma Git \u00e8 diventato il de facto standard meritatamente. Ti consiglio di utilizzare proprio lui, anche se ci sono altre opzioni disponibili.<\/p>\n

<\/p>\n

\"Guida<\/p>\n

<\/p>\n

Ecco come appare il pipeline DevOps dopo aver aggiunto lo SCM.<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Lo strumento CI\/CD pu\u00f2 automatizzare il caricamento e il rilascio del codice sorgente e la collaborazione in team. Non male, vero? Ma come possiamo trasformarlo in un'applicazione funzionante, amata da miliardi di utenti?<\/p>\n

<\/p>\n

Passo 3: strumento di automazione della build<\/h3>\n

<\/p>\n

Tutto procede per il meglio. Puoi rilasciare il codice e registrare le modifiche nel sistema di controllo versioni, oltre a invitare amici a collaborare con te. Ma, per ora, non hai un'applicazione. Perch\u00e9 diventi un'app web, deve essere compilata e imballata per la distribuzione o eseguita come file eseguibile. (I linguaggi di programmazione interpretati, come JavaScript o PHP, non devono essere compilati).<\/p>\n

<\/p>\n

Utilizza lo strumento di automazione della build. Qualunque strumento tu scelga, compiler\u00e0 il codice nel formato necessario e automatizzer\u00e0 la pulizia, la compilazione, i test e la distribuzione. Gli strumenti di build variano a seconda del linguaggio, ma solitamente vengono utilizzate le seguenti opzioni open-source.<\/p>\n

<\/p>\n

\"Guida<\/p>\n

<\/p>\n

Eccellente! Ora inseriamo i file di configurazione dello strumento di automazione della build nel sistema di controllo versioni affinch\u00e9 lo strumento CI\/CD li compili.<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Sembra che vada tutto bene. Ma dove possiamo ora implementare tutto questo?<\/p>\n

<\/p>\n

Passo 4: server per applicazioni web<\/h3>\n

<\/p>\n

Quindi, hai un file impacchettato che pu\u00f2 essere eseguito o distribuito. Affinch\u00e9 l'applicazione porti realmente valore, deve avere qualche servizio o interfaccia, ma devi trovare un posto dove ospitarlo.<\/p>\n

<\/p>\n

L'applicazione web pu\u00f2 essere ospitata su un server per applicazioni web. Il server per applicazioni offre un ambiente in cui \u00e8 possibile eseguire la logica software dal pacchetto, gestire il rendering dell'interfaccia e aprire servizi web tramite socket. Hai bisogno di un server HTTP e di alcuni altri ambienti (come una macchina virtuale, per esempio) per installare il server per applicazioni. Per ora, immaginiamo di conoscere tutto ci\u00f2 durante il processo (anche se di contenitori parler\u00f2 pi\u00f9 avanti).<\/p>\n

<\/p>\n

Ci sono diversi server per applicazioni web open source.<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Abbiamo gi\u00e0 quasi realizzato una catena DevOps funzionante. Ottimo lavoro!<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

In pratica, qui puoi fermarti; dopo te la cavi da solo, ma \u00e8 utile parlare anche della qualit\u00e0 del codice.<\/p>\n

<\/p>\n

Passo 5: Copertura dei test<\/h3>\n

<\/p>\n

I testare richiedono molto tempo e impegno, ma \u00e8 meglio identificare subito gli errori e migliorare il codice per soddisfare gli utenti finali. A questo scopo ci sono molti strumenti open source che non solo testano il codice, ma forniscono anche suggerimenti su come migliorarlo. La maggior parte degli strumenti CI\/CD pu\u00f2 integrarsi con questi strumenti e automatizzare il processo.<\/p>\n

<\/p>\n

I test sono suddivisi in due parti: framework di test per scrivere ed eseguire i test, e strumenti con suggerimenti per migliorare la qualit\u00e0 del codice.<\/p>\n

<\/p>\n

Framework di test<\/h3>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Strumenti con suggerimenti per la qualit\u00e0<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

La maggior parte di questi strumenti e framework sono scritti per Java, Python e JavaScript, poich\u00e9 C++ e C# sono proprietari (anche se GCC ha un codice sorgente aperto).<\/p>\n

<\/p>\n

Abbiamo implementato strumenti di copertura dei test, e ora il pipeline DevOps dovrebbe apparire come mostrato nel diagramma all'inizio della guida.<\/p>\n

<\/p>\n

Passi aggiuntivi<\/h2>\n

<\/p>\n

Container<\/h3>\n

<\/p>\n

Come gi\u00e0 detto, il server delle applicazioni pu\u00f2 essere ospitato su una macchina virtuale o su un server, ma i container sono pi\u00f9 popolari.<\/p>\n

<\/p>\n

Cosa sono i container<\/a><\/noindex>? \u0412\u043a\u0440\u0430\u0442\u0446\u0435, \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0435\u0441\u0442\u0430, \u0447\u0435\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0431\u0435\u0437 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u043d\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c, \u043d\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0432\u043c\u0435\u0449\u0430\u0435\u0442 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0438\u0445 \u0437\u0430\u0442\u0440\u0430\u0442.<\/p>\n

<\/p>\n

Per i container si usa normalmente Docker e Kubernetes, anche se ci sono altre opzioni.<\/p>\n

<\/p>\n

\"Guida<\/a><\/noindex><\/p>\n

<\/p>\n

Leggi articoli su Docker e Kubernetes su Opensource.com<\/a><\/noindex>:<\/p>\n

<\/p>\n