Newsgroup: it.lavoro.informatica
Titolo: CI/CD pipeline con docker

Nel mio attuale progetto, stiamo definendo una CI/CD pipeline da zero.
 
Credo che qualcuno qui dentro (rootkit?) abbia gia` usato docker per 
questo e vorrei chiedere se e` una buona idea usarlo anche nel nostro caso.
 
Per fortuna, abbiamo liberta` di scelta sulle tecnologie da adottare. 
Usiamo principalmente Java/Spring Boot per il back-end e 
Angular/Typescript per il front-end.
 
Useremmo Jenkins Blue Ocean per la pipeline, SonarQube per i quality 
gates, Checkmarx e BlackDuck per i security scans.
 
La nostra esigenza e`:
 
1) Lato CI: di integrare il lavoro degli sviluppatori il piu` 
frequentemente possibile, fare un left-shifting dei controlli di 
sicurezza in modo da avere un feedback il piu` immediato possibile se 
nuove secuirity vulnerabilities vengono introdotte nel codice;
 
2) Lato CD: di fare deployment automatico dell'intero sistema su AWS, ad 
ogni merge su master, possibilimente in maniera blue/green.
 
Abbiamo intenzione di usare docker (quindi AWS ECR per il registry) e 
stiamo valutando tecnologie per il deployment (AWS ECS, Fargate, etc..).
 
Non abbiamo grosse esigenze di orchestrazione al momento (quindi non 
stiamo guardando a Kubernetes/EKS, per ora).
 
In quanto a CI, io vorrei spingere per il trunk-based development e 
avere short-lived feature branches che convergono in master il piu` 
frequentemente possibile. Le funzionalita` incomplete sarebbero 
mascherate da feature toggles.
 
Jenkins farebbe partire il build su master (che ovviamente include unit 
test ed integration test), sfornerebbe le immagini docker e farebbe un 
push su ECR.
 
Da quel punto in poi, quali consigli avete sul deployment? Conviene 
usare Fargate? Conviene usare ECS + Terraform?
 
L'idea sarebbe di fare un deployment su un sistema "green", lanciare gli 
acceptance tests e i performance tests e, se tutto passa, switchare il 
"blue". Conviene pensare da subito al blue/green o e` un'inutile 
complicazione?

On 20/07/2019 16:19, 4ndre4 wrote:
 
[...]
 
Ps.: se a qualcuno interessasse, sto leggendo i post di Brikman:
 
https://www.ybrikman.com/writing/2015/11/11/running-docker-aws-ground-up/
 
https://www.ybrikman.com/writing/2015/05/19/docker-osx-dev/
 
https://www.ybrikman.com/writing/2016/03/31/infrastructure-as-code-microservices-aws-docker-terraform-ecs/
 
 

 usare Fargate? Conviene usare ECS + Terraform?
 
io sono un fan sfegatato di ansible. ormai lo uso anche per fare il sugo, 
quindi anche per fare i deploy.
 
 

Grazie! Sì, anche noi adotteremo ad Ansible. Non ho mai usato OpenShift ma tutti me ne parlano strabene. Approfondirò. 
 
Vorrei seguire un approccio "evoluzionario" all'architettura del nostro sistema: partire da qualcosa di semplice ed incrementarne le funzionalità sprint dopo sprint.
 
Vorrei solo avere giornate di 48 ore per seguire le tecnologie frontend, quelle backend e devsecops :-/

 quelle backend e devsecops :-/
 
io quelle di frontend sono anni che non le guardo nemmeno e quelle di 
backend mi stanno cominciando a stufare più che altro perché la qualità 
delle commesse è quella che è. 
almeno in italia vedo che se uno si specializza *per* *bene* in 
tecnologie devops ha davanti autentiche praterie. una certificazione della 
cloud native foundation o redhat secondo me valgono 50 certificazioni 
java o qualsiasi altro linguaggio. 
poi salteranno fuori le volpi del c++ e del cobol a dire che l'uva è solo 
una moda.

 java o qualsiasi altro linguaggio.
 
Vero. E` una valutazione che ho fatto anch'io, anche perche` il mondo 
DevOps mi sembra molto piu` interessante dello sviluppo, in questo 
momento. Sara` che dopo un ventennio, mi sono un po' stufato anche io.
I tool di sviluppo non presentano vere innovazioni da un bel po' di 
anni, mentre dal punto di vista "ops" c'e` tanto fermento.
Ho colleghi che si sono totalmente spostati su quello. Ho sempre 
ritenuto DevOps piu` come una cultura che non un ruolo, ma cio` che c'e` 
da sapere, dal punto di vista infrastrutturale, architetturale, di 
integrazione, ecc..., e` talmente vasto e vario da rappresentare una 
specializzazione a se`.

 io quelle di frontend sono anni che non le guardo 
 
Perchè il livello è basso/concorrenza non professionale basso costo o che altro?


diciamo che sviluppare i frontend non mi ha mai attirato molto. un buon 
contributo alla frustrazione l'hanno dato i vari grunt, gulp, bower, yarn 
e compagnia bella che rendevano le build una specie di giostra medievale.
e poi oggettivamente su tanti progetti occuparsi del fe è una gran menata.

 e poi oggettivamente su tanti progetti occuparsi del fe è una gran menata.
 
Si`, troppa troppa roba. A me viene ancora proposto di cercare 
sviluppatori Full Stack, sui progetti. Per un periodo la consideravo una 
cosa fattibile. Ora mi sembra un'illusione. Devi conoscere almeno 
Angular e React, il primo che (almeno qui in UK) sta progressivamente 
scendendo, ma ancora dominante, e il secondo che sta guadagnando terreno 
(per fortuna: e` un gran bel framework). Oltre a dover conoscere 
TypeScript in aggiunta a JavaScript, un buon superset CSS (Sass o LESS), 
piu` tutte le tecnologie di testing, bundling (e.g. webpack), etc..
Ci vuole veramente tanto tanto tempo, pratica e studio.
A me, sinceramente, il front-end non dispiace affatto. Oggi, con React e 
tool come Gatsby, e` diventato tutto molto interessante. Il problema e` 
il tempo!!
 
 

 questo e vorrei chiedere se e` una buona idea usarlo anche nel nostro caso.
 
sto anch'io impostando una pipeline CI/CD. Siccome il deploy lo faccio con Ansible, penso non utilizzero' docker sul fronte CD.
 
Per quanto riguarda CI, vorrei usarlo per il database, visto che con docker non ti serve ripristinare lo stato del database dopo aver fatto girare i test che toccano i dati.
 
In realta' lo usero' (secondi i miei piani) anche per la la build (compilazione + unit test) e per lanciare gli user acceptance test e integration test.
 
Il tutto orchestrato da AWS CodePipeline.

 build una specie di giostra medievale.
 
Letteralmente mai sentiti prima (so'na pippa sul web), giusto grunt per sentito dire ma ho capito la tipologia di casini purtroppo visto che in rete ne girano di agghiaccianti posts e logs al riguardo. Non ci metterei mai mano pagato a ste robe.


Io son capace di perdere giornate dietro ai vari webpack/grunt/gulp e stocazzo. Poi 
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
 
 
  ngw

 Per quanto riguarda CI, vorrei usarlo per il database, visto che con docker non ti serve ripristinare lo stato del database dopo aver fatto girare i test che toccano i dati.
 
Prova a vedere se questo fa al caso tuo: 
https://www.testcontainers.org/
 

 Noi vorremmo usare Ansible + Docker + Packer ma non vorremmo sovraingegnerizzare - il rasoio di Occam e` sempre li` in agguato :D
 
Prova a guardare CircleCI, puoi semplificare molto
 
  ngw

Grazie! 

 Prova a guardare CircleCI, puoi semplificare molto
 
Ho colloquiato piu` di una persona che lo ha usato. E` veramente interessante e sembra che offra tutte le caratteristiche che ci servano. Purtroppo non ho potere decisionale sull'utilizzo di certe tecnologie. Dobbiamo limitarci a cio` che e` sul TechRadar del cliente. Dovremo adattarci ad usare Jenkins (Blue Ocean) per la pipeline.


Si l'avevo gia' visto, non sono sicuro mi serva nel mio contesto. Se mi serve so che posso usarlo. 
 
Voi che strategia usate per fare testing di codice che fa chiamate al db? Intendo tirate su e giu' docker ad ogni test oppure una sola volta per suite. Oppure non usate docker ma il buon vecchio DBUnit o simili?

 Voi che strategia usate per fare testing di codice che fa chiamate al db? 
 
Nel mio precedente progetto, testavamo i vari *Repository.java usando H2 e creando i dati di test al momento del build del progetto (sfruttando i meccanismi interni di Hibernate). Quindi, fondamentalmente unit tests. Non era pero` un metodo che mi piaceva, perche` il db era Postgres, facilissimo da dockerizzare e avremmo potuto usare quello per i test (che sarebbero pero` diventati integration tests). In quel caso, si`, lanci il container, popoli i dati di test esegui i test e butti via tutto. Lo farei per suite, pero`, non per singolo test. Noi non abbiamo mai avuto il tempo di farlo pero`. Nel mio attuale progetto, non abbiamo ancora pensato a come eseguire i test sul database. E` un po' complicato perche` usiamo database a grafo, non relazionali, e AWS Neptune nello specifico (usiamo SPARQL e RDF/XML).
Anzi, se qualcuno ha idea di come usare docker in quel contesto...


da quello che leggo Neptune e' un managed service, quindi Docker puoi scordatelo :) 
Se l'interfaccia e' pero' SQARQL potresti dockerizzare un db che supporta quell'interfaccia (Apache Jena Fuseki), oppure ricreare l'infrastruttura con CloudFormation (opzionale) e uploadare i dati all'inizio della suite.

 Se l'interfaccia e' pero' SQARQL potresti dockerizzare un db che supporta quell'interfaccia (Apache Jena Fuseki), oppure ricreare l'infrastruttura con CloudFormation (opzionale) e uploadare i dati all'inizio della suite.
 
Si`, in teoria potremmo usare un qualunque graphdb che adotti gli standard W3C. Io pero` volevo evitarlo ed usare direttamente Neptune. L'idea era proprio quella di avere delle spot instance da tirare su per il tempo degli acceptance/performance tests. Vedremo :)