Crea una pipeline CI/CD per le distribuzioni cloud utilizzando le azioni Github e il servizio Oracle Cloud Infrastructure DevOps

La distribuzione rapida di software è essenziale per garantire l'esecuzione efficiente delle tue applicazioni nel cloud. Il servizio Oracle DevOps offre un'esperienza di distribuzione continua end-to-end agli sviluppatori.
Quando fornisci soluzioni in una soluzione multi-cloud o ibrida, potresti voler separare le diverse fasi di un processo di miglioramento continuo/distribuzione continua (CI/CD) per diversi motivi:
  • Per evitare l'esposizione di tutte le destinazioni di distribuzione a un servizio che si trova all'esterno di alcuni livelli di sicurezza.
  • Parti di un processo di distribuzione possono differire a seconda di quando Infrastructure as Code (IaC) potrebbe far parte del processo di distribuzione.
  • Riduci al minimo l'impatto potenziale della latenza nei processi di distribuzione. L'esecuzione del passo finale viene pertanto controllata in locale solo con le connessioni e le dipendenze locali coinvolte.
  • Possibilità di gestire e rilasciare gli asset di controllo che si estendono su più ambienti in un'unica posizione. Invece di avere fonti distribuite.

Questa architettura di riferimento risponde a queste considerazioni, utilizzando parti del relativo servizio esterne a Oracle Cloud (ad esempio, GitHub e altre parti all'interno di OCI, come DevOps). Questa architettura di riferimento analizza il processo di distribuzione (CD) alle piattaforme Oracle Cloud Infrastructure (OCI): Oracle Container Engine for Kubernetes (OKE), Funzioni e istanze di computazione. L'immagine contenitore comune viene creata utilizzando un servizio separato (in modo che l'elemento sia universale) e quindi distribuita da DevOps in modo che non comunichi direttamente OKE.

L'automazione delle release del software con la distribuzione della pipeline aumenta la produttività degli sviluppatori e consente di rilasciare le funzioni con maggiore frequenza e meno errori. Evita i tempi di inattività durante le distribuzioni e automatizza la complessità dell'aggiornamento delle applicazioni. Oracle DevOps può essere utilizzato da entrambi i clienti che eseguono la migrazione dei carichi di lavoro da cloud on premise o altri a OCI e dai clienti che sviluppano nuove applicazioni nell'infrastruttura OCI.

Architettura

In questa architettura di riferimento, un'applicazione di esempio viene distribuita da GitHub utilizzando le azioni GitHub e il servizio DevOps OCI. L'applicazione viene distribuita nel cluster OKE.

Il diagramma riportato di seguito illustra questa architettura di riferimento.

Segue la descrizione di devops-arch.png
Descrizione dell'illustrazione devops-arch.png

devops-arch-oracle.zip

Questa architettura dispone dei componenti riportati di seguito.
  • Area

    Un'area OCI è un'area geografica localizzata contenente uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e le grandi distanze possono separarle (tra paesi o addirittura continenti).

    L'architettura utilizza un'unica area.

  • Sistema CI esterno

    Questa architettura utilizza le azioni GitHub come sistema di integrazione continua esterna. GitHub Le azioni automatizzano, personalizzano ed eseguono i flussi di lavoro di sviluppo del software dal repository GitHub. In questo caso, le azioni GitHub vengono utilizzate per creare il codice e poi recuperarlo mediante Docker. Quando l'immagine in container è pronta, GitHub Azioni esegue il push dell'immagine in un repository di artifact OCI (in alternativa, l'artifact viene posizionato in una posizione centrale in cui è possibile configurare le azioni GitHub per nudge DevOps per recuperare l'artifact. Ciò significa che il contenuto viene estratto, non sottoposto a push. Dopo aver completato il trasferimento al repository artifact, viene avviata la pipeline di distribuzione DevOps OCI. È inoltre possibile utilizzare altri sistemi di integrazione continua come Jenkins o Gitlab in base a tali requisiti.

    Se si utilizzano le tecniche IaC, prima della distribuzione la pipeline potrebbe utilizzare servizi quali Resource Manager per creare un'istanza di un ambiente e, una volta completata, ridurre tali risorse utilizzando Resource Manager per .

    La pipeline di distribuzione Devops può anche memorizzare l'output risultante in un posto sicuro per la reportistica.

  • DevOps progetto

    Un progetto DevOps è un raggruppamento logico di risorse necessarie per implementare il carico di lavoro di integrazione e distribuzione continue (CI/CD). Le risorse DevOps possono essere artifact, pipeline di distribuzione e ambienti. I progetti DevOps semplificano l'abilitazione di log, monitoraggio e notifiche per tutte le risorse DevOps.

  • Pipeline di distribuzione

    Una pipeline di distribuzione contiene i requisiti che devono essere soddisfatti per distribuire un set di artifact a un ambiente. Le pipeline contengono fasi, ovvero i componenti di base di una pipeline. Una pipeline può avere fasi che vengono eseguite in modo seriale o parallelo, in modo da poter controllare il flusso e la logica della release del software.

  • Fasi di distribuzione
    Le fasi sono singole azioni eseguite durante un'esecuzione di una pipeline. La pipeline di distribuzione DevOps include i seguenti tipi di fasi predefiniti da utilizzare nel processo di release:
    • Distribuzione in sequenza: release incrementale a OKE, funzioni o gruppi di istanze.
    • Attesa: attendere N secondi.
    • Approvazione manuale: procedere se viene fornita un'approvazione; interrompere se viene rifiutata un'approvazione.
    • Richiama funzione: esegue task personalizzati e l'integrazione richiamando una funzione e passa un artifact di parametri di richiesta.
  • Artifact DevOps

    Un artifact DevOps è un riferimento o un puntatore a qualsiasi file, file binario, pacchetto, file manifesto o immagine che costituisce l'applicazione. Quando si crea un artifact, è necessario informare Oracle DevOps della posizione di origine dell'artifact effettivo. DevOps supporta il registro dell'immagine contenitore OCI e i repository del registro degli artifact OCI.

  • Repository di artifact

    Il repository di artifact viene utilizzato per creare repository per raggruppare artifact simili. Una volta creato il repository, è possibile caricare gli artifact. Questi artifact sono una raccolta di file di testo, file binari e file manifesto di distribuzione che verranno consegnati all'ambiente di distribuzione di destinazione. Ogni artifact ha un nome, che viene fatto del relativo percorso: versione. Il percorso è una stringa che consente di organizzare gli artifact.

  • Servizi di registrazione e notifiche OCI

    Il servizio di log OCI memorizza i log correlati alla distribuzione. L'output del runtime di distribuzione e i risultati finali della distribuzione vengono visualizzati come voci di log. Il servizio di notifiche OCI fornisce visibilità sullo stato più recente del progetto di distribuzione e sulle relative risorse ed esegue le azioni necessarie. Ad esempio, si riceve una notifica quando un evento importante, ad esempio una fase di una pipeline di distribuzione in attesa di approvazione. Quando si riceve il messaggio di notifica, è possibile passare a DevOps pipeline di distribuzione e approvare la fase.

  • Ambienti di distribuzione
    Un ambiente è una raccolta di risorse informatiche di un cliente in cui vengono distribuiti gli artifact. Gli ambienti possono essere una funzione, un'istanza della virtual machine (VM) di computazione o Bare Metal o un cluster OKE.
    • Cluster Oracle Kubernetes (OKE): Oracle Container Engine for Kubernetes è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni in container nel cloud.
    • Istanze di computazione: il servizio di computazione OCI consente di eseguire il provisioning e gestire gli host di computazione nel cloud. Puoi avviare le istanze di computazione con forme che soddisfano i requisiti delle tue risorse in termini di CPU, memoria, larghezza di banda della rete e storage.
    • Functions: Oracle Functions è una piattaforma completamente gestita, multi-tenant, altamente scalabile, su richiesta, Functions-as-a-Service. Si basa su OCI di livello enterprise e si basa sul motore open source Fn Project.
    In questa architettura viene utilizzato un cluster OKE come ambiente. Gli ambienti possono trovarsi in aree OCI diverse dall'area della pipeline di distribuzione. Ciò consente agli sviluppatori di eseguire la distribuzione in più aree OCI utilizzando la stessa pipeline di distribuzione.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza. I requisiti potrebbero differire da
  • VCN

    Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ogni blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Utilizzare i blocchi CIDR che si trovano all'interno dello spazio di indirizzi IP privati standard.

    Dopo aver creato una VCN, è possibile modificare, aggiungere e rimuovere i relativi blocchi CIDR.

    Questa architettura utilizza una rete VCN pubblica per ospitare il cluster OKE. Puoi anche usare una VCN privata. In tal caso, utilizzare un gateway NAT per concedere l'accesso al cluster tramite la rete Internet pubblica.

  • Forme di computazione

    Questa architettura utilizza un'immagine del sistema operativo Oracle Linux con la forma flessibile E3 o E4 che dispone di risorse minime per ospitare gli host di calcolo nei nodi del cluster OKE. Se l'applicazione richiede più memoria o core, è possibile scegliere una forma diversa.

  • OKE

    Questa architettura viene distribuita al cluster OKE come endpoint di destinazione. I nodi di lavoro vengono distribuiti su un sistema operativo Oracle Linux E3 o E4. Questa architettura utilizza tre nodi di lavoro nel cluster, ma è possibile creare fino a 1.000 nodi in ogni cluster.

  • Registro immagini contenitore

    Questa architettura distribuisce il registro come registro Docker privato per uso interno. Le immagini Docker vengono trasferite e trasferite dal registro. Inoltre, puoi utilizzare il registro come registro Docker pubblico, consentendo a qualsiasi utente con accesso a Internet e conoscenza dell'URL appropriato di estrarre le immagini dai repository pubblici in Oracle Cloud.

  • Registro artifact

    Questa architettura crea un artifact per il software e la configurazione utilizzati da un cluster OKE. L'architettura crea un repository di registro artifact per uso interno. I file binari, il testo e le configurazioni di distribuzione del software vengono caricati e scaricati dal repository del registro di artifact.

Considerazioni

Quando si distribuisce questa architettura di riferimento, tenere presenti i punti riportati di seguito.

  • DevOps-distribuzioni supportate

    DevOps supporta le distribuzioni in OKE, negli host di computazione e nelle funzioni. Questa architettura viene distribuita in un cluster OKE. Considerare la possibilità di eseguire la distribuzione in altri endpoint in base ai requisiti.

  • Supporto di Linux

    Solo gli host Linux sono supportati per le distribuzioni dei gruppi di istanze nelle istanze di computazione.

  • Artifact distribuiti

    Gli artifact da distribuire con DevOps devono trovarsi in un registro artifact o in un repository di registro immagini container OCI.

  • Raggruppamento di applicazioni

    Come best practice, raggruppa ogni applicazione e tutti i suoi microservizi in un unico progetto. Accertarsi che la proposta di valore di suddivisione del processo sia compresa e che le divisioni siano mantenute.

Distribuzione

Per distribuire questa architettura, seguire le istruzioni per la distribuzione delle applicazioni Java in questo Live Lab:

Log modifiche

Questo log elenca le modifiche significative: