Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Serverless Italy - DevOps Bot

Serverless Italy - DevOps Bot

Come abbiamo sviluppato un bot di Slack per capire i messaggi da parte del team di sviluppo ed operations, elaborarne il contesto e le autorizzazioni dell'utente per poi eseguirle realmente sull'infrastruttura nel Cloud.

L'integrazione sfrutta EventBridge per scambiare i messaggi dall'account AWS principale (dove risiede l'integrazione per Slack) verso l'account AWS dell'infrastruttura target.

Le procedure eseguite sono coordinate utilizzando Step Functions, dove delle Lambda eseguono comandi bash sulle istanze (tramite Systems Manager), contattano le API di AWS per modificare le risorse (ASG, EC2, RDS, Aurora Serverless, CloudFront), attendono cambi di stato, monitorano allarmi e notificano lo sviluppatore sull'avanzamento delle operazioni tramite Slack.

Fabio Gollinucci

March 12, 2020
Tweet

More Decks by Fabio Gollinucci

Other Decks in Programming

Transcript

  1. Necessità Autonomia sviluppatori Rendere autonomi gli sviluppatori di operare sull’infrastruttura.

    Accesso sicuro e monitorato Accedere in maniera sicura all’infrastruttura e tenere traccia delle operazioni. Don't Repeat Yourself (DRY) Non ripetere le operazioni manualmente ma bensì automatizzarle. Documentazione dei processi Descrivere i processi in modo semplice e che si possano modificare rapidamente.
  2. AWS Chatbot - Utilizziamo un solo account Slack ma abbiamo

    decine di account AWS, uno per ogni cliente, infrastruttura o semplicemente un diverso progetto. - Chi ha accesso a Slack a diversi livelli di conoscenza e non è possibile lasciar eseguire qualsiasi comando a chiunque. - Non sempre si può eseguire un determinato comando e vanno prima fatti dei controlli sul carico infrastrutturale. - I comandi devono essere più ad alto livello.
  3. Autorizzazioni utente Se nessuna policy viene trovata per il comando,

    infrastruttura o ambiente l’esecuzione del comando viene negata. Se è presente una policy che include il comando l’esecuzione del comando viene concessa. Se è presenta una policy ma con approval impostato a true allora l’esecuzione viene messa in pausa, viene inviata una richiesta al team hosting ed in base alla risposta l’esecuzione può essere negata oppure concessa.
  4. Esecuzione processi I processi vengono orchestrati da StepFunctions. Una serie

    di Lambda consentono l’accesso alle API di AWS, modifiche risorse infrastrutturali (RDS/CloudFront/ASG/ECS) e creare cicli di attesa.
  5. Step Function Processo organizzato tramite una macchina a stati. È

    possibile visualizzare lo schema graficamente per una comprensione migliore. Facile da debuggare analizzano input e output dei vari step e aver chiaro il flusso di lavoro.
  6. Serverless Applications Il deploy tramite SAM viene eseguito in pipelines

    per velocizzare l’aggiornamento delle applicazioni. Le applicazioni sono versionate usando il Semantic Versioning. Condivisione dei processi cross-account.
  7. Le difficoltà incontrate Lambda cold starts Essendo il bot non

    utilizzato molto di frequente soffre molto di cold starts. La soluzione che abbiamo portato è quella di usare le reserved concurrency per le Lambda coinvolte Integrazione con allarmi CloudWatch Una volta progettato e descritte bene le procedure possiamo utilizzare per reagire a determinati allarmi infrastrutturali. Contesti diversi per Dialogflow Se un messaggio viene inviato in privato oppure in un canale cambia il modo di “capire” il messaggio essendo diverso il contesto. Maggiore controllo sui flussi Prima di uscire dalla fase di test vorremo ancora aggiungere qualche controllo sull’esecuzione del comando come: - eseguire un solo comando per volta - fermare tutti i comandi in esecuzione - gestire le richieste come code per posticipazione e retry in caso di errore