{"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 un pipeline DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Guida<\/p>\n

DevOps \u00e8 diventato la soluzione standard per risolvere processi di sviluppo software lenti, disconnessi o non funzionanti. Il problema \u00e8 che, se sei un principiante in DevOps e non sai da dove cominciare, potresti mancare di comprensione di questi metodi. In questo articolo parleremo di cosa sia un pipeline DevOps, insieme a una guida per costruirne uno in cinque passi. Anche se questo tutorial non \u00e8 esaustivo, dovrebbe fornirti una base per iniziare il tuo percorso e ampliare le tue conoscenze in futuro. Ma cominciamo con la storia.<\/p>\n

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

\nIn passato ho lavorato nel team cloud di Citi Group, sviluppando un'applicazione web per l'Infrastructure-as-a-Service (IaaS) per la gestione dell'infrastruttura cloud di Citi, ma sono sempre stato interessato a come rendere il processo di sviluppo pi\u00f9 efficiente e portare cambiamenti culturali positivi nel team di sviluppo. La risposta l'ho trovata in un libro raccomandato da Greg Lavender, il direttore tecnico di Citi per l'architettura e l'infrastruttura cloud. Il libro si intitola \u00abIl Progetto Fenice\u00bb (Il Progetto Fenice<\/a><\/noindex>), e in esso vengono spiegati i principi del DevOps, presentati come un romanzo.<\/p>\n

Nella tabella sul retro del libro \u00e8 mostrato quanto spesso le diverse aziende distribuiscono i loro sistemi in un ambiente 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? Tutto perch\u00e9 queste aziende hanno trovato il modo di creare una pipeline DevOps quasi perfetta.
\n<\/a><\/noindex>
\nEravamo lontani da questo fino a quando non abbiamo implementato DevOps in Citi. All'epoca, nel mio team c'erano vari ambienti, ma il deployment sul server di sviluppo era completamente manuale. Tutti gli sviluppatori avevano accesso a un solo 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 informarsi reciprocamente delle loro intenzioni, il che era piuttosto doloroso. Inoltre, c'erano problemi con una copertura del codice a basso livello, processi di deployment manuali ingombranti e l'assenza di tracciabilit\u00e0 del codice deployato associato a un determinato task o storia utente.<\/p>\n

Ho capito che era necessario agire e ho trovato un collega con cui condividere la stessa visione. Abbiamo deciso di collaborare per creare un primo pipeline DevOps: lui ha installato una macchina virtuale e un server applicativo Tomcat, mentre io lavoravo su Jenkins, integrando Atlassian Jira e BitBucket, e occupandomi della copertura dei test del codice. Questo progetto collaterale \u00e8 stato molto successo: abbiamo quasi completamente automatizzato molti processi, raggiunto un'affidabilit\u00e0 del nostro server di sviluppo del quasi 100%, garantito monitoraggio e migliorato la copertura dei test del codice, e aggiunto la possibilit\u00e0 di collegare i rami in Git con le attivit\u00e0 in Jira o i 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 usato estensioni come Jenkins files o Ansible. Tuttavia, questa pipeline semplice funzionava bene, forse grazie al principio di Pareto (noto anche come regola 80\/20).<\/p>\n

Introduzione al DevOps e alla pipeline CI\/CD<\/h3>\n

\nSe chiedi a diverse persone: \"Che cos'\u00e8 il DevOps?\", probabilmente riceverai risposte diverse. Il DevOps, come l'Agile, si \u00e8 evoluto per comprendere molteplici discipline, ma la maggior parte delle persone concorda su alcuni aspetti: il DevOps \u00e8 una pratica di sviluppo software o un ciclo di vita dello sviluppo software (SDLC) con al centro il cambiamento della cultura, in cui sviluppatori e non sviluppatori operano in un ambiente in cui:<\/p>\n

Sono automatizzate operazioni che prima venivano svolte manualmente;
\nOgnuno fa ci\u00f2 che sa fare meglio;
\nIl numero di implementazioni in un determinato intervallo di tempo aumenta; aumenta la capacit\u00e0 di lavoro;
\nSi migliora la flessibilit\u00e0 nello sviluppo.<\/p>\n

Sebbene avere i giusti strumenti software non sia l'unica cosa necessaria per creare un ambiente DevOps, alcuni strumenti sono indispensabili. Uno strumento chiave \u00e8 l'integrazione continua e il deployment continuo (CI\/CD). In questa pipeline, gli ambienti hanno varie 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 deployment.<\/p>\n

Questo articolo descrive un approccio a cinque fasi per la creazione di una pipeline DevOps, simile a quella mostrata nel diagramma seguente, utilizzando strumenti open source.<\/p>\n

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

\nLa prima cosa necessaria \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 l'approccio DevOps ed \u00e8 diventato lo standard de facto.<\/p>\n

Cos'\u00e8 Jenkins? Pensalo come un magico telecomando universale che pu\u00f2 comunicare con vari servizi e strumenti, organizzandoli. Di per s\u00e9, uno strumento CI\/CD come Jenkins \u00e8 inutile, ma diventa pi\u00f9 potente man mano che si connette a diversi 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 uno strumento CI\/CD:<\/p>\n

\"Guida<\/p>\n

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

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

\nIl miglior (e forse il pi\u00f9 semplice) modo per verificare che il tuo strumento CI\/CD possa fare magie \u00e8 integrarlo con uno strumento di controllo della versione (SCM). Perch\u00e9 hai bisogno del controllo del codice sorgente? Supponiamo che tu stia sviluppando un'applicazione. Ogni volta che crei un'app, stai programmando e non importa se usi Java, Python, C++, Go, Ruby, JavaScript o uno qualsiasi dei tantissimi linguaggi di programmazione. Il codice che scrivi si chiama codice sorgente. All'inizio, specialmente quando lavori da solo, probabilmente puoi mettere tutto in una directory locale. Ma quando il progetto cresce e inviti altre persone a collaborare, hai bisogno di un modo per prevenire conflitti mentre condividi efficacemente le modifiche. Hai anche bisogno di un modo per ripristinare versioni precedenti, perch\u00e9 creare backup e fare copia\/incollo \u00e8 ormai obsoleto. Hai bisogno di qualcosa di meglio per te e per i tuoi compagni di squadra.<\/p>\n

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

Sebbene esistano numerosi strumenti di controllo del codice sorgente, Git \u00e8 lo standard, e questo \u00e8 un dato di fatto. Ti consiglio vivamente di utilizzare Git, anche se, se lo desideri, 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 una pipeline DevOps con l'aggiunta di strumenti di controllo del codice sorgente.<\/p>\n

\"Guida<\/p>\n

Uno strumento CI\/CD pu\u00f2 automatizzare i processi di verifica, acquisizione del codice sorgente e collaborazione tra i membri. Non sembra male? Ma come creare un'applicazione funzionante che miliardi di persone possano usare e apprezzare?<\/p>\n

Passo 3: Creazione dello strumento di automazione della compilazione<\/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 fare un'applicazione web, deve essere compilata e impacchettata in un formato di pacchetto distribuibile o eseguita come file eseguibile. (Tieni presente che un linguaggio di programmazione interpretato, come JavaScript o PHP, non richiede compilazione).<\/p>\n

Utilizza uno strumento di automazione della compilazione. Indipendentemente dallo strumento di automazione della compilazione che decidi di utilizzare, tutti perseguono lo stesso obiettivo: raccogliere il codice sorgente in un formato desiderato e automatizzare il compito di pulizia, compilazione, test e distribuzione in un determinato ambiente. Gli strumenti di compilazione 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

Ottimo! Puoi inserire i file di configurazione dello strumento di automazione della build nel sistema di gestione del codice sorgente e lasciare che il tuo strumento CI\/CD componga tutto insieme.<\/p>\n

\"Guida<\/p>\n

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

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

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

Il server per applicazioni web \u00e8 proprio quel contenitore. Il server fornisce un ambiente in cui pu\u00f2 essere definita la logica del pacchetto da distribuire. Inoltre, il server offre un'interfaccia e mette a disposizione servizi web, aprendo socket per il mondo esterno. Hai bisogno di un server HTTP, oltre a un ambiente (come una macchina virtuale) per la sua installazione. Per ora, supponiamo che tu lo scopra pi\u00f9 avanti (anche se parler\u00f2 di contenitori pi\u00f9 sotto).<\/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 fondamentale per uno sviluppatore di applicazioni e vale la pena prendersene cura.<\/p>\n

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

\nImplementare i test pu\u00f2 essere un'ulteriore richiesta complessa, ma gli sviluppatori devono rilevare eventuali errori nell'applicazione in una fase iniziale e migliorare la qualit\u00e0 del codice per garantire che gli utenti finali siano soddisfatti. Fortunatamente, esistono molti strumenti open source per testare il tuo codice e fornire raccomandazioni per migliorare la sua qualit\u00e0. Ancora meglio, la maggior parte degli strumenti CI\/CD pu\u00f2 integrarsi con questi strumenti e automatizzare il processo.<\/p>\n

Il testing del codice consiste in due parti: framework di testing del codice che aiutano a scrivere e eseguire test, e strumenti di suggerimento 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 dei framework menzionati sopra sono scritti per Java, Python e JavaScript, mentre C++ e C# sono linguaggi di programmazione proprietari (sebbene GCC abbia un codice sorgente aperto).<\/p>\n

Ora che hai implementato strumenti di copertura del codice attraverso dei test, il tuo pipeline DevOps dovrebbe apparire simile al diagramma mostrato all'inizio di questa guida.<\/p>\n

Passi aggiuntivi<\/h3>\n

\nContainer<\/b><\/p>\n

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

Cosa sono i contenitori? In breve, una macchina virtuale richiede un ingente volume di memoria del sistema operativo, superiore alla dimensione dell'applicazione, mentre un contenitore ha bisogno solo di alcune librerie e configurazioni per eseguire l'applicazione. \u00c8 evidente che le macchine virtuali hanno ancora applicazioni importanti, ma un contenitore \u00e8 una soluzione leggera per l'hosting di applicazioni, inclusi i server di applicazione.<\/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 intermedi<\/b><\/p>\n

Il nostro pipeline DevOps \u00e8 principalmente focalizzato sulla co-creazione e sul disegno di applicazioni, ma ci sono molte altre cose che possono essere fatte con gli strumenti DevOps. Una di queste \u00e8 l'utilizzo di strumenti Infrastructure as Code (IaC), noti anche come strumenti di automazione intermedi. Questi strumenti aiutano ad automatizzare l'installazione, la gestione e altre attivit\u00e0 per il software intermedio. Ad esempio, uno strumento di automazione pu\u00f2 estrarre applicazioni come server di applicazioni, database e strumenti di monitoraggio, con configurazioni appropriate e distribuirle su un server di applicazioni.<\/p>\n

Ecco alcuni strumenti di automazione intermedi open source:<\/p>\n

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

\"Guida<\/p>\n

Scopri come ottenere una professione richiesta da zero o migliorare le tue competenze e stipendio, seguendo corsi online a pagamento di SkillFactory:<\/p>\n