{"id":1785,"date":"2020-10-02T11:15:08","date_gmt":"2020-10-02T09:15:08","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1785"},"modified":"2021-03-17T15:27:33","modified_gmt":"2021-03-17T14:27:33","slug":"gitlab-vs-aws-codepipeline-un-match-allultimo-commit","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/gitlab-vs-aws-codepipeline-un-match-allultimo-commit\/","title":{"rendered":"GitLab VS AWS CodePipeline: un match all\u2019ultimo Commit!"},"content":{"rendered":"\n
GitLab<\/strong> \u00e8 diventato uno tra gli strumenti pi\u00f9 utilizzati dai Devops. Include tante funzionalit\u00e0 in un solo servizio ed \u00e8 possibile installarlo on-premise o utilizzarlo in versione SaaS.<\/p>\n\n\n\n Il piano gratuito \u00e8 sufficiente per alcuni dei pi\u00f9 comuni casi d\u2019uso come ad esempio mantenere una codebase, eseguire pipeline e gestire le informazioni sui progetti. Anche Amazon Web Services permette di implementare sistemi di CI\/CD<\/strong> con un modello di pagamento a consumo attraverso l\u2019uso dei servizi AWS CodeCommit, AWS CodeBuild, AWS CodePipeline<\/strong>.<\/p>\n\n\n\n Selezionare il miglior strumento da utilizzare durante la progettazione di un nuovo business o per migrare applicazioni legacy in Cloud non \u00e8 mai banale. Ma non abbiate paura, cari sviluppatori: questo articolo vi aiuter\u00e0 a fare chiarezza! I due servizi stanno per dare vita ad un match alla pari su un terreno di gioco comune che permetta un test ad armi pari: stiamo parlando dell\u2019AWS Well-Architected Framework<\/strong>, il framework di AWS pensato per la progettazione di applicazioni ed architetture che siano manutenibili, sicure, resilienti, efficienti e ottimizzate dal punto di visto dei costi.<\/p>\n\n\n\n \u00c8 basato su 5 pilastri fondamentali<\/a> – Eccellenza Operativa, Sicurezza, Affidabilit\u00e0, Efficienza delle Prestazioni, Ottimizzazione dei Costi – e non riguarda nessun servizio AWS in particolare, cos\u00ec da poter essere usato come riferimento per implementare qualsiasi servizio o infrastruttura.<\/p>\n\n\n\n Accogliamo quindi i contendenti di oggi: da un lato Gitlab, dall\u2019altro si sta scaldando AWS CodePipeline!<\/p>\n\n\n\n Iniziamo un ipotetico match all\u2019ultimo commit fra GitLab e AWS CodePipeline.<\/p>\n\n\n\n Ogni pilastro dell\u2019AWS Well Architected Framework sar\u00e0 usato come round; i punteggi saranno basati sui principi di progettazione di ogni pilastro.<\/p>\n\n\n\n Per questo round, i punti saranno definiti su questi principi:<\/p>\n\n\n\n GitLab e CodePipeline permettono entrambi di utilizzare template yaml per definire delle pipeline per eseguire compiti come compilare progetti e distribuirli. E\u2019 possibile definire fasi di esecuzione e differenti passi per ogni fase.<\/p>\n\n\n\n Useremo un progetto di esempio<\/a>.<\/p>\n\n\n\n Partiamo con GitLab:<\/p>\n<\/div><\/div>\n\n\n\n Passiamo ora a AWS CodePipeline<\/p>\n\n\n\n Gitlab permette di definire l\u2019immagine da usare per la build, mentre per CodePipeline l\u2019immagine \u00e8 definita nella configurazione della pipeline. La sintassi \u00e8 molto chiara per entrambi i servizi e la flessibilit\u00e0 che deriva dal loro utilizzo \u00e8 notevole. <\/p>\n\n\n\n Il punteggio \u00e8 di 1 – 1.<\/strong><\/p>\n\n\n\n Andando pi\u00f9 nel dettaglio, CodePipeline consente anche di distribuire stack sfruttando CloudFormation<\/a> e di fare quindi Continuous Delivery anche su intere infrastrutture<\/strong>.<\/p>\n\n\n\n Per questo round, i punti saranno definiti su questi principi: <\/p>\n\n\n\n I meccanismi di autenticazione offerti da GitLab includo la possibilit\u00e0 di utilizzare altri IdP federati come Active Directory e SAML e, pianificando con cura la configurazione, potremo ottenere una gestione centralizzata degli utenti. Se volessimo, per\u00f2, utilizzare SAML SSO per gruppi sarebbe necessario passare ad uno dei piani a pagamento. <\/p>\n\n\n\n AWS CodePipeline usa lo stesso strato di autenticazione ed autorizzazione di AWS, con integrazione con Active Directory, SAML\u2026 e anche di SAML SSO per i gruppi. AWS passa in leggero vantaggio visto anche il numero minore di meccanismi di autenticazione offerti gratuitamente da GitLab. <\/p>\n\n\n\n Anche per quanto riguarda la tracciabilit\u00e0 e limitazione dell\u2019accesso ai dati AWS, GitLab accusa il colpo di un piano gratuito piuttosto limitato: il log di audit \u00e8 incluso solamente nei piani a pagamento, mentre CloudTrail \u00e8 incluso e configurato per ogni servizio AWS in ogni nostro account.<\/p>\n\n\n\n AWS incrementa il suo vantaggio: 3 – 1 per CodePipeline.<\/strong><\/p>\n\n\n\n Il colpo pi\u00f9 duro a GitLab arriva per\u00f2 da alcune discussioni aperte e segnalazioni sulla sicurezza dei \u201crunner\u201d di GitLab come questa<\/a> e sulla cifratura dei dati memorizzati come questa (cache e artifacts)<\/a>.<\/p>\n\n\n\n Il runner manager di GitLab ha bisogno di ruoli e permessi corretti per interagire con i servizi AWS e, ad esempio, distribuire le applicazioni. Se il numero di applicazioni cresce, diventa necessario assegnare permessi aggiuntivi al runner o aggiungerne altri, dando loro il minimo permesso possibile. In questo modo per\u00f2 il numero di risorse coinvolte cresce, facendo crescere anche complessit\u00e0 di gestione e costi.<\/p>\n\n\n\n Ogni servizio AWS ha la possibilit\u00e0 di cifrare i dati memorizzati ed in transito. In pi\u00f9, i ruoli IAM permettono di evitare l\u2019utilizzo di token, access key e altri meccanismi di autenticazione vulnerabili.<\/p>\n\n\n\n CodePipeline prosegue la sua fuga: \u00e8 un 4 – 1.<\/strong><\/p>\n\n\n\n Per questo round, i punti saranno definiti su questi principi: <\/p>\n\n\n\n \u00c8 giusto specificare che per questo specifico round, le singole necessit\u00e0 influenzano molto l\u2019implementazione degli ambienti di build per tutti e due i servizi.<\/em><\/p>\n\n\n\n Sia GitLab che CodePipeline possono scalare orizzontalmente, automatizzare i cambiamenti e non richiedono nessuna pianificazione avanzata di uso delle risorse (a meno che non stiate usando un solo grosso runner on-premise per GitLab).<\/p>\n\n\n\n Entrambi guadagnano un prezioso punto: siamo a 5 – 2.<\/strong><\/p>\n\n\n\n GitLab implementa un sistema a plugin ed \u00e8 possibile usare executors personalizzati che aggiungono scalabilit\u00e0 e flessibilit\u00e0: \u00e8 sicuramente un vantaggio\u2026 e un punto per il servizio che accorcia le distanze : 5 – 3.<\/strong> <\/p>\n\n\n\n AWS CodePipeline pu\u00f2 per\u00f2 essere distribuito fra pi\u00f9 availability zone, quindi in caso di fallimento in eu-west-1-a le build possono ancora funzionare nelle rimanenti 2 AZ.<\/p>\n\n\n\n Nel plugin che implementa l\u2019autoscaling su EC2 di GitLab la ridondanza su pi\u00f9 AZ non \u00e8 invece possibile. Ecco un esempio di configurazione<\/a>.<\/p>\n\n\n\n \u00c8 possibile definire solamente una singola subnet ed una sola Availability Zone. Con questa configurazione la build fallir\u00e0 se la zona scelta fallisce. AWS conquista il punto, siamo a 6 – 3.<\/strong><\/p>\n\n\n\n Per GitLab \u00e8 comunque possibile scrivere un executor personalizzato che permetta di aumentare l\u2019affidabilit\u00e0, ma svilupparlo richiede una considerevole quantit\u00e0 di tempo.<\/p>\n\n\n\n Continuiamo con gli ultimi due round.<\/p>\n\n\n\n Per questo round i punti saranno definiti su questi principi: <\/p>\n\n\n\n Anche se GitLab e CodePipeline hanno molto in comune, GitLab \u00e8 pi\u00f9 flessibile: supporta molti tipi di installazione e di configurazione e questo vale sicuramente un punto extra. <\/p>\n\n\n\n Aggiorniamo il punteggio a 6 – 4.<\/strong><\/p>\n\n\n\n Offre per\u00f2 un supporto pi\u00f9 limitato in ambito serverless: non \u00e8 possibile, ad esempio, utilizzare Docker in Docker sull\u2019executor personalizzato GitLab Fargate, non essendo possibile utilizzare il socket Docker. Dal canto suo, CodePipeline offre supporto completo alle build serverless, anche per le build Docker in Docker.<\/p>\n\n\n\n Sembra che su questo argomento ci sia un pareggio! Entrambi i servizi guadagnano un punto: 7 – 4 per CodePipeline.<\/strong><\/p>\n\n\n\n Per questo round i punti saranno definiti su questi principi: <\/p>\n\n\n\n Analizzando i modelli di pricing dei due servizi, vediamo che mentre i piani a pagamento di GitLab prevedono un costo per singolo utente, le utenze AWS sono gratuite e il servizio CodeBuild prevede un pagamento in base al numero di minuti utilizzati<\/a>. In concreto, utilizzando una istanza general1.small (2 core e 3gb di RAM) la spesa su AWS sar\u00e0 di 5 dollari per 1.000 minuti di esecuzione.<\/p>\n\n\n\n Con i runner condivisi di GitLab, invece, sar\u00e0 possibile acquistare 1.000 minuti per 10 dollari (i primi 2.000 minuti sono gratuiti).<\/p>\n\n\n\n \u00c8 anche possibile utilizzare l\u2019autoscaling AWS per le build se non si vogliono utilizzare i runner shared di GitLab, ma in questo caso saranno necessarie istanze EC2 per il runner manager ed altre per permettere alle build di scalare. Un\u2019altra possibilit\u00e0 \u00e8 l\u2019acquisto di istanze reserved o spot, se il tipo di business lo permette. <\/p>\n\n\n\n Sull\u2019ottimizzazione dei costi non abbiamo dubbi: AWS si accaparra l\u2019ultimo match offrendo soluzioni pronte all\u2019uso e \u201cchiavi in mano\u201d.<\/p>\n\n\n\nLe regole del gioco<\/h2>\n\n\n\n
Round 1: Eccellenza operativa<\/h3>\n\n\n\n
image: python:latest\n\nvariables:\n PIP_CACHE_DIR: \"$CI_PROJECT_DIR\/.cache\/pip\"\n\ntest:\n script:\n\t- python setup.py test\n\t- pip install tox flake8 # you can also use tox\n\t- tox -e py36,flake8\n\nrun:\n script:\n - python setup.py bdist_wheel\n - pip install dist\/*\n artifacts:\n paths:\n - dist\/*.whl\n<\/pre>\n\n\n\n
version: 0.2\nenv:\n\tvariables: PIP_CACHE_DIR: \"$CI_PROJECT_DIR\/.cache\/pip\"\nphases:\n\ttest:\n \t - python setup.py test\n \t - pip install tox flake8 # you can also use tox\n \t - tox -e py36,flake8\n\n\trun:\n \t - python setup.py bdist_wheel\n \t - pip install dist\/*\n \t \n artifacts:\n\tfiles:\n \t - dist\/*.whl\n<\/pre>\n\n\n\n
Con questo colpo basso, CodePipeline si aggiudica un punto ulteriore e passa al comando: il punteggio \u00e8 di 2 – 1 per CodePipeline.<\/strong> <\/p>\n\n\n\nRound 2: Sicurezza<\/h3>\n\n\n\n
Round3: Affidabilit\u00e0<\/h3>\n\n\n\n
[runners.machine]\n IdleCount = 1\n IdleTime = 1800\n MaxBuilds = 10\n MachineDriver = \"amazonec2\"\n MachineName = \"gitlab-docker-machine-%s\"\n MachineOptions = [\n \"amazonec2-access-key=XXXX\",\n \"amazonec2-secret-key=XXXX\",\n \"amazonec2-region=us-central-1\",\n \"amazonec2-vpc-id=vpc-xxxxx\",\n \"amazonec2-subnet-id=subnet-xxxxx\",<\/b>\n \"amazonec2-zone=x\",<\/b>\n \"amazonec2-use-private-address=true\",\n \"amazonec2-tags=runner-manager-name,gitlab-aws-autoscaler,gitlab,true,gitlab-runner-autoscale,true\",\n \"amazonec2-security-group=xxxxx\",\n \"amazonec2-instance-type=m4.2xlarge\",\n ]\n<\/pre>\n\n\n\n
Round 4: Efficienza Operativa.<\/h3>\n\n\n\n
Round 5: Ottimizzazione dei Costi<\/h3>\n\n\n\n
(https:\/\/nodramadevops.com\/2019\/02\/identifying-undifferentiated-heavy-lifting\/<\/a> )<\/li>Podio e conclusioni<\/h2>\n\n\n\n