Questo documento descrive la popolare metodologia delle app a dodici fattori e come applicarla quando si sviluppano app eseguite su Google Cloud. Se utilizzi questa metodologia, puoi creare app scalabili e resilienti di cui eseguire il deployment continuo con la massima agilità.
Questo documento è destinato agli sviluppatori che conoscono Google Cloud, il controllo della versione, l'integrazione continua e la tecnologia dei container.
Introduzione
Gli sviluppatori stanno spostando le app nel cloud e, in questo modo, acquisiscono maggiore esperienza nella progettazione e nel deployment di app cloud-native. Da questa esperienza è emersa una serie di best practice, comunemente note come dodici fattori. La progettazione di un'app tenendo a mente questi fattori ti consente di eseguire il deployment nel cloud di app più portabili e resilienti rispetto alle app di cui è stato eseguito il deployment in ambienti on-premise, in cui il provisioning di nuove risorse richiede più tempo.
Tuttavia, la progettazione di app cloud-native moderne richiede un cambiamento nel modo in cui concepisci la progettazione del software, la configurazione e il deployment, rispetto alla progettazione di app per ambienti on-premise. Questo documento ti aiuta a capire come applicare i dodici fattori al design della tua app.
Vantaggi delle app a 12 fattori
La progettazione a 12 fattori ti aiuta anche a disaccoppiare i componenti dell'app, in modo che ogni componente possa essere facilmente sostituito o fatto lo scale up o lo scale down senza problemi. Poiché i fattori sono indipendenti da qualsiasi linguaggio di programmazione o stack software, la progettazione a dodici fattori può essere applicata a un'ampia varietà di app.
I dodici fattori
1. Codebase
Devi monitorare il codice della tua app in un sistema di controllo della versione come Git o Mercurial. Puoi lavorare sull'app controllando il codice nel tuo ambiente di sviluppo locale. L'archiviazione del codice in un sistema di controllo della versione consente al tuo team di collaborare fornendo un audit trail delle modifiche al codice, un modo sistematico di risolvere i conflitti di unione e la possibilità di eseguire il rollback del codice a una versione precedente. Fornisce inoltre un punto da cui eseguire l'integrazione continua (CI) e il deployment continuo (CD).
È possibile che gli sviluppatori lavorino su diverse versioni del codice nei propri ambienti di sviluppo, ma in qualsiasi momento la fonte attendibile è il codice nel sistema di controllo della versione. Il codice nel repository è ciò che viene creato, testato e sottoposto a deployment e il numero di repository è indipendente dal numero di ambienti. Il codice nel repository viene utilizzato per produrre una singola build, che viene combinata con una configurazione specifica per l'ambiente per produrre una release immutabile, una release in cui non è possibile apportare modifiche, compresa la configurazione, di cui è possibile eseguire il deployment in un ambiente. Eventuali modifiche necessarie per la release dovrebbero comportare una nuova release.
Cloud Source Repositories consente di collaborare e gestire il codice in un repository Git privato, scalabile e completo. Include funzionalità di ricerca del codice in tutti i repository. Puoi anche connetterti ad altri prodotti Google Cloud come Cloud Build, App Engine, Cloud Logging e Pub/Sub.
2. Dipendenze
Per quanto riguarda le dipendenze per le app a 12 fattori, ci sono due considerazioni: dichiarazione delle dipendenze e isolamento delle dipendenze.
Le app a dodici fattori non dovrebbero mai avere dipendenze implicite. Devi dichiarare esplicitamente le dipendenze e controllarle nel controllo della versione. In questo modo puoi iniziare a utilizzare il codice rapidamente e in modo ripetibile, nonché monitorare facilmente le modifiche alle dipendenze. Molti linguaggi di programmazione offrono un modo per dichiarare esplicitamente le dipendenze, ad esempio pip per Python e Bundler per Ruby.
Dovresti anche isolare un'app e le sue dipendenze pacchettizzandole in un container. I container consentono di isolare un'app e le sue dipendenze dal suo ambiente e di garantire che l'app funzioni in modo uniforme nonostante le differenze tra gli ambienti di sviluppo e di gestione temporanea.
Artifact Registry è un servizio privato di gestione degli artefatti completamente gestito che supporta vari tipi di artefatti come immagini container, pacchetti di linguaggio (come Maven e npm) e pacchetti di sistema operativo (come RPM). Per gestire più facilmente i risultati delle build CI/CD e le loro dipendenze, puoi utilizzare Cloud IAM con Artifact Registry con controllo dell'accesso granulare. Artifact Analysis rileva le vulnerabilità nelle immagini container inviate ad Artifact Registry per garantire la sicurezza del deployment delle immagini container.
Le integrazioni CI/CD esistenti ti consentono inoltre di impostare pipeline completamente automatizzate per ricevere feedback rapidi. Puoi eseguire il push delle immagini nel registro, quindi eseguirne il pull utilizzando un endpoint HTTP da qualsiasi macchina, che si tratti di un'istanza di Compute Engine o del tuo hardware.
3. Configurazione
Ogni app moderna richiede un qualche tipo di configurazione. Di solito sono disponibili configurazioni diverse per ogni ambiente, ad esempio sviluppo, test e produzione. Queste configurazioni di solito includono le credenziali dell'account di servizio e gli handle delle risorse per i servizi di supporto come i database.
Le configurazioni per ogni ambiente devono essere esterne al codice e non devono essere incluse nel controllo della versione. Tutti lavorano su una sola versione del codice, ma hai più configurazioni. L'ambiente di deployment determina la configurazione da utilizzare. Ciò consente di eseguire il deployment di una versione del programma binario in ogni ambiente, dove l'unica differenza è la configurazione del runtime. Un modo semplice per verificare se la configurazione è stata esternalizzata correttamente consiste nel verificare se il codice può essere reso pubblico senza rivelare alcuna credenziale.
Un modo per esternalizzare la configurazione è creare file di configurazione. Tuttavia, i file di configurazione sono in genere specifici di un linguaggio o di un framework di sviluppo.
Un approccio migliore consiste nell'archiviare la configurazione nelle variabili di ambiente. Questi elementi sono facili da modificare per ogni ambiente in fase di runtime, è improbabile che vengano controllati nel controllo della versione e sono indipendenti dal linguaggio di programmazione e dal framework di sviluppo. In Google Kubernetes Engine (GKE), puoi utilizzare ConfigMaps. In questo modo puoi associare variabili di ambiente, numeri di porta, file di configurazione, argomenti della riga di comando e altri artefatti di configurazione ai container e ai componenti di sistema dei tuoi pod in fase di runtime.
Cloud Functions e Cloud Run supportano l'utilizzo delle variabili di ambiente. Puoi esternalizzare le configurazioni e modificarle dalla console Google Cloud o utilizzando Google Cloud SDK.
4. Servizi di supporto
Ogni servizio utilizzato dall'app nell'ambito del suo normale funzionamento, ad esempio file system, database, sistemi di memorizzazione nella cache e code di messaggi, deve essere accessibile come servizio ed essere esternalizzato nella configurazione. Questi servizi di supporto vanno considerati come astrazioni per la risorsa sottostante. Ad esempio, quando l'app scrive dati nello spazio di archiviazione, trattare lo spazio di archiviazione come servizio di supporto ti consente di modificare senza problemi il tipo di archiviazione sottostante, perché è disaccoppiato dall'app. Puoi quindi apportare una modifica, ad esempio passare da un database PostgreSQL locale a Cloud SQL per PostgreSQL senza modificare il codice dell'app.
5. Build, release, esecuzione
È importante separare il processo di deployment del software in tre fasi distinte: build, rilascio ed esecuzione. Ogni fase dovrebbe generare un artefatto identificabile in modo univoco. Ogni deployment deve essere collegato a una release specifica, come risultato della combinazione della configurazione di un ambiente con una build. Ciò consente rollback semplici e un audit trail visibile della cronologia di ogni deployment di produzione.
Puoi attivare manualmente la fase di build, ma di solito viene attivata automaticamente quando esegui il commit del codice che ha superato tutti i test richiesti. La fase di creazione acquisisce il codice, recupera le librerie e gli asset richiesti e li pacchettizza in un programma binario o container autonomo. Il risultato della fase di creazione è un artefatto di build.
Quando la fase di build è completata, quella di rilascio combina l'artefatto di build con la configurazione di un ambiente specifico. In questo modo viene generata una release. La release può essere sottoposta automaticamente a deployment nell'ambiente da un'app di deployment continuo. In alternativa, puoi attivare la release tramite la stessa app di deployment continuo.
Infine, la fase di esecuzione avvia la release e la avvia. Ad esempio, se esegui il deployment in GKE, Cloud Build può chiamare il passaggio di creazione gke-deploy per eseguire il deployment nel tuo cluster GKE. Cloud Build può gestire e automatizzare le fasi di creazione, rilascio ed esecuzione in più linguaggi e ambienti utilizzando i file di configurazione di compilazione in formato YAML o JSON.
Inoltre, puoi utilizzare Cloud Deploy, che offre un servizio completamente gestito che fornisce la distribuzione continua a GKE, Cloud Run e GKE Enterprise. Con Cloud Deploy puoi creare una pipeline di distribuzione che include passaggi di approvazione e promozione senza soluzione di continuità in più ambienti. Inoltre, Cloud Deploy supporta il rollback in un solo passaggio di un'applicazione di cui è stato eseguito il deployment in qualsiasi destinazione.
6. Processi
Esegui app a dodici fattori nell'ambiente come uno o più processi. Questi processi devono essere stateless e non devono condividere dati tra loro. Ciò consente alle app di fare lo scale up tramite la replica dei loro processi. La creazione di app stateless rende inoltre i processi portabili in tutta l'infrastruttura di computing.
Se sei abituato al concetto di sessioni "permanenti", ciò richiede un cambiamento nel modo in cui concepisci la gestione e la persistenza dei dati. Poiché i processi possono scomparire in qualsiasi momento, non è possibile fare affidamento sui contenuti dello spazio di archiviazione locale disponibili o sul fatto che qualsiasi richiesta successiva sarà gestita dallo stesso processo. Pertanto, devi salvare esplicitamente tutti i dati che devono essere riutilizzati in un servizio di supporto esterno come un database.
Se hai bisogno di salvare i dati in modo permanente, puoi utilizzare Memorystore e Filestore come servizio di supporto per memorizzare nella cache lo stato delle app e condividere dati comuni tra i processi per favorire il basso accoppiamento.
7. Associazione di porte
In ambienti non cloud, le app web vengono spesso scritte per essere eseguite in container di app come GlassFish, Apache Tomcat e Apache HTTP Server. Al contrario, le app a dodici fattori non si basano su container di app esterni. Raggruppano invece la libreria del server web come parte dell'app stessa.
È una best practice dell'architettura per consentire ai servizi di esporre un numero di porta,
specificato dalla variabile di ambiente
PORT.
Le app che esportano l'associazione di porte sono in grado di consumare le informazioni sull'associazione di porte esternamente (come variabili di ambiente) quando utilizzano il modello Platform as a Service. In Google Cloud puoi eseguire il deployment delle app su servizi della piattaforma come Compute Engine, GKE, App Engine o Cloud Run.
In questi servizi, un livello di routing instrada le richieste da un nome host rivolto al pubblico ai processi web collegati alla porta. Ad esempio, quando esegui il deployment delle tue app in App Engine, dichiari le dipendenze per aggiungere una libreria di server web all'app, come Express (per Node.js), Flask e Gunicorn (per Python) o Jetty (per Java).
Non impostare come hardcoded i numeri di porta nel codice. Fornisci invece i numeri di porta nell'ambiente, ad esempio in una variabile di ambiente. In questo modo le tue app sono portabili quando le esegui su Google Cloud.
Poiché Kubernetes ha un Service Discovery integrato, in Kubernetes puoi astrarre le associazioni di porte mappando le porte di servizio ai container. Il rilevamento dei servizi viene eseguito utilizzando i nomi DNS interni.
Anziché impostare come hardcoded la porta su cui il server web è in ascolto, la configurazione utilizza una variabile di ambiente. Il seguente snippet di codice di un'app App Engine mostra come accettare un valore di porta trasmesso in una variabile di ambiente.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Contemporaneità
Dovresti scomporre la tua app in processi indipendenti in base ai tipi di processi, come i processi in background, web e dei lavoratori. Ciò consente di fare lo scale up e lo scale down dell'app in base ai requisiti dei singoli carichi di lavoro. La maggior parte delle app cloud-native consente di scalare on demand. Dovresti progettare l'app come più processi distribuiti, in grado di eseguire in modo indipendente blocchi di lavoro e di fare lo scale out aggiungendo altri processi.
Le seguenti sezioni descrivono alcuni costrutti per consentire la scalabilità delle app. Le app basate sui principi di disponibilità e statelessness come base hanno tutte le carte in regola per trarre vantaggio da questi costrutti di scalabilità orizzontale.
Utilizzo di Cloud Run
Cloud Run è una piattaforma di computing che consente di eseguire i container direttamente sull'infrastruttura gestita da Google. Cloud Run supporta due modalità di esecuzione
del codice. Cloud Run services viene eseguito ininterrottamente come servizio. Viene solitamente utilizzato per
rispondere a richieste o eventi web. Cloud Run jobs esegue codice che esegue un lavoro
specifico e si chiude al termine dell'operazione. Cloud Run offre inoltre
Cloud Scheduler per eseguire job batch. Questa struttura è adatta a implementare
la contemporaneità e a scalare possibili architetture di servizio.
Per ulteriori informazioni su Cloud Run, consulta Che cos'è Cloud Run.
Utilizzo di Cloud Functions
Le Cloud Functions sono funzioni stateless a uso specifico che vengono eseguite su Google Cloud, dove l'architettura sottostante su cui vengono eseguite è gestita per te da Google. Cloud Functions risponde ai trigger di eventi, come un caricamento in un bucket Cloud Storage o un messaggio Pub/Sub. Ogni chiamata di funzione risponde a un singolo evento o richiesta.
Cloud Functions gestisce le richieste in entrata assegnandole alle istanze della funzione. Quando il volume delle richieste in entrata supera il numero di istanze esistenti, Cloud Functions potrebbe avviare nuove istanze per gestire le richieste. Questo comportamento di scalabilità automatica e completamente gestito consente a Cloud Functions di gestire molte richieste in parallelo, ciascuna utilizzando un'istanza diversa della funzione.
Utilizzo di App Engine
Puoi ospitare le tue app nell'infrastruttura gestita di Google Cloud utilizzando App Engine. Le istanze sono le unità di calcolo utilizzate da App Engine per scalare automaticamente l'app. In qualsiasi momento, la tua app può essere eseguita su una o più istanze, con le richieste distribuite tra tutte.
Lo scheduler App Engine decide come gestire ogni nuova richiesta. Lo scheduler potrebbe utilizzare un'istanza esistente (inattiva o che accetta richieste in parallelo), inserire la richiesta in una coda di richieste in attesa o avviare una nuova istanza per tale richiesta. La decisione prende in considerazione il numero di istanze disponibili, la velocità con cui l'app gestisce le richieste (la sua latenza) e il tempo necessario per avviare una nuova istanza.
Se utilizzi la scalabilità automatica, puoi creare un equilibrio tra prestazioni e costi impostando l'utilizzo target della CPU, la velocità effettiva target e il numero massimo di richieste in parallelo.
Puoi specificare il tipo di scalabilità nel file app.yaml, che carichi per
la versione del servizio. In base a questo input di configurazione, l'infrastruttura
App Engine utilizza istanze dinamiche o residenti. Per ulteriori informazioni sui tipi di scalabilità, consulta la documentazione di App Engine.
Utilizzo della scalabilità automatica di GKE
Esistono alcuni costrutti Kubernetes chiave che si applicano ai processi di scalabilità:
Scalabilità automatica orizzontale dei pod (HPA). Kubernetes può essere configurato per fare lo scale up o lo scale down del numero di pod in esecuzione nel cluster in base a metriche standard o personalizzate. Questo è utile quando devi rispondere a un carico variabile sul tuo cluster GKE.
Scalabilità automatica dei nodi. Nei momenti di aumento della domanda, potrebbe essere necessario scalare il cluster per ospitare più pod. Con GKE, puoi configurare il cluster per la scalabilità in modo dichiarativo. Se la scalabilità automatica è abilitata, GKE scala automaticamente i nodi quando è necessario pianificare pod aggiuntivi e i nodi esistenti non possono ospitarli. Inoltre, GKE fa lo scale down dei nodi quando il carico sul cluster diminuisce, in base alle soglie configurate.
Job. GKE supporta i job Kubernetes. Un job può essere definito in modo generico come un'attività che richiede l'esecuzione di uno o più pod. Il job potrebbe essere eseguito una volta o in base a una pianificazione. I pod in cui viene eseguito il job vengono eliminati al completamento del job. Il file YAML che configura il job specifica i dettagli su gestione degli errori, parallelismo, come vengono gestiti i riavvii e così via.
Utilizzo di Compute Engine
In alternativa, puoi eseguire il deployment e gestire le tue app su Compute Engine. In questo caso, puoi scalare la tua app per rispondere ai carichi di variabili utilizzando i gruppi di istanze gestite in base all'utilizzo della CPU, alle richieste gestite o ad altri indicatori di telemetria dell'app.
La figura seguente illustra le funzionalità principali fornite dai gruppi di istanze gestite.
L'utilizzo dei gruppi di istanze gestite consente all'app di scalare in base alla domanda in entrata e di offrire disponibilità elevata. Questo concetto funziona intrinsecamente bene per le app stateless come i front-end web e per carichi di lavoro ad alte prestazioni basati su batch.
9. Rilasciabilità
Per le app eseguite sull'infrastruttura cloud, dovresti trattare tali app e l'infrastruttura sottostante come risorse usa e getta. Le tue app devono essere in grado di gestire la perdita temporanea dell'infrastruttura sottostante e devono poter essere arrestate e riavviate automaticamente.
I principi chiave da considerare sono:
- Disaccoppia funzionalità come la gestione dello stato e l'archiviazione dei dati transazionali utilizzando i servizi di supporto. Per ulteriori informazioni, consulta la sezione Servizi di supporto in precedenza in questo documento.
- Gestisci le variabili di ambiente al di fuori dell'app in modo che possano essere utilizzate in fase di runtime.
- Assicurati che il tempo di avvio sia il minimo. Ciò significa che devi decidere in che misura creare i livelli da creare nelle immagini quando utilizzi le macchine virtuali, ad esempio immagini pubbliche e personalizzate. Questa decisione è specifica per ogni app e dovrebbe essere basata sulle attività eseguite dagli script di avvio. Ad esempio, se scarichi diversi pacchetti o programmi binari e li inizializza durante l'avvio, una parte considerevole del tuo tempo di avvio sarà dedicata al completamento di queste attività.
- Usa le funzionalità native di Google Cloud per le attività dell'infrastruttura. Ad esempio, puoi utilizzare gli aggiornamenti in sequenza in GKE e gestire i token di sicurezza utilizzando Cloud Key Management Service (Cloud KMS).
Utilizza l'indicatore SIGTERM (quando disponibile) per avviare un arresto pulito. Ad esempio, quando App Engine Flex arresta un'istanza, di solito invia un segnale di STOP (SIGTERM) al container dell'app. La tua app può utilizzare questo indicatore per eseguire qualsiasi azione di pulizia prima dell'arresto del container. La tua app non deve rispondere all'evento SIGTERM. In condizioni normali, il sistema attende fino a 30 secondi per l'arresto dell'app e poi invia un segnale KILL (SIGKILL).
Lo snippet seguente in un'app App Engine mostra come intercettare il segnale SIGTERM per chiudere le connessioni aperte al database.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Parità ambientale
Le app aziendali si spostano in ambienti diversi durante il loro ciclo di vita di sviluppo. In genere si tratta di ambienti di sviluppo, test, gestione temporanea e produzione. È buona norma mantenere questi ambienti il più simili possibile.
La parità ambientale è una funzionalità che la maggior parte degli sviluppatori considera una determinata. Tuttavia, man mano che le aziende crescono e i loro ecosistemi IT si evolvono, la parità dell'ambiente diventa più difficile da mantenere.
Mantenere la parità dell'ambiente è diventato più facile negli ultimi anni perché gli sviluppatori hanno adottato il controllo del codice sorgente, la gestione della configurazione e i file di configurazione basati su modelli. Ciò semplifica il deployment di un'app in più ambienti in modo coerente. Ad esempio, utilizzando Docker e Docker Compose, puoi assicurarti che lo stack delle app mantenga la sua forma e la sua strumentazione in tutti gli ambienti.
La seguente tabella elenca i servizi e gli strumenti di Google Cloud che puoi utilizzare quando progetti app da eseguire su Google Cloud. Questi componenti hanno scopi diversi e, collettivamente, aiutano a creare flussi di lavoro che rendono gli ambienti più coerenti.
| Componente Google Cloud | Purpose |
|---|---|
| Cloud Source Repositories | Un unico posto in cui il tuo team può archiviare, gestire e monitorare il codice. |
| Artifact Registry | Un gestore di pacchetti universale per tutti gli artefatti e le dipendenze della build. |
| Cloud Build | Un servizio completamente gestito che esegue le build sull'infrastruttura di Google Cloud. |
| Cloud KMS | Archivia le chiavi di crittografia in un unico servizio cloud centrale per utilizzarle direttamente da altre risorse e applicazioni cloud. |
| Cloud Storage | Archivia immagini personalizzate create da dischi di origine, immagini, snapshot o immagini archiviate in Cloud Storage. Puoi utilizzare queste immagini per creare istanze di macchine virtuali (VM) personalizzate per le tue app. |
| Cloud Deploy | Fornisci la distribuzione automatica delle tue applicazioni a una serie di più ambienti di destinazione in una sequenza definita. |
11. Log
I log ti informano sull'integrità delle tue app. È importante disaccoppiare la raccolta, l'elaborazione e l'analisi dei log dalla logica di base delle app. Il disaccoppiamento del logging è particolarmente utile quando le app richiedono scalabilità dinamica e sono in esecuzione su cloud pubblici, perché elimina l'overhead associato alla gestione della posizione di archiviazione dei log e all'aggregazione da VM distribuite (e spesso temporanee).
Google Cloud offre una suite di strumenti utili per la raccolta, l'elaborazione e l'analisi strutturata dei log. È buona norma installare l'agente Cloud Logging nelle VM di Compute Engine. (per impostazione predefinita, l'agente è preinstallato nelle immagini VM di App Engine e GKE). L'agente monitora un insieme preconfigurato di località di logging. I log generati dalle app in esecuzione nella VM vengono raccolti e trasmessi a Cloud Logging.
Se il logging è abilitato per un cluster GKE, viene eseguito il deployment di un agente Logging su ogni nodo che fa parte del cluster. L'agente raccoglie i log, li arricchisce con metadati pertinenti e li inserisce in un datastore. Questi log sono disponibili per la revisione utilizzando Cloud Logging. Se hai bisogno di un maggiore controllo su ciò che viene registrato, puoi utilizzare i daemonset Fluentd.
Per maggiori informazioni, consulta Configurare l'agente Logging.
12. Processi di amministrazione
I processi amministrativi di solito consistono in attività una tantum o a tempo ripetibili, come la generazione di report, l'esecuzione di script batch, l'avvio di backup dei database e la migrazione degli schemi. Il fattore dei processi amministrativi nel manifesto dei dodici fattori è stato scritto pensando alle attività una tantum. Per le app cloud-native, questo fattore diventa più pertinente quando crei attività ripetibili e le indicazioni in questa sezione sono orientate ad attività come quelle.
I trigger a tempo sono spesso creati come cron job e sono gestiti intrinsecamente dalle app stesse. Questo modello funziona, ma introduce una logica strettamente collegata all'app e che richiede manutenzione e coordinamento, in particolare se le app sono distribuite in fusi orari diversi.
Di conseguenza, quando progetti per i processi amministrativi, devi disaccoppiare la gestione di queste attività dall'app stessa. A seconda degli strumenti e dell'infrastruttura su cui viene eseguita l'app, utilizza i seguenti suggerimenti:
- Per eseguire app su GKE, avvia container separati per le attività di amministrazione. Puoi sfruttare i CronJobs in GKE. I CronJob vengono eseguiti in container temporanei e ti consentono di controllare le tempistiche, la frequenza di esecuzione e i nuovi tentativi se i job hanno esito negativo o se richiedono troppo tempo per essere completato.
- Per l'hosting di app su App Engine o Compute Engine, puoi esternalizzare il meccanismo di trigger e creare un endpoint da far richiamare. Questo approccio consente di definire un confine intorno a ciò di cui sono responsabili le app, in contrasto con l'obiettivo specifico dell'endpoint. Cloud Tasks è un servizio di esecuzione delle attività asincrono completamente gestito che puoi utilizzare per implementare questo pattern con App Engine. Puoi inoltre utilizzare Cloud Scheduler, uno scheduler di livello enterprise completamente gestito su Google Cloud, per attivare operazioni a tempo.
Oltre i dodici fattori
I dodici fattori descritti in questo documento forniscono indicazioni su come approccio alla creazione di app cloud-native. Queste app sono gli elementi di base di un'azienda.
Un'azienda tipica ha molte app come queste, spesso sviluppate da diversi team in modo collaborativo per fornire funzionalità aziendali. È importante stabilire alcuni principi aggiuntivi durante il ciclo di vita dello sviluppo delle app, e non come un passaggio successivo, per definire il modo in cui le app comunicano tra loro e le modalità di protezione e controllo dell'accesso.
Le seguenti sezioni descrivono alcune di queste considerazioni aggiuntive che dovresti fare durante la progettazione e lo sviluppo dell'app.
Metti in primo piano le API
Le app comunicano tramite API. Quando crei app, pensa a come verrà utilizzata dall'ecosistema dell'app e inizia a progettare una strategia API. Una buona progettazione dell'API ne facilita l'utilizzo da parte degli sviluppatori e degli stakeholder esterni. È buona norma iniziare documentando l'API utilizzando la specifica OpenAPI prima di implementare qualsiasi codice.
Le API astraggono la funzionalità di base dell'app. Un endpoint API ben progettato deve isolare e disaccoppiare le applicazioni utilizzate dall'infrastruttura delle app che fornisce il servizio. Questo disaccoppiamento ti offre la possibilità di modificare il servizio sottostante e la sua infrastruttura in modo indipendente, senza influire sui consumatori dell'app.
È importante catalogare, documentare e pubblicare le API che sviluppi in modo che i consumatori delle API possano scoprirle e utilizzarle. Idealmente, vuoi che i consumer delle API si occupino autonomamente. Puoi farlo configurando un portale per gli sviluppatori. Un portale per gli sviluppatori funge da punto di ingresso per tutti i consumer di API: interni per l'azienda o esterni per i consumatori, ad esempio gli sviluppatori del tuo ecosistema di partner.
Apigee, la suite di prodotti per la gestione delle API di Google, ti aiuta a gestire l'intero ciclo di vita delle API, dalla progettazione alla creazione fino alla pubblicazione.
Sicurezza
La sicurezza è eterogenea e include sistemi operativi, reti e firewall, sicurezza di dati e database, sicurezza delle app e gestione di identità e accessi. È di fondamentale importanza affrontare tutte le dimensioni della sicurezza nell'ecosistema di un'azienda.
Dal punto di vista di un'app, le API forniscono l'accesso alle app nel tuo ecosistema aziendale. Pertanto, assicurati che questi componenti di base svolgano considerazioni relative alla sicurezza durante il processo di progettazione e creazione dell'app. Ecco alcune considerazioni per contribuire a proteggere l'accesso alla tua app:
- TLS (Transport Layer Security). Utilizzare TLS per contribuire a proteggere i dati in transito. Potresti voler utilizzare TLS reciproca per le tue app aziendali. Questo aspetto è semplificato se utilizzi mesh di servizi come Istio su Google Kubernetes Engine. Inoltre, in alcuni casi d'uso è comune creare liste consentite e liste bloccate basate sugli indirizzi IP come ulteriore livello di sicurezza. La sicurezza dei trasporti implica anche la protezione dei servizi da attacchi DDoS e bot.
- Sicurezza delle app e degli utenti finali. I sistemi di sicurezza dei trasporti contribuiscono a garantire la sicurezza dei dati in transito e instaura un clima di fiducia. Tuttavia, è buona norma aggiungere la sicurezza a livello di app per controllare l'accesso all'app in base al relativo consumatore. I consumatori possono essere altre app, dipendenti, partner o clienti finali della tua azienda. Puoi applicare la sicurezza utilizzando le chiavi API (per il consumo delle app), l'autenticazione e l'autorizzazione basate su certificazione, la piattaforma di scambio JSON Web Tokens (JWT) o il Security Assertion Markup Language (SAML).
Il panorama della sicurezza si evolve costantemente all'interno di un'azienda, rendendo più difficile per te codificare i costrutti di sicurezza nelle tue app. I prodotti di gestione delle API come Apigee aiutano a proteggere le API in tutti i livelli menzionati in questa sezione.
La sicurezza della catena di fornitura del software è un problema difficile da risolvere. È importante prendere precauzioni. Software Delivery Shield è una soluzione end-to-end completamente gestita che aiuta a migliorare la sicurezza della catena di fornitura del software durante l'intero ciclo di vita dello sviluppo del software. Offre i seguenti servizi e altri:
Cloud Build. Supporta le build di livello 3 SLSA per le immagini container e genera la provenienza delle build autenticata e non falsabile per le applicazioni containerizzate.
Assured Open Source Software. Consente di ridurre il rischio per la catena di fornitura del software utilizzando gli stessi pacchetti OSS utilizzati da Google.
Inoltre, sono disponibili vari servizi e funzioni per contribuire a migliorare la sicurezza della catena di fornitura del software.
Per saperne di più sulla sicurezza della catena di fornitura del software, consulta Sicurezza della catena di fornitura del software. Per ulteriori informazioni su Software Delivery Shield, consulta la panoramica di Software Delivery Shield.
Passaggi successivi
- Esamina l'app demo dei microservizi che utilizza principi dell'app a dodici fattori ed è creata utilizzando i prodotti e i servizi Google Cloud.
- Visita il Cloud Architecture Center e scopri le architetture di riferimento, le linee guida e le best practice per la creazione o la migrazione dei carichi di lavoro su Google Cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.