Tag: CI/CD

Pubblicato il

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.

Pubblicato il

Introduzione alla CI/CD con GitHub: Possibilità, Limiti e Costi

Nel mondo dello sviluppo software moderno, l’efficienza e l’affidabilità sono essenziali. Una delle pratiche chiave per raggiungere questi obiettivi è l’adozione di CI/CD (Continuous Integration/Continuous Deployment). Vediamo insieme cosa significa, come funziona su GitHub e quali sono i costi e i limiti da considerare.

1. Cosa è una CI/CD e perché è importante usarla

Continuous Integration (CI) è la pratica di automatizzare l’integrazione del codice che sviluppatori diversi stanno scrivendo. Ogni modifica viene testata automaticamente, assicurando che nuove aggiunte non rompano il codice esistente.

Continuous Deployment (CD), invece, automatizza il processo di rilascio delle modifiche in produzione, riducendo il tempo di consegna del software e migliorando l’affidabilità grazie a test e verifiche continue.

Perché usarla?

  • Qualità del Codice: Identificazione rapida di bug e problemi.
  • Velocità: Riduzione dei tempi di rilascio.
  • Affidabilità: Processi ripetibili e verificati automaticamente.
  • Feedback Rapido: Feedback immediato sugli effetti delle modifiche.

2. Come funziona la CI/CD con GitHub

GitHub Actions è la soluzione di GitHub per implementare CI/CD. Consente di automatizzare, personalizzare e eseguire i workflow di sviluppo software direttamente nel repository GitHub. Ecco come funziona:

  • Workflow: Un insieme di comandi definiti in un file YAML che descrive cosa deve succedere quando avviene un evento specifico (es. push, pull request).
  • Action: Ogni step del workflow è rappresentato da un’azione. GitHub offre molte azioni predefinite, ma è anche possibile creare azioni personalizzate.
  • Eventi: Gli eventi che scatenano il workflow, come un push su un branch specifico o l’apertura di una pull request.

3. Altre info di contesto (workflow, azioni con contesto ed espressioni)

  • Workflow: Scritti in YAML e memorizzati nella directory .github/workflows/ del repository. Un workflow può contenere più job che vengono eseguiti in parallelo o in sequenza.
  • Azioni con Contesto: Ogni azione può accedere al contesto delle informazioni del repository, dell’evento scatenante e altro ancora.
  • Espressioni: Utilizzate per eseguire condizioni logiche all’interno dei workflow, come ${{ github.event_name == 'push' }} per eseguire un’azione solo su eventi di push.

4. Creare una CI/CD per un progetto: workflow per staging e produzione

Per creare una pipeline CI/CD che esegue diversi workflow su branch differenti, segui questi passi:

  1. Creare il file YAML del workflow:
    • Crea un file chiamato .github/workflows/staging.yml per il workflow di staging.
    • Crea un file chiamato .github/workflows/production.yml per il workflow di produzione.
  2. Configurare il workflow di staging:
    Ecco un esempio di un file YAML di staging.
name: CI/CD Staging

on:
  push:
    branches:
      - staging

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Deploy to staging
        run: echo "Deploying to staging server..."
  1. Configurare il workflow di produzione:
    Qui vediamo un esempio dello YAML di produzione
name: CI/CD Production

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Deploy to production
        run: echo "Deploying to production server..."

5. Costi e Limiti

GitHub Actions è gratuito per i repository pubblici, ma ha limiti di utilizzo per i repository privati. Ecco una panoramica dei costi e dei limiti:

  • Repository Pubblici: Gratuito con limiti di runtime mensili.
  • Repository Privati: Piani gratuiti con limiti di runtime, piani a pagamento disponibili per aumentare i limiti.
  • Limiti di utilizzo: 2000 minuti di runtime gratuiti al mese per i repository privati sul piano gratuito. Oltre questo, si pagano i minuti extra.

Implementare una CI/CD con GitHub Actions offre numerosi vantaggi in termini di qualità del codice, velocità di rilascio e affidabilità. È una pratica che, sebbene richieda un investimento iniziale in termini di tempo e risorse, ripaga ampiamente migliorando l’efficienza del team di sviluppo. Con una configurazione appropriata, è possibile automatizzare flussi di lavoro complessi e garantire rilasci sicuri e tempestivi.

Proudly powered by WordPress