Workloads Quickstart Guide

A Workload is a high-level abstraction describing application(s) and/or service(s) that provide business value. A Workload is self-contained.

Workloads are configured under the CG DevX installation GitOps repository and then managed by the team owning the Workload.

CG DevX's goal is to provide isolation at the Workload level through all the core services provided by the CG DevX platform.

A Workload is divided into the following logical blocks:

  • Source code: Code of the service(s) the workload consists of
  • K8s manifests: All the manifests required to run a workload on K8s
  • IaC: Additional out-of-cluster resources required by the Workload. When using Crossplane, CRDs should be merged with K8s manifests.

These blocks can all be part of one repository or belong to different repositories, depending on user requirements.

To provide better isolation of concerns, two repositories are provided by default; one contains the source code for the Workload, and the other contains manifests and IaC. When a user wants to use a different schema, workloads should be created manually, or the repository structure should be adjusted after the workload bootstrap. Bootstrap templates are designed to enable users to blend them or split the GitOps repository into two.

Prerequisites

  • An up and running CG DevX cluster. Workloads are defined in the CG DevX platform GitOps repository. All operations with workloads should be done from the same machine used for CG DevX cluster provisioning, as there is a hard dependency on the output of the CG DevX setup flow.
  • There should be no other ongoing changes (active PRs) in the CG DevX platform GitOps repository. This is required to avoid inconsistency in the infrastructure state.

Workloads Management

Create

Workload configuration is generated by the workload create command. This command creates a new feature branch in the CG DevX platform GitOps repository, pushes all the required configurations, and opens a pull request (PR).

As a user, you should review the PR and apply the changes via the PR automation solution (Atlantis). You can get more details on Atlantis commands here.

This creates new repositories for your Workload under your Git organizations. By default, CG DevX will create two repositories, one for Workload application(s)/service(s) source code, and another for manifests, environment definitions, and Infrastructure as Code (IaC). This is done to provide better isolation and access control, and can be changed by updating the Workload configuration for the VCS module. For example, you may want to use one repository per application/service instead of using a monorepo, which is CG DevX's default behavior.

You can delete a Workload by running the workload delete command. This will reverse the changes done by the workload create command and open a PR to apply them.

Note: You must create and delete workloads one by one to avoid conflicts.

Bootstrap

When a PR opened by the workload create command is merged and closed, you can bootstrap Workload repositories with the workload bootstrap command. This command provides the following features based on templates created by the CG DevX team:

  • A pre-defined folder structure
  • Environment definitions (dev, sta, prod environments)
  • IaC templates
  • CI/CD process for Workload application(s)/service(s)
  • IaC PR automation configuration

Note: Reference implementations of delivery pipelines, repository structure, manifest, and environment definitions are given as examples of platform capabilities. They should be adjusted for your specific use case before production use.

The following templates are used by default:

After uploading parameterized repo templates, the workload bootstrap process will create a PR under your Workload GitOps repository to initialize secrets and create the IAM role for the Workload service.

Your new workload will have a pre-built CI process triggered by a tag applied to the workload source code repository. Semantic versioning is used. CI builds an image (or images when you have more than one service in your monorepo) and uploads them to the CG DevX image registry (Harbor). After that, it updates the image version of the Workload service in K8s deployment definitions in the Workload GitOps repository to trigger the CD process. At this point, you can promote changes from the dev environment to other environments by running the promotion action under the Workload GitOps repository.

Manually Customizing and Managing Workloads

On a platform level, workloads are defined as a set of Workload objects that are passed to IaC modules via the terraform.tfvars.json file (more here).

To create additional workloads or workload repositories, or to manage repository settings, you need to update terraform.tfvars.json.

The workloads variable schema consists of:

variable "workloads" {
  description = "workloads configuration"
  type = map(object({
    description = optional(string, "")
    repos = map(object({
      description = optional(string, "")
      visibility = optional(string, "private")
      auto_init = optional(bool, false)
      archive_on_destroy = optional(bool, false)
      has_issues = optional(bool, false)
      default_branch_name = optional(string, "main")
      delete_branch_on_merge = optional(bool, true)
      branch_protection = optional(bool, true)
      atlantis_enabled = optional(bool, false)
    }))
  }))
  default = {}
}

Workloads are managed and discovered by ArgoCD automatically. For more details please see under the hood section