GitHub Actions con Lightsail
Published: 2023-10-03 14:24:24

---
title: GitHub Actions con Lightsail
published: true
date: 2023-03-30 00:00:00 UTC
tags: 
canonical_url: 
---

GitHub Actions e AWS: in che modo possiamo sfruttare questa feature di GitHub con AWS Lightsail, il servizio di Amazon per creare delle istanze di hosting già pronte all’uso?

Da quando Amazon ha avviato questo servizio, ha aperto le porte a tutte quelle persone che hanno bisogno di un hosting che sia semplice da usare e che non sia costoso: in questo articolo vedremo infatti come sfruttare queste due tecnologie per avere un flusso che applichi la Continuous Delivery e il Continuous Deployment!

# Cosa vedrai

- [GitHub Actions](#github-actions)
- [Esempio](#esempio)
- 
  - [Risorse utili](#risorse-utili)

# GitHub Actions

[GitHub Actions](https://github.com/features/actions) è una feature che automatizza la creazione, il test e la distribuzione del software. Ma non si ferma qui: ti permette anche di eseguire qualsiasi tipo di operazione sul tuo repository quando si verifica un evento specifico.

Per avere un quadro completo di cosa sia GitHub Actions, aiuta a scomporlo nei suoi numerosi componenti, che trovi nel [precedente articolo](https://theredcode.it/github/github-actions) sul tema.

# Esempio

In questo articolo vedremo come utilizzare le GitHub Actions per eseguire il deploy di un’applicazione Hugo su un’istanza Lightsail basata su LAMP: questi passaggi sono validi per qualsiasi tipologia di applicazione debba essere deployata **sotto un web server come Apache o Nginx**.

Sarà necessario seguire alcuni steps: dovremo definire quale **evento** attiverà le azioni descritte nella sezione relativa ai _job_ e poi **descrivere tutti gli step** che devono essere seguiti per poter procedere.

Nel nostro caso, avremo bisogno che la GitHub Action vada a scaricare Hugo nella versione utilizzata per poi generare il contenuto di build del sito e pubblicarlo all’interno dell’istanza Lightsail.

![](https://theredcode.it/img/github-action-steps.png)

Partiamo però dalla parte più semplice: scegliamo il repository da utilizzare per la creazione della GitHub Action e assegnamole un nome:

![](https://theredcode.it/img/github-action-create.png)

![](https://theredcode.it/img/github-action-name.png)

Per decidere il nome del flusso di lavoro, inseriamo la proprietà _name_:

```
name: Deploy Hugo site to Lighsail

```

A questo punto, andiamo a descrivere il trigger che dovrà _scatenare_ la Action e portare all’esecuzione i diversi step di lavoro; per questo esempio, utilizzeremo come evento il _push_ di un commit sul branch _master_ del repository.

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

```

Passo successivo: descrivere i passaggi che devono essere eseguiti per portare la nostra applicazione sull’istanza Lightsail. Per farlo, ci sarà bisogno di descrivere all’interno della sezione _jobs_ il flusso di lavoro che deve essere elaborato.

Grazie ai _jobs_, è possibile eseguire più operazioni **in parallelo** : in questo caso però, i passaggi da eseguire saranno sequenziali, perché ognuno di essi è fondamentale per quello successivo.

_build_ è il nome assegnato al **job** : questo è infatti l’ID che viene assegnato al task per descrivere in modo univoco l’attività che verrà eseguita.

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:

```

Ogni job **viene eseguito in un ambiente di esecuzione chiamato _runner environment_** il cui sistema viene specificato nell’istruzione _runs-on_. Per le attività dell’esempio, andremo ad utilizzare una distribuzione Ubuntu, specificando anche eventuali variabili di ambiente che ci possono tornare utili nelle fasi successive.

> Come avviene l’esecuzione? GitHub ha un insieme di macchine virtuali su Azure che vengono utilizzate per questo tipo di operazioni, sfruttando dei servizi chiamati proprio _runner_.

Per **scegliere il runner** è possibile seguire diverse strategie: nella [documentazione](https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job) vengono elencati tutti i_runner_ che sono disponibili e hostati da GitHub, tra cui Ubuntu, Windows e MacOS. Esistono diverse modalità con cui utilizzare questi _runner_: andiamo ad utilizzare quella più semplice, dichiarando <ins>il nome del
<em>self-hosted</em> runner.</ins>

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.99.1

```

Il primo passaggio utilizza un’azione denominata _actions/checkout@v2_. Questa è un’azione fornita da GitHub che verificherà il tuo repository sul runner, in modo che possa essere compilato e testato.

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.99.1

 steps:
 - uses: actions/checkout@v2
 with:
 submodules: true # Fetch Hugo themes
 fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod

```

Per il secondo step, andiamo a descrivere qual è il task da eseguire, che _action_ utilizzare e con che modalità: nel caso di esempio, lo step che deve essere eseguito per primo è quello che configura Hugo nella versione utilizzata per lo sviluppo del sito, per cui utilizzeremo una **action** presente su GitHub creata proprio per Hugo.

> Se utilizziamo una tecnologia diversa per il sito statico con cui si vuole lavorare, è sufficiente cercare la GitHub Action più adatta nel [Marketplace](https://github.com/marketplace)!

Gli argomenti possono essere forniti all’azione nella sezione _with_; in questo esempio, specifichiamo la versione estesa di Hugo 0.99.1, secondo la [documentazione](https://github.com/peaceiris/actions-hugo) della GitHub Action.

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.99.1

 steps:
 - uses: actions/checkout@v2
 with:
 submodules: true # Fetch Hugo themes
 fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: ${{ env.HUGO_VERSION }}
 extended: true

```

Lo step successivo è quello di andare a **minificare** il codice di Hugo: questo step produrrà quindi una cartella denominata _public_ che possiamo andare ad utilizzare per pubblicare l’applicazione sotto il web server nello step successivo.

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.99.1

 steps:
 - uses: actions/checkout@v2
 with:
 submodules: true # Fetch Hugo themes
 fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: ${{ env.HUGO_VERSION }}
 extended: true

 - name: Build environment production
 run: hugo --minify

```

L’ultimo step è quello relativo alla copia dei file sull’istanza Lightsail: trattandosi di una sorta di server per_hosting_, possiamo infatti pensare di copiare i file utilizzando **scp** della cartella _public_ nell’istanza.

Per accedervi, avremo bisogno però di alcune informazioni, tra cui la chiave, l’indirizzo IP, la porta e lo username. Tutte queste informazioni sono disponibili <ins>all’interno della dashboard di Lightsail</ins> relativo all’istanza che utilizziamo.

Trattandosi di informazioni _sensibili_, per fornire questi valori alla GitHub Action, l’ideale è utilizzare i **Secret** : si tratta di oggetti che fanno parte del repository e che possono essere utilizzati per _memorizzare dati sensibili_, come chiavi, certificati o password. Soprattutto se utilizziamo un repository pubblico, queste informazioni non dovrebbero essere visibili!

Per creare i Secret, andiamo nella sezione _“Settings”_ del repository e nel menù a sinistra clicchiamo su “Secrets”:

![](https://theredcode.it/img/github-action-secrets.png)

Per lo scopo di esempio, sarà importante creare un _secret_ che contenga le informazioni descritte in precedenza: ad esempio, andremo a creare un secret che contenga all’interno della variabile “HOST” l’indirizzo IP dell’istanza Lightsail:

![](https://theredcode.it/img/github-actions-secret-create.png)

Ripetiamo la stessa procedura per tutti i campi che vogliamo memorizzare nei Secret e ci concentriamo sulla chiave: per collegarsi all’istanza Lightsail tramite SSH, ci viene infatti fornita una chiave di default (o custom) che è possibile scaricare dalla dashboard del servizio AWS e che ci permette di avviare una connessione con un qualsiasi terminale.

Per la GitHub Action utilizziamo, nel caso del campo _key_, la chiave dell’istanza fornita da AWS Lightsail memorizzata in un _secret_ ad hoc.

A questo punto, siamo pronti per copiare, a partire dalla cartella _public_, il sito statico all’interno del web server di Apache!

```
name: Deploy Hugo site to Pages

on:
 push:
 branches: ["master"]

jobs:
 build:
 runs-on: ubuntu-latest
 env:
 HUGO_VERSION: 0.99.1

 steps:
 - uses: actions/checkout@v2
 with:
 submodules: true # Fetch Hugo themes
 fetch-depth: 0 # Fetch all history for .GitInfo and .Lastmod
 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: ${{ env.HUGO_VERSION }}
 extended: true

 - name: Build environment production
 run: hugo --minify

 - name: copy file via ssh password
 uses: appleboy/scp-action@master
 with:
 host: ${{ secrets.HOST }}
 port: ${{ secrets.PORT }}
 source: "./public"
 key: ${{ secrets.SSH_KEY_PRIVATE }}
 target: "/opt/bitnami/apache2/htdocs"
 username: ${{ secrets.USERNAME }}
 overwrite: true

```

Terminato quest’ultimo step, sarà sufficiente verificare che l’esecuzione vada a buon fine: il flusso di lavoro (aka_workflow_) sarà presente sotto la sezione “Actions”, mentre il file che descrive la Action appena creato viene pushato all’interno del repository sotto _.github/workflows_:

![](https://theredcode.it/img/github-action-execution.png)

> Se ti è piaciuto questo articolo, non ti dimenticare di commentare e condividere! ⬇️

# Risorse utili

- [Documentazione ufficiale](https://docs.github.com/en/actions)