Variabili e segreti

Quale livello scegliere?

Project secret: valore condiviso da più ambienti o servizi.
Environment variable: valore specifico di production, staging o preview.
Add-on binding: valore di connessione generato da database o cache.
Service variable: valore specifico del servizio, con la priorità più alta.

In caso di conflitto, l’ordine sopra va dalla priorità più bassa alla più alta. I nomi delle chiavi sono visibili, mentre i valori segreti vengono mascherati dopo il salvataggio.

Build-time e runtime

Le variabili build-time sono disponibili al builder durante la creazione dell’artefatto, per esempio quelle usate dal bundler frontend. Le variabili runtime vengono inserite solo durante l’esecuzione del processo e sono più adatte alle credenziali. Se un’applicazione legge una variabile all’avvio, modificarla richiede un nuovo deploy o un riavvio.

Non inserire segreti in Git, Dockerfile, argomenti di build pubblici, screenshot o log. Se un valore viene divulgato, sostituiscilo nella fonte originale e poi esegui un nuovo deploy del servizio.

Variabili di riferimento

I riferimenti evitano di duplicare valori che potrebbero non essere più allineati. Vengono risolti durante il deploy:


DATABASE_URL=${{ Postgres.DATABASE_URL }}
APP_KEY=${{ shared.APP_KEY }}
PUBLIC_URL=https://${{ GERDOO_PUBLIC_DOMAIN }}

${{ shared.KEY }} legge un segreto del progetto, ${{ ServiceName.KEY }} un valore di un altro servizio e ${{ KEY }} un valore del contesto del servizio stesso. Se un riferimento non viene risolto, controlla nome del servizio, ambiente, ortografia della chiave e presenza del collegamento.

Due archivi nella CLI

gerdoo service env gestisce la semplice mappa env. gerdoo service vars gestisce l’archivio tipizzato con opzioni --build-time e --secret. Per le nuove configurazioni, l’archivio tipizzato è la scelta più chiara.