Gli esempi in questa pagina mostrano alcuni scenari ipotetici che utilizzano parchi risorse che illustrano alcuni dei concetti e delle best practice delle nostre guide. Prima di leggere questa guida, dovresti conoscere i concetti descritti in Introduzione ai parchi risorse e Requisiti e best practice del parco risorse.
Esempio 1: parchi risorse con risorse di produzione, gestione temporanea e sviluppo
In questo primo esempio, sono presenti quattro cluster. Due cluster sono per la produzione (in due regioni per la ridondanza), uno per la gestione temporanea e il test e l'ultimo per lo sviluppo. Tutti i cluster sono di proprietà e amministrati
a livello centrale da un team della piattaforma. In questo semplice esempio, sono presenti due servizi:
frontend e backend. Tuttavia, scenari più complessi potrebbero avere
un numero maggiore di servizi e cluster.
Approccio 1: separare i parchi risorse per produzione, gestione temporanea e sviluppo
Un possibile approccio all'utilizzo dei parchi risorse è quello di creare parchi risorse separati per le risorse di produzione, gestione temporanea e sviluppo.
Per farlo, creiamo tre progetti host del parco risorse separati e collochiamo le risorse al loro interno. In alternativa, nel caso del nostro cluster di sviluppo on-premise, registriamo il cluster nel progetto example-dev. Non abbiamo dovuto
risolvere molti dei problemi di uguaglianza degli spazi dei nomi e di uguaglianza dei servizi a causa della
granularità in questo esempio, ma ci siamo assicurati che gli spazi dei nomi dei cluster prod-east e
prod-west fossero ben normalizzati.
Il vantaggio di questo approccio è che l'isolamento tra ciascuno dei parchi risorse è molto forte. Lo svantaggio principale di questo approccio è che abbiamo bisogno di amministrare tre diversi parchi risorse, il che rende più difficile ottenere la coerenza tra produzione, gestione temporanea e sviluppo. Per i team di sviluppo, invece, è più difficile utilizzare servizi in fasi.
Approccio 2: un parco risorse per tutte le risorse
In questo approccio, creiamo un unico parco risorse per tutte le risorse.
Per farlo, possiamo lasciare le risorse nel progetto example e creare il parco risorse al suo interno. Avremmo potuto separare le nostre risorse di produzione e di gestione temporanea inserendole in altri progetti host del parco risorse e sfruttando il VPC condiviso, ma in questo esempio abbiamo scelto di non farlo per semplicità.
Con questo approccio, dobbiamo garantire che i nostri spazi dei nomi e servizi siano normalizzati in tutto il parco risorse. Ad esempio, rinominiamo il nostro nome generico frontend
in frontend-prod e frontend-staging rispettivamente nei cluster di produzione e di gestione temporanea. Infine, anche se potremmo mantenere i nomi originali degli spazi dei nomi di sviluppo, forniamo nomi più chiari (ad esempio frontend-dev-alice) per indicare che si tratta di spazi dei nomi di sviluppo.
Con questo approccio, preferiamo preferire la facilità di gestione all'isolamento. Ci affidiamo all'autorizzazione del mesh di servizi per impedire comunicazioni indesiderate tra i servizi, ma possiamo amministrare facilmente l'intero sistema con un unico parco risorse. Questo accordo ci consente di applicare criteri a tutte le risorse, il che può dare la certezza che lo sviluppo sembra molto vicino alla produzione.
Approccio 3: separa i parchi risorse per la produzione e per quelli non di produzione
In questo approccio, adottiamo una via di mezzo che combina le risorse di gestione temporanea e di sviluppo in un parco risorse non di produzione, ponendo al contempo la produzione in un parco risorse separato.
Per farlo, creiamo due progetti host del parco risorse, uno per la produzione e uno per
non di produzione. Inoltre, posizioniamo le nostre risorse direttamente in quei progetti, con il cluster dev on-premise registrato nel nostro parco risorse non di produzione. Dobbiamo
normalizzare gli spazi dei nomi e i servizi tra le nostre risorse di gestione temporanea e
sviluppo per fare chiarezza; ad esempio, rinominiamo frontend in
frontend-staging nel cluster di gestione temporanea.
Il vantaggio in questo caso è che la produzione è ben isolata dalla non produzione. Ad esempio, possiamo consentire ai servizi di sviluppo di comunicare con i servizi di gestione temporanea, in modo che la frontend della sviluppatrice Alice possa parlare con un backend inscenato mentre sviluppa il suo servizio.
Riepilogo
Ciascuno degli approcci descritti nell'esempio 1 è valido. La scelta scelta dalla tua organizzazione dipende dall'isolamento, dalla coerenza (e dalla facilità di gestione); in altre parole, il livello di isolamento necessario tra i diversi tipi di risorse e la coerenza necessaria tra i diversi tipi di risorse. Maggiore coerenza è più facile da ottenere con meno parchi risorse. Il terzo approccio viene offerto come possibile compromesso, mantenendo la produzione completamente isolata e offrendo agli sviluppatori la possibilità di lavorare su servizi in fasi.
Esempio 2: parchi risorse con diversi proprietari di risorse
In questo esempio abbiamo due team, team-a e team-b. Questi team possiedono e gestiscono i propri cluster ed entrambi hanno utilizzato gli spazi dei nomi frontend e backend per i servizi che producono. Tuttavia, né frontend né backend del team-a sono in realtà uguali a quelli del team-b. I due team vogliono creare un mesh di servizii in modo che i loro servizi possano interagire.
Senza un intervento, non è possibile rendere questi cluster
parte dello stesso mesh. Un buon punto di partenza è trasferire la proprietà dei cluster a un team centralizzato della piattaforma per stabilire la fiducia tra i cluster. In alternativa, se i team a e B si fidano l'uno dell'altro, possono coordinarsi per formare questa fiducia.
Il passaggio successivo consiste nel normalizzare l'utilizzo dello spazio dei nomi in modo che frontend e
backend non siano più sovraccarichi nei cluster di questi due team. Al termine, possono creare un unico parco risorse su tutte le risorse e creare il proprio mesh di servizi.
Se non è possibile stabilire questo livello di attendibilità, i team team-a e team-b devono formare due parchi risorse separati che utilizzano due progetti host diversi del parco risorse. Lo svantaggio di questo approccio è che ora devono sfruttare la federazione mesh, che è più difficile da amministrare rispetto a un singolo mesh. Il vantaggio è che nessuno dei due team ha bisogno di normalizzare gli spazi dei nomi e i servizi di cui è stato eseguito il deployment, ed è possibile solo una comunicazione esplicita e specificamente autorizzata.
