Questo documento descrive le metodologia delle app a 12 fattori e come applicarla quando sviluppi app in esecuzione in Google Cloud. Se utilizzi questa metodologia, puoi creare applicazioni scalabili e resilienti che possono essere implementate continuamente con la massima agilità.
Questo documento è rivolto agli sviluppatori che conoscono bene Google Cloud, controllo della versione, integrazione continua e container tecnologia.
Introduzione
Gli sviluppatori stanno spostando le app nel cloud e, di conseguenza, diventano sempre più esperienza nella progettazione e nel deployment di app cloud-native. Da questa esperienza è emerso un insieme di best practice, comunemente noto come dodici fattori. Progettare un'app tenendo presenti questi fattori ti consente di eseguire il deployment delle app nel cloud più portabili e resilienti rispetto alle app implementate 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 di pensare alla progettazione, alla configurazione e al deployment del software rispetto alla progettazione di app per ambienti on-premise. Questo documento ti aiuta a comprendere come applicare i dodici fattori al design della tua app.
Vantaggi delle app a 12 fattori
La metodologia di progettazione a 12 fattori aiuta anche a disaccoppiare i componenti dell'app, in modo da poter sostituire o fare lo scale up o lo scale down di ogni componente con facilità. Poiché I fattori sono indipendenti dal linguaggio di programmazione o dallo stack software, la progettazione a 12 fattori può essere applicata a un'ampia gamma di app.
I 12 fattori
1. Codebase
Devi monitorare il codice della tua app in un sistema di controllo della versione come Git o Mercurial. Lavori all'app e dai un'occhiata al codice al tuo di sviluppo software. 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 per risolvere i conflitti di unione e la possibilità di il codice a una versione precedente. Offre anche il punto di partenza per svolgere attività integrazione (CI) e deployment continuo (CD).
Sebbene gli sviluppatori possano lavorare su versioni diverse del codice nei propri ambienti di sviluppo, in qualsiasi momento la fonte attendibile è il codice nel sistema di controllo del codice sorgente. Il codice nel repository viene compilato, provato e implementato e il numero di repository è indipendente dal numero di ambienti. Il codice nel repository viene utilizzato per produrre un singolo che viene combinata con la configurazione specifica dell'ambiente per produrre una release immutabile in cui non è possibile apportare modifiche, inclusa la release del deployment, di cui può essere eseguito il deployment in un ambiente. (Qualsiasi modifica obbligatorio per la release deve generare una nuova release).
2. Dipendenze
Ci sono due aspetti importanti da tenere in considerazione per quanto riguarda le dipendenze per le app a 12 fattori: la dichiarazione delle dipendenze e l'isolamento delle dipendenze.
Le app a 12 fattori non dovrebbero mai avere dipendenze implicite. Devi dichiarare le dipendenze in modo esplicito e controllale nel controllo della versione. Ciò consente di iniziare a utilizzare il codice rapidamente e in modo ripetibile semplifica il monitoraggio delle modifiche alle dipendenze. Molti linguaggi di programmazione offrono un modo per dichiarare esplicitamente le dipendenze, ad esempio pip per Python e Bundler per Ruby.
Devi anche isolare un'app e le sue dipendenze pacchettizzandole in una containerizzato. I container consentono di isolare un'app e le sue dipendenze dalla sua e garantire che l'app funzioni in modo uniforme nonostante eventuali differenze tra gli ambienti di sviluppo e di gestione temporanea.
Artifact Registry è un servizio di gestione degli elementi privati completamente gestito che supporta vari tipi di elementi, come immagini container, pacchetti di linguaggio (ad esempio Maven e npm) e pacchetti di sistemi operativi (ad esempio RPM). Per aiutarti a gestire i risultati delle compilazioni CI/CD e le relative dipendenze, puoi utilizzare Cloud IAM con Artifact Registry con controllo granulare dell'accesso. Analisi degli artefatti rileva le vulnerabilità nelle immagini container di cui è stato eseguito il push su Artifact Registry per garantire che le immagini container siano sicure prima di eseguirne il deployment.
Le integrazioni CI/CD esistenti ti consentono inoltre di impostare pipeline completamente automatizzate per ottenere un feedback rapido. Puoi caricare le immagini nel registry e poi recuperarle utilizzando un endpoint HTTP da qualsiasi macchina, che si tratti di un'istanza Compute Engine o del tuo hardware.
3. Configurazione
Ogni app moderna richiede una qualche forma di configurazione. Di solito hai 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 ai servizi di supporto come i database.
Le configurazioni di ciascun ambiente devono essere esterne al codice nel controllo della versione. Tutti lavorano su una sola versione del codice, ma hai più configurazioni. L'ambiente di deployment e determina la configurazione da utilizzare. Ciò consente a una versione del programma binario il deployment in ciascun ambiente, dove l'unica differenza è il runtime configurazione. Un modo semplice per verificare se la configurazione è stata externalizzata correttamente è vedere se il codice può essere reso pubblico senza rivelare alcuna credenziale.
Un modo per esternalizzare la configurazione consiste nel creare i file di configurazione. Tuttavia, i file di configurazione sono in genere specifici per un linguaggio o un framework di sviluppo.
Un approccio migliore consiste nel memorizzare la configurazione nelle variabili di ambiente. Sono facili da modificare per ogni ambiente in fase di esecuzione, non è probabile 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 elementi di configurazione ai container e ai componenti di sistema dei pod al runtime.
Funzioni di Cloud Run e Cloud Run per supportare l'uso 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 come servizio ed esternalizzata nella configurazione. Devi considerare questi servizi di supporto come astrazioni per la risorsa sottostante. Ad esempio, quando l'app scrive i dati nello spazio di archiviazione, trattando lo spazio di archiviazione come un servizio di supporto di modificare senza interruzioni il tipo di archiviazione sottostante, dato che è disaccoppiato direttamente dall'app. Puoi quindi apportare una modifica, ad esempio il passaggio da un PostgreSQL in 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: build, release ed esecuzione. Ogni fase deve generare un artefatto identificabili in modo univoco. Ogni deployment deve essere collegato a una specifica release ottenuta combinando la configurazione di un ambiente con una build. Questo consente rollback semplici e un audit trail visibile della cronologia deployment di produzione.
Puoi attivare manualmente la fase di creazione, ma solitamente viene attivato automaticamente quando esegui il commit di codice che ha superato tutti i test richiesti. La fase di compilazione prende il codice, recupera le librerie e gli asset richiesti e li impacchetta in un file binario o un contenitore autonomo. Il risultato della fase di compilazione è un artefatto di compilazione.
Una volta completata la fase di build, la fase di rilascio combina l'artefatto della build con la configurazione di un ambiente specifico. Viene generata una release. La release può essere implementata automaticamente nell'ambiente da un'app di implementazione continua. In alternativa, puoi attivare la release tramite la stessa app di implementazione continua.
Infine, la fase di esecuzione avvia la release. Ad esempio, se stai eseguendo il deployment in GKE, Cloud Build può chiamare il passaggio di compilazione gke-deploy per eseguire il deployment nel tuo cluster GKE. Cloud Build può gestire e automatizzare le fasi di compilazione, rilascio ed esecuzione in più lingue e ambienti utilizzando file di configurazione di compilazione in formato YAML o JSON.
Inoltre, puoi utilizzare Cloud Deploy che, come servizio completamente gestito, fornisce la distribuzione continua in GKE, Cloud Run e GKE Enterprise. Con Cloud Deploy puoi creare una pipeline di distribuzione che includa i passaggi di approvazione e la promozione senza problemi a 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 12 fattori nell'ambiente come uno o più processi. Queste procedure devono essere stateless e non devono condividere dati tra loro. Questo consente lo scale up delle app attraverso la replica dei processi. Creazione in corso... le applicazioni stateless rendono inoltre portabili i processi in tutta l'infrastruttura di computing.
Se hai familiarità con il concetto di "persistente" sessioni, è necessario modificare di come gestire e rendere persistenti i dati. Poiché i processi possono essere eliminati in qualsiasi momento, non puoi fare affidamento sulla disponibilità dei contenuti dello spazio di archiviazione locale o sull'eventuale gestione della richiesta successiva dallo stesso processo. Pertanto, devi memorizzare esplicitamente tutti i dati che devono essere riutilizzati in un servizio di supporto esterno come un database.
Se hai bisogno di mantenere i dati, puoi usare Memorystore e Filestore come servizio di supporto per memorizzare nella cache lo stato per le tue app e condividere dati tra i processi per favorire un basso accoppiamento.
7. Associazione di porte
Negli ambienti non cloud, le app web vengono spesso scritte per essere eseguite in container per app come GlassFish, Apache Tomcat e Apache HTTP Server. Al contrario, le app a 12 fattori non si basano su container di app esterni. Raggruppano invece la libreria dei server web come parte dell'app stessa.
È una best practice di architettura per i servizi esporre un numero di porta, specificato dalla variabile di ambiente PORT.
Le app che esportano la mappatura delle porte sono in grado di utilizzare le informazioni sulla mappatura delle porte esternamente (come variabili di ambiente) quando si utilizza il modello piattaforma-as-a-service. In Google Cloud puoi eseguire il deployment di app su servizi di piattaforma come Compute Engine, GKE, App Engine o in Cloud Run.
In questi servizi, un livello di routing instrada le richieste da un nome host visibile al pubblico. ai processi web legati alla porta. Ad esempio, quando esegui il deployment delle tue app su App Engine, dichiari le dipendenze per aggiungere una libreria del web server all'app, ad esempio Express (per Node.js), Flask e Gunicorn (per Python) o Jetty (per Java).
Non devi codificare i numeri di porta nel codice. Devi invece fornire i numeri di porta nell'ambiente, ad esempio in una variabile di ambiente. In questo modo, le tue app diventano portabili quando le esegui su Google Cloud.
Poiché Kubernetes ha Service Discovery integrato, in Kubernetes astraggono le associazioni di porte mediante la mappatura delle porte di servizio ai container. Il Service Discovery viene eseguito utilizzando i nomi DNS interni.
Invece di impostare come hardcoded la porta su cui il server web rimane in ascolto, la porta utilizza una variabile di ambiente. Il seguente snippet di codice di un'app App Engine mostra come accettare un valore di porta passato 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à
Devi decomporre l'app in processi indipendenti in base ai tipi di processo, come i processi in background, web e di lavoro. Consente lo scale up della tua app o meno in base ai requisiti dei singoli carichi di lavoro. La maggior parte delle app cloud-native puoi scalare su richiesta. Devi progettare l'app come più processi distribuiti in grado di eseguire in modo indipendente blocchi di lavoro e scalare aggiungendo altri processi.
Le seguenti sezioni descrivono alcuni concetti per consentire alle app di su larga scala. App create con i principi della rilasciabilità e l'statelessness in fondo sono ben posizionati per trarre vantaggio da questi costrutti di la scalabilità orizzontale di un'applicazione.
Utilizzo di Cloud Run
Cloud Run
è una piattaforma di calcolo che ti consente di eseguire container direttamente sull'infrastruttura gestita da Google. Cloud Run supporta due modi per eseguire
le API nel tuo codice. Cloud Run services viene eseguito continuamente come servizio. In genere viene utilizzato per rispondere a richieste o eventi web. Cloud Run jobs esegue codice che esegue specifiche
lavoro e si arresta quando termina il lavoro. Cloud Run offre inoltre
Cloud Scheduler per eseguire job batch. Questa struttura è adatta a implementare
della contemporaneità e della scalabilità di possibili architetture di servizio.
Per ulteriori informazioni Cloud Run, consulta Che cos'è Cloud Run.
Utilizzo delle funzioni Cloud Run
Le funzioni Cloud Run sono funzioni stateless e monouso che vengono eseguite su Google Cloud, dove l'architettura di base su cui vengono eseguite è gestita da Google. Le funzioni Cloud Run rispondono ai trigger di eventi, come un caricamento in una nel bucket Cloud Storage o in un messaggio Pub/Sub. Ogni chiamata della funzione risponde a un singolo evento o richiesta.
Le funzioni Cloud Run gestisce le richieste in entrata assegnandole alle istanze della tua funzione. Quando il volume delle richieste in entrata supera il numero di istanze esistenti, le funzioni Cloud Run potrebbero avviare nuove istanze per gestire le richieste. Questo comportamento di scalabilità automatica e completamente gestito consente alle funzioni Cloud Run di gestire molte richieste in parallelo, ognuna utilizzando un'istanza diversa personalizzata.
Utilizzo di App Engine
Puoi ospitare le tue app sull'infrastruttura gestita di Google Cloud utilizzando in App Engine. Le istanze sono le unità di calcolo utilizzate da App Engine per scalare automaticamente la tua app. In qualsiasi momento, la tua app può essere in esecuzione su una o più istanze, con le richieste distribuite su tutte.
Lo scheduler di App Engine decide come gestire ogni nuova richiesta. Lo schedulatore potrebbe utilizzare un'istanza esistente (inattiva o che accetta richieste simultanee), inserire la richiesta in una coda di richieste in attesa o avviare una nuova istanza per la richiesta. La decisione prende in considerazione il numero di istanze disponibili, la velocità con cui la tua app ha soddisfatto 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 della CPU target, il throughput target e il numero massimo di richieste simultanee.
Puoi specificare il tipo di scalabilità nel file app.yaml, per cui esegui il caricamento
la versione del servizio. In base a questo input di configurazione, App Engine
dell'infrastruttura 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 aumentare o diminuire il numero di pod in esecuzione nel cluster in base a metriche standard o personalizzate. È utile quando devi rispondere a un carico variabile in un cluster Kubernetes.
Scalabilità automatica dei nodi. Nei periodi di maggiore domanda, potrebbe essere necessario scalare il cluster per e ospitare più pod. Con GKE, puoi configurare in modo dichiarativo il tuo cluster per scalare. Con la scalabilità automatica abilitata, GKE esegue automaticamente lo scale up dei nodi quando è necessario pianificare pod aggiuntivi e quando i nodi esistenti non sono in grado di accomodarli. GKE fa lo scale down dei nodi anche quando il carico del cluster diminuisce in base alle soglie configurate.
Job. GKE supporta i job Kubernetes. Per job si intende in generale un'attività che richiede uno o più pod per essere eseguita per eseguire l'attività. Il job potrebbe essere eseguito una volta o in base a una pianificazione. I pod in cui viene eseguito il job vengono eliminati al termine del job. Il file YAML che configura il job specifica i dettagli relativi alla gestione degli errori, al parallelismo, alla gestione dei riavvii e così via.
Utilizzo di Compute Engine
In alternativa, puoi eseguire il deployment delle app e gestirle su Compute Engine. In questo caso, puoi scalare l'app in modo che risponda a carichi variabili utilizzando gruppi di istanze gestite (MIG) in base all'utilizzo della CPU, alle richieste gestite o ad altri indicatori di telemetria della tua app.
La figura seguente illustra le funzionalità principali dei gruppi di istanze gestite che fornisce.
L'utilizzo dei gruppi di istanze gestite consente alla tua app di adattarsi alla domanda in arrivo ed essere altamente disponibile. Questo concetto funziona bene per impostazione predefinita 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 che vengono eseguite sull'infrastruttura cloud, devi trattarle e l'infrastruttura di base come risorse usa e getta. Le tue app dovrebbero essere in grado di gestire la perdita temporanea dell'infrastruttura sottostante e di eseguire un arresto e un riavvio graceful.
I principi chiave da prendere in considerazione includono:
- Scollega funzionalità come la gestione dello stato e l'archiviazione dei dati transazionali utilizzando i servizi di supporto. Per ulteriori informazioni, consulta Servizi di supporto all'inizio di 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 minimo. Ciò significa che devi decidere quanto stratificare le immagini quando utilizzi le macchine virtuali, ad esempio le immagini pubbliche rispetto a quelle personalizzate. Questa decisione è specifica per ciascuna app e deve essere basato sulle attività eseguite dagli script di avvio. Ad esempio, se stai scaricando diversi pacchetti o file binari e li stai inizializzando durante l'avvio, una parte considerevole del tuo tempo di avvio al completamento di queste attività.
- Usa le funzionalità native di Google Cloud per eseguire l'infrastruttura attività di machine learning. Ad esempio, puoi utilizzare gli aggiornamenti incrementali in GKE e gestire le tue chiavi di sicurezza utilizzando Cloud Key Management Service (Cloud KMS).
Utilizza l'indicatore SIGTERM (se disponibile) per avviare un arresto pulito. Ad esempio, quando l'ambiente flessibile di App Engine arresta un'istanza, normalmente invia un segnale di arresto (SIGTERM) al contenitore dell'app. La tua app può utilizza questo indicatore per eseguire azioni di pulizia prima che il container si arresti verso il basso. L'app non deve rispondere all'evento SIGTERM. Sottopeso condizioni normali, il sistema attende fino a 30 secondi per l'arresto dell'app e poi invia un segnale KILL (SIGKILL).
Il seguente snippet in un'app di App Engine mostra come può intercettare il segnale SIGTERM per chiudere le connessioni di database aperte.
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à dell'ambiente
Le app aziendali si spostano in diversi ambienti durante il loro ciclo di vita di sviluppo. In genere, questi ambienti sono sviluppo, test, gestione temporanea e produzione. È buona norma mantenere questi ambienti simili possibile.
La parità dell'ambiente è una funzionalità che la maggior parte degli sviluppatori dà per scontata. Tuttavia, man mano che le aziende crescono e i loro ecosistemi IT si evolvono, l’ambiente la parità diventa più difficile da mantenere.
Negli ultimi anni è diventato più facile mantenere la parità dell'ambiente perché gli sviluppatori hanno adottato il controllo del codice sorgente, la gestione della configurazione e i file di configurazione basati su modelli. In questo modo è più facile eseguire il deployment di un'app in più ambienti in modo coerente. Ad esempio, utilizzando Docker e Docker Compose, può garantire che lo stack di app mantenga la sua forma e la sua strumentazione ambienti cloud-native.
La tabella seguente elenca i servizi e gli strumenti Google Cloud che puoi utilizzare per progettare app da eseguire su Google Cloud. Questi componenti hanno scopi diversi e, nel loro insieme, ti aiutano a creare flussi di lavoro che rendono più coerenti i tuoi ambienti.
| Componente Google Cloud | Purpose |
|---|---|
| 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 tue build sull'infrastruttura di Google Cloud. |
| Cloud KMS | Archivia le tue chiavi di crittografia in un unico servizio cloud centrale per l'uso diretto da altre risorse e applicazioni cloud. |
| Cloud Storage | Archivia le 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 il caricamento automatico delle tue applicazioni in una serie di più ambienti di destinazione in una sequenza definita. |
11. Log
I log offrono consapevolezza circa lo stato delle app. È importante disaccoppia la raccolta, l'elaborazione e l'analisi dei log dalla logica principale le tue app. Il disaccoppiamento del logging è particolarmente utile quando le app richiedono scalabilità dinamica e sono in esecuzione su cloud pubblici, perché elimina overhead associato alla gestione della località di archiviazione per i log e dell'aggregazione di 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 prassi installare l'agente Cloud Logging nelle VM Compute Engine. L'agente è preinstallato nelle immagini VM di App Engine e GKE per impostazione predefinita. L'agente monitora un insieme preconfigurato di posizioni di logging. I log generati dalle tue app in esecuzione nella VM vengono raccolti e trasmessi in streaming a Cloud Logging.
Quando il logging è abilitato per un cluster GKE, un agente di logging viene eseguito su ogni nodo che fa parte del cluster. L'agente raccoglie i log, arricchisce i log con metadati pertinenti e li rende persistenti in un datastore. Questi log possono essere esaminati utilizzando Cloud Logging. Se hai bisogno di un maggiore controllo su ciò che viene registrato, puoi utilizzare i daemonset Fluentd.
Per ulteriori informazioni, consulta Configurare l'agente Logging.
12. Processi di amministrazione
Le procedure amministrative in genere consistono in attività una tantum o ripetibili programmate, come la generazione di report, l'esecuzione di script batch, l'avvio di backup del database e la migrazione degli schemi. Il fattore dei processi di amministrazione nel manifesto dei dodici fattori è stato scritto tenendo conto delle attività una tantum. Per le app cloud-native, questo fattore diventa più pertinente quando crei attività ripetibili e le indicazioni questa sezione è orientata verso attività simili.
I trigger a tempo vengono spesso creati come cron job e gestiti intrinsecamente le app in sé. Questo modello funziona, ma introduce una logica strettamente associata all'app e che richiede manutenzione e coordinamento, soprattutto se le app sono distribuite in fusi orari diversi.
Pertanto, quando progetti per i processi di amministrazione, devi disaccoppiare e la gestione di queste attività dall'app stessa. A seconda degli strumenti e dell'infrastruttura su cui viene eseguita la tua app, utilizza i seguenti suggerimenti:
- Per eseguire app su GKE, avvia contenitori separati per le attività di amministrazione. Puoi sfruttare i vantaggi CronJobs in GKE. I CronJob vengono eseguiti in container effimeri e ti consentono di controllare la tempistica, la frequenza di esecuzione e i tentativi di nuovo se i job non riescono o se impiegano troppo tempo per essere completati.
- Per ospitare le app su App Engine o Compute Engine, puoi externalizzare il meccanismo di attivazione e creare un endpoint da invocare per l'attivatore. Questo approccio consente di definire un confine per le responsabilità delle app, a differenza dell'obiettivo a scopo unico dell'endpoint. Cloud Tasks è un'attività asincrona completamente gestita che puoi usare per implementare questo pattern in App Engine. Puoi anche utilizzare Cloud Scheduler, un programmatore completamente gestito di livello enterprise su Google Cloud, per attivare operazioni programmate.
Oltre i 12 fattori
I dodici fattori descritti in questo documento forniscono indicazioni su come dovresti la 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 collaborazione per fornire funzionalità aziendali. È importante stabilire alcuni principi aggiuntivi durante il ciclo di vita dello sviluppo delle app e non come ripensamento, per affrontare il modo in cui le app comunicano tra loro e come sono protette e controllate.
Le seguenti sezioni descrivono alcune di queste considerazioni aggiuntive che puoi durante la progettazione e lo sviluppo dell'app.
Pensare incentrato sulle API
Le app comunicano tramite API. Quando sviluppi app, pensa a come verrà utilizzata dall'ecosistema della tua app e inizia a progettare una strategia API. Un buon design dell'API la rende facile da utilizzare per gli sviluppatori di app e per le parti interessate esterne. È buona prassi iniziare documentando l'API utilizzando OpenAPI prima di implementare qualsiasi codice.
Le API astraggono la funzionalità dell'app sottostante. Un endpoint API ben progettato deve isolare e disaccoppiare le applicazioni che utilizzano l'app dall'app dell'infrastruttura che fornisce il servizio. Questo disaccoppiamento ti offre la possibilità di modificare il servizio sottostante e la sua infrastruttura in modo indipendente, senza impatto sui consumatori dell'app.
È importante catalogare, documentare e pubblicare le API che sviluppi in modo da che i consumatori delle API possano scoprire e utilizzare le API. L'ideale è vuoi che i consumer delle API si occupino in prima persona. Puoi farlo configurare un portale per gli sviluppatori. Un portale per sviluppatori funge da punto di accesso tutti i consumer delle API: interni per l'azienda o esterni per i consumatori, gli sviluppatori del tuo ecosistema di partner.
Apigee, La suite di prodotti per la gestione delle API di Google consente di gestire l'intero ciclo di vita delle API dalla progettazione alla creazione fino alla pubblicazione.
Sicurezza
L'ambito della sicurezza è ampio e include sistemi operativi, reti e firewall, sicurezza dei dati e dei 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 accesso alle app nella tua azienda all'interno dell'ecosistema Google Cloud. Pertanto, devi assicurarti che questi componenti di base tengano conto delle considerazioni sulla sicurezza durante la progettazione e la compilazione dell'app. Di seguito sono riportate alcune considerazioni per contribuire a proteggere l'accesso alla tua app:
- Transport Layer Security (TLS). Utilizza TLS per proteggere i dati in transito. Può essere utile utilizzare TLS comune per le app aziendali. semplifica l'operazione se utilizzi mesh di servizi come Istio su Google Kubernetes Engine. In alcuni casi d'uso, è comune anche creare liste consentite e non consentite gli indirizzi IP come ulteriore livello di sicurezza. La sicurezza del trasporto prevede anche la protezione dei tuoi servizi da attacchi DDoS e tramite bot.
- Sicurezza delle app e degli utenti finali. La sicurezza dei trasporti contribuisce a garantire la sicurezza dei dati in transito e instaura un clima di fiducia. Tuttavia, è buona prassi aggiungere la sicurezza a livello di app per controllare l'accesso alla tua app in base a chi è il consumatore dell'app. I consumatori possono essere altre app, dipendenti, partner o clienti finali della tua azienda. Puoi applicare la sicurezza utilizzando le chiavi API (per le app di consumo), l'autenticazione e l'autorizzazione basate su certificazione, lo scambio di token web JSON (JWT) o Security Assertion Markup Language (SAML).
Il panorama della sicurezza si evolve costantemente all'interno di un'azienda, difficili da programmare per la sicurezza nelle tue app. Prodotti per la gestione delle API come Apigee le API sicure a 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 ancora:
Cloud Build. Supporta Build SLSA livello 3 per immagini container e genera origini di build autenticate e non falsificabili per per applicazioni containerizzate.
Software open source di Assured. Contribuisce a ridurre il rischio per la tua catena di fornitura software utilizzando gli stessi pacchetti OSS che utilizza Google.
Inoltre, sono disponibili vari servizi e funzioni per contribuire a migliorare la sicurezza della catena di fornitura del software.
Per ulteriori informazioni sulla catena di fornitura del software alla sicurezza, vedi Sicurezza della catena di fornitura del software. Per ulteriori informazioni su Software Delivery Shield, vedi Panoramica di Software Delivery Shield.
Passaggi successivi
- Esamina il app demo di microservizi che impiega principi dell'app a 12 fattori ed è stato creato i prodotti e i servizi Google Cloud.
- Visita il Centro architetture cloud e scopri architetture di riferimento, indicazioni e 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 Centro architetture cloud.