{"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 utilizzando strumenti open source","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Guida
\nCreazione della prima catena DevOps in cinque passi per principianti.<\/em><\/p>\n

<\/p>\n

DevOps \u00e8 diventato la panacea per processi di sviluppo troppo lenti, disconnessi e problematici. Ma \u00e8 necessario avere conoscenze minime in DevOps. Qui verranno esplorati concetti come la catena DevOps e come crearla in cinque passi. Non \u00e8 una guida completa, ma solo una \u201cbase\u201d che pu\u00f2 essere ampliata. Iniziamo con la 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 capire come ottimizzare la catena di sviluppo e migliorare la cultura tra gli sviluppatori. Greg Lavender, il nostro CTO per l'architettura e l'infrastruttura cloud, mi ha consigliato un libro Progetto \u00abFenice\u00bb<\/a><\/noindex>. Spiega splendidamente i principi di DevOps ed \u00e8 anche molto scorrevole.<\/p>\n

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

La tabella sul retro mostra con quale frequenza le aziende rilasciano nuove versioni:<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Da noi in Citi le cose non andavano affatto in questo modo, fino a quando non siamo passati a DevOps. All'epoca la mia squadra aveva ambienti diversi, ma il rilascio sul server di sviluppo avveniva manualmente. Tutti gli sviluppatori avevano accesso solo a un server di sviluppo basato su IBM WebSphere Application Server Community Edition. Ad ogni tentativo contemporaneo di rilascio, il server \"crashava\", e dovevamo ogni volta \u201ctrattare\u201d dolorosamente tra di noi. Inoltre, avevamo una copertura del codice con test insufficiente, un processo di rilascio manuale complesso e nessuna possibilit\u00e0 di monitorare il rilascio del codice sulla base di qualche compito o richiesta del cliente.<\/p>\n

<\/p>\n

Era chiaro che dovevamo fare urgentemente qualcosa, e ho trovato un collega con la mia stessa visione. Abbiamo deciso di creare insieme la prima catena DevOps: lui ha configurato una macchina virtuale e un server applicazioni Tomcat, mentre io mi sono occupato di Jenkins, integrazione con Atlassian Jira e BitBucket, cos\u00ec come della copertura del codice con test. Il progetto \u00e8 stato un successo: abbiamo completamente automatizzato la catena di sviluppo, raggiunto quasi il 100% di uptime del server di sviluppo, e potevamo monitorare e migliorare la copertura del codice con test, e il branch Git poteva essere collegato al rilascio e al compito Jira. E quasi tutti gli strumenti con cui abbiamo costruito la catena DevOps erano open source.<\/p>\n

<\/p>\n

In effetti, la catena era semplificata, dato che non abbiamo nemmeno utilizzato configurazioni avanzate con Jenkins o Ansible. Ma ce l'abbiamo fatta. Forse \u00e8 conseguenza del principio Pareto<\/a><\/noindex> (ovvero la regola 80\/20).<\/p>\n

<\/p>\n

Breve descrizione della catena DevOps e CI\/CD<\/h3>\n

<\/p>\n

DevOps ha diverse definizioni. Come Agile, DevOps comprende diverse discipline. Ma la maggior parte sarebbe d'accordo con la seguente definizione: DevOps \u00e8 un metodo, o ciclo di vita, di sviluppo software, il cui principio principale \u00e8 creare una cultura in cui sviluppatori e altri dipendenti sono \"sulla stessa lunghezza d'onda\", il lavoro manuale \u00e8 automatizzato, ciascuno si occupa di ci\u00f2 che sa fare meglio, aumenta la frequenza delle consegne, la produttivit\u00e0 e la flessibilit\u00e0.<\/p>\n

<\/p>\n

E sebbene solo gli strumenti non siano sufficienti per creare un ambiente DevOps, sono indispensabili. Il pi\u00f9 importante di essi \u00e8 l'integrazione continua e la consegna continua (CI\/CD). Nella catena ci sono diverse fasi per ciascun ambiente (ad esempio, DEV (sviluppo), INT (integrazione), TST (test), QA (controllo qualit\u00e0), UAT (test di accettazione da parte degli utenti), STG (preparazione), PROD (utilizzo)), i compiti manuali sono automatizzati, gli sviluppatori possono scrivere codice di qualit\u00e0, consegnarlo e possono facilmente riposizionarsi.<\/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

Passiamo all'azione.<\/p>\n

<\/p>\n

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

<\/p>\n

Per prima cosa, hai bisogno di uno strumento CI\/CD. Jenkins \u00e8 uno strumento CI\/CD open source scritto in Java con licenza MIT, da cui \u00e8 iniziata la popolarizzazione del movimento DevOps ed \u00e8 diventato di fatto lo standard per CI\/CD.<\/p>\n

<\/p>\n

E cos'\u00e8 Jenkins? Immagina di avere un telecomando magico per vari servizi e strumenti. Di per s\u00e9, uno strumento CI\/CD come Jenkins \u00e8 inutile, ma unito a 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 passaggio successivo.<\/p>\n

<\/p>\n

Passaggio 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 versioni (source control management, SCM). Perch\u00e9 \u00e8 necessario il controllo versioni? Supponiamo che stiate sviluppando un'applicazione. La scrivete in Java, Python, C++, Go, Ruby, JavaScript o in qualsiasi altro linguaggio, ce ne sono tanti. Ci\u00f2 che scrivete \u00e8 chiamato codice sorgente. All'inizio, soprattutto se lavorate da soli, potete salvare tutto in una cartella locale. Ma quando il progetto cresce e si uniscono pi\u00f9 persone, avete bisogno di un modo per condividere le modifiche nel codice, evitando conflitti durante le fusioni. E dovete anche avere un modo per ripristinare versioni precedenti senza utilizzare backup e senza fare copy-paste sui file di codice.<\/p>\n

<\/p>\n

E qui senza SCM non si va da nessuna parte. SCM memorizza il codice nei repository, gestisce le sue versioni e coordina il lavoro tra gli sviluppatori.<\/p>\n

<\/p>\n

Ci sono molti strumenti SCM, ma Git \u00e8 giustamente diventato lo standard de facto. Consiglio di utilizzarlo, anche se ci sono altre opzioni.<\/p>\n

<\/p>\n

\"Guida<\/p>\n

<\/p>\n

Ecco come appare il pipeline DevOps dopo l'aggiunta di SCM.<\/p>\n

<\/p>\n

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

<\/p>\n

Lo strumento CI\/CD pu\u00f2 automatizzare il caricamento e il download del codice sorgente e favorire la collaborazione in team. Non male? Ma come si fa ora a 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. Potete caricare codice e registrare le modifiche nel sistema di controllo versioni, e anche invitare amici a lavorare con voi. Ma ancora non avete un'app. Per renderla un'applicazione web, deve essere compilata e confezionata per la distribuzione o eseguita come file eseguibile. (Un linguaggio di programmazione interpretato, come JavaScript o PHP, non ha bisogno di essere compilato.)<\/p>\n

<\/p>\n

Utilizzate uno strumento di automazione della build. Qualunque strumento scegliate, raccoglier\u00e0 il codice nel formato necessario e automatizzer\u00e0 la pulizia, la compilazione, il testing e la distribuzione. Gli strumenti di build variano a seconda del linguaggio, ma di solito si utilizzano le seguenti opzioni open source.<\/p>\n

<\/p>\n

\"Guida<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Quindi, hai un file pacchettizzato che pu\u00f2 essere eseguito o distribuito. Affinch\u00e9 l'applicazione porti davvero valore, deve avere qualche servizio o interfaccia, ma \u00e8 necessario trovare un posto per tutto questo.<\/p>\n

<\/p>\n

Un'applicazione web pu\u00f2 essere ospitata su un server di applicazioni. Il server di applicazioni fornisce un ambiente in cui \u00e8 possibile eseguire la logica del programma dal pacchetto, eseguire il rendering dell'interfaccia e aprire servizi web tramite socket. Hai bisogno di un server HTTP e di alcuni altri ambienti (una macchina virtuale, ad esempio) per installare il server di applicazioni. Per ora, immaginiamo di avere tutto chiaro nel processo (anche se parler\u00f2 dei container pi\u00f9 avanti).<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

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

<\/p>\n

In linea di principio, qui puoi fermarti, dopodich\u00e9 te la caverai da solo, ma vale la pena parlare anche della qualit\u00e0 del codice.<\/p>\n

<\/p>\n

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

<\/p>\n

Il testing richiede molto tempo e impegno, ma \u00e8 meglio trovare subito gli errori e migliorare il codice per soddisfare gli utenti finali. Per questo scopo, ci sono molti strumenti open source che non solo testeranno il codice, ma offriranno anche consigli su come migliorarlo. La maggior parte degli strumenti CI\/CD pu\u00f2 connettersi a questi strumenti e automatizzare il processo.<\/p>\n

<\/p>\n

Il testing \u00e8 suddiviso in due parti: framework di testing per scrivere ed eseguire test, e strumenti con suggerimenti per migliorare la qualit\u00e0 del codice.<\/p>\n

<\/p>\n

Framework di testing<\/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 \u00e8 scritta per Java, Python e JavaScript, poich\u00e9 C++ e C# sono proprietari (anche se GCC ha codice sorgente aperto).<\/p>\n

<\/p>\n

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

<\/p>\n

Ulteriori passi<\/h2>\n

<\/p>\n

Contenitori<\/h3>\n

<\/p>\n

Come ho gi\u00e0 detto, il server di applicazioni pu\u00f2 essere ospitato su una macchina virtuale o 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 di solito si utilizza 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