Google Cloud Platform da zero: setup account, IAM e prima applicazione

Se hai bisogno di un server per la tua applicazione, ma non vuoi gestire hardware o pagare canoni a vita, Google Cloud Platform (GCP) è una scelta solida. Il problema? Spesso si parte dal deploy e ci si dimentica di impostare correttamente account, budget e permessi. Risultato: un conto salato a fine mese e un accesso troppo largo a risorse sensibili.

Noi, di Meteora Web, veniamo dalla contabilità – bilanci, partita doppia, liquidazione IVA. Quando lavoriamo su cloud, la prima domanda è sempre: quanto costa e quanto rende? Il resto viene dopo.

Questa guida ti porta dal vuoto al deploy di una applicazione su GCP con IAM configurato a dovere. Niente teoria astratta: comandi pronti da copiare, decisioni da prendere, errori da evitare.

Account e Billing: non sbagliare all'inizio

Un account GCP senza vincoli di budget è un assegno in bianco. Lo vediamo spesso: clienti che attivano servizi, dimenticano di fermarli e si ritrovano con migliaia di euro da pagare. Noi partiamo sempre dal controllo dei costi.

Creare un account GCP e attivare i budget alert

Vai su console.cloud.google.com e segui la procedura guidata. Dopo aver inserito i dati di fatturazione, la prima cosa da fare è configurare un budget alert:

# Abilita il billing API nella console o via gcloud
gcloud services enable billingbudgets.googleapis.com

# Crea un budget di 100€ con soglie al 50%, 80% e 100%
gcloud billing budgets create \
    --billing-account=BILLING_ACCOUNT_ID \
    --display-name="Budget mensile 100€" \
    --budget-amount=100 \
    --threshold-rules=percent=0.5,percent=0.8,percent=1.0

Nota: sostituisci BILLING_ACCOUNT_ID con l'ID che trovi in Billing > Account management. Noi consigliamo di partire con un budget basso e aumentarlo solo dopo aver testato i carichi.

Costi: attivare i billing alerts con notifiche email

Per ricevere le notifiche, devi associare un canale di comunicazione:

# Crea un canale email per le notifiche
gcloud alpha monitoring channels create \
    --display-name="Email alert" \
    --type=email \
    --channel-labels=email_address=tuo@email.com

# Collega il canale al budget appena creato
gcloud billing budgets update BUDGET_NAME \
    --notifications-pubsub-topic=projects/PROJECT_ID/topics/billing-alerts \
    --email-recipients=tuo@email.com

Perché è importante? Un cliente ci ha raccontato di aver dimenticato una VM con GPU attiva per un weekend: 1.200€ di sorpresa. Con gli alert si ferma in tempo.

IAM: chi fa cosa nel cloud

IAM (Identity and Access Management) è il sistema di permessi di GCP. Un errore comune: dare ruolo Owner a tutti per comodità. Noi lo chiamiamo “la via più veloce per un incidente di sicurezza”.

Utenti, ruoli e service account: le differenze

• Utente – una persona fisica (tu o un collaboratore) che accede con account Google.
• Service Account – un'identità per applicazioni o processi (es. un backend che legge da un database).
• Ruolo – insieme di permessi (es. roles/storage.objectViewer).

Regola d'oro: mai usare le credenziali di un utente umano in un'applicazione. Usa sempre un service account.

Il principio del minimo privilegio

Assegna solo i permessi strettamente necessari. Vuoi che un'applicazione scriva log? Dai il ruolo roles/logging.logWriter, non roles/editor.

Creare un service account per la tua applicazione

# Crea un service account con ID e descrizione
PROJECT_ID="tuo-progetto-id"
SA_NAME="mia-app-sa"

gcloud iam service-accounts create $SA_NAME \
    --display-name="Service Account per la mia applicazione" \
    --project=$PROJECT_ID

# Assegna il ruolo di Invoker per Cloud Run (se poi deploy lì)
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/run.invoker"

# Crea e scarica la chiave JSON (da custodire con cura!)
gcloud iam service-accounts keys create ./mia-app-key.json \
    --iam-account=$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com

Attenzione: non commettere l'errore di includere mia-app-key.json nel repository Git. Usa variabili d'ambiente o un secret manager.

Errore comune: service account key in chiaro nel repository

Abbiamo fatto audit per un'azienda: la chiave JSON del service account era su un repo pubblico su GitHub. Chiunque poteva lanciare istanze a loro spese. Soluzione rapida: ruotare la chiave e utilizzare Secret Manager o l'autenticazione tramite workload identity federation (più avanzata).

La prima applicazione su Cloud Run

Cloud Run ti permette di deployare un container senza gestire server. Paghi solo per le richieste e il tempo di esecuzione: ideale per iniziare senza impegno economico.

Un'app Node.js Hello World

Crea un file app.js:

const express = require('express');
const app = express();
const PORT = process.env.PORT || 8080;

app.get('/', (req, res) => {
  res.send('Hello da Meteora Web su GCP!');
});

app.listen(PORT, () => {
  console.log(`Server in ascolto su porta ${PORT}`);
});

Crea un Dockerfile:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 8080
CMD ["node", "app.js"]

E un package.json:

{
  "name": "gcp-hello",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}

Deploy con gcloud

# Abilita la API di Cloud Run
gcloud services enable run.googleapis.com

# Costruisci l'immagine con Cloud Build
PROJECT_ID="tuo-progetto-id"
IMAGE_NAME="gcr.io/$PROJECT_ID/hello-meteora"
gcloud builds submit --tag $IMAGE_NAME .

# Deploy su Cloud Run con il service account appena creato
gcloud run deploy hello-meteora \
    --image $IMAGE_NAME \
    --platform managed \
    --region europe-west1 \
    --service-account=$SA_NAME@$PROJECT_ID.iam.gserviceaccount.com \
    --allow-unauthenticated \
    --memory=256Mi \
    --concurrency=80

# Ottieni l'URL
gcloud run services describe hello-meteora --region europe-west1 --format='value(status.url)'

Nota: --allow-unauthenticated rende l'endpoint pubblico. In produzione, valuta l'uso di IAP o di un API Gateway.

Configurare il dominio e HTTPS gestito

Cloud Run fornisce un certificato SSL gestito automaticamente. Basta mappare un dominio personalizzato dalla console o con gcloud:

gcloud beta run domain-mappings create \
    --service hello-meteora \
    --domain tua-app.meteoraweb.it \
    --region europe-west1

Segui le istruzioni per aggiungere i record DNS. Nessun costo extra per il certificato SSL.

Monitoraggio e log

Visualizza i log in tempo reale:

gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=hello-meteora" --limit 10

# Stream continuo
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=hello-meteora" --freshness=10m

Noi consigliamo di impostare un alert sui log di errore: quando l'applicazione crasha, ricevi una notifica. Si configura in Logging > Log-based Metrics.

Sintesi: cosa fare adesso

1. Attiva gli alert di budget prima di avviare qualsiasi servizio. Un costo imprevisto è il nemico numero uno.
2. Crea un service account per l'applicazione, non usare il tuo account utente.
3. Assegna solo i ruoli necessari – parti dal minimo e aggiungi se serve.
4. Deploy su Cloud Run con un container semplice per testare il flusso.
5. Proteggi le chiavi – mai su Git, mai in immagini Docker senza attenzione.

Il cloud è potente, ma senza disciplina diventa un costo. Noi, di Meteora Web, lavoriamo ogni giorno per rendere la tecnologia un investimento, non una spesa. Se vuoi approfondire la parte di monitoring e analytics, dai un'occhiata alla nostra guida su Google Tag Manager – perché anche i dati devono essere governati.