Il seguente software deve essere installato sul proprio pc:
Quando parlo di Continuous Integration & Delivery, molto spesso, mi trovo di fronte a persone che credono che basti avere un sistema di build automatico, oppure di fronte a persone che credono che per loro sia qualcosa di inaccessibile! Un'idea diffusa è che gli strumenti necessari per praticarla sono complessi e richiedono parecchio studio e tempo per creare l'infrastruttura di base.
Purtroppo entrambe le posizioni sono estremamente lontane dalla realtà!
Con questo workshop vorrei mostrare una soluzione “chiavi in mano” per sperimentare le pratiche di Continuous Integration & Delivery in pochi minuti! Dimostrando che la sfida non è dominare gli strumenti, ma cambiare noi stessi e il nostro modo di lavorare e approcciare questo argomento in modo differente.
Durante questo workshop creiamo l'infrastruttura di base che ci permette di fare Continuous e lavorememo a un semplice micro-servizio, rilasciato come container docker, che converte i codici colore dal formato HEX al formato HSL e viceversa.
Iniziamo con dare un'indicazione di quale sia una infrastruttura tipica che ci permette di praticare Continuous Integration.
Parliamo di software, quindi i mattoncini che ci servono sono un sistema di Source Code Management (SCM), un repository per gli artefatti e un sistema automatizzato di build. Questi mattoncini li installermo e li configureremo su una VM che chiameremo Turnkey.
Abbiamo bisogno anche di alcuni ambienti separati per eseguire il nostro micro-servizio e per la precisione useremo un ambiente di dev / test e uno di pre-produzione / staging. Ognuno di questi ambienti corrisponde a una VM dedicata.
La nostra infrastruttura è costituita da 3 ambienti differenti che corrispondono 1:1 ad altrettante VMs e per la precisione:
- turnkey: VM per SCM, repository binari e sistema automatizzato di build
- testing: VM per effettuare i test del nostro micro-servizio
- staging: VM configurata in modo identico a quelle di produzione
Possiamo distinguere gli strumenti utilizzati in 2 categorie, in base allo scopo per cui li usiamo:
- Strumenti per l'Infrastruttura:
- Vagrant (provisioning e configurazione di VMs)
- Virtualbox
- Ansible (installazione e configurazione software)
- Strumenti per il Codice:
- git e GitLab-CE (gestione codice sorgente)
- docker-registry (repository binary)
- Jenkins (strumento per effettuare build automatiche)
- Ansible (installazione e configurazione software)
Vagrant è un gestore di Macchine Virtuali (VMs).
Le caratteristiche principali di questo software sono:
- Software Libero: licenza MIT
- disaccoppiamento tra gestore delle VMs e gli 'hypervisors' tramite 'providers'
- libreria pubblica di 'box' pronti all'uso (imamgini di VMs pronte all'uso)
- possiblità di creare nuovi 'box' in modo semplice
- configurazione delle VMs di cui fare il 'provision' tramite file testuale
In questo workshop la nostra infrastruttura è composta da 3 ambienti differenti:
- ambiente con strumenti per lo sviluppo e CI/CD
- ambiente di testing
- ambiente di pre-produzione / staging
E' stata creata una VM per ogni ambiente al fine di mantenerli separati e isolati; per avviare le VM basta lanciare un singolo comando!
cd vagrant
vagrant plugin install vagrant-vbguest
vagrant upAl termine dell'esecuzione del comando vagrant up avremo i nostri 3 ambienti avviati con installato tutto il necessario.
L'installazione del software e una parte della sua configurazione viene fatto in automatico tramite 'Ansible' (vedi il prossimo capitolo).
Ansible è un software che consente di automatizzare le procedure di installazione e configurazione dei sistemi 'unix-like' e 'Ms Windows' (dalla versione 1.7).
Le caratteristiche principali di questo software sono:
- Software Libero: licenza GNU GPL v3
- agent-less: sfrutta le connessioni ssh
- minimale
- estendibile mediante plugin
- sicuro (usa ssh e utenti unix)
- dichiarativo
- idempotente
- semplice da imparare (file basati su yaml)
Ansible si basa sui concetti di 'Inventory', 'Role' 'Task' e 'Playbook'. In questa breve introduzione non entreremo nei dettagli dei concetti elencati sopra, ma in modo semplice possiamo definirli come:
- Inventory: uno o più file che descrivono censiscono i singoli server (nodi) o gruppi di nodi da gestire e che definiscono varibili specifiche per quel nodo o gruppo
- Role: insieme di task, configurazioni e varibili specifiche che servono per installare o configurare un prodotto o servizio e.g. 'docker'
- Task: raccolta di 'istruzioni' basilari che servono per installare o configurare ogni singola parte di un prodotto o servizi più complesso e.g. 'docker machine', 'docker compose', 'enable docker via tcp'
- Playbook: è quello che effettivamente andiamo a leggere ed eseguire. Esso istruisce su come mappare Inventory e Role
Viene sfruttato in 2 momenti distinti e con scopi differenti:
- installazione e configurazione degli ambienti... le 3 VM avviate tramite Vagrant
- deploy e configurazione del nostro micro-service
Nel primo caso viene lanciato automaticamente dal processo di provisioning di Vagrant; mentre, nel secondo caso verrà lanciato dalla nostra 'Build & Delivery Pipeline'
GitLab Community Edition (GitLab-CE) è una piattaforma web per la gestione del codice sorgente basata su git.
Le caratteristiche principali di questo software sono:
- Software Libero: licenza MIT
- gestione repository git
- gestione granulare dei permessi
- issue tracking
- code review tool
- host di documentazione web
- funzionalità per supportare CI/CD (build pipeline, gestione dei deploy)
- integrazione con Docker e Kubernetes
- repository per container docker
- integrazione con sistemi di monitoring
- DevOps Ready and Friendly (lo dichiara 'GitLab Inc.')
GitLab-CE può fare tantissime cose, ma noi lo useremo solo per gestire il repository del codice sorgente. Nella pratica, avremmo potuto usare git "puro", senza alcuna sovrastruttura software per gestire i repository e i permessi e senza alcuna interfaccia web o funzionalità aggiuntiva.
La scelta di usare GitLab-CE non è stata fatta con leggerenzza... Continuous Integration e Continuous Delivery NON possono e NON devono essere ridotte meramente a un sistema di Build Automation; esse fanno parte delle Pratiche eXtreme Programming e della Cultura DevOps e GitLab-CE ha alcune funzionalità utili per supportarci su queste vie, andando altre alla strada del "Continuous". Si è scelto di usare e mostrarvi GitLab-CE semplicemente per fornirvi uno strumento utile per sperimentare altre pratiche e supportarvi nel vostro lavoro quotidiano.
La nostra istanza è avviata come container Docker. Sul repository ufficiale di docker sono presenti parecchie immagini, tra cui quella "ufficiale" di GitLab-CE. Esso è raggiungibile a questo url: http://192.168.50.91:8002/
Una volta eseguito il primo accesso e creata la password per l'utente 'root' possiamo creare il repository per il nostro micro-servizio:
- Create a project:
- Project name: hex2hsl
- Visibility Level: Public
URL repository hex2hsl: http://192.168.50.91:8002/root/hex2hsl.git
Jenkins, da molti, è considerato lo strumento indispensabile e per eccellenza per fare "Continuous Integration", ma sarà vero? Mi sono chiesto più volte cos'è e cosa realmente fa... scavando fino alla radici ho trovato questa risposta:
Jenkins è un Job Scheduler & Executor
Sì, semplicemente esegue e pianifica delle attività. Normalmente queste attività sono le build delle nostre applciazioni, ma nessuno ci vieta di utilizzarlo per altri tipi scopi.
Le caratteristiche principali di questo software sono:
- Software Libero: licenza MIT
- altamente configurabile
- flessibile e duttile
- estendibile con plugin
- gestione e provision integrata dei tool utilizzati nelle attività
- architettura master/slave
In questo workshop lo useremo per il suo scopo principale... esguire build automatiche e permetterci di fare Continuous Integration & Delivery.
Vediamo come cofiguralo partendo da zero applicando alcune buone pratiche per rendere il sistema scalabile, resiliente ed affidabile. La nostra istanza è avviata come container Docker ed è raggiungibile a questo url: http://192.168.50.91:8003/
Prima di iniziare è necessario recuperare la password di default generata in fase di installazione, quindi eseguite in una console i seguenti comandi:
vagrant ssh turnkey
docker exec turnkey_jenkins cat /var/jenkins_home/secrets/initialAdminPasswordWizard iniziale:
- password: vedi codice sopra
- Customize Jenkins: Install Suggested Plugins
- Create First Admin User: Continue as admin
- Instance Configuration: http://192.168.50.91:8003/
Al primo accesso:
- Manage Jenkins -> Configure Global Security: Anyone can do anything
- Manage Jenkins -> Mange Nodes:
- New Node:
- Node Name: schiavo
- mettere la spunta su Permanent Agent
- premere ok
- Pagina successiva:
- Remote root directory: /data/jenkins/nodes/
- Host: 192.168.50.91
- Credentials -> Add -> Jenkins:
- Kind: SSH Username with private key
- Username: vagrant
- Private Key: enter directly
- Key: copia il contenuto del file ./ansible/ssh/id_rsa
- Host Key Verification Strategy: Non verify Verification Strategy
- New Node:
- Manage Jenkins -> Manage Plugins:
- Manage Jenkins -> Global Tool Configuration:
- NodeJS:
- Name: nodejs-8
- Install automatically
- Version: 8.12.0
- Docker:
- Name: docker-latest
- Install automatically
- Version: latest
- NodeJS:
Copyright © 2018 Gianni Bombelli @ Intré S.r.l.
Except where otherwise noted, content on this documentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.