Helm Deployment via VMware Aria Automation Code Stream + Kubernetes

-

 

Overview

This deployment model integrates VMware Aria Automation Code Stream with Kubernetes to securely and automatically execute Helm chart deployments.

The approach leverages a short-lived Kubernetes Job that handles:

  • Git repository checkout

  • Helm chart installation/upgrade

  • Automatic cleanup post-execution

This ensures secure, ephemeral, and repeatable deployments with minimal cluster footprint.


Design Components

🔹 Code Stream Pipeline

  • Type: Kubernetes Task

  • Trigger: Manual or scheduled

  • Inputs: Git credentials (e.g., gitusername1, gitpassword2)

  • Purpose: Submits Kubernetes Job manifest to the target cluster


🔹 Kubernetes Job

  • API Version: batch/v1

  • Namespace: <Name Space>

  • Service Account: crypto (preconfigured RBAC permissions)

  • Image: Custom Alpine with Helm + Git CLI (k8s:1.33.3)

  • Execution Steps:

    1. Clone Helm chart from internal GitLab

    2. Run helm upgrade --install with values file

    3. Deploy resources into target namespace


🔹 Security Controls

  • ServiceAccount RBAC: Least-privilege access (create/update/patch on deployments, secrets, configmaps)

  • ImagePullSecrets: (creds) for private registry authentication

  • Git Access: HTTPS with token-based authentication

🔹 Lifecycle Management

  • Restart Policy: Never

  • Retries: backoffLimit: 0 (fail fast)

  • Cleanup: ttlSecondsAfterFinished: 60 for automatic pod/job deletion


Deployment Flow

  1. Pipeline Trigger → User initiates Code Stream pipeline with GitLab inputs

  2. Job Submission → Code Stream submits manifest to Kubernetes API

  3. Git & Helm Execution → Job container clones repo and runs helm upgrade --install

  4. Helm Deployment → Resources applied into namespace (--create-namespace if needed)

  5. Cleanup → Job & pod auto-delete after 60s/120s

  6. Validation → Operator checks with helm status & Kubernetes resources


Process Flow Diagram



Key Highlights

  1. Ephemeral Execution → No long-running CI/CD pods; jobs auto-cleanup

  2. Isolation → Each deployment runs independently, avoiding conflicts

  3. Rollback Ready → helm rollback services <REVISION> --namespace <NS> supported via pipeline

  4. Secure by Design → ServiceAccount with least privilege, private registry auth

  5. Namespace Agnostic → Can target any namespace via manifest update

  6. Minimal Footprint → TTL ensures no resource leftovers

  7. Scalable → Parallel deployments for multiple teams without interference


Implementation & Output

  • Code Stream pipeline screenshot




  • vRO task execution (optional)

  • Kubernetes Job logs

         kubectl get jobs -n <name space>

  • Helm release status (helm status <release> -n <namespace>)

        helm history application-name -n <name space>

  • Namespace pods/services after deployment


Further Automation

If you need enhancements or additional automation features, feel free to reach out. HashtagForge


Comments

Post a Comment

Popular posts from this blog

CSP-102547 Patch Upgrade Experience VMware Identity Manager 3.3.7 & Aria Suite Lifecycle 8.18.0 (Patch 5 → 7)

-
Image
In this blog, I would like to share my real-time experience and troubleshooting steps while applying the CSP-102547 patch for: VMware Identity Manager (vIDM): 3.3.7 VMware Aria Suite Lifecycle (vRLCM): 8.18.0 (Patch 5 to Patch 7) This includes the issues encountered during PostgreSQL cluster patching and how they were resolved.   Pre-Upgrade Validation Before starting the upgrade, I performed the necessary pre-check validations : Verified vIDM cluster node health Checked vRLCM status and services Confirmed connectivity and credentials We followed the official Broadcom KB article:    https://knowledge.broadcom.com/external/article/426230   Patch Upgrade Status VMware Identity Manager CSP-102547 patch was applied successfully All vIDM cluster nodes were upgraded without issues Aria Suite Lifecycle Upgrade from Patch 5 to Patch 7 completed successfully   Issue During Postgr...
Read more

Bulk Import DFW Rules to NSX-T using Aria Automation

-
Image
 Managing a large number of Distributed Firewall (DFW) rules manually in NSX-T can be time-consuming and error-prone. In enterprise environments, firewall rules are often provided in bulk through spreadsheets and need to be applied consistently across policies. In this blog, we’ll explore how to automate bulk creation and update of NSX-T DFW rules using VMware Aria Automation (vRA) and vRealize Orchestrator (vRO) , driven by a CSV input file . Use Case Overview The goal of this automation is to: Import firewall rules in bulk using a CSV file Automatically create or update DFW rules in NSX-T Enforce platform limits and validations Support large-scale rule deployments in a controlled manner This solution is ideal for: Firewall rule migrations Compliance-driven rule deployment Large-scale application onboarding Input CSV Format The automation accepts a CSV file with the following fields: Policy Name ,  Source ,  Destination,  Protocol ,...
Read more

VCF 9 Automation vs Aria Automation 8.x (Part 1)

-
  Key Differences That Matter for Modern Cloud Automation With the release of VMware Cloud Foundation (VCF) 9 , automation has evolved beyond what Aria Automation 8.x originally delivered. While Aria Automation 8.x was a powerful standalone automation platform, VCF 9 Automation is designed as a deeply integrated, platform-native automation layer . This blog explains the real-world differences , especially from an architect, automation engineer, and platform operations perspective. 1. Platform Philosophy Shift Aria Automation 8.x Designed as a standalone automation product Focused on self-service provisioning Required manual integration with vSphere, NSX, vROps, and Code Stream Automation was often project-based , not platform-driven VCF 9 Automation Built as a core capability of VMware Cloud Foundation Automation is platform-native , not an add-on Tight lifecycle alignment with VCF components Automation is infrastructure-aware by default 2. Installa...
Read more