Recently, I had a stimulating conversation with a customer who expressed concerns about their public cloud costs and their interest in repatriating some workloads back to their private cloud, built on VMware Cloud Foundation.
While this engagement is still in its early stages and more details will be gathered in the coming weeks, one statement stood out: "My developers just care about their code."
With the significant advancements in VMware Aria Automation, especially with the Cloud Consumption Interface (CCI), I felt confident in embracing the challenge to create a conceptual flow demonstrating the art of the possible.
Here’s a look at the initial workflow we've conceptualized:
- Code Commit:
- The developer commits new code to the application's repository in GitLab;
- Triggering the Pipeline:
- GitLab triggers a pipeline in VMware Aria Automation.;
- This pipeline consists of two main tasks;
- First Task - Orchestrator Workflow:
- The first task calls a VMware Aria Orchestrator workflow, which performs the following actions:
- Clones the repository containing the new application code;
- Creates a Dockerfile referencing the new code and the base Docker image defined for the application;
- Builds a new Docker image based on this Dockerfile;
- Pushes the new image to the container registry;
- Second Task - New Deployment:
- The pipeline then initiates the second task, which is to create a new deployment;
- This deployment process involves;
- Creating a namespace for the application;
- Setting up a service load balancer to expose the application externally;
- Deploying the application itself using the newly built image from the registry;
All these components were created on top of a Tanzu Kubernetes Cluster, provisioned and made available through the Cloud Consumption Interface.
Interested in seen this worflow in action ?!?
