Identificare l'architettura o la soluzione più adatta

Considerare la serie di fattori di valutazione (o fattori di stress) per identificare l'architettura di riferimento (RA) o la soluzione più adatta alle proprie esigenze. Le sezioni seguenti forniscono informazioni sui fattori da considerare.

Per ogni fattore, ti forniamo un'indicazione se un'architettura o una soluzione supporta o meno il fattore. Se necessario, puoi renderlo più sfumato dando a ogni fattore un punteggio numerico. Utilizzare la matrice di informazioni e decisioni utilizzando questi suggerimenti.

Tenere traccia delle colonne che corrispondono alla risposta preferita.
Confronta l'RA o la soluzione che meglio soddisfa le tue esigenze con ogni fattore di valutazione utilizzando la matrice decisionale.
Aggiungere una ponderazione ai fattori che sono più importanti per voi rispetto ad altri.

Considera i vari fattori di valutazione

Considerare ogni fattore di valutazione e quindi confrontarli con ogni architettura e soluzione per determinare quella più adatta alle proprie esigenze.

Container, Virtual Machine (VM) o Specialista

Puoi ridimensionare le risorse in modo efficiente per processi che richiedono maggiore potenza di computazione distribuendo i processi in container all'interno di un ambiente di orchestrazione container di tipo Kubernetes. Task quali i test di unità e l'analisi del codice statico possono trarre vantaggio da questo tipo di analisi. La maggiore complessità della configurazione end-to-end sta nell'utilizzo dei container. Il tuo team dovrà sapere come utilizzare gli strumenti di orchestrazione dei container come Kubernetes. L'uso dei container garantisce inoltre che, quando i container vengono eliminati, impediscano accidentalmente il recupero delle dipendenze transitorie o dei dati di stato precedenti.

L'uso di una VM è più semplice poiché puoi creare una singola VM per gestire tutti i passi di una pipeline. Un contenitore è di natura monolitica. Un approccio VM allevia anche problemi come consentire l'hosting degli sviluppatori ed evita problemi di utilizzo di Windows rispetto agli host Linux.

Alcuni scenari specialistici supporteranno solo i prodotti PaaS o SaaS in cui il processo di creazione prepara e distribuisce gli artifact per il servizio. È possibile orchestrare questa operazione utilizzando uno strumento generico. In alcuni casi l'uso di uno strumento specifico può essere più vantaggioso. Ad esempio, Oracle Visual Builder Studio è progettato per soluzioni che coinvolgono Visual Builder.

Orchestrazione della pipeline con OCI nativo e prodotti open source/terze parti

L'uso di strumenti specifici del dominio o molto personalizzabili, inclusi strumenti open source come Jenkins, consente una maggiore libertà nel processo di creazione durante l'esecuzione rispetto all'uso di soluzioni native OCI. Sebbene gli strumenti come OCI DevOps rilasciano regolarmente nuove funzioni, Tuttavia, questa flessibilità è necessaria per gestire un maggior numero di fasi dei processi, ad esempio sviluppo, applicazione di patch e monitoraggio, anche quando si eseguono pipeline tipiche.

Repository di distribuzione standardizzati o repository di prodotti speciali

I servizi nativi supporteranno i requisiti quando si gestiscono le configurazioni utilizzando servizi standard del settore come OCI Git, GitLab o GitHub e strumenti simili. I processi CI/CD possono essere vincolati a repository legacy parzialmente integrati. Potrebbe essere necessario apportare modifiche significative alla pipeline per poter utilizzare i processi CI/CD con repository legacy.

Gestione della configurazione standard del settore o strumenti legacy

Quando si utilizzano i servizi forniti nel cloud, è tipico che il servizio supporti solo soluzioni standard del settore mediante sistemi di gestione della configurazione (CM), come Git e SVN. Tali provider di servizi possono anche supportare meccanismi di gestione della configurazione specializzati necessari per i prodotti del fornitore. Se è necessario utilizzare un sistema CM legacy o di nicchia, potrebbe essere necessario prendere in considerazione soluzioni di terze parti supportate dal provider di sistemi CM. Ad esempio, il supporto di CVS come soluzione legacy può richiedere agli utenti di utilizzare strumenti di terze parti per gestire la configurazione.

Distribuzione multicloud o cloud singolo

L'implementazione della stessa soluzione di base in più cloud può aggiungere complessità che dovresti considerare. Ad esempio, se il processo di distribuzione viene incorporato in un servizio Terraform, ogni provider di servizi cloud dovrà disporre di processi di distribuzione che tengono conto delle differenze rispetto a diversi provider Terraform. Considerazioni più sottili, come un chipset di destinazione per le immagini Docker, potrebbero essere necessarie poiché sarà necessario creare immagini diverse.

Per garantire una maggiore sicurezza, è possibile scegliere di non esporre le destinazioni di distribuzione per una soluzione di distribuzione esterna. Ad esempio, se si sta distribuendo su Oracle Container Engine for Kubernetes (OKE) e Azure Kubernetes (AKE), è possibile utilizzare GitHub per contenere il codice comune e GitHub Actions per orchestrare la build del container. È tuttavia possibile scegliere di non esporre AKS e OKE direttamente alle azioni GitHub. Si consideri invece una soluzione multifase con Azure e OCI per fornire l'orchestrazione della distribuzione e utilizzare GitHub per i processi di creazione continua o il codice core.

Si consideri una soluzione multifase quando Infrastructure-as-Code (IaC) fa parte del processo di distribuzione. Ciò consente a ciascun ambiente di disporre di una configurazione IaC diversa per il provisioning dei servizi di computazione, storage e gestiti. L'uso di Kubernetes consente di limitare o rimuovere tali problemi.

Processi di personalizzazione processo o Bespoke

Se sono necessari processi speciali o di nicchia, gli strumenti per supportare la pipeline di build devono consentire estensioni per la configurazione personalizzata. La creazione di processi personalizzati richiede maggiore impegno. È necessario prendere in considerazione e valutare il rischio di come modifiche future potrebbero impedire il funzionamento della personalizzazione.

Potenziale scala

I carichi di lavoro di sviluppo possono variare a causa di fattori come le tendenze comuni durante un giorno lavorativo. Ad esempio, gli impegni per riepilogare le attività di fine giornata che attivano i processi CI/CD determinano un aumento del carico di lavoro alla fine della giornata lavorativa. Con il progredire dei progetti durante tutto il loro ciclo di vita di creazione, rilascio e distribuzione, l'infrastruttura di creazione registra un aumento della domanda. Esiste un modello di aumento delle richieste di piccole modifiche, in quanto i problemi minori vengono affrontati alla fine dei cicli di rilascio/sprint.

Rivedere la matrice delle decisioni

Le architetture e le soluzioni sono raggruppate sotto un numero comune, ad esempio 1a, 1b e 1c, in base a variazioni sottili. Ad esempio, un singolo nodo per la soluzione CI/CD o la stessa soluzione con una diversa configurazione degli strumenti indica che la soluzione può funzionare su larga scala. Ogni raggruppamento è un'intestazione di colonna nella matrice decisionale e ogni fattore è un'intestazione di riga. I callout all'interno della tabella, ad esempio ¹, forniscono informazioni aggiuntive.

Architettura e raggruppamenti di soluzioni

Orchestrazione Jenkins (con due varianti)
1. Imposta una pipeline CI/CD per le distribuzioni cloud con Jenkins: approccio di distribuzione minimo senza ridimensionamento o resilienza
2. Distribuisci Jenkins in modalità master/agente: distribuzione scalabile e resiliente
3. Crea una pipeline continua di integrazione e distribuzione utilizzando il servizio Oracle DevOps
GitLab
1. Distribuire GitLab per abilitare le pipeline CI/CD in OCI
2. Distribuisci GitLab Runner su Oracle Container Engine for Kubernetes con ridimensionamento automatico del cluster
OCI DevOps: varianti per serverless e container
1. Creare una pipeline CICD utilizzando il servizio Oracle Cloud Infrastructure DevOps e le funzioni OCI
2. Crea una pipeline continua di integrazione e distribuzione utilizzando il servizio Oracle DevOps
GitHub Azioni: Crea una pipeline CI/CD per le distribuzioni cloud utilizzando le azioni GitHub e il servizio Oracle Cloud Infrastructure DevOps
Strategia applicativa moderna: Pianifica strategie di distribuzione di app moderne con Oracle Cloud Infrastructure Devops
Hub mobile: creare una pipeline CI/CD per le applicazioni mobile
Bot: Creazione di una pipeline CI/CD per i componenti personalizzati dei bot

La seguente matrice decisionale rappresenta le variazioni tra architetture e soluzioni per consentire di identificare quella appropriata alle esigenze aziendali.

Fattore	1. Orchestrazione Jenkins	2. GitLab	3. OCI DevOps	4. GitHub Azioni	5. Strategia per le applicazioni moderne	6. Hub mobile	7. Bot
Container, virtual machine (VM) o specialista	VM e contenitore (anche se le VM delle destinazioni soluzione fornite)	VM o contenitore	VM e contenitore	VM e contenitore	VM e contenitore	Specialista	Specialista
Orchestrazione della pipeline con prodotti OCI nativi o non gestiti con prodotti open source/di terze parti	Sì	Sì	No	Sì	No	No (Oracle Dev Cloud)	No
Repository di distribuzione standardizzati	Sì^1,3	Sì¹	No	No (nell'implementazione RA - ma possibile)	Sì¹	No	No
Repository di gestione della configurazione supportati	GIT, SVN e altri	GIT (DISAMBIGUA)	GIT (DISAMBIGUA)	GIT (DISAMBIGUA)	GIT (DISAMBIGUA)	GIT (DISAMBIGUA)	GIT (DISAMBIGUA)
Distribuzione multicloud o cloud singolo	Singolo^2,3	Singolo o multi-cloud	Singolo²	Singolo o multi-cloud	Singolo²	Singola	No
Personalizzazione dei processi o processi su misura	Sì	Sì	Sì	Sì	Sì	No	Limitata
Potenziale di scala	1a - No 1b - Sì	Sì	Sì	Sì	Sì	No	No

Note a piè di pagina tabella

Nota:

¹ OCIR è conforme agli standard.
² Utilizza OCI per guidare i processi in altri ambienti. Ma solleva anche la sfida di un'esposizione indesiderabile ai servizi in altri ambienti.
³ Utilizza OCI DevOps nella fase di distribuzione per l'opzione 1a, pertanto limita tale fase a un singolo cloud.