Firebase Studio e pubblicazione backend

Nella lezione precedente, abbiamo visto una delle tante possibilità implementative di backend per Firebase Studio. L'abbiamo realizzato in Python, formato grazie all'interazione con l'Intelligenza Artificiale di Mountain View e l'abbiamo testato in locale. Tutto all'interno del browser e addirittura in un'unica finestra in quanto Firebase Studio ha questa grande capacità di concentrare il tutto in un IDE, basato sulla logica di Visual Studio Code, in cui troviamo in maniera ordinata, al contempo, prompt, ambiente di programmazione, terminali e project explorer.

Ma se volessimo pubblicare il backend come potremmo procedere?

Containerizzazione come soluzione per Firebase Studio

La particolarità dei backend è che, a seconda della tecnologia e del linguaggio scelti, si possono avere contesti ed installazioni del tutto diverse tra loro. Pertanto più che di modalità di pubblicazione dovremmo parlare di approccio alla pubblicazione indipendentemente dalla tecnologia impiegata.

La soluzione per affrontare l'approntamento di un qualsiasi ambiente di esecuzione, in maniera manutenibile, evolutiva e scalabile è, al giorno d'oggi, la containerizzazione, tipicamente affidata alla tecnologia Docker.

Anche nel caso di un backend di Firebase Studio, può essere un'ottima soluzione sebbene non l'unica in quanto potremmo caricare il nostro artefatto in un qualsiasi server in grado di eseguirlo.

Il Cloud di Google si sposa con la containerizzazione in Cloud Run di cui abbiamo già parlato in questa guida.

Da progetto a container

Visto che abbiamo un normale progetto Python, nel nostro backend, ci serve quel qualcosa che permetta di trasformare ogni applicazione in un'immagine Docker ovvero un Dockerfile. Potremmo scriverlo da soli ma avendo un prompt ed un assistente a disposizione non dobbiamo fare altro che chiedere qualcosa come: crea un dockerfile per pubblicare su Cloud Run questo progetto inserendo nell'immagine solo il minimo indispensabile per il suo avvio in container.

Ricordiamo sempre che buona parte di file e cartelle che vediamo nel progetto sono destinate a Firebase Studio come ambiente produttivo, non al server API finale pertanto chiederemo di includere nell'immagine Docker solo il necessario all'esecuzione.

Il file che viene prodotto (con qualche piccola sistemazione "stilistica" successiva) è il seguente:

FROM python:3.11-slim
ENV PYTHONUNBUFFERED=True
ENV APP_HOME=/app
WORKDIR $APP_HOME
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY main.py .
CMD ["sh", "-c", "exec gunicorn --bind 0.0.0.0:$PORT --workers 1 --threads 8 --timeout 0 main:app"]

Come si vede ha incluso solo la parte applicativa del progetto escludendo tutto ciò che riguarda NIX e ambiente virtuale Python: il container in esecuzione sarà l'unico contesto applicativo. Ciò potrà essere richiesto per qualsiasi tecnologia di backend. Inoltre, qui abbiamo escluso per leggibilità tutti i commenti che Gemini ha creato per noi ma, in realtà, il Dockerfile è stato scritto con molte annotazioni a latere.

Pubblicazione su Cloud Run

Con la sola aggiunta del Dockerfile, il backend potrebbe già essere pubblicato così. In fin dei conti potremmo ottenere un'immagine Docker con:

$ docker build -t apiserver .

da eseguire in locale (scegliendo porte TCP da personalizzare) con:

$ docker run -d -p 5000:5000 --rm apiserver

o pubblicare su qualsiasi piattaforma di esecuzione container.

Tuttavia, nel mondo Google, senza creare la propria immagine si può procedere alla pubblicazione con due servizi Cloud Build che si occupa di produrre un'immagine partendo dai nostri sorgenti e Cloud Run che la esegue.

Ricordiamo che per poter utilizzare con successo queste operazioni è necessario possedere un accesso a Google Cloud ed un Billing Account per la fatturazione. Questo sebbene la sperimentazione, grazie a soglie di gratuità piuttosto generose, spesso si può condurre senza costi. Servirà inoltre aver definito il progetto Google legato al proprio account.

Sommariamente, senza entrare troppo nei dettagli della piattaforma Cloud, avremo due passaggi da eseguire con il client di Google Cloud Platform, gcloud:

• creazione dell'immagine partendo da sorgenti e Dockerfile:
  

  gcloud builds submit --tag gcr.io/[PROJECT-ID]/[IMAGE-NAME]

  
  L'immagine sarà caricata sul registry gcr contestualizzandola nel progetto Google scelto ed il nome che vorremo assegnarle;
• attivazione del servizio (così si chiama un'applicazione Cloud Run in esecuzione) su una specifica regione Cloud, avviando l'immagine creata poco fa:
  

  gcloud run deploy [SERVICE-NAME] \
      --image gcr.io/[PROJECT-ID]/[IMAGE-NAME] \
      --platform managed \
      --region [REGION] \
      --allow-unauthenticated

  Qui non dovremo fare altro che scegliere nome del servizio e regione ed indicare l'identificativo esatto dell'intera immagine.

Con l'avvio in Cloud Run avremo un backend, generato con l'AI, messo in esecuzione come un servizio. In generale, diciamo che uno dei vantaggi di Firebase Studio è un accompagnamento completo nella creazione affiancato però da un'apertura totale delle possibilità di pubblicazione che dal locale fino al Cloud sono le più disparate, diversificate per livello di complessità e di costo ma soprattutto non necessariamente legate al mondo Cloud di Google.