Distribuisci Oracle Cloud Infrastructure Kubernetes Engine (OKE) utilizzando i moduli Terraform avanzati

Introduzione

Questa è la seconda esercitazione della nostra serie di automazione di Oracle Cloud Infrastructure Kubernetes Engine (OKE), sulla base dei concetti di base del primo, Crea Oracle Cloud Infrastructure Kubernetes Engine Cluster utilizzando Terraform. In questo articolo, portiamo le distribuzioni OKE al livello successivo introducendo l'automazione avanzata e la progettazione modulare per il provisioning di ambienti scalabili, resilienti e altamente personalizzabili su Oracle Cloud Infrastructure (OCI).

Progettata per i tecnici e i clienti Oracle, questa guida ti consente di trasformare una configurazione Terraform di base in un modulo riutilizzabile e strutturato che può essere personalizzato in base a qualsiasi dimensione di distribuzione. Sfruttando i principi dell'infrastruttura come codice (IaC) con Terraform (versione della comunità), in combinazione con Jenkins e Oracle Command Line Interface (CLI), forniamo una soluzione di provisioning single-click per i cluster OKE, le relative configurazioni e i test automatici.

Questo tutorial si concentra su quattro aree chiave:

  1. Design e automazione modulari: crea moduli riutilizzabili per componenti di base come VCN, cluster OKE e host bastion, con controllo delle versioni per la compatibilità al fine di semplificare la gestione e promuovere il riutilizzo del codice.
  2. Configurazione dinamica: consente di gestire le impostazioni specifiche dell'ambiente (dev, test, prod) da un unico codebase per distribuzioni coerenti e ripetibili.
  3. Pool di nodi avanzati: ottimizza l'uso e i costi delle risorse con forme specializzate, immagini OKE compatibili ed etichette per il posizionamento intelligente dei carichi di lavoro.
  4. Integrazione CI/CD trasparente: automatizza il provisioning e gli aggiornamenti OKE utilizzando pipeline che integrano Terraform, Jenkins e OCI CLI per implementazioni one-click efficienti.

L'architettura descritta in questa guida utilizza una topologia di rete a livelli per creare una base sicura e scalabile. Separa il piano di controllo, i nodi di lavoro e il traffico del load balancer, garantendo flessibilità per i carichi di lavoro aziendali di qualsiasi scala. Dimostreremo come automatizzare completamente il provisioning di tale ambiente, tra cui networking, cluster e pool di nodi, fornendo al contempo gli strumenti per personalizzare ed estendere la soluzione alle tue esigenze.

Questa esercitazione presuppone una comprensione dei principi di Kubernetes, networking e IaC, nonché una conoscenza pratica di strumenti come Terraform, OCI CLI e Jenkins. Alla fine, avrai le competenze per distribuire un ambiente OKE resiliente, ad alte prestazioni e scalabile su OCI, con la flessibilità di adattarlo ai tuoi requisiti specifici.

Panoramica di Oracle Cloud Infrastructure Kubernetes Engine (OKE)

Anche se Oracle Cloud Infrastructure Kubernetes Engine (OKE) è un servizio gestito, eseguire con successo carichi di lavoro mission-critical richiede un approccio architettonico deliberato e ben strutturato. Il passaggio da un'impostazione di base a un ambiente scalabile di livello Enterprise richiede un'attenta pianificazione e l'uso di strumenti Infrastructure as Code (IaC) come Terraform.

La modularizzazione e l'automazione sono fondamentali per OKE per garantire scalabilità, sicurezza ed efficienza operativa. Sfruttando moduli strutturati e strumenti di automazione, le aziende possono distribuire e gestire carichi di lavoro mission-critical con coerenza, ridurre gli errori manuali e accelerare il time-to-market.

Il diagramma riportato di seguito illustra l'architettura OKE, evidenziandone la topologia di rete a più livelli, l'endpoint API privato e i controlli dell'accesso sicuro.

Architettura OKE

Per un esempio dettagliato dell'architettura, consultare la documentazione Oracle.

Considerazioni architettoniche
La creazione di un ambiente OKE scalabile implica l'affrontare almeno le seguenti sfide tecniche chiave:

Elementi di progettazione chiave
Questa soluzione modulare si basa su un'architettura di rete su più livelli, che fornisce una base sicura e scalabile per i carichi di lavoro aziendali su OKE:

Creazione di un'automazione Terraform modulare per OKE

Trasformando una configurazione Terraform flat in una configurazione structured, la progettazione modulare è essenziale per creare ambienti ripetibili e scalabili. Questo approccio garantisce una migliore organizzazione, riusabilità del codice e manutenibilità su scala aziendale, con un controllo delle versioni per la compatibilità e la collaborazione tra i team.

Processo di trasformazione: modulo da piano a strutturato

A partire dal modulo flat descritto nella prima esercitazione, il codice viene rifatturato in un design modulare:

  1. Ristrutturazione della directory: creazione di moduli figlio (vcn, oke, bastion) e organizzazione delle risorse nelle rispettive cartelle.
  2. Applicazione dei principi chiave:
    • Struttura e logica: incapsula le risorse in directory autonome (ad esempio modules/vcn, modules/oke, modules/bastion) e suddivide il codice monolitico in main.tf, variables.tf e outputs.tf per la leggibilità e la manutenibilità.
    • Input/Output e controllo delle versioni: consente di definire gli input in variables.tf, esporre gli output in outputs.tf e utilizzare il controllo delle versioni del modulo Terraform (vincolo version in source) per garantire un flusso di dati e una compatibilità ottimali.
    • Orchestrazione: gestisce la logica condizionale, ad esempio count, a livello di modulo radice, mantenendo i moduli figlio concentrati sulle proprie risorse.

Struttura della directory: Flat vs. Modular

Flat Module: una singola directory monolitica con tutte le risorse in pochi file. Semplice per le prove di concetto, ma diventa ingestibile man mano che la complessità cresce.

Struttura del modulo piatto

Modulo strutturato: ogni gruppo di risorse (VCN, OKE, Bastion) si trova nella propria directory del modulo. Il modulo radice orchestra le dipendenze e la configurazione di livello superiore.

Struttura modulo avanzata

Moduli di esempio

Perché i moduli?

Orchestrazione dei moduli - root main.tf

Il file root main.tf orchestra la distribuzione di tre moduli chiave (modules/vcn, modules/oke e modules/bastion) in sequenza. Ogni modulo viene richiamato in modo condizionale in base ai flag di configurazione (is_vcn_created, is_oke_created, is_bastion_created), offrendo flessibilità nella distribuzione. Di seguito è riportata una versione semplificata del flusso di orchestrazione, evidenziando la logica del modulo chiave senza dettagliare l'intero main.tf.

Flusso di orchestrazione:

  1. Modulo VCN (modules/vcn):
    • Esegue il provisioning della rete cloud virtuale (VCN) e delle subnet correlate (ad esempio, subnet private per l'API e i nodi di lavoro Kubernetes, subnet pubbliche per i load balancer e il bastion).
    • Controllato da is_vcn_created. Se abilitata, crea la VCN; in caso contrario, presuppone una VCN esistente (è necessario fornire l'OCID della subnet utilizzata).
    • Esempio di snippet: 
         module "vcn" {
       count = var.is_vcn_created ? 1 : 0  
       source = "./modules/vcn?ref=v1.0.0"  # Specify the module version  
       # Key variables: compartment_id, vcn_cidr_block, subnet configs, ...  
   }
  2. Modulo OKE (modules/oke):
    • Distribuisce il cluster OKE (Kubernetes Engine) OCI, inclusi il piano di controllo e i pool di nodi gestiti facoltativi.
    • Dipende dal modulo VCN per gli ID subnet. Richiamato solo se is_oke_created e is_vcn_created sono true.
    • Esempio di snippet: 
         module "oke" {
       count = var.is_oke_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/oke?ref=v1.0.0"  # Specify the module version   
       # Key variables: vcn_id, subnet IDs, k8 version, node pool config, ...  
   }
  3. Modulo di base (modules/bastion):
    • Crea un host bastion per l'accesso SSH sicuro alle risorse private.
    • Dipende dal modulo VCN per l'ID subnet pubblica. Richiamato solo se is_bastion_created e is_vcn_created sono true.
    • Esempio di snippet: 
         module "bastion" {
       count = var.is_bastion_created && var.is_vcn_created ? 1 : 0  
       source = "./modules/bastion?ref=v1.0.0"  # Specify the module version   
       # Key variables: bastion_subnet_id, SSH keys, parameters...  
   }

      Note chiave:

    • Dipendenze dei moduli: gli output del modulo VCN, ad esempio module.vcn[0].vcn_id, vengono passati come input ai moduli OKE e Bastion, garantendo una chiara catena di dipendenze.
    • Logica di configurazione: le mappe dei parametri semplificate (ad esempio, node_pool_param, bastion_params) semplificano la configurazione e la leggibilità.
    • Controllo delle versioni: l'uso dei vincoli di versione in source garantisce la distribuzione dei moduli con le versioni corrette e testate, garantendo la compatibilità

Dopo aver creato una struttura Terraform modulare per OKE, il passo successivo consiste nell'automatizzare la distribuzione. L'automazione garantisce coerenza, riduce gli errori manuali, accelera il processo di provisioning e migliora direttamente il Time-to-Market (TTM) consentendo la consegna rapida di nuove funzionalità e servizi.

Opzioni di automazione

Diversi strumenti possono automatizzare le distribuzioni OKE, tra cui Terraform CLI, OCI Resource Manager (ORM), OCI CLI, moduli Ansible OCI e Helm. Tuttavia, questa guida si concentra sui due approcci più importanti dell'infrastruttura come codice (IaC) in Oracle Cloud Infrastructure (OCI): Terraform CLI e OCI Resource Manager (ORM).

Entrambi gli strumenti utilizzano lo stesso linguaggio di configurazione dichiarativo HashiCorp (HCL), ma differiscono nei rispettivi modelli operativi:

Esaminiamo ciascuna opzione nel dettaglio.

Opzione 1: Distribuire le risorse OKE con l'interfaccia CLI Terraform

L'interfaccia CLI Terraform è la scelta ideale quando è necessario il controllo completo sull'ambiente locale. È più adatto per singoli sviluppatori o piccoli team che possono gestire il file di stato e collaborare in modo efficace utilizzando un backend condiviso. La sua portabilità ti consente di eseguirlo da qualsiasi computer: runner locali, VM, container, OCI CloudShell o CI/CD come Jenkins. Tuttavia, questa flessibilità include responsabilità, come la gestione dei file di stato e la garanzia di impostazioni locali coerenti tra i membri del team.

Per iniziare, scaricare ed estrarre il pacchetto del codice sorgente dell'interfaccia CLI Terraform nella directory di lavoro Terraform. Questo pacchetto include main.tf, un esempio terraform.tfvars e configurazioni dettagliate dei moduli: scaricare oke_advanced_module.zip.

La distribuzione di OKE con l'interfaccia CLI Terraform prevede sette task chiave, dalla configurazione delle variabili e della rete all'impostazione del cluster OKE, dei pool di nodi e dell'host bastion. Di seguito sono riportati i passi dettagliati per eseguire il provisioning e verificare l'ambiente OKE utilizzando l'interfaccia CLI Terraform.

Task 1.1: Configurare le variabili Terraform

Aggiornare il file terraform.tfvars con dettagli specifici dell'ambiente, ad esempio tenancy_ocid, area, compartment_ocid e network_compartment_ocid. Abilitare i flag riportati di seguito per controllare la creazione delle risorse.

Task 1.2: Configurazione di rete

Definire i blocchi CIDR per la VCN e le relative subnet:

Task 1.3: Configurazione cluster OKE

Task 1.4: Configurazione pool di nodi

Configurazione host bastion task 1.5

Task 1.6: Esegui comandi Terraform

Per distribuire l'infrastruttura, eseguire i comandi seguenti:

	terraform init
	terraform plan
	terraform apply

Al termine di terraform apply, verrà eseguito il provisioning del cluster OKE con:

Task 1.7: Verifica

  1. Andare a OCI Console per verificare la configurazione del cluster.
  2. Eseguire terraform destroy per eseguire il cleanup delle risorse al termine.

Automazione della distribuzione OKE con la pipeline CI/CD Jenkins
Per integrare la distribuzione OKE nelle pipeline DevOps, l'interfaccia CLI Terraform è una scelta eccellente. Il nostro approccio, dettagliato in Crea Oracle Cloud Infrastructure Kubernetes Engine Cluster utilizzando Terraform, utilizza lo script bash per orchestrare il processo. Questo flusso di lavoro può essere consolidato in una pipeline Jenkins per l'esecuzione automatica.

Opzione 2: Automazione di OKE con OCI Resource Manager

OCI Resource Manager (ORM) è la scelta ideale quando hai bisogno di una soluzione gestita e cloud nativa per le distribuzioni dell'infrastruttura. È particolarmente adatto per ambienti collaborativi e aziendali in cui la sicurezza, la gestione centralizzata dello stato e la governance sono fondamentali. Il vantaggio principale di ORM è che gestisce l'intero ciclo di vita della distribuzione all'interno di OCI, memorizzando in modo sicuro il file di stato e prevenendo i conflitti. Ciò elimina la necessità di impostare o gestire un backend condiviso a livello locale. Inoltre, la profonda integrazione di ORM con Oracle Cloud consente di sfruttare le funzioni native di OCI come Identity and Access Management (IAM), migliorando la sicurezza e il controllo.

In questa esercitazione, combiniamo OCI Resource Manager (ORM) con OCI CLI, Bash e li integriamo nelle pipeline CI/CD Jenkins, offrendo un flusso di automazione one-click completo con funzionalità DevOps aggiuntive come il rilevamento delle deviazioni, la gestione sicura dello stato e la collaborazione del team con il controllo delle versioni per la compatibilità.

Flusso di OCI Resource Manager
Il diagramma seguente illustra il flusso di lavoro ORM, composto da sette passi:
Flusso di lavoro ORM

  1. Configurazione di origine: definisce l'origine della configurazione IaC (ad esempio, OCI Object Storage, GitHub, file ZIP).
  2. Modello Terraform: l'infrastruttura viene definita utilizzando Terraform.
  3. OCI Resource Manager: ORM prende il modello Terraform e gestisce il processo di provisioning.
  4. Crea uno stack: ORM utilizza il modello per creare uno stack di risorse OCI.
  5. Piano: genera un piano che descrive le azioni da eseguire.
  6. Applica: esegue il provisioning delle risorse in base al piano.
  7. Elimina: esegue l'annullamento della fornitura delle risorse quando non sono più necessarie.

Per distribuire un cluster OKE utilizzando il nuovo modulo di OCI Resource Manager (ORM), iniziare scaricando il modulo avanzato per ORM: oke_advanced_module_orm.zip. Questa versione è preconfigurata per ORM, con variabili impostate su segnaposto generici come REPLACE_WITH_YOUR_OWN_VARIABLE_VALUE.

Task 2.1: Configurazione origine

Aggiornare variables.tf con i dettagli specifici dell'ambiente, ad esempio l'area, i CIDR di rete e i flag per controllare la creazione delle risorse (VCN, cluster OKE, pool di nodi, host bastion).

Lo script bash riportato di seguito crea il file zip delle origini delle risorse ORM.

Verificare la directory di origine (~/oke_advanced_module_orm) per assicurarsi che un file denominato stackconfig.zip contenga tutte le definizioni delle risorse terraform.

Task 2.2: Crea stack OCI Resource Manager

Utilizzare l'interfaccia CLI OCI per creare uno stack ORM. Lo script seguente semplifica il processo:

Script Bash: create_new_oke_stack.sh.

	#!/bin/bash
	
	# Load environment variables (e.g., COMPARTMENT_ID, STACK_NAME, etc.)
	source "./env-vars"

	# Create the Oracle Resource Manager stack and capture the OCID
	stack_output=$(oci resource-manager stack create \
	--compartment-id "$COMPARTMENT_ID" --display-name "$STACK_NAME" \
	--description "$STACK_DESCRIPTION" --config-source "$CONFIG_SOURCE")

	# Extract the OCID of the newly created stack and display it
	STACK_OCID=$(echo "$stack_output" | jq -r '.data.id')

	echo "Stack OCID: $STACK_OCID"

Task 2.3: Esegui job piano stack

Eseguire il job Plan per verificare le modifiche prima di applicarle. Questo ciclo a secco garantisce trasparenza nelle modifiche dell'infrastruttura.

Script Bash: create_oke_stack_plan_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID)
	source "./env-vars"

	# Create a plan job for the specified stack
	plan_job_output=$(oci resource-manager job create-plan-job \
		--stack-id "$STACK_OCID")

	# Extract the OCID of the plan job and check for errors
	PLAN_JOB_OCID=$(echo "$plan_job_output" | jq -r '.data.id')
	if [[ -z "$PLAN_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve plan job OCID." >&2
		exit 1
	fi

	echo "Plan job OCID: $PLAN_JOB_OCID"

Task 2.4: Crea job di candidatura

Eseguire il provisioning del cluster OKE e delle risorse associate, ad esempio il pool di nodi, utilizzando il job Apply.

Script Bash: create_oke_stack_apply_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an apply job for the specified stack
	apply_job_output=$(oci resource-manager job create-apply-job \
		--stack-id "$STACK_OCID" \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the apply job and check for errors
	APPLY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$APPLY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve apply job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $APPLY_JOB_OCID"

Task 2.5: Esegui job di eliminazione

Eseguire il cleanup delle risorse eseguendo il job Destroy quando l'ambiente non è più necessario.

Script Bash: create_oke_stack_destroy_job.sh

	#!/bin/bash

	# Load environment variables (e.g., STACK_OCID, EXEC_PLAN_STRATEGY)
	source "./env-vars"

	# Create an  jotroy for the specified stack
	apply_job_output=$(oci resource-manager job create-destroy-job \
		--stack-id "$STACK_OCID"  \
		--execution-plan-strategy "$EXEC_PLAN_STRATEGY")

	# Extract the OCID of the destroy job and check for errors
	DESTROY_JOB_OCID=$(echo "$apply_job_output" | jq -r '.data.id')
	if [[ -z "$DESTROY_JOB_OCID" ]]; then
		echo "Error: Failed to retrieve destroy job OCID." >&2
		exit 1
	fi

	echo "Apply job OCID: $DESTROY_JOB_OCID"

Automazione di OKE con Jenkins e OCI Resource Manager

Abbiamo creato una pipeline Jenkins per automatizzare il processo di provisioning end-to-end (procedure 2.1-2.4). La pipeline esegue script bash utilizzando l'interfaccia CLI OCI per interagire con ORM.

L'immagine seguente mostra l'automazione one-click per i primi quattro task; il passo destroy non è incluso per semplicità.

OKEJenkinsPipeline

La pipeline include la configurazione di origine, la creazione dello stack ORM, la generazione del piano, il provisioning delle risorse e l'annullamento del provisioning delle risorse facoltativo.

Passi successivi

L'utilizzo di Terraform per il provisioning OKE garantisce coerenza, automazione e scalabilità. Le progettazioni modulari, combinate con OCI Resource Manager e le pipeline CI/CD, rendono le implementazioni più semplici e facili da gestire. Nella prossima esercitazione verranno illustrate le best practice per il monitoraggio, la sicurezza e la preparazione alla produzione. Basandoci su queste basi, estenderemo i moduli a Oracle AIOps, creeremo un progetto OKE end-to-end per le applicazioni AI e dimostreremo come gli analytics di registrazione con osservabilità basata sull'intelligenza artificiale possono rilevare anomalie e rafforzare la sicurezza della piattaforma di container.

Conferme

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Oracle Learning Explorer.

Per la documentazione del prodotto, visitare Oracle Help Center.