Open Application Model su AWS Elastic Kubernetes Services (EKS)

Da tempo sto seguendo la community che si è occupata della definizione dello standard OAM. Per chi non ha mai sentito parlare di questo, OAM si pone come lo standard futuro per la definizione di applicazioni ed il modellamento di architetture.

Il binomio vincente lo si ottiene quando si unisce l’OAM all’orcheatratore di container per eccellenza: Kubernetes è difatti diventato lo standard de facto in container orchestration e la sua adozione ha registrato una crescita notevole su ogni cloud publico o privato che sia. Tuttavia, le risorse core di Kubernetes come Services e Deployment rappresentano solo alcuni pezzi di un intero contesto applicativo e non sono esaustivi a descrivere l’intera applicazione in maniera consistente.

L’obiettivo finale di OAM è quindi quello di semplificare la vita degli sviluppatori poichè, questo standard, aiuta a descrivere una cloud-native application creando un descrittore in YAML che ha come principale focus quello di descrivere l’applicazione e le componenti necessarie al running, creando però una completa astrazione rispetto l’infrastruttura sottostante.

Nello specifico, la definizione dell’applicazione consiste in 4 parti: gli Application Components, gli Application Traits, gli Application Scopes e la configurazione applicativa. Con gli Application Components, gli sviluppatori creano una descrizione dichiarativa per definire il tipo di applicazione che devono deployare e gestire. Con gli Application Traits, l’operation definisce le funzionalità operative dell’istanza di ogni componente: per esempio, esso può definire il security group da associare, la policy di accesso ad esso oppure la politica di scaling. Gli Application Scopes raggruppano i componenti applicativi con caratteristiche simili. Per concludere, la configurazione applicativa viene usata per istanziare l’applicazione, riferendosi agli Application Component ed applicando gli Application Traits ad essa.

1. Open Application Model Overview

Partendo dalla versatilità di Kubernetes ed implementando lo standard OAM, nasce KuveVela. Esso è un sistema di deploy moderno di applicazioni realizzato con uno stack cloud native: basandosi sull’OAM ed utilizzando Kubernetes come control plane, KubeVela risolve il problema di rendere davvero “portable” il deploy di una applicazione.

Di seguito mi concentrerò nel riportare i passi necessari per l’installazione di KubeVela su un cluster EKS e successivamente, attraverso degli esempi concreti, ne illustrerò i punti di forza che rendono KubeVela una tecnologia davvero distruptive.

Installazione EKS

All’interno del repository github associato a questo articolo, ho previsto dei moduli terraform che si occuperanno di creare un piccolo cluster EKS che verrà utilizzato per i nostri scopi. Per evitare di spendere troppo tempo su tematiche non oggetto di questo articolo, ho effettuato un fork del progetto “aws-eks-accellerator-for-terraform” messo a disposizione da AWS su Github. Al progetto ho aggiunto un modulo terraform per l’installazione automatica di Kubevela tramite Helm. Il codice è disponibile sul mio account:

GitHub - emanuelr93/aws-eks-oam-example: The AWS EKS Accelerator for Terraform is a framework…

Dopo aver effettuato il clone del progetto in locale, assicurarsi di configurare il profilo di default sulla macchina con le credenziali AWS che si vogliono utilizzare per il deploy.

Successivamente alla configurazione, è possibile installare il cluster con il seguente comando:

make tf-apply-eks env=dev region=eu-south-1 account=application subenv=dev

In circa 20 minuti, un cluster composto da 2 nodi t3.large verrà deployato e al suo interno sarà installato automaticamente kubevela:

Eseguendo il comando seguente si potra verificare che Kubevela è correttamente in esecuzione:

bash -c “$configure_kubectl” && kubectl get pods -n vela-system

L’output dovrebbe mostrare 3 pod in running:

Finalmente abbiamo un cluster EKS con il controller di Kubevela installato. Possiamo proseguire con un test per verificarne il corretto funzionamento.
Per farlo, consiglio di installare la Vela CLI che tornerà utile per l’interazione con KubeVela lanciando il seguente comando:

curl -fsSl https://kubevela.io/script/install.sh | bash

Tramite la Vela CLI, sarà possibile attivare gli addon disponibili al seguente link: https://kubevela.io/docs/platform-engineers/advanced-install#addons
Per concludere il nostro test, occorrerà abilitare l’addon di FluxCD e Terraform. Eseguendo il seguente comando, dopo qualche secondo saranno abilitati gli addon necessari:

vela addon enable fluxcd && vela addon enable terraform

Poichè al momento non è supportato il binding del ruolo del pod, per permettere il corretto funzionamento del controller terraform, sarà necessaria la creazione di un secret che contiene la AWS_ACCESS_KEY_ID e la AWS_SECRET_ACCESS_KEY che abbiano i permessi per effettuare il deploy delle risorse che serviranno. Esportare le credenziali come variabili d’ambiente ed utilizzare il seguente comando per creare il secret Kubernetes:

echo "awsAccessKeyID: ${AWS_ACCESS_KEY_ID}\nawsSecretAccessKey: ${AWS_SECRET_ACCESS_KEY}\nawsSessionToken: ${AWS_SESSION_TOKEN}" > aws-credentials.conf && kubectl create secret generic aws-account-creds -n vela-system --from-file=credentials=aws-credentials.conf && rm -f aws-credentials.conf

Installare quindi la configurazione del terraform provider tramite il seguente comando:

cat <<EOF | kubectl create -f -
apiVersion: terraform.core.oam.dev/v1beta1
kind: Provider
metadata:
  name: aws
spec:
  provider: aws
  region: eu-south-1
  credentials:
    source: Secret
    secretRef:
      namespace: vela-system
      name: aws-account-creds
      key: credentials
EOF

D’ora in poi sarà possibile effettuare il provisioning di risorse AWS tramite Kubevela. Creaimo un componenete di esempio (nel nostro caso sarà la definizione di un bucket s3). Per farlo eseguire il comando di seguito:

cat <<EOF | kubectl create -f -
apiVersion: core.oam.dev/v1alpha2
kind: ComponentDefinition
metadata:
  name: s3-bucket
  namespace: vela-system
  annotations:
    definition.oam.dev/description: Terraform configuration for S3 Bucket
  labels:
    type: terraform
spec:
  workload:
    definition:
      apiVersion: terraform.core.oam.dev/v1beta1
      kind: Configuration
  schematic:
    terraform:
      configuration: |
        terraform {
          required_providers {
            aws = {
              source = "hashicorp/aws"
              version = "~> 3.0"
            }
          }
        }
        provider "aws" {
          region = var.region
        }
        resource "aws_s3_bucket" "bucket-acl" {
          bucket = var.bucket
          acl    = var.acl
        }
        output "BUCKET_NAME" {
          value = aws_s3_bucket.bucket-acl.bucket_domain_name
        }
        variable "bucket" {
          default = "vela-website"
          type = string
        }
        variable "acl" {
          default = "private"
          type = string
        }
        variable region {
            type        = string
            default     = "eu-south-1"
            description = "Place where to deploy the database"
        }
EOF

Per accertarsi che l’operazione sia andata a buon fine, è possibile usare il comando:

vela show s3-bucket

L’output dovrebbe mostrare la definizione del componente:

L’ultimo passo è quello di provare a creare una applicazione che usa il componente appena definito. E’ possibile usare il seguente comando:

cat <<EOF | kubectl create -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: provision-cloud-aws-sample
spec:
  components:
    - name: sample-s3-bucket
      type: s3-bucket
      properties:
        bucket: test-emanuelr93
        acl: private
        writeConnectionSecretToRef:
          name: s3-conn
EOF

Dopo qualche secondo, dalla console sarà possibile verificare l’avvenuta creazione del bucket:

Ora che il cluster è configurato, siamo pronti per realizzare scenari più complessi. Nel prossimo articolo, mi occuperò di utilizzare kubevela per dimostrare quanto l’OpenApplicationModel potrebbe cambiare le modalità di deploy nel futuro, rendendo la vita di Dev ed Ops più semplice.

Se ti è piaciuto condividi l’articolo! Grazie