• We are AWS Experts.

    Bring your Cloud projects to life right away thanks to beSharp’s Cloud Experts

chat icon TALK WITH AN EXPERT! Contact us at+39-339-7816800

Cloud Professional Services

A full range of Cloud services


beSharp animation

Cloud
Architectures

We designbuild and manage Cloud infrastructures on Amazon Web Services.




beSharp animation

Cloud
Development

We develop Cloud Native software and transform your existing applications into Cloud-Aware ones.




beSharp animation

Cloud
Consulting

We define every aspect of your Cloud Transformation, from strategy to cost estimates.



Discover our services!

Cloud Transformation!

The shortest path between your ideas and great results.

What is the secret formula for making every project a success? Knowledge, experience and a healthy dose of confidence. beSharp works with you to define a Cloud approach that takes into account your technical and economic needs. Our Cloud Experts design, build and manage infrastructures and services in the Cloud with Amazon Web Services, so that we can offer you the support of the most experienced technicians and the Cloud services of the world’s top provider at the same time.

DISCOVER OUR SERVICES
  • beSharp is excellent. They can figure out and resolve complicated problems on the fly, where others usually fail.

    Gabriele Repossi / Repossi Macchine Agricole S.R.L.
  • A young, super competent team driven by an innate passion for technology. The support they offer us sets them apart from mere suppliers - they’re more like a partner that believes in our projects just as much as we do.

    Dario Brignone / Satispay

Cloud Experts, since the very beginning.

All of our experience is entirely at your disposal.

What does it mean to be What does it mean to be 100% Cloud? It means having all the resources you need to bring your projects to life in the best possible way at your fingertips, 24/7. Take advantage of this huge potential with our Cloud Experts: beSharp was founded to deal with the Cloud and has always been the key partner for Amazon Web Services in Italy.? It means having all the resources you need to bring your projects to life in the best possible way at your fingertips, 24/7. Take advantage of this huge potential with our Cloud Experts: beSharp was founded to deal with the Cloud and has always been the key partner for Amazon Web Services in Italy.

COME AND MEET OUR CLOUD EXPERTS
aws partner logo

Our partner

AWS Advanced Partner

Born in the Cloud, 100% focused on AWS.

Scalability, security, and resilience are fundamental when you're choosing Cloud services capable of supporting your online business at any time. That's why we are with Amazon Web Services: with tens of success stories under our belt, our Cloud Expert team is one of the most specialized in Cloud migrations, Serverless development and 24/7 support on AWS managed services.

Discover our advantages

From our blog

Read the latest news!

<?php
$data 
=
WP_Query::__set_state(array(
   
'query' => 
  array (
    
'order' => 'DESC',
    
'posts_per_page' => 4,
    
'suppress_filters' => true,
  ),
   
'query_vars' => 
  array (
    
'order' => 'DESC',
    
'posts_per_page' => 4,
    
'suppress_filters' => true,
    
'error' => '',
    
'm' => '',
    
'p' => 0,
    
'post_parent' => '',
    
'subpost' => '',
    
'subpost_id' => '',
    
'attachment' => '',
    
'attachment_id' => 0,
    
'name' => '',
    
'static' => '',
    
'pagename' => '',
    
'page_id' => 0,
    
'second' => '',
    
'minute' => '',
    
'hour' => '',
    
'day' => 0,
    
'monthnum' => 0,
    
'year' => 0,
    
'w' => 0,
    
'category_name' => '',
    
'tag' => '',
    
'cat' => '',
    
'tag_id' => '',
    
'author' => '',
    
'author_name' => '',
    
'feed' => '',
    
'tb' => '',
    
'paged' => 0,
    
'meta_key' => '',
    
'meta_value' => '',
    
'preview' => '',
    
's' => '',
    
'sentence' => '',
    
'title' => '',
    
'fields' => '',
    
'menu_order' => '',
    
'embed' => '',
    
'category__in' => 
    array (
    ),
    
'category__not_in' => 
    array (
    ),
    
'category__and' => 
    array (
    ),
    
'post__in' => 
    array (
    ),
    
'post__not_in' => 
    array (
    ),
    
'post_name__in' => 
    array (
    ),
    
'tag__in' => 
    array (
    ),
    
'tag__not_in' => 
    array (
    ),
    
'tag__and' => 
    array (
    ),
    
'tag_slug__in' => 
    array (
    ),
    
'tag_slug__and' => 
    array (
    ),
    
'post_parent__in' => 
    array (
    ),
    
'post_parent__not_in' => 
    array (
    ),
    
'author__in' => 
    array (
    ),
    
'author__not_in' => 
    array (
    ),
    
'meta_query' => 
    array (
    ),
    
'ignore_sticky_posts' => false,
    
'cache_results' => true,
    
'update_post_term_cache' => true,
    
'lazy_load_term_meta' => true,
    
'update_post_meta_cache' => true,
    
'post_type' => '',
    
'nopaging' => false,
    
'comments_per_page' => '50',
    
'no_found_rows' => false,
  ),
   
'tax_query' => 
  
WP_Tax_Query::__set_state(array(
     
'queries' => 
    array (
    ),
     
'relation' => 'AND',
     
'table_aliases' => 
    array (
    ),
     
'queried_terms' => 
    array (
    ),
     
'primary_table' => 'p2bcloud_posts',
     
'primary_id_column' => 'ID',
  )),
   
'meta_query' => 
  
WP_Meta_Query::__set_state(array(
     
'queries' => 
    array (
    ),
     
'relation' => NULL,
     
'meta_table' => NULL,
     
'meta_id_column' => NULL,
     
'primary_table' => NULL,
     
'primary_id_column' => NULL,
     
'table_aliases' => 
    array (
    ),
     
'clauses' => 
    array (
    ),
     
'has_or_relation' => false,
  )),
   
'date_query' => false,
   
'request' => 'SELECT SQL_CALC_FOUND_ROWS  p2bcloud_posts.ID FROM p2bcloud_posts  WHERE 1=1  AND p2bcloud_posts.post_type = \'post\' AND (p2bcloud_posts.post_status = \'publish\')  ORDER BY p2bcloud_posts.post_date DESC LIMIT 0, 4',
   
'posts' => 
  array (
    
=> 
    
WP_Post::__set_state(array(
       
'ID' => 231,
       
'post_author' => '3',
       
'post_date' => '2017-11-29 19:13:21',
       
'post_date_gmt' => '2017-11-29 18:13:21',
       
'post_content' => '<img class="aligncenter wp-image-232 size-large" src="http://test-blog.besharp.net/wp-content/uploads/2017/11/IMG_3812-1024x768.jpg" alt="" width="1024" height="768" />

Ed eccoci, finalmente, ad uno degli appuntamenti più attesi e importanti dell\'anno per beSharp e per tutto il mondo del Cloud: AWS re: Invent. Quest\'anno il nostro team è ancora più nutrito per non perderci nemmeno un bit di quello che si preannuncia essere l\'evento Cloud più grande di sempre, per numero si sessioni ed eventi e soprattutto partecipanti (si parla di più di 40.000 persone!!! -  numero ufficioso al momento)

&nbsp;

In attesa degli appuntamenti più importanti, come i keynote di Andy Jassy (oggi, alle 17 ora italiana) e di Werner Vogels (domani) dove verranno sicuramente annunciate le novità più interessanti, che riassumeremo nei prossimi post del blog, ecco una breve carrellata dei nuovi servizi che son stati annunciati nei primi due giorni della conferenza, "nascosti" all\'interno di vari eventi e sessioni:

<a href="https://aws.amazon.com/sumerian/">Amazon Sumerian</a>: un tool semplificato per la creazione di applicazioni 3D, di realtà aumentata e di realtà virtuale, compatibile tra l\'altro con OculusRift e iOS11

<a href="https://aws.amazon.com/media-services/">AWS Media Services (Elemental)</a>: una suite molto completa di tool per la gestione di contenuti multimediali; Media Convert per il transcoding, Media Live per lo streaming Media Package per la distillazione dei contenuti per i vari device e formati, Media Store per lo storage dei contenuti e Media Taylor per l\'inserimento di dinamico di advertising targettizzato all\'interno dei video. Si preannuncia uno strumento estremamente potente e interessante, già utilizzato in beta da Netflix, Hulu e Amazon Video.

<a href="https://aws.amazon.com/appsync/">AWS AppSync</a>: un tool di alto livello (che si basa ovviamente sui building block esistenti di AWS, come S3 e DynamoDB) per la creazione di applicazioni data-driven , utilizzando lo standard <a href="http://graphql.org">GraphQL</a>. Il tool è molto sofisticato e merita di sicuro ulteriori approfondimenti (e sarà sicuramente oggetto di test al nostro ritorno :-) ), ma da una prima analisi le caratteristiche più interessanti sembrano il supporto nativo alla collaborazione real-time, la funzionalità offline e la risoluzione automatica dei conflitti di sincronizzazione dei dati.

<a href="https://aws.amazon.com/blogs/aws/new-aws-privatelink-endpoints-kinesis-ec2-systems-manager-and-elb-apis-in-your-vpc/">AWS PrivateLink</a>: finalmente la possibilità per i clienti AWS di accedere a servizi di terze parti (SaaS) che già sono ospitati su AWS passando per la rete privata senza attraversare Internet e quindi senza la necessità di IP pubblico, per massimizzare la sicurezza e il trust. Disponibile anche per i servizi venduti tramite AWS Marketplace.

<a href="https://aws.amazon.com/amazon-mq/">Amazon MQ</a>: una versione gestita e ridondata del popolare message broker <a href="http://activemq.apache.org">Apache ActiveMQ</a>

<a href="https://aws.amazon.com/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/">Bare Metal EC2</a>: questa è la prima bomba! Possibilità di gestire server fisici con gli stessi tool di provisioning di istanze virtuali. utile per chi vuole usare hypervisor personalizzati, per installare sistemi legacy o sistemi operativi non nativamente supportati da AWS e anche per gestire licenze "ostili" che non sono pensate per macchine virtuali e Cloud. Questo stesso servizio è alla base di <a href="https://aws.amazon.com/vmware/">Vmware Cloud on AWS</a>.

<a href="https://aws.amazon.com/guardduty/">Amazon GuardDuty</a>: un tool completamente automatico che utilizza il Machine Learning per rilevare possibili minacce di sicurezza a un\'infrastruttura AWS e reagire dinamicamente e immediatamente.

[NERD MODE ON] Inoltre, alla Tuesday Night Peter Desantis (responsabile di tutte le infrastrutture AWS) ha rivelato alcuni interessanti dettagli tecnici su Nitro System, il nuovo stack di gestione di EC2 gestito completamente su hardware ASIC proprietario e Hyperplane, il bus proprietario che AWS usa per gestire connessioni di rete super scalabili per i suoi servizi. pazzesco! [NERD MODE OFF]

Per il momento abbiamo finito. Mentre scrivevamo queste righe è partito il keynote di Andy Jassy e non potete nemmeno immaginare le incredibili novità annunciate. Per quelle vi rimandiamo al nostro post rissuntivo di domani che, a questo punto, ci terrà svegli tutta la notte!

Vi lasciamo con una piccola gallery di foto carine! :-) Ciao!!

[gallery columns="4" link="file" size="medium" ids="234,235,236,237,238,239,240,241"]'
,
       
'post_title' => 'AWS re:Invent 2017 - Day 1 e 2',
       
'post_excerpt' => '',
       
'post_status' => 'publish',
       
'comment_status' => 'open',
       
'ping_status' => 'open',
       
'post_password' => '',
       
'post_name' => 'aws-reinvent-2017-day-1-e-2',
       
'to_ping' => '',
       
'pinged' => '',
       
'post_modified' => '2017-11-30 17:34:01',
       
'post_modified_gmt' => '2017-11-30 16:34:01',
       
'post_content_filtered' => '',
       
'post_parent' => 0,
       
'guid' => 'http://test-blog.besharp.net/?p=231',
       
'menu_order' => 0,
       
'post_type' => 'post',
       
'post_mime_type' => '',
       
'comment_count' => '0',
       
'filter' => 'raw',
    )),
    
=> 
    
WP_Post::__set_state(array(
       
'ID' => 196,
       
'post_author' => '3',
       
'post_date' => '2017-05-04 17:52:44',
       
'post_date_gmt' => '2017-05-04 15:52:44',
       
'post_content' => 'Nell’<a href="http://test-blog.besharp.net/2017/04/07/single-sign-on-con-g-suite-sulla-console-di-amazon-web-services/">ultimo articolo</a> abbiamo parlato di come utilizzare gli account <strong>G-suite</strong> aziendali per effettuare il <strong>Single-Sign-On</strong> sulla web console di <strong>Amazon Web Services</strong>.

L’accesso alla web console copre solamente una parte delle esigenze di chi lavora quotidianamente con AWS. In particolare gli sviluppatori e i DevOps necessitano quasi sempre di una <a href="http://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys"><strong>coppia access key/secret key</strong></a> sui loro personal computer per utilizzare la <a href="https://aws.amazon.com/cli/">AWS CLI</a>, per chiamare singole API di AWS (ad esempio quelle dei nuovi servizi di AI come <a href="https://aws.amazon.com/rekognition/">Rekognition</a> e <a href="https://aws.amazon.com/lex/">Lex</a>) e per poter utilizzare tutte quelle applicazioni desktop (pensiamo ad esempio ai vari file manager basati su S3 – come l’ottimo <a href="https://www.cloudberrylab.com/explorer/amazon-s3.aspx">CloudBerry File Explorer</a>, o ai client Git per l’utilizzo di <a href="https://aws.amazon.com/codecommit/">CodeCommit</a>) che a loro volta utilizzano le API di AWS.

Access key e secret key <strong>non sono associabili direttamente a uno IAM role</strong> (il cui utilizzo tramite l’API AssumeRole abbiamo già visto essere una best practice di sicurezza), ma <strong>necessitano di uno IAM user dedicato</strong>, il che renderebbe di fatto vano l’assumere un ruolo AWS con delle credenziali centralizzate.

Questa limitazione necessitava giocoforza una soluzione un po’ creativa ed è così che in beSharp <strong>ci siamo inventati beAuth</strong>.

[caption id="attachment_201" align="aligncenter" width="584"]<a href="http://test-blog.besharp.net/wp-content/uploads/2017/05/beAuth_login.png" rel="lightbox"><img class="wp-image-201 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/05/beAuth_login.png" alt="" width="584" height="584" /></a> All\'avvio il programma mostra la schermata di login di G-suite (alla quale può essere associata la two-factor-authentication di Google)[/caption]

beAuth è un piccolo software installabile come agent all’interno del sistema operativo, che utilizza le credenziali G-suite e il meccanismo di SSO basato sul <strong>protocollo SAML</strong> (che abbiamo visto nel precedente articolo) per generare coppie access key/secret key temporanee e legate allo IAM role assunto, che vengono ruotate a intervalli prestabiliti (tipicamente 1 ora) all’interno della configurazione della AWS CLI. In questo modo, oltre alla CLI stessa, tutti i servizi che vi si appoggiano possono accedere alle risorse AWS ereditando temporaneamente i permessi del ruolo assunto, senza la necessità di disporre di uno IAM user dedicato.

[caption id="attachment_202" align="aligncenter" width="584"]<img class="wp-image-202 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/05/beAuth_panel.png" alt="" width="584" height="584" /> Il pannello di controllo di beAuth mostra le informazioni relative alla sessione (che dura di default 12 ore) e alla durata della coppia access/secret key (che scade dopo un\'ora), identifica l\'utente connesso, lo IAM role assunto e le chiavi attive in un determinato momento. La chiave attiva viene configurata in automatico come default nella AWS CLI[/caption]

Inoltre, siccome uno IAM role può essere assunto anche <strong>cross-account</strong>, con le stesse credenziali G-suite (opportunamente configurate) si possono ottenere coppie access/secret key per account differenti, <strong>soluzione estremamente utile nel caso in cui l’azienda disponga di più account AWS</strong> (ad esempio test – staging – produzione) oppure nel caso in cui si amministrino molteplici account AWS per conto di diversi clienti.

Per tutti i software che non si basano sulla CLI ma che necessitano l’inserimento diretto di coppie access/secret key, <strong>beAuth permette di generare coppie “usa e getta”</strong> della durata massima di 1 ora che possono essere inserite manualmente alla bisogna per singole chiamate o sessioni di lavoro.

[caption id="attachment_203" align="aligncenter" width="500"]<img class="wp-image-203 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/05/beAuth_rinnovo_chiavi.png" alt="" width="500" height="499" /> Le chiavi possono essere rigenerate alla bisogna e copiate-incollate all\'interno di qualsiasi applicazione di terze parti[/caption]

I vantaggi di questa soluzione sono molteplici:
<ul>
     <li><strong>Praticità:</strong> si può accedere a TUTTE le risorse AWS (e non solo alla CLI) con un unico account centralizzato, che coincide con l’account G-suite, senza la necessità di implementare complesse infrastrutture Active Directory.</li>
     <li><strong>Sicurezza:</strong> il tutto si basa sul meccanismo di <a href="http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html">AssumeRole e STS token</a>, quindi rispettando appieno le best practice di sicurezza dettate da AWS, le stesse che stanno alla base di servizi come S3, <a href="https://aws.amazon.com/solutions/case-studies/">considerati sicuri da molte aziende della lista Fortune500</a>. Il fatto che ci sia la possibilità di ruotare le chiavi con molta frequenza rende il tutto ancora più rock solid!</li>
     <li><strong>Semplicità:</strong> beAuth si configura in automatico, per cui, una volta fatto il setup iniziale (5 minuti), tutto quello che è richiesto all’utente è di loggarsi con le proprie credenziali G-suite, senza dover gestire complicati script o switchare tutto il giorno tra credenziali e account differenti, potendosi così concentrare sulle proprie attività “core”.</li>
     <li><strong>Portabilità:</strong> beAuth è realizzata in <a href="https://electron.atom.io/">Electron</a>, quindi è portabile su qualunque sistema operativo desktop (Windows, Mac OS, Linux), ha un footprint ridottissimo in termini di consumo di risorse di sistema, è completamente sotto il controllo dell’utente e non necessita di permessi particolari per essere eseguita</li>
     <li><strong>Costi:</strong> tutto questo genera 0 (ZERO) costi lato AWS, il che non guasta :-P</li>
</ul>
Che ne dite di questa nostra soluzione creativa? Siete interessati a implementare beAuth all’interno della vostra azienda? Volete realizzare qualcosa di simile in casa? Avete suggerimenti o domande? <a href="https://www.besharp.it/contacts/">Contattateci</a> e commentate qui sotto per avere tutte le risposte!'
,
       
'post_title' => 'Idea creativa: Single-sign-on con G-suite per i client di sviluppo!',
       
'post_excerpt' => '',
       
'post_status' => 'publish',
       
'comment_status' => 'open',
       
'ping_status' => 'open',
       
'post_password' => '',
       
'post_name' => 'single-sign-on-con-g-suite-per-i-client-di-sviluppo-unidea-creativa',
       
'to_ping' => '',
       
'pinged' => '',
       
'post_modified' => '2017-05-31 15:03:47',
       
'post_modified_gmt' => '2017-05-31 13:03:47',
       
'post_content_filtered' => '',
       
'post_parent' => 0,
       
'guid' => 'http://test-blog.besharp.net/?p=196',
       
'menu_order' => 0,
       
'post_type' => 'post',
       
'post_mime_type' => '',
       
'comment_count' => '0',
       
'filter' => 'raw',
    )),
    
=> 
    
WP_Post::__set_state(array(
       
'ID' => 149,
       
'post_author' => '3',
       
'post_date' => '2017-04-07 14:28:30',
       
'post_date_gmt' => '2017-04-07 12:28:30',
       
'post_content' => 'Chi, tra gli utilizzatori di della console di AWS, non si è mai scontrato con l’annoso problema di <strong>gestire molteplici utenti su altrettanti account</strong>, dovendo creare diversi IAM user e, per ognuno di essi, password complesse, oltre alla quanto mai fondamentale (ma decisamente scomoda, diciamoci la verità) <strong>two-factor-authentication</strong>?

Proprio riguardo a quest’ultima, dando per scontato che non si voglia utilizzare un token hardware dedicato per ogni singolo IAM user, la scelta ricade quasi obbligatoriamente sul <a href="https://en.wikipedia.org/wiki/Google_Authenticator"><strong>Google Authenticator</strong></a>, con codici e QR code che proliferano come funghi e che diventa complicato salvaguardare da eventi nefasti legati allo smartphone (furti, smarrimenti, rotture, backup, cambio device…)

AWS in realtà offrirebbe <a href="https://aws.amazon.com/blogs/aws/new-cross-account-access-in-the-aws-management-console/">un servizio di <strong>cross-account access</strong></a> per la sua management console, che ha però diversi limiti, tra i quali:
<ul>
     <li>il limite massimo di 5 account AWS gestiti;</li>
     <li>l\'essere basato sui cookie del browser da cui si accede (se cambiamo browser o cancelliamo la cache si azzera tutto);</li>
     <li>il richiedere almeno uno IAM user "master" da cui partire, che necessita di credenziali di login e TFA dedicate.</li>
</ul>
La risposta più consona alla necessità di gestire centralmente utenti e accessi, per AWS così come per la stragrande maggioranza delle applicazioni che necessitano autenticazione multi-utente, si chiama  <strong>Single-sign-on</strong> (SSO).

Tipicamente, il meccanismo del SSO si basa su un <a href="https://en.wikipedia.org/wiki/Identity_provider"><strong>Identity Provider</strong></a> (un repository centralizzato di tutte le identità aziendali con relativi attributi – username, password, gruppi, ruoli ecc…) e una serie di <strong>Service Provider</strong> (le applicazioni dove gli utenti si possono loggare con le loro identità aziendali) che vengono federati all\'Identity Provider con <strong>relazioni di <em>trust</em> forte</strong>, basate tipicamente sulla <strong>condivisione di chiavi, certificati o token</strong>. In questo modo gli utenti possono utilizzare un’unica utenza (e quindi una sola password e una singola TFA), gestita in maniera centralizzata, per loggarsi in tutte le applicazioni per le quali sono stati abilitati.

Se i Service Provider possono essere le applicazioni più disparate (Web, desktop, mobile, accesso remoto, CLI, API ecc….), gli Identity Provider sono quasi sempre dei <strong><a href="https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol">server LDAP</a> o <a href="https://en.wikipedia.org/wiki/Active_Directory">Microsoft Active Directory</a></strong>. In particolare MS AD è lo standard de facto nella maggior parte delle aziende più strutturate per la gestione delle identità aziendali, ed è infatti supportato di default da tutte le applicazioni che prevedano la possibilità di fare SSO.

Tuttavia <strong>non è così comune trovare implementata un’infrastruttura MS AD</strong> (ma il discorso vale in parte anche per LDAP), in particolar modo nelle realtà più piccole o giovani e agili, per ragioni che spaziano <strong>dai costi alla complessità di gestione</strong> (specie se si necessita del servizio di AD erogato in alta affidabilità), senza trascurare il fatto che MS AD è tipico di realtà Microsoft-centriche (quasi tutte le grandi aziende legacy) ed è quindi meno diffuso dove il parco client è più eterogeneo (Windows+Mac+Linux…).

Una tendenza molto diffusa in realtà è quella di utilizzare come Identity Provider l’account Google Apps (da poco rinominato in <a href="https://gsuite.google.com/">G Suite</a>) aziendale, servizio ampiamente diffuso e largamente utilizzato per le funzionalità di posta elettronica e colaboration. In questo modo si può fare SSO sulle numerosissime <strong>applicazioni che già nativamente supportano la funzione “login with Google”</strong>, ma anche su quelle (come è il caso della console di AWS) che supportano lo <a href="https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language"><strong>standard SAML</strong></a>, standard per il quale da circa un anno G Suite eroga il servizio di Identity Provider.

[caption id="attachment_186" align="alignnone" width="624"]<img class="wp-image-186 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/WD_2.png" alt="" width="624" height="294" /> Schema di funzionamento dell\'autenticazione tramite SAML tra G Suite e la console di AWS[/caption]

Vediamo quindi come <strong>configurare i nostri account AWS e G Suite per far funzionare il Single-Sign-On con SAML</strong>.

Innanzi tutto, nella pagina di amministrazione di G Suite, dobbiamo aggiungere degli attributi custom ai nostri utenti, tramite i quali il nostro Identity Provider (Google) comunicherà al Service Provider (AWS) oltre all’identità dell’utente loggato, informazioni aggiuntive che spiegheremo in seguito.

<img class="alignnone wp-image-173 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/user_attributes.png" alt="" width="1588" height="596" />

Creiamo una categoria di attributi custom e chiamiamola “AWS SAML” e creiamo gli attributi “IAM Role” e “SessionDuration”. E’ importante che entrambi gli attributi siano privati (ovvero non visualizzabili da tutti gli utenti della vostra organizzazione) e che l’attributo “IAM Role” supporti valori multipli.

<img class="alignnone wp-image-174 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/user_attributes2.png" alt="" width="1349" height="1369" />

<img class="alignnone wp-image-175 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/user_attributes3.png" alt="" width="1430" height="965" />

Fatto questo andiamo nella sezione “Apps” e aggiungiamo una nuova applicazione SAML, partendo dal template pre-configurato per AWS.

<img class="alignnone wp-image-170 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/saml.png" alt="" width="3312" height="943" />

<img class="alignnone wp-image-171 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/saml2.png" alt="" width="1362" height="1329" />

Scarichiamo (opzione 2) gli IDP Metadata (di fatto un file .xml che contiene alcuni parametri di configurazione e il certificato X509 su cui si basa la relazione di <em>trust</em> tra IdP e SP) e teniamoli da parte per un passaggio successivo. <strong>ATTENZIONE!!! Il contenuto di questo file non deve essere diffuso per nessun motivo; sulla sua segretezza si basa la sicurezza di tutta la soluzione!</strong>

<img class="alignnone wp-image-159 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/idp_meta.png" alt="" width="1331" height="1286" />

Proseguiamo nella configurazione mappando l’entità SAML “Name ID” su “Primary Email” (ovvero l’utente verrà presentato alla console AWS con l’indirizzo mail come identificativo univoco).

<img class="alignnone wp-image-161 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/mapping1.png" alt="" width="1337" height="1277" />

Nel passaggio successivo dobbiamo configurare tre mapping aggiuntivi (attenzione che qui la UI di G Suite non è molto chiara, in quanto non si leggono bene gli URL nella colonna di sinistra):
<ul>
     <li>L’attributo <em>https://aws.amazon.com/SAML/Attributes/RoleSessionName</em> va mappato nuovamente su “Primary Email”</li>
     <li>L’attributo <em>https://aws.amazon.com/SAML/Attributes/Role</em> va mappato sull’attributo custom “IAM role” che abbiamo creato prima. In questo modo stiamo dicendo ad AWS quali ruoli l’utente è autorizzato ad assumere e su quali account.</li>
     <li>Va aggiunto l’attributo <em>https://aws.amazon.com/SAML/Attributes/SessionDuration</em> che va mappato sull’attributo custom “SessionDuration” che abbiamo creato prima. Qui stiamo dicendo ad AWS quanto deve durare la sessione di un determinato utente prima di essere sloggato in automatico.</li>
</ul>
<img class="alignnone wp-image-162 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/mapping2.png" alt="" width="1345" height="1295" />

È molto utile poter personalizzare questo parametro perché di default la sessione dura 1 ora, e, per esperienza di chi lavora parecchio sulla console AWS, è un valore molto basso, che comporta numerosi e scomodi logout forzati durante l’operatività quotidiana. <strong>ATTENZIONE!!! Questo “trick” è un’esclusiva di beSharp; non è documentato sulle guide ufficiali ne’ di Google ne’ di AWS! (nda).</strong>

A questo punto la configurazione di G Suite è terminata e passiamo alla configurazione di AWS.

Andiamo nella sezione <a href="https://aws.amazon.com/iam/">IAM</a> --&gt; Identity Providers e creiamone uno nuovo, di tipo SAML, che chiamiamo “GoogleApps”; in questo punto dovremo caricare gli IdP metadata che abbiamo scaricato in precedenza (una volta caricato il file in questo punto, suggerisco di cancellarlo dal proprio computer)

<img class="alignnone wp-image-155 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/aws_idp.png" alt="" width="3328" height="807" />

<img class="alignnone wp-image-156" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/aws_idp2-400x227.png" alt="" width="500" height="284" />

<img class="alignnone wp-image-157" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/aws_idp3.png" alt="" width="500" height="227" />

Poi creiamo un nuovo IAM role che chiamiamo “GoogleLogin” e come tipo di ruolo selezioniamo “Identity Provider Access” --&gt; “WebSSO” e lo associamo all’Identity Provider “GoogleApps” che abbiamo appena creato.

<img class="alignnone wp-image-164 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role.png" alt="" width="1962" height="609" />

<img class="alignnone wp-image-165 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role2.png" alt="" width="3304" height="818" />

<img class="alignnone wp-image-166 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role3.png" alt="" width="3232" height="558" />

Nei passi successivi del wizard associamo una policy allo IAM role per dare i permessi (nel nostro esempio abbiamo dato i permessi di admin – <strong>DON’T TRY THIS AT HOME!!! :-)</strong> ) e la configurazione lato AWS è terminata.

<img class="alignnone wp-image-167 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role4.png" alt="" width="2413" height="1015" />

<img class="alignnone wp-image-168 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role5.png" alt="" width="3292" height="1595" />

<img class="alignnone wp-image-169 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/role6.png" alt="" width="1976" height="604" />

Adesso torniamo nell’amministrazione di G Suite, per assegnare ai singoli utenti i permessi relativi a quali ruoli possono assumere e su quali account AWS.

<img class="alignnone wp-image-176 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/utente.png" alt="" width="3311" height="1530" />

Questa è la parte meno intuitiva della configurazione: per quanto riguarda i ruoli e gli account accessibili, AWS si aspetta da Google dei valori di questo tipo:
<pre lang="yaml">arn:aws:iam::1234567891012:role/GoogleLogin,arn:aws:iam::1234567891012:saml-provider/GoogleApps</pre>
Come vedete si tratta di due <a href="http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html">ARN</a> separati da una virgola. Il primo è l’ARN del ruolo che quell’utente può assumere, il secondo è l’ARN dell’identity provider che abbiamo creato all’interno dell’account AWS. (il numero 1234567891012 è un segnaposto che va sostituito con il vero account number del vostro account AWS). Questo valore va inserito nel campo custom “IAM role” che abbiamo creato in precedenza. In questo modo possiamo specificare per ogni utente quale ruolo può assumere e su quale account AWS.

<img class="alignnone wp-image-154 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/attributi.png" alt="" width="1305" height="804" />

<img class="alignnone wp-image-163 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/mario_rossi.png" alt="" width="3322" height="1606" />

Se vi ricordate bene abbiamo fatto in modo che l’attributo “IAM role” supportasse valori multipli; infatti è possibile, per lo stesso utente, specificare più ruoli all’interno dello stesso account, o anche su account differenti. Basterà aggiungere altre tuple del tipo:
<pre lang="yaml">arn:aws:iam::112233445566:role/Ruolo1,arn:aws:iam::112233445566:saml-provider/GoogleApps
arn:aws:iam::112233445566:role/Ruolo2,arn:aws:iam::112233445566:saml-provider/GoogleApps</pre>
e subito dopo il login ci verrà chiesto quale ruolo vogliamo assumere su quale account.

Ovviamente, perchè tutto funzioni, nel nostro esempio dovremmo ripetere la procedura di federazione SAML (con lo scambio degli IdP metadata) anche per l’account 112233445566

Nel campo custom “SessionDuration” potete specificare, per ogni utente, la durata in secondi della sessione di login. Suggerisco il valore 28800, che corrisponde a 8 ore, ovvero circa a una tipica giornata lavorativa.

A questo punto non ci resta che abilitare la SAML application che abbiamo creato, e tutti gli utenti si troveranno una nuova icona nel loro menu di accesso rapido alle Google Apps.

<img class="alignnone wp-image-172 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/turn_on.png" alt="" width="3312" height="1158" />

Facciamo login quindi con il nostro account di prova "Mario Rossi" e, cliccando sull’icona corrispondente, verremo magicamente indirizzati verso la console AWS dove, come potete vedere, risultiamo loggati con il nostro account federato, m.rossi@besharp.net.

<img class="alignnone wp-image-158 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/icona.png" alt="" width="3351" height="1431" />

<img class="alignnone wp-image-160 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/04/login.png" alt="" width="3228" height="1123" />

Soddisfatti? :-)

Nel prossimo articolo vedremo come abbiamo utilizzato, in maniera decisamente creativa, lo stesso approccio basato su G Suite e SSO per utilizzare ai servizi AWS che prevedono l’autenticazione tramite la coppia key/secret, come la <a href="https://aws.amazon.com/cli/">AWS CLI</a>, <a href="https://aws.amazon.com/codecommit/">CodeCommit</a> e l’accesso alle API da client extra VPC.

Negli articoli successivi, invece, approfondiremo l’utilizzo di G Suite come Identity Provider per tutti gli altri servizi che normalmente richiederebbero una federazione con Active Directory o LDAP.

Avete dubbi o domande? Commentate l\'articolo, vi risponderemo ASAP! E se volete implementare una soluzione come questa ma vi manca il tempo o la voglia... <a href="mailto:info@besharp.it">chiamateci</a>!'
,
       
'post_title' => 'Single-sign-on con G Suite sulla console di Amazon Web Services',
       
'post_excerpt' => '',
       
'post_status' => 'publish',
       
'comment_status' => 'open',
       
'ping_status' => 'open',
       
'post_password' => '',
       
'post_name' => 'single-sign-on-con-g-suite-sulla-console-di-amazon-web-services',
       
'to_ping' => '',
       
'pinged' => '',
       
'post_modified' => '2017-05-31 12:32:45',
       
'post_modified_gmt' => '2017-05-31 10:32:45',
       
'post_content_filtered' => '',
       
'post_parent' => 0,
       
'guid' => 'http://test-blog.besharp.net/?p=149',
       
'menu_order' => 0,
       
'post_type' => 'post',
       
'post_mime_type' => '',
       
'comment_count' => '0',
       
'filter' => 'raw',
    )),
    
=> 
    
WP_Post::__set_state(array(
       
'ID' => 98,
       
'post_author' => '3',
       
'post_date' => '2017-03-10 15:33:42',
       
'post_date_gmt' => '2017-03-10 14:33:42',
       
'post_content' => '<span style="font-weight: 400;">Con il lancio di <a href="https://aws.amazon.com/codebuild/">CodeBuild</a> avvenuto lo scorso novembre <a href="https://www.youtube.com/watch?v=ZDScBNahsL4">sul palco del re:Invent</a>, AWS ha aggiunto il tassello mancante alla suite di strumenti gestione del ciclo di sviluppo del software</span>

<span style="font-weight: 400;"><a href="http://test-blog.besharp.net/2016/12/03/aws-reinvent-2016-parola-chiave-trasformazione/">Noi c’eravamo</a> e non aspettavamo altro per poterci mettere all’opera e implementare finalmente <strong>un sistema di Continuous Delivery interamente basato su servizi gestiti da Amazon Web Services</strong>.</span>

<!--more-->

<span style="font-weight: 400;">Prima di CodeBuild, infatti, la suite di AWS copriva unicamente gli aspetti relativi al source control (<a href="https://aws.amazon.com/codecommit/">CodeCommit</a>), alla gestione dei rilasci (<a href="https://aws.amazon.com/codedeploy/">CodeDeploy</a>) e all’orchestrazione (<a href="https://aws.amazon.com/codepipeline/">CodePipeline</a>), costringendo gli sviluppatori ad utilizzare tool di terze parti (ad esempio <a href="https://jenkins.io/">Jenkins</a>) per la gestione delle fasi di build e test. Tool che vanno configurati e gestiti manualmente, con tutte le problematiche che ne conseguono in termini di complessità, costi e affidabilità della soluzione.</span>

<span style="font-weight: 400;">Pensiamo infatti a quanto lo stack di Continuous Delivery da un lato sia critico (un inconveniente a questi tool può compromettere ore o giorni di lavoro di un intero team di sviluppo), ma dall’altro rappresenti, specie per team DevOps piccoli e agili, un oggetto estraneo alle attività “core”, su cui concentrare il minor sforzo possibile; <strong>una sorta di </strong></span><strong><i>black-box</i> che deve semplicemente funzionare. </strong>

<span style="font-weight: 400;">Uno stack di Continuous Delivery deve:</span>
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Essere estremamente affidabile (nessun single-point-of-failure)</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Garantire la durabilità dei dati (in particolare per quanto riguarda i repository)</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Richiedere un effort di gestione e configurazione minimo</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Integrarsi facilmente sia con gli ambienti e i tool di sviluppo che con quelli di produzione</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Poter scalare facilmente di pari passo con la crescita del team e dei progetti</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;">Costare poco :-)</span></li>
</ul>
<span style="font-weight: 400;">Per gli utenti AWS, l’utilizzo di uno stack di CD interamente basato sui suoi servizi managed è il modo più naturale ed immediato di rispondere a tutti questi requisiti</span>
<h2>La soluzione</h2>
<span style="font-weight: 400;">Rivediamo brevemente quali sono i tool che abbiamo a disposizione:</span>
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;"><strong>CodeCommit:</strong> un servizio di repository git completamente gestito e scalato automaticamente</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;"><strong>CodeBuild:</strong> un sistema di build e testing basato sui container</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;"><strong>CodeDeploy:</strong> un sistema agent-based per effettuare il deploy sulle istanze EC2 in modo automatico.</span></li>
     <li style="font-weight: 400;"><span style="font-weight: 400;"><strong>CodePipeline:</strong> un orchestrator completamente integrato nell’ecosistema AWS, in grado di far interagire gli altri tre servizi fra loro, oppure con provider di terze parti</span></li>
</ul>
<span style="font-weight: 400;">Il nostro team ha realizzato una <strong>soluzione completa e automatizzata per la gestione del software lifecycle su Amazon Web Services</strong>, applicabile sia su ambienti ibridi (in questo caso l’integrazione con il repository e la build avviene in Cloud, mentre il deploy può svolgersi su qualsiasi tipo di istanza, sia in Cloud che on-premise), che su ambienti interamente Cloud-based, con le macchine di staging e produzione anch’esse sul Cloud.</span>

[caption id="attachment_108" align="alignleft" width="900"]<img class="wp-image-108 size-full" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/FullStackCDonAWS-e1489149925140.png" alt="" width="900" height="520" /> Gli sviluppatori fanno push del codice su CodeCommit, parte un trigger e CodePipeline prende il codice e lo dà in pasto a CodeBuild che esegue la build e i test e crea l\'artifact pronto per il deploy. A questo punto CodePipeline passa il pacchetto a CodeDeploy che effettua il rilascio su un pol di istanze EC2. A ogni passaggio S3 viene usato come storage di appoggio degli artifacts.[/caption]

&nbsp;

Utilizzare solo servizi AWS, compatibili e progettati appositamente per cooperare tra di loro, ha il vantaggio di poter disporre di trigger specifici e setup estremamente semplificati. <strong>Tutto scala automaticamente e senza la necessità di interventi tecnici particolari</strong>; il team è quindi sollevato dall’onere di dimensionare a priori l’infrastruttura di Continuous Delivery.

<span style="font-weight: 400;">E’ possibile, inoltre, gestire la security e i permessi in modo granulare sfruttando IAM role e IAM policy. A differenza di ciò che avviene con l’utilizzo di altri strumenti poi, è possibile rimanere confinati all’interno della sandbox di un singolo account Amazon, senza dover esporre nessun endpoint all’esterno per avviare il processo di build.</span>

<span style="font-weight: 400;">Abbiamo scoperto che CodeBuild si occupa delle fasi di build e test sfruttando il provisioning dei container; questi ultimi si avviano solo quando necessario, ottimizzando così le prestazioni ed eliminando la necessità di istanze dedicate come avviene ad esempio durante l’utilizzo di Jenkins.</span>

<span style="font-weight: 400;">Altra caratteristica fondamentale di CodeBuild è l’isolamento, che permette di <strong>segregare ogni build sia a livello applicativo, sia a livello delle release.</strong></span>
<h2>I Costi AWS</h2>
<span style="font-weight: 400;">Prima di cominciare col tutorial, buttiamo un occhio ai costi AWS generati da questa soluzione:</span>

<span style="font-weight: 400;">Il prezzo di ciascuna pipeline di CodePipeline è di 1$/mese, mentre, per i primi 5 utenti (50GB e 10000 richieste git), il servizio CodeCommit è totalmente gratuito. Dal sesto utente in avanti il costo è di 1$/mese a utente.</span>

<span style="font-weight: 400;">Il costo del servizio CodeBuild è calcolato in base ai minuti di utilizzo effettivo dei container che effettuano le build, modello che permette un notevole risparmio economico rispetto ai classici runner basati su istanze EC2, che sono invece tariffate su base oraria </span>

<span style="font-weight: 400;">CodeDeploy è gratuito, senza limiti di traffico o di tempo.</span>

<span style="font-weight: 400;">A questi vanno aggiunti i costi di storage e banda generati da S3, che viene utilizzato come storage di appoggio degli artifact tra uno step e l’altro di ogni pipeline.</span>

<span style="font-weight: 400;">Ovviamente i costi possono variare molto in base al contesto e all’organizzazione di ogni team, ma ci sentiamo di dire che nella maggioranza dei casi questo stack risulti <strong>una delle soluzioni più economiche in assoluto.</strong></span>

<span style="font-weight: 400;">Entriamo ora nel vivo dell’implementazione</span> <span style="font-weight: 400;">.</span>
<h2>CodeCommit</h2>
<span style="font-weight: 400;">Il primo servizio da configurare è CodeCommit. </span>

<span style="font-weight: 400;"><span style="text-decoration: underline;">Creiamo il repository</span> accedendo alla console AWS oppure, nel caso di accesso programmatico, alla CLI.</span>

<img class="alignnone size-full wp-image-126" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodeCommit1.png" alt="" width="679" height="500" />

<span style="font-weight: 400;"><span style="text-decoration: underline;">Creiamo ora un IAM user</span> che ci permetta di procedere con le principali azioni git sul repository appena creato. </span>

<span style="font-weight: 400;"><img class="alignnone size-full wp-image-127" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodeCommit2.png" alt="" width="967" height="781" />
</span><span style="font-weight: 400;">Per ottenere i permessi di accesso al repo, occorre autenticarsi come IAM user. Ecco i possibili metodi:</span>
<ul>
     <li style="font-weight: 400;"><i><span style="font-weight: 400;">Git credential helper, </span></i><span style="font-weight: 400;">sfrutta la CLI. Serve quindi una coppia di chiavi per l’accesso;</span></li>
     <li style="font-weight: 400;"><i><span style="font-weight: 400;">chiave SSH</span></i><span style="font-weight: 400;"> che è possibile caricare dalla gestione utenti IAM;</span></li>
     <li style="font-weight: 400;"><i><span style="font-weight: 400;">username e password</span></i><span style="font-weight: 400;"> generati, sempre, dalla console di gestione IAM (utilizzo su HTTPS).</span></li>
</ul>
<span style="font-weight: 400;">A ogni push del codice sorgente dell’app, questo viene preso in carico da CodeBuild, che si occupa del provisioning di un ambiente temporaneo e isolato (container) all’interno del quale si svolgeranno le fasi di build e test.</span>
<h2>CodeBuild</h2>
<span style="font-weight: 400;">Prima di procedere alle fasi di test e build, configuriamo CodeBuild specificando il <span style="text-decoration: underline;">taglio del container</span>, il <span style="text-decoration: underline;">tipo di immagine desiderata</span> (ad esempio container Linux con preinstallato un framework fra quelli disponibili o un’immagine custom) e <span style="text-decoration: underline;">specificando i passaggi</span> che desideriamo che CodeBuild svolga per effettuare test e build dell’app. Quest’ultimo passaggio <span style="text-decoration: underline;">prevede la scelta tra due metodologie</span>: dichiarazione dei comandi inline oppure mediante un file denominato buildspec.yml che andrà a richiamare gli hook del ciclo di build. </span>

<span style="font-weight: 400;">Noi abbiamo scelto di utilizzare quest’ultimo metodo poiché, in questo modo, <span style="text-decoration: underline;">il file YAML buildspec può essere versionato insieme al codice dell’applicazione</span>, dandoci la possibilità di cambiare le procedure di test e build appena prima della fase di build stessa.</span>

<img class="alignnone size-full wp-image-125" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodeBuild.png" alt="" width="1380" height="1259" />

<span style="font-weight: 400;">All’interno di ciascun hook, quindi, abbiamo specificato i comandi che CodeBuild dovrà eseguire, momento per momento.</span>

<span style="font-weight: 400;">Di seguito un esempio generico della struttura di un file buildspec.yml posto nella root directory del repository:  </span>
<pre lang="yaml">version: 0.1

environment_variables:
plaintext:
JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64"

phases:
install:
commands:
- apt-get update -y
- apt-get install -y maven
pre_build:
commands:
- echo Nothing to do in the pre_build phase...
build:
commands:
- echo Build started on `date`
- mvn install
post_build:
commands:
- echo Build completed on `date`
artifacts:
files:
- target/messageUtil-1.0.jar
discard-paths: yes
</pre>
<span style="font-weight: 400;">Dall’ultima fase del buildspec.yml abbiamo fatto in modo di ottenere un bundle che fosse compatibile con CodeDeploy, servizio utilizzato nella prossima fase; <span style="text-decoration: underline;">il pacchetto ottenuto dall’ultima fase di build contiene sia l’applicazione pronta per essere messa in opera, sia gli script da eseguire per installarla e configurarla sull’istanza di deploy</span>.</span>
<h2>CodeDeploy</h2>
<span style="font-weight: 400;">Il funzionamento di CodeDeploy prevede l’esecuzione dei propri script dall’interno dell’istanza; per questo, su ogni istanza dell’infrastruttura target del processo, andranno installati la CLI di AWS e il CodeDeploy agent. </span>

<span style="font-weight: 400;">Creiamo un file contenente la dichiarazione degli hook, questa volta denominato appspec.yml. Dopo aver creato da zero gli script necessari, abbiamo deciso, per ciascun hook, quali e quanti di essi chiamare.</span>

<img class="alignnone size-full wp-image-128" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodeDeploy.png" alt="" width="941" height="919" />

<span style="font-weight: 400;">Il file YAML appspec, in questo specifico caso, prevede che nel bundle vengano create due cartelle: una (</span><i><span style="font-weight: 400;">App) </span></i><span style="font-weight: 400;">dedicata all’applicazione e una (</span><i><span style="font-weight: 400;">Scripts)</span></i><span style="font-weight: 400;"> dedicata agli script. </span>

<span style="font-weight: 400;">Di seguito un esempio generico della struttura di un file appspec.yml posto nella root directory del bundle:  </span>
<pre lang="yaml">version: 0.0
os: linux
files:
- source: App/
destination: /var/www/html/
- source: nginx.conf
destination: /etc/nginx/
hooks:
BeforeInstall:
- location: Scripts/UnzipResourceBundle.sh
timeout: 300
runas: root
- location: Scripts/InstallDependencies.sh
timeout: 300
runas: ubuntu
AfterInstall:
- location: Scripts/FixPermissions.sh
timeout: 300
runas: root
ApplicationStart:
- location: Scripts/WebServerStart.sh
timeout: 300
runas: root
ValidateService:
- location: Scripts/ValidateService.sh
timeout: 300
runas: ubuntu</pre>
<h2>CodePipeline</h2>
Parallelamente ai tre tool che abbiamo appena descritto, lavora <span style="text-decoration: underline;">CodePipeline, l’ochestrator dei servizi che si occupa di passare gli output generati da ciascuna fase al servizio successivo che li utilizzerà come input per svolgere il proprio compito.</span> Ogni fase del processo di Continuous Integration sfrutta la piattaforma S3 come storage di supporto.

<span style="font-weight: 400;">Affinché CodePipeline funzioni, <span style="text-decoration: underline;">occorre creare una pipeline</span>; per fare ciò, accediamo alla console AWS ed effettuiamo i seguenti passaggi:</span>
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;">scegliere un nome per la pipeline;</span></li>
</ul>
<img class="alignnone size-full wp-image-130" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodePipeline1.png" alt="" width="1026" height="363" />
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;">scegliere la sorgente, nel nostro caso CodeCommit;</span></li>
</ul>
<img class="alignnone size-full wp-image-131" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodePipeline2.png" alt="" width="1026" height="594" />
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;">configurare il passo di build, nel nostro caso CodeBuild;</span></li>
</ul>
<img class="alignnone size-full wp-image-132" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodePipeline3.png" alt="" width="1021" height="688" />
<ul>
     <li style="font-weight: 400;"><span style="font-weight: 400;">scegliere del provider di deploy, nel nostro caso CodeDeploy.</span></li>
</ul>
<img class="alignnone size-full wp-image-133" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodePipeline4.png" alt="" width="1018" height="627" />

<span style="font-weight: 400;">La Pipeline è stata creata con successo.</span>

<img class="alignnone size-full wp-image-129" src="http://test-blog.besharp.net/wp-content/uploads/2017/03/CodePipeline_final.png" alt="" width="285" height="774" />

<span style="font-weight: 400;">Nel momento in cui CodeCommit viene collegato a CodePipeline <span style="text-decoration: underline;">si crea automaticamente un trigger che fa corrispondere ad ogni </span></span><span style="text-decoration: underline;"><i><span style="font-weight: 400;">git push</span></i></span><span style="font-weight: 400;"><span style="text-decoration: underline;"> effettuato l’avvio del processo descritto nella pipeline creata</span>.</span>

<span style="font-weight: 400;">Il codice sorgente risultato da questa fase viene consegnato, sotto forma di input, a CodeBuild, il quale genera un bundle che servirà a sua volta da input a CodeDeploy. Sarà quest’ultimo ad installare l’app sull’infrastruttura target.</span>
<blockquote><i><span style="font-weight: 400;">N.B. è importante verificare la correttezza del codice generato alla fine di ciascuna fase da ciascuno strumento; essendo ciascun risultato il punto di partenza per la fase successiva, se un output risultasse sbagliato, tutto il processo di deploy risulterebbe compromesso.</span></i></blockquote>
<span style="font-weight: 400;">Noi stiamo utilizzando questa soluzione da ormai qualche settimana e siamo estremamente soddisfatti: abbiamo eliminato tutti gli effort di gestione della nostra precedente infrastruttura di Continuous Delivery, aumentando il numero di build che possiamo gestire in parallelo, <span style="text-decoration: underline;">e stiamo anche spendendo sensibilmente meno</span>. Questo stack si rivela quindi ottimo in termini di efficienza, affidabilità ed economicità. </span>

<span style="font-weight: 400;">E voi, cosa ne pensate? </span>

<span style="font-weight: 400;">Se la nostra soluzione vi ha incuriositi e l’idea di implementarla nel vostro flusso di lavoro vi esalta, lasciate un commento o <a href="https://www.besharp.it/contacts/">contattateci</a>! Saremo felici di rispondere ad ogni vostra domanda, di leggere le vostre impressioni e, perché no, di aiutarvi a trarre il massimo vantaggio da questa applicazione.</span>'
,
       
'post_title' => 'Full stack Continuous Delivery su AWS',
       
'post_excerpt' => '',
       
'post_status' => 'publish',
       
'comment_status' => 'open',
       
'ping_status' => 'open',
       
'post_password' => '',
       
'post_name' => 'full-stack-continuous-delivery-su-aws',
       
'to_ping' => '',
       
'pinged' => '',
       
'post_modified' => '2017-05-31 12:33:53',
       
'post_modified_gmt' => '2017-05-31 10:33:53',
       
'post_content_filtered' => '',
       
'post_parent' => 0,
       
'guid' => 'http://test-blog.besharp.net/?p=98',
       
'menu_order' => 0,
       
'post_type' => 'post',
       
'post_mime_type' => '',
       
'comment_count' => '0',
       
'filter' => 'raw',
    )),
  ),
   
'post_count' => 4,
   
'current_post' => -1,
   
'in_the_loop' => false,
   
'post' => 
  
WP_Post::__set_state(array(
     
'ID' => 231,
     
'post_author' => '3',
     
'post_date' => '2017-11-29 19:13:21',
     
'post_date_gmt' => '2017-11-29 18:13:21',
     
'post_content' => '<img class="aligncenter wp-image-232 size-large" src="http://test-blog.besharp.net/wp-content/uploads/2017/11/IMG_3812-1024x768.jpg" alt="" width="1024" height="768" />

Ed eccoci, finalmente, ad uno degli appuntamenti più attesi e importanti dell\'anno per beSharp e per tutto il mondo del Cloud: AWS re: Invent. Quest\'anno il nostro team è ancora più nutrito per non perderci nemmeno un bit di quello che si preannuncia essere l\'evento Cloud più grande di sempre, per numero si sessioni ed eventi e soprattutto partecipanti (si parla di più di 40.000 persone!!! -  numero ufficioso al momento)

&nbsp;

In attesa degli appuntamenti più importanti, come i keynote di Andy Jassy (oggi, alle 17 ora italiana) e di Werner Vogels (domani) dove verranno sicuramente annunciate le novità più interessanti, che riassumeremo nei prossimi post del blog, ecco una breve carrellata dei nuovi servizi che son stati annunciati nei primi due giorni della conferenza, "nascosti" all\'interno di vari eventi e sessioni:

<a href="https://aws.amazon.com/sumerian/">Amazon Sumerian</a>: un tool semplificato per la creazione di applicazioni 3D, di realtà aumentata e di realtà virtuale, compatibile tra l\'altro con OculusRift e iOS11

<a href="https://aws.amazon.com/media-services/">AWS Media Services (Elemental)</a>: una suite molto completa di tool per la gestione di contenuti multimediali; Media Convert per il transcoding, Media Live per lo streaming Media Package per la distillazione dei contenuti per i vari device e formati, Media Store per lo storage dei contenuti e Media Taylor per l\'inserimento di dinamico di advertising targettizzato all\'interno dei video. Si preannuncia uno strumento estremamente potente e interessante, già utilizzato in beta da Netflix, Hulu e Amazon Video.

<a href="https://aws.amazon.com/appsync/">AWS AppSync</a>: un tool di alto livello (che si basa ovviamente sui building block esistenti di AWS, come S3 e DynamoDB) per la creazione di applicazioni data-driven , utilizzando lo standard <a href="http://graphql.org">GraphQL</a>. Il tool è molto sofisticato e merita di sicuro ulteriori approfondimenti (e sarà sicuramente oggetto di test al nostro ritorno :-) ), ma da una prima analisi le caratteristiche più interessanti sembrano il supporto nativo alla collaborazione real-time, la funzionalità offline e la risoluzione automatica dei conflitti di sincronizzazione dei dati.

<a href="https://aws.amazon.com/blogs/aws/new-aws-privatelink-endpoints-kinesis-ec2-systems-manager-and-elb-apis-in-your-vpc/">AWS PrivateLink</a>: finalmente la possibilità per i clienti AWS di accedere a servizi di terze parti (SaaS) che già sono ospitati su AWS passando per la rete privata senza attraversare Internet e quindi senza la necessità di IP pubblico, per massimizzare la sicurezza e il trust. Disponibile anche per i servizi venduti tramite AWS Marketplace.

<a href="https://aws.amazon.com/amazon-mq/">Amazon MQ</a>: una versione gestita e ridondata del popolare message broker <a href="http://activemq.apache.org">Apache ActiveMQ</a>

<a href="https://aws.amazon.com/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/">Bare Metal EC2</a>: questa è la prima bomba! Possibilità di gestire server fisici con gli stessi tool di provisioning di istanze virtuali. utile per chi vuole usare hypervisor personalizzati, per installare sistemi legacy o sistemi operativi non nativamente supportati da AWS e anche per gestire licenze "ostili" che non sono pensate per macchine virtuali e Cloud. Questo stesso servizio è alla base di <a href="https://aws.amazon.com/vmware/">Vmware Cloud on AWS</a>.

<a href="https://aws.amazon.com/guardduty/">Amazon GuardDuty</a>: un tool completamente automatico che utilizza il Machine Learning per rilevare possibili minacce di sicurezza a un\'infrastruttura AWS e reagire dinamicamente e immediatamente.

[NERD MODE ON] Inoltre, alla Tuesday Night Peter Desantis (responsabile di tutte le infrastrutture AWS) ha rivelato alcuni interessanti dettagli tecnici su Nitro System, il nuovo stack di gestione di EC2 gestito completamente su hardware ASIC proprietario e Hyperplane, il bus proprietario che AWS usa per gestire connessioni di rete super scalabili per i suoi servizi. pazzesco! [NERD MODE OFF]

Per il momento abbiamo finito. Mentre scrivevamo queste righe è partito il keynote di Andy Jassy e non potete nemmeno immaginare le incredibili novità annunciate. Per quelle vi rimandiamo al nostro post rissuntivo di domani che, a questo punto, ci terrà svegli tutta la notte!

Vi lasciamo con una piccola gallery di foto carine! :-) Ciao!!

[gallery columns="4" link="file" size="medium" ids="234,235,236,237,238,239,240,241"]'
,
     
'post_title' => 'AWS re:Invent 2017 - Day 1 e 2',
     
'post_excerpt' => '',
     
'post_status' => 'publish',
     
'comment_status' => 'open',
     
'ping_status' => 'open',
     
'post_password' => '',
     
'post_name' => 'aws-reinvent-2017-day-1-e-2',
     
'to_ping' => '',
     
'pinged' => '',
     
'post_modified' => '2017-11-30 17:34:01',
     
'post_modified_gmt' => '2017-11-30 16:34:01',
     
'post_content_filtered' => '',
     
'post_parent' => 0,
     
'guid' => 'http://test-blog.besharp.net/?p=231',
     
'menu_order' => 0,
     
'post_type' => 'post',
     
'post_mime_type' => '',
     
'comment_count' => '0',
     
'filter' => 'raw',
  )),
   
'comment_count' => 0,
   
'current_comment' => -1,
   
'found_posts' => '11',
   
'max_num_pages' => 3.0,
   
'max_num_comment_pages' => 0,
   
'is_single' => false,
   
'is_preview' => false,
   
'is_page' => false,
   
'is_archive' => false,
   
'is_date' => false,
   
'is_year' => false,
   
'is_month' => false,
   
'is_day' => false,
   
'is_time' => false,
   
'is_author' => false,
   
'is_category' => false,
   
'is_tag' => false,
   
'is_tax' => false,
   
'is_search' => false,
   
'is_feed' => false,
   
'is_comment_feed' => false,
   
'is_trackback' => false,
   
'is_home' => true,
   
'is_404' => false,
   
'is_embed' => false,
   
'is_paged' => false,
   
'is_admin' => false,
   
'is_attachment' => false,
   
'is_singular' => false,
   
'is_robots' => false,
   
'is_posts_page' => false,
   
'is_post_type_archive' => false,
   
'query_vars_hash' => '40f30d1ad44567250b4b14ef25cc3ea0',
   
'query_vars_changed' => true,
   
'thumbnails_cached' => false,
   
'stopwords' => NULL,
   
'compat_fields' => 
  array (
    
=> 'query_vars_hash',
    
=> 'query_vars_changed',
  ),
   
'compat_methods' => 
  array (
    
=> 'init_query_flags',
    
=> 'parse_tax_query',
  ),
));
?>

AWS re:Invent 2017 – Day 1 e 2


of Francesca Adragna - 29 November 2017

CONTINUE

Full stack Continuous Delivery su AWS


of Francesca Adragna - 10 March 2017

CONTINUE

chat-image TALK WITH AN EXPERT! Contact us at+39-339-7816800

scroll up image