GitHub Actions CI/CD per l’Automazione del Deployment su ECS Fargate

GitHub Actions è uno strumento potente per l’automazione dei workflow di CI/CD, che offre ai team di sviluppo una soluzione efficiente per automatizzare il ciclo di vita del codice, dalla fase di build alla distribuzione in produzione. In questa guida esploreremo le nozioni chiave, i costi e i passaggi per creare una pipeline CI/CD utilizzando GitHub Actions, con particolare attenzione al deployment su AWS ECS Fargate.

Cosa è la CI/CD e Perché è Importante?

La Continuous Integration (CI) e la Continuous Deployment (CD) sono pratiche essenziali per migliorare la qualità e la velocità di rilascio del software.

  • CI automatizza l’integrazione del codice di più sviluppatori, eseguendo test ogni volta che viene effettuato un push.
  • CD gestisce il rilascio del codice in produzione, aggiornando automaticamente l’applicazione con nuove modifiche una volta superati i test.

GitHub Actions e il Funzionamento dei Workflow

Con GitHub Actions, possiamo creare pipeline di CI/CD per automatizzare i processi del ciclo di vita del codice. La piattaforma utilizza workflow scritti in YAML per definire una serie di operazioni eseguite automaticamente al verificarsi di eventi specifici (es. push o pull request). Ogni workflow può contenere:

  • Jobs: blocchi che descrivono passaggi di build, test e deployment.
  • Actions: task riutilizzabili eseguiti nei jobs.
  • Events: condizioni che scatenano i workflow, come push, pull_request, ecc.

Differenza tra uses e run nelle Azioni

Nel file YAML di GitHub Actions, possiamo trovare sia il comando uses sia il comando run per eseguire operazioni diverse:

  • uses: richiama un’azione predefinita o custom da GitHub Actions, utile per operazioni comuni e riutilizzabili (es. actions/checkout@v2 per clonare il repository).
  • run: esegue comandi di shell inline, ottimo per eseguire comandi personalizzati come npm install o docker build.

Esempio di Configurazione CI/CD con GitHub Actions

Per configurare una pipeline che builda un’immagine Docker e la deploya su AWS ECS Fargate, possiamo seguire i passaggi seguenti.

Configurazione del Workflow

Ecco un esempio di configurazione di workflow in YAML per GitHub Actions. Questo workflow si attiva al push su staging o master e include una build Docker, il push dell’immagine su Amazon ECR e l’aggiornamento di un container Fargate su ECS.

name: CI/CD Pipeline

on:
  push:
    branches:
      - staging
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest  # Runner predefinito Ubuntu

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Log in to Amazon ECR
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build Docker image
        run: |
          docker build -t ${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:latest -f Dockerfile.alpine .
          docker tag ${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:latest ${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:${{ github.sha }}

      - name: Push Docker image to Amazon ECR
        run: |
          docker push ${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:latest
          docker push ${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:${{ github.sha }}

      - name: Update ECS Service
        run: |
          cluster_name=your-cluster-name
          service_name=your-service-name
          new_image=${{ secrets.AWS_ECR_REGISTRY }}/${{ secrets.AWS_ECR_REPOSITORY }}:${{ github.sha }}

          ecs_task_def=$(aws ecs describe-services --cluster $cluster_name --services $service_name | jq -r '.services[0].taskDefinition')
          ecs_task_def_arn=$(aws ecs describe-task-definition --task-definition $ecs_task_def | jq -r '.taskDefinition.taskDefinitionArn')

          new_task_def=$(aws ecs describe-task-definition --task-definition $ecs_task_def | jq -r '.taskDefinition | .containerDefinitions[0].image = "'$new_image'" | del(.taskDefinitionArn) | del(.requiresAttributes) | del(.revision) | del(.status) | del(.registeredAt) | del(.registeredBy) | del(.compatibilities)')

          echo $new_task_def > new_task_def.json
          new_task_def_arn=$(aws ecs register-task-definition --cli-input-json file://new_task_def.json | jq -r '.taskDefinition.taskDefinitionArn')

          aws ecs update-service --cluster $cluster_name --service $service_name --task-definition $new_task_def_arn

Spiegazione Passo per Passo

  1. Runner ubuntu-latest: GitHub Actions usa un ambiente temporaneo (Ubuntu) per buildare e testare il codice, separato dal container di produzione.
  2. Checkout del Codice: Utilizza actions/checkout per clonare il repository.
  3. Configurazione di Docker e AWS CLI: Set up Docker per build e logga su Amazon ECR per il push.
  4. Build e Push dell’Immagine Docker: L’immagine viene costruita e pushata su ECR usando docker build e docker push.
  5. Aggiornamento del Servizio su Fargate: Con aws ecs update-service viene aggiornata la task definition del servizio, causando un aggiornamento del container Fargate con la nuova immagine.

Costi di GitHub Actions

Per i repository pubblici, GitHub Actions è gratuito. Per i repository privati, GitHub offre 2000 minuti gratuiti al mese, superati i quali i costi sono i seguenti:

  • Ubuntu: $0.008/minuto
  • Windows: $0.016/minuto
  • macOS: $0.24/minuto

Opzioni di ottimizzazione:

  • Runner Self-Hosted: Eseguendo i workflow su server propri, non ci sono costi aggiuntivi per i minuti di GitHub, ma solo per l’infrastruttura.
  • Ottimizzazione del Workflow: Attivare workflow solo per eventi specifici e ridurre i tempi di esecuzione con caching per risparmiare minuti.

Tirando le somme

GitHub Actions è una soluzione potente per CI/CD che, unita a AWS ECS Fargate, consente di automatizzare completamente il processo di deployment, riducendo i tempi di rilascio e migliorando l’affidabilità. Con una configurazione ottimizzata e un’attenta gestione dei costi, è possibile automatizzare il flusso di lavoro mantenendo alta l’efficienza.

Qual è il mio ip da terminale? Come fare in una sola riga con un comando elementare.

Si può eseguire un comando per capire quale sia il proprio indirizzo IP? E poi, diciamocela tutta: quanto è noioso nelle operazioni sistemistiche, mentre si è nel bel mezzo di un “colloquio” con un server remoto, attraverso la propria console, capire quale sia l’ip esposto della macchina (quello pubblico per intenderci)?

La pigrizia è lo stimolo più grande di chi progetta soluzioni, magari non proprio per tutti, ma credo per tanti!

Io uso semplicemente una chiamata a una pagina web con curl, provare per credere:

curl ifconfig.me

Come avere le previsioni meteo da terminale linux

A terminal between a cloud and a shiny sun

Sei un utente Linux? Usi Mint, RedHat, Ubuntu o qualunque altra distribuzione? Vuoi consultare il meteo nella maniera più figa che esiste?

Se se il classico soggetto che vuole fare tutto da console e aprire un browser per sapere che tempo fa domani a Roma, allora sappi che questo breve post è fatto a posta per te!

Come consultare il meteo da terminale

Semplicissimo, devi sapere che un lungimirante e nerdissimo utente della rete (tale Igor Chubin) ha creato questo sito internet, wttr.in, dove è possibile consultare il meteo della città del mondo che preferisci, direttamente dal tuo browser o direttamente da terminale!

An example of the terminal usage of wttr.in
Da console è possibile ottenere il meteo di una città o di una timezone semplicamente interrogando con curl l’url giusta. Nell’esempio curl wttr.in/napoli.

La url da richiamare via browser è: wttr.in/<nome-città>, ad esempio wttr.in/roma oppure wttr.in/pavia.

Se al posto di richiamarla via browser volete ottenere il risultato sul terminale chiamate la url con curl, ad esempio: curl wttr.in/napoli.

Ma parlando di meteo devo dire che il sito internet più azzeccato e divertente che io abbia mai visto è: piovedomaniaroma.it.

Consultatelo e capirete perché è geniale! 😀