{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Guida per principianti: creiamo una pipeline DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se sei un principiante nel DevOps, dai un'occhiata a questa guida per creare il tuo primo pipeline in cinque fasi.<\/i><\/p>\n

\"Guida<\/p>\n

Il DevOps \u00e8 diventato la soluzione standard per correggere processi di sviluppo software lenti, disconnessi o malfunzionanti. Il problema \u00e8 che, se sei un principiante nel DevOps e non sai da dove cominciare, potresti non avere una comprensione di questi metodi. In questo articolo parler\u00f2 della definizione di un pipeline DevOps e fornir\u00f2 una guida alla sua creazione in cinque passi. Anche se questa guida non \u00e8 esaustiva, dovrebbe darti una base per iniziare il tuo percorso e ampliare le tue conoscenze in futuro. Ma iniziamo con la storia.<\/p>\n

Il mio viaggio nel DevOps<\/h3>\n

\nIn passato ho lavorato nel team cloud della Citi Group, sviluppando un'app web Infrastructure-as-a-Service (IaaS) per gestire l'infrastruttura cloud di Citi, ma sono sempre stato interessato a come rendere il processo di sviluppo pi\u00f9 efficiente e a portare cambiamenti culturali positivi nel team di sviluppo. La risposta l'ho trovata in un libro raccomandato da Greg Lavender, Chief Technology Officer di Citi per l'architettura cloud e l'infrastruttura. Il libro si intitolava \"The Phoenix Project\"The Phoenix Project<\/a><\/noindex>, e spiega i principi del DevOps, presentandosi come un romanzo.<\/p>\n

Nella tabella sul retro del libro viene mostrato con quale frequenza diverse aziende distribuiscono i loro sistemi in ambienti di rilascio:<\/p>\n

Amazon: 23.000 al giorno
\nGoogle: 5.500 al giorno
\nNetflix: 500 al giorno
\nFacebook: Una volta al giorno
\nTwitter: 3 volte a settimana
\nAzienda tipica: Una volta ogni 9 mesi<\/p>\n

Come sono possibili le frequenze di Amazon, Google e Netflix? \u00c8 tutto perch\u00e9 queste aziende hanno trovato un modo per creare quasi un pipeline DevOps ideale.
\n<\/a><\/noindex>
\nEravamo lontani da questo fino a quando non abbiamo implementato DevOps in Citi. All'epoca nella mia squadra c'erano diversi ambienti, ma il deployment sul server di sviluppo era completamente manuale. Tutti gli sviluppatori avevano accesso solo a un server di sviluppo basato su IBM WebSphere Application Server Community Edition. Il problema era che il server si spegneva ogni volta che pi\u00f9 utenti tentavano di eseguire il deployment contemporaneamente, quindi gli sviluppatori dovevano avvisarsi a vicenda delle proprie intenzioni, il che era piuttosto frustrante. Inoltre, c'erano problemi con la copertura del codice a basso livello, i processi ingombranti del deployment manuale e l'assenza della possibilit\u00e0 di tracciare il deployment del codice collegato a un compito specifico o a una storia utente.<\/p>\n

Ho capito che dovevo fare qualcosa e ho trovato un collega con la mia stessa visione. Abbiamo deciso di collaborare per creare il nostro primo pipeline DevOps: lui ha installato una macchina virtuale e un server applicativo Tomcat, mentre io lavoravo su Jenkins, integravo Atlassian Jira e BitBucket e mi occupavo della copertura del codice. Questo progetto secondario \u00e8 stato molto fruttuoso: abbiamo automatizzato quasi completamente molti processi, raggiunto praticamente il 100% di operativit\u00e0 del nostro server di sviluppo, garantito tracciabilit\u00e0 e migliorato la copertura del codice, oltre ad aver aggiunto la possibilit\u00e0 di collegare i branch in Git con i compiti in Jira o con il deployment. La maggior parte degli strumenti che abbiamo utilizzato per costruire la nostra pipeline DevOps erano open source.<\/p>\n

Ora capisco quanto fosse semplice la nostra pipeline DevOps: non abbiamo utilizzato estensioni come Jenkins files o Ansible. Tuttavia, questa semplice pipeline funzionava bene, forse grazie al principio di Pareto (noto anche come regola 80\/20).<\/p>\n

Una breve introduzione a DevOps e alla pipeline CI\/CD<\/h3>\n

\nSe chiedi a diverse persone: \u00abCos'\u00e8 DevOps?\u00bb, probabilmente riceverai diverse risposte. DevOps, proprio come Agile, si \u00e8 evoluto per comprendere molte discipline diverse, ma la maggior parte delle persone sar\u00e0 d'accordo su alcune cose: DevOps \u00e8 una pratica di sviluppo software o un ciclo di vita dello sviluppo software (SDLC), il cui principio centrale \u00e8 il cambiamento della cultura in cui sviluppatori e non sviluppatori esistono in un ambiente in cui:<\/p>\n

Le operazioni che una volta venivano eseguite manualmente sono automatizzate;
\nOgnuno fa ci\u00f2 in cui \u00e8 migliore;
\nIl numero di implementazioni in un dato intervallo di tempo aumenta; Aumenta la capacit\u00e0;
\nAumenta la flessibilit\u00e0 nello sviluppo.<\/p>\n

Sebbene avere gli strumenti software giusti non sia l'unica cosa necessaria per creare un ambiente DevOps, alcuni strumenti sono essenziali. Uno strumento chiave \u00e8 l'integrazione continua e il deployment continuo (CI\/CD). In questo pipeline, l'ambiente ha diverse fasi (ad esempio, DEV, INT, TST, QA, UAT, STG, PROD), molte operazioni sono automatizzate e gli sviluppatori possono scrivere codice di alta qualit\u00e0, ottenere flessibilit\u00e0 nello sviluppo e un'alta frequenza di distribuzioni.<\/p>\n

Questo articolo descrive un approccio a cinque fasi per creare un pipeline DevOps, simile a quello illustrato nel diagramma seguente, utilizzando strumenti open source.<\/p>\n

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

\nLa prima cosa di cui hai bisogno \u00e8 uno strumento per CI\/CD. Jenkins, uno strumento open source basato su Java e distribuito con licenza MIT, \u00e8 il mezzo che ha reso popolare la direzione DevOps ed \u00e8 diventato lo standard di fatto.<\/p>\n

Ma cos'\u00e8 Jenkins? Consideralo come un telecomando universale magico che pu\u00f2 comunicare con vari servizi e strumenti e metterli in ordine. Da solo, uno strumento CI\/CD come Jenkins \u00e8 inutile, ma diventa pi\u00f9 potente man mano che si collega a vari strumenti e servizi.<\/p>\n

Jenkins \u00e8 solo uno dei tanti strumenti open source per CI\/CD che puoi utilizzare per costruire un pipeline DevOps.<\/p>\n

Jenkins: Creative Commons e MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Ecco come appaiono i processi DevOps con lo strumento CI\/CD:<\/p>\n

\"Guida<\/p>\n

Hai uno strumento CI\/CD in esecuzione sul tuo localhost, ma per il momento puoi fare poco. Passiamo alla fase successiva del viaggio nel mondo DevOps.<\/p>\n

Passo 2: Gestione dei sistemi di controllo del codice sorgente<\/h3>\n

\nIl modo migliore (e forse pi\u00f9 semplice) per verificare che il tuo strumento CI\/CD possa fare magie \u00e8 integrarsi con uno strumento di controllo del codice sorgente (SCM). Perch\u00e9 hai bisogno del controllo del codice sorgente? Supponiamo che tu stia sviluppando un'applicazione. Ogni volta che crei un'applicazione, programmi, indipendentemente dal fatto che tu stia utilizzando Java, Python, C++, Go, Ruby, JavaScript o uno dei miliardi di linguaggi di programmazione. Il codice che scrivi \u00e8 chiamato codice sorgente. All'inizio, specialmente quando lavori da solo, \u00e8 probabile che tu possa mettere tutto in una directory locale. Ma quando il progetto cresce e inviti altre persone a collaborare, hai bisogno di un modo per evitare conflitti durante uno scambio efficace delle modifiche. Hai anche bisogno di un modo per ripristinare versioni precedenti, perch\u00e9 fare backup e copiare\/incollare in esse \u00e8 ormai obsoleto. Hai bisogno di qualcosa di meglio.<\/p>\n

\u00c8 qui che uno strumento di controllo del codice sorgente diventa praticamente indispensabile. Questo strumento salva il tuo codice nei repository, tiene traccia delle versioni e coordina il lavoro dei partecipanti al progetto.<\/p>\n

Sebbene esistano molti strumenti di controllo del codice sorgente, Git \u00e8 lo standard, e questo \u00e8 vero. Ti consiglio vivamente di utilizzare Git, anche se, se vuoi, ci sono altre opzioni open source.<\/p>\n

Git: GPLv2 e LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Ecco come appare un pipeline DevOps con l'aggiunta di strumenti di controllo del codice sorgente.<\/p>\n

\"Guida<\/p>\n

Lo strumento CI\/CD pu\u00f2 automatizzare i processi di verifica, recupero del codice sorgente e collaborazione tra i membri. Non male? Ma come trasformarlo in un'applicazione funzionante, in modo che miliardi di persone possano utilizzarla e apprezzarla?<\/p>\n

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

\nOttimo! Puoi controllare il codice e apportare modifiche al sistema di controllo del codice sorgente, oltre a invitare i tuoi amici a collaborare allo sviluppo. Ma non hai ancora creato un'applicazione. Per creare un'applicazione web, deve essere compilata e impacchettata in un formato di pacchetto distribuibile o eseguita come file eseguibile. (Nota che un linguaggio di programmazione interpretato, come JavaScript o PHP, non necessita di compilazione).<\/p>\n

Utilizza uno strumento di automazione della build. Indipendentemente dallo strumento di automazione della build che decidi di utilizzare, tutti perseguono lo stesso obiettivo: compilare il codice sorgente in un formato desiderato e automatizzare il compito di pulizia, compilazione, test e distribuzione in un ambiente specifico. Gli strumenti di build varieranno a seconda del tuo linguaggio di programmazione, ma ecco alcune opzioni comuni open source.<\/p>\n

Nome
\nLicenza
\nLinguaggio di programmazione<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Fantastico! Puoi inserire i file di configurazione dello strumento di automazione della build nel sistema di gestione del codice sorgente e permettere al tuo strumento CI\/CD di assemblare tutto insieme.<\/p>\n

\"Guida<\/p>\n

Tutto bene, vero? Ma dove distribuire la tua applicazione?<\/p>\n

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

\nFinora hai un file impacchettato, che pu\u00f2 essere sia eseguibile che installabile. Affinch\u00e9 qualsiasi applicazione sia veramente utile, deve fornire qualche servizio o interfaccia, ma hai bisogno di un contenitore per ospitare la tua applicazione.<\/p>\n

Un server per applicazioni web \u00e8 proprio quel contenitore. Fornisce un ambiente in cui pu\u00f2 essere definita la logica del pacchetto distribuito. Il server fornisce anche un'interfaccia e offre servizi web, aprendo socket al mondo esterno. Hai bisogno di un server HTTP, oltre a un certo ambiente (ad esempio, una macchina virtuale) per la sua installazione. Nel frattempo, supponiamo che tu ne sappia di pi\u00f9 in seguito (anche se di seguito parler\u00f2 dei contenitori).<\/p>\n

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

Nome
\nLicenza
\nLinguaggio di programmazione<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Il tuo pipeline DevOps \u00e8 quasi pronto per l'uso. Ottimo lavoro!<\/p>\n

\"Guida<\/p>\n

Anche se puoi fermarti qui e gestire l'integrazione da solo, la qualit\u00e0 del codice \u00e8 un aspetto fondamentale per un sviluppatore di applicazioni, e su questo bisogna prestare attenzione.<\/p>\n

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

\nL'implementazione dei test pu\u00f2 rappresentare un ulteriore impegno, ma gli sviluppatori devono rilevare eventuali errori nell'applicazione nelle fasi iniziali e migliorare la qualit\u00e0 del codice per garantire che gli utenti finali siano soddisfatti. Fortunatamente, esistono numerosi strumenti open source per testare il tuo codice e generare suggerimenti per migliorare la sua qualit\u00e0. Anche meglio, la maggior parte degli strumenti CI\/CD pu\u00f2 integrarsi con questi strumenti e automatizzare il processo.<\/p>\n

Il testing del codice si compone di due parti: framework di testing del codice, che aiutano a scrivere e eseguire i test, e strumenti per generare suggerimenti, che aiutano a migliorare la qualit\u00e0 del codice.<\/p>\n

Sistemi di testing del codice<\/b><\/p>\n

Nome
\nLicenza
\nLinguaggio di programmazione<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Sistemi di raccomandazione per migliorare il codice<\/b><\/p>\n

Nome
\nLicenza
\nLinguaggio di programmazione<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Nota che la maggior parte degli strumenti e framework menzionati sopra sono scritti per Java, Python e JavaScript, poich\u00e9 C++ e C# sono linguaggi di programmazione proprietari (anche se GCC \u00e8 open source).<\/p>\n

Ora che hai implementato gli strumenti di copertura del codice testato, il tuo pipeline DevOps dovrebbe assomigliare al diagramma mostrato all'inizio di questa guida.<\/p>\n

Ulteriori passi<\/h3>\n

\nContenitori<\/b><\/p>\n

Come ho gi\u00e0 detto, puoi ospitare il tuo server su una macchina virtuale o un server, ma i container sono una soluzione popolare.<\/p>\n

Cosa sono i container? In breve, una macchina virtuale ha bisogno di una grande quantit\u00e0 di memoria di sistema operativo, superiore alla dimensione dell'applicazione, mentre un container ha bisogno solo di alcune librerie e configurazioni per eseguire l'applicazione. \u00c8 chiaro che le macchine virtuali hanno ancora applicazioni importanti, ma il container \u00e8 una soluzione leggera per ospitare l'applicazione, incluso il server delle applicazioni.<\/p>\n

Sebbene ci siano altre opzioni di container, i pi\u00f9 popolari sono Docker e Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Strumenti di automazione intermedia<\/b><\/p>\n

Il nostro pipeline DevOps \u00e8 principalmente orientato alla co-creazione e distribuzione di applicazioni, ma esistono molte altre cose che si possono fare con gli strumenti DevOps. Uno di questi \u00e8 l'uso di strumenti Infrastructure as Code (IaC), noti anche come strumenti di automazione intermedia. Questi strumenti aiutano ad automatizzare l'installazione, la gestione e altre attivit\u00e0 per il middleware. Ad esempio, uno strumento di automazione pu\u00f2 estrarre applicazioni come server di applicazioni, database e strumenti di monitoraggio, con le configurazioni corrette e distribuirle su un server di applicazioni.<\/p>\n

Ecco alcuni strumenti di automazione intermedia a codice aperto:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache o GPL<\/p>\n

\"Guida<\/p>\n

Scopri i dettagli su come ottenere una professione richiesta da zero o fare un Level Up in abilit\u00e0 e stipendio, seguendo i corsi online a pagamento di SkillFactory:<\/p>\n