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 rendere scalabile e resilienti di cui è possibile eseguire il deployment continuo 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ù con esperienza nella progettazione e nel deployment di app cloud-native. Da questa esperienza, è emerso un insieme di best practice, comunemente note 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 di modo di pensare su software engineering, configurazione e deployment, rispetto la 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 progettazione a 12 fattori aiuta anche a disaccoppiare i componenti dell'app, ogni componente può essere sostituito con facilità, oppure può essere fatto lo scale up o lo scale down 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 dodici fattori
1. Codebase
Dovresti monitorare il codice della tua app in un sistema di controllo della versione come Git o Mercuriale. 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).
Gli sviluppatori potrebbero lavorare su diverse versioni del codice ambienti di sviluppo, in qualsiasi momento la fonte attendibile è il codice il sistema di controllo della versione. Il codice nel repository è ciò che viene creato, viene testato e sottoposto a deployment e il numero di repository è indipendente dal diversi 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. (Eventuali modifiche obbligatorio per la release dovrebbe generare una nuova release).
2. Dipendenze
Ci sono due aspetti importanti da tenere in considerazione per quanto riguarda le dipendenze app: dichiarazione delle dipendenze e 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 privata degli artefatti completamente gestito che supporta vari di artefatti come immagini container, pacchetti di linguaggio (come Maven e npm) e pacchetti di sistemi operativi (come RPM). Per aiutarti a gestire i risultati delle tue operazioni CI/CD e le loro dipendenze, puoi usare Cloud IAM con Artifact Registry con un controllo dell'accesso granulare. 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 eseguire il push delle immagini nel registro e poi eseguire il pull delle immagini utilizzando un endpoint HTTP da qualsiasi macchina, che si tratti di un'istanza Compute Engine o il 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 esternalizzato correttamente è vedere se il codice può essere reso pubblico senza che rivela eventuali credenziali.
Un modo per esternalizzare la configurazione consiste nel creare i file di configurazione. Tuttavia, i file di configurazione sono in genere specifici di un linguaggio o di uno sviluppo il modello di machine learning.
Un approccio migliore consiste nel memorizzare la configurazione nelle variabili di ambiente. Si tratta di facili da modificare per ciascun ambiente in fase di runtime, non verranno probabilmente controllati al controllo della versione, e sono indipendenti dal linguaggio di programmazione framework di sviluppo. In Google Kubernetes Engine (GKE), puoi utilizzare ConfigMaps. Ciò ti consente di associare variabili di ambiente, numeri di porta, file di configurazione gli argomenti della riga di comando e altri artefatti di configurazione di container e componenti di sistema in fase di runtime.
Cloud Functions 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. Dovresti pensare a questi 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 release specifica il risultato della combinazione della 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 creazione prende il codice, recupera le librerie e gli asset richiesti e li pacchettizza in un file binario o container autonomo. Il risultato la fase di build è un artefatto della build.
Una volta completata la fase di build, la fase di rilascio combina l'artefatto della build con la configurazione di un ambiente specifico. Questo produce una release. La di Google Cloud può essere implementato automaticamente nell'ambiente tramite una di deployment. In alternativa, puoi attivare il rilascio tramite la stessa di deployment.
Infine, la fase di esecuzione avvia la release. Ad esempio, se
di cui esegui il deployment in GKE, Cloud Build può
gke-deploy
per il deployment nel tuo cluster GKE. Cloud Build
può gestire e automatizzare le fasi di build, rilascio ed esecuzione
linguaggi e ambienti utilizzando file di configurazione di compilazione in YAML o JSON
formato.
Inoltre, puoi utilizzare Cloud Deploy che offrono la distribuzione continua in GKE, Cloud Run e con GKE Enterprise. Con Cloud Deploy puoi creare una pipeline di distribuzione che include l'approvazione passaggi e una promozione perfetta in più ambienti. Inoltre, Cloud Deploy supporta un rollback in un 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. Questi i processi 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. Perché i processi possono scomparire in qualsiasi momento, non puoi fare affidamento sul fatto che lo spazio di archiviazione locale sia disponibile o che qualsiasi richiesta successiva verrà gestita con la stessa procedura. Pertanto, devono conservare in modo esplicito tutti i dati che devono essere riutilizzati in una 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
In ambienti non cloud, le app web vengono spesso scritte per essere eseguite in container di app ad esempio 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.
Sono best practice sull'architettura dei servizi per esporre un numero di porta,
specificato dal
PORT
variabile di ambiente.
Le app che esportano l'associazione di porte possono utilizzare le informazioni relative all'associazione di porte esternamente (come variabili di ambiente) quando si utilizza Platform as a Service un modello di machine learning. 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 app in App Engine, dichiari le dipendenze per aggiungere una libreria di server web come Express (per Node.js), Flask e Gunicorn (per Python), o Jetty (per Java).
Non inserire numeri di porta hardcoded nel codice. Devi invece fornire i numeri di porta nell'ambiente, ad esempio in una variabile di ambiente. Questo rende portabili le tue app 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. Service Discovery tramite 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 L'app App Engine mostra come accettare un valore di porta passato in un 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 processo ad esempio in background, web e worker. 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 di fare lo scale out aggiungendo più 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 computing che ti consente di eseguire i 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. Di solito è abituato
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 di Cloud Functions
Cloud Functions sono funzioni stateless a uso specifico in esecuzione su Google Cloud, l'architettura sottostante su cui vengono eseguite è gestita per te da Google. Cloud Functions risponde ai trigger di eventi, come un caricamento in un nel bucket Cloud Storage o in un messaggio Pub/Sub. Ogni funzione la chiamata risponde a un singolo evento o richiesta.
Cloud Functions gestisce le richieste in entrata assegnandole alle istanze della tua funzione. Quando il volume di richieste in entrata supera il numero di richieste esistenti di Compute Engine, 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, 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. Istanze sono le unità di calcolo utilizzate da App Engine per scalare automaticamente dell'app. In qualsiasi momento, la tua app può essere eseguita su un'istanza o su più istanze e le richieste vengono distribuite su tutte le istanze.
Lo scheduler di App Engine decide come gestire ogni nuova richiesta. La lo scheduler potrebbe usare un'istanza esistente (una inattiva o una accetta richieste in parallelo), metti la richiesta in una coda di richieste in attesa o avvia una nuova istanza per quella richiesta. La decisione prende in considerazione il numero di istanze disponibili, la velocità con cui la tua 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 rendimento e impostando l'utilizzo della CPU target, la velocità effettiva target e il valore massimo richieste in parallelo.
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
di scalabilità, consulta le
documentazione di App Engine.
Utilizzo della scalabilità automatica di GKE
Ci sono alcuni concetti chiave di Kubernetes 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. È 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 utilizzare in modo dichiarativo e configurare il cluster per la scalabilità. Con scalabilità automatica è abilitato, GKE scala automaticamente i nodi quando devono essere pianificati e quando i nodi esistenti non sono che li rappresentano. GKE fa lo scale down dei nodi anche quando il carico del cluster diminuisce in base alle soglie configurate.
Job. GKE supporta 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 completamento del job. La Il file YAML che configura il job specifica i dettagli sulla gestione degli errori, il parallelismo, come vengono gestiti i 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 per rispondere ai carichi variabili utilizzando gruppi di istanze gestite in base all'utilizzo della CPU, alle richieste gestite o ad altri indicatori di telemetria dalla tua app.
La figura seguente illustra le funzionalità principali dei gruppi di istanze gestite che fornisce.
Utilizzo gruppi di istanze gestite consente alla tua app di adattarsi alla domanda in entrata e di essere ad alta disponibilità. Questo concetto funziona intrinsecamente bene con le app stateless come i front-end web e basati su batch e ad alte prestazioni.
9. Rilasciabilità
Per le app eseguite sull'infrastruttura cloud, dovresti trattare queste app e l'infrastruttura sottostante come risorse usa e getta. Le tue app devono poter a gestire la perdita temporanea dell'infrastruttura sottostante e dovrebbe essere in grado arrestarsi e riavviarsi.
I principi chiave da prendere in considerazione includono:
- Disaccoppia le funzionalità, ad esempio la gestione e l'archiviazione transazionali usando i servizi di supporto. Per ulteriori informazioni, vedi Servizi di supporto in precedenza in questo documento.
- Gestisci le variabili di ambiente al di fuori dell'app in modo che possano essere è usata durante l'esecuzione.
- Assicurati che il tempo di avvio sia minimo. Ciò significa che devi decidere la creazione di livelli nelle immagini quando si utilizzano le macchine virtuali, come immagini pubbliche e 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 in sequenza in GKE gestire i token di sicurezza con Cloud Key Management Service (Cloud KMS).
Utilizza il segnale SIGTERM (quando disponibile) per avviare un arresto anomalo. Ad esempio, quando App Engine Flex arresta un'istanza, di solito invia un segnale STOP (SIGTERM) al container di 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à ambientale
Le app aziendali si spostano in diversi ambienti durante il loro sviluppo durante il ciclo di vita di attività. In genere questi ambienti sono di sviluppo, test e gestione temporanea, e produzione. È buona norma mantenere questi ambienti simili possibile.
La parità ambientale è una funzionalità che la maggior parte degli sviluppatori considera un determinato. Tuttavia, man mano che le aziende crescono e i loro ecosistemi IT si evolvono, l’ambiente la parità diventa più difficile da mantenere.
Mantenere la parità ambientale è diventato più facile negli ultimi anni perché gli sviluppatori hanno adottato il controllo del codice sorgente, la gestione delle configurazioni e i modelli di configurazione dei deployment. Questo semplifica il deployment di un'app su più 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 per scopi diversi e aiutano collettivamente a creare flussi di lavoro che la coerenza degli 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 su Google Cloud dell'infrastruttura. |
| 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 immagini personalizzate create da dischi di origine, immagini snapshot o immagini archiviate in Cloud Storage. Puoi utilizzare questi per creare istanze di macchine virtuali (VM) su misura per app. |
| Cloud Deploy | Fornisci la distribuzione automatica delle tue applicazioni a una serie di degli ambienti di destinazione in una sequenza definita. |
11. Log
I log ti offrono consapevolezza circa lo stato delle tue 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 Agente Cloud Logging nelle tue VM Compute Engine. (L'agente è preinstallate nelle immagini VM di App Engine e GKE per impostazione predefinita. L'agente monitora un insieme preconfigurato di località di logging. I log generati dalle app in esecuzione nella VM vengono raccolti e trasmessi in flusso su Cloud Logging.
Quando il logging è abilitato per un cluster GKE, viene eseguito un agente Logging il deployment 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 un maggiore controllo su ciò che viene registrato, puoi usare i daemonset Fluentd.
Per ulteriori informazioni, consulta Configurare l'agente Logging.
12. Processi di amministrazione
I processi amministrativi consistono solitamente in attività una tantum o in tempo reale, ripetibili come la generazione di report, l'esecuzione di script batch, l'avvio del database i backup e la migrazione degli schemi. I processi amministrativi sono il fattore determinante manifest del modello a 12 fattori è stato scritto pensando ad 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. Questo modello funziona, ma introduce una logica strettamente associato all'app e che richiede manutenzione e coordinamento, soprattutto 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. In base agli strumenti e ai dell'infrastruttura su cui viene eseguita la tua app, utilizza i seguenti suggerimenti:
- Per l'esecuzione di app su GKE, avvia container separati per attività amministrative. Puoi sfruttare i vantaggi CronJobs in GKE. I CronJob vengono eseguiti in container temporanei e ti consentono controllano i tempi, la frequenza di esecuzione e i nuovi tentativi in caso di esito negativo o se il loro completamento richiede troppo tempo.
- Per l'hosting di app su App Engine o Compute Engine, può esternalizzare il meccanismo di attivazione e creare un endpoint trigger per richiamare. Questo approccio aiuta a definire un confine attorno a ciò che responsabili delle app, a differenza dell'ambito specifico endpoint. Cloud Tasks è un'attività asincrona completamente gestita che puoi usare per implementare questo pattern in App Engine. Puoi anche utilizzare Cloud Scheduler, uno scheduler completamente gestito di livello aziendale su Google Cloud, attivare operazioni a tempo.
Oltre i dodici fattori
I dodici fattori descritti in questo documento forniscono indicazioni su come dovresti la creazione di app cloud-native. Queste app rappresentano la base per blocchi di un'azienda.
Una tipica azienda ha molte app come queste, spesso sviluppate da diversi team in modo collaborativo per fornire funzionalità aziendali. È importante stabilire principi aggiuntivi durante il ciclo di vita di sviluppo dell'app e non come per capire come le app comunicano tra loro e come protetti e con controllo degli accessi.
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 crei le app, pensa a come queste verrà consumato dall'ecosistema della tua app e inizia progettando un'API. strategia. Una buona progettazione dell'API semplifica l'utilizzo dell'API da parte degli sviluppatori di app stakeholder esterni. È buona prassi iniziare documentando l'API utilizzando 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 che utilizzano l'app dall'app 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
Il regno della sicurezza è ampio e include sistemi operativi, reti e firewall, sicurezza di dati e database, sicurezza delle app e identità e accesso gestione dei dispositivi. È di fondamentale importanza esaminare tutte le dimensioni sicurezza nell'ecosistema aziendale.
Dal punto di vista di un'app, le API forniscono accesso alle app nella tua azienda all'interno dell'ecosistema Google Cloud. Devi quindi assicurarti che questi componenti di base rispondano considerazioni sulla sicurezza durante il processo di progettazione e creazione dell'app. Considerazioni per contribuire a proteggere l'accesso alla tua app includono quanto segue:
- TLS (Transport Layer Security). Utilizza il protocollo 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. Sicurezza dei trasporti comporta anche la protezione dei servizi da attacchi DDoS e bot.
- Sicurezza delle app e dell'utente finale. La sicurezza dei trasporti contribuisce a garantire la sicurezza dei dati in transito e instaura un clima di fiducia. Tuttavia, una best practice consiste nell'aggiungere Sicurezza a livello di app per controllare l'accesso all'app in base al dell'app. I consumatori possono essere altre app, dipendenti, partner o per i clienti finali della tua azienda. Puoi applicare la sicurezza utilizzando le chiavi API (per il consumo di app), l'autenticazione e l'autorizzazione basate sulla certificazione, JWT (Token web JSON) piattaforma di scambio pubblicitario o SAML (Security Assertion Markup Language).
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 e altri servizi:
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 i rischi per la catena di fornitura del software utilizzando lo stesso software open source e pacchetti utilizzati da 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.