Come caricare su Amazon S3 dalle azioni GitHub

GitHub Actions è un potente strumento CI/CD per l'esecuzione di build automatizzate dal tuo repository GitHub. L'ultimo passaggio di questo processo è la distribuzione, che comporta il caricamento degli artefatti di build in un punto in cui è possibile accedervi facilmente. AWS S3 è lo storage preferito da molte persone ed è facile da integrare con gli script di Actions.

Perché utilizzare i bucket AWS S3 per la distribuzione?

Vale la pena notare che GitHub Actions ha un sistema di archiviazione degli artefatti di base, tuttavia, non vorrai utilizzarlo in produzione. È a scopo di archiviazione e test e gli artefatti delle build completate scadranno dopo 90 giorni.

C'è anche GitHub Packages, che è progettato per sostituire i gestori di pacchetti specifici della lingua come npm di JavaScript. Questo può essere molto utile se stai pubblicando un pacchetto NPM, ma non è altrettanto utile per altri tipi di build.

Per ogni altro tipo di artefatto, i bucket S3 di Amazon rimangono uno dei modi preferiti per caricare i file per la distribuzione e l'implementazione. Sono supportati dal sistema di autorizzazioni IAM di AWS, che offre un'eccellente sicurezza ed è in grado di ottimizzare i controlli di accesso al codice sorgente compilato.

In alternativa, se lo desideri utilizzando i contenitori Docker per la distribuzione, ti consigliamo invece di utilizzare un registro contenitori. Fortunatamente, GitHub ha un registro privato con cui è facile integrarsi e puoi leggere la nostra guida all'utilizzo per saperne di più.

RELAZIONATO: Come iniziare con il nuovo Docker Container Registry di Github

Utilizzare S3 è abbastanza semplice e la maggior parte dei passaggi mostrati qui si applicherà anche alle soluzioni di archiviazione compatibili con S3, come Digital Ocean Spaces o self -hosted MinIO, poiché utilizzano la stessa API.

Caricamento su AWS S3 da operazioni GitHub

RELAZIONATOCome utilizzare le azioni di GitHub per automatizzare le build del tuo repository

Per iniziare, ti consigliamo di assicurarti che il resto dello script di build delle azioni di GitHub funzioni e produca una build valida, poiché in genere non desidera eseguire il debug di più problemi contemporaneamente.

Se non ne hai ancora uno, la configurazione dipenderà dalla tua build toolchain, ma puoi leggere la nostra guida alla configurazione di build automatizzate per saperne di più. Puoi anche testare l'artefatto che verrà caricato utilizzando l'azione upload-artifact incorporata in GitHub, che pubblica i contenuti di una directory come bundle.

Puoi quindi confermare la creazione del pacchetto nel Riepilogo > Manufatti.

Una volta che hai una build che non è ;t in caso contrario, puoi aggiungere il caricamento S3 alla fine di esso. Non esiste un modo ufficiale per farlo facilmente ed esistono molte soluzioni diverse su GitHub Actions Marketplace.

Il più popolare è S3 Sync, che utilizza l'API S3 nativa per caricare artefatti costruiti ed è facile da configurare. Ci sono anche semplici wrapper come s3cmd, che ti permettono di passare i comandi direttamente alla CLI di S3.

Una nota, tuttavia, la maggior parte di questi si basa su corridori ospitati da Linux o contenitori Docker, che vengono forniti con le dipendenze necessarie per il funzionamento della CLI S3. Linux è ciò su cui viene eseguita la maggior parte delle build, ma se devi utilizzare Windows per eseguire le tue build, dovrai utilizzare un'azione diversa. Quello multipiattaforma che abbiamo scoperto funzionare è stcalica/s3-upload. Questo utilizza un wrapper JavaScript che installa il pacchetto s3cmd e funziona perfettamente su Windows.

Una cosa che devi fare prima è impostare GitHub Secrets per i tuoi token di autenticazione AWS. Questi non possono essere pubblici ovviamente e dovranno essere archiviati nei segreti del repository e accessibili per nome. Ciò impedisce la perdita accidentale dei tuoi token e consente una facile gestione delle chiavi.

Puoi leggere la nostra guida sull'utilizzo dei segreti di GitHub per saperne di più, ma la cosa principale che ti viene richiesta è andare al repository impostazioni, quindi fai clic su Segreti > Azioni e crea un

Quindi, alla fine dello script GitHub Actions, aggiungi un nome “deploy” passo e impostalo per utilizzare l'azione s3-sync o quella che hai scelto. Dovrai passare i segreti per la chiave di accesso e l'ID che hai configurato come variabili di ambiente.

… – nome: Deploy To S3 – utilizza: actions/checkout@master – utilizza: jakejarvis/s3-sync-action@master con: args: –acl public-read –follow-symlinks –delete env: AWS_S3_BUCKET : ${{ secrets.AWS_S3_BUCKET }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} AWS_REGION: 'us-east-1' # opzionale: il valore predefinito è us-east-1 SOURCE_DIR: 'bin/Linux/net48' # opzionale: il valore predefinito è l'intero repository DEST_DIR: '/' # opzionale: il valore predefinito è la radice del bucket

Con questo flusso di lavoro in particolare, puoi anche passare argomenti direttamente a s3cmd, che può essere utilizzato per attivare gli ACL di lettura pubblica, ad esempio. Qui, l'oggetto è impostato su public e i vecchi contenuti in quella directory nel bucket vengono cancellati, assicurando che tutto corrisponda all'output della build senza file vecchi.

Con quello aggiunto, tutto ciò che resta è eseguire il commit delle modifiche allo script di build e, facoltativamente, rieseguire manualmente la build se non si riavvia automaticamente su un nuovo commit. Non vedrai alcun output di compilazione in GitHub, perché è stato inviato a S3, ma puoi controllare i log da s3cmd nella sezione “deploy to S3” passaggio nel registro di compilazione:

Speriamo che tu&#8217 ;vedrai un output di log simile a quello sopra, a conferma che il processo è stato eseguito correttamente.