Reusable Patterns :: GitLab for EKS

Ultimate GitOps: Deploy Secure Microservices to AWS EKS with the GitLab Agent > 1. Prereqs, Prep & Support > Reusable Patterns

Reusable Patterns For Production and Training

Reusable Patterns for Production

The following patterns are reusable in production environments.

For CD Push and GitOps: Group Level Integration With Automatic Per-Project Abstractions

For both major scenarios covered by the Kubernetes Agent, this workshop models doing the integrations at a group level and then ensuring that Kubernetes namespace uniqueness is handled for environments - including Auto DevOps environments. This is similar to how both Auto DevOps and Kubernetes Certificate Connections have traditionally operated, but it requires that specific patterns are followed to achieve it.

CD Push Scenarios: Auto DevOps, Dynamic Review Environments and Security Scanning

Demonstrates preservation of GitLab Auto DevOps, Auto Dynamic Review Environments and Security Scanning while using GitLab Agent connection method. Does so for an entire group heirarchy similar to the former Certificate Connection Method. Done through strategic group placement of Auto DevOps CI/CD Variables and GitLab Agent registration shown here:

gl-k8s-agent-least-config-least-privilege

GitOps: Auto DevOps, Dynamic Review Environments and Security Scanning

GitLab GitOps pattern retains usage of Auto DevOps, Dynamic Review Environments and Security Scanning to qualify new application versions for GitOps scenarios. This is done through Auto DevOps enablement in the Application Building Project.

GitOps: Loose Project Coupling

Loose coupling between the Application Building Project and the Environment Deployment Project accomodates many production oriented GitOps deployment scenarios.

GitOps: Promote Image to Latest Only If Testing Passes

An Application Build Project image is only tagged as “latest” if the pipeline passes. If staging is enabled, it is also a manual step.

GitOps: Least Configuration

Least Configuration - template repositories for exercises are designed to be self-abstracting so that there is as little manual code updates to the scaffolding as possible before it is ready to run. For instance, the Application Build Project is simply copied to a new sub-group or new name and it is ready to build. The Environment Deployment project requires a manual update to map it to the correct Application Project and it is ready to run. This capability is a result of the above models of Group Level Integration combined with leveraging existing artifact metadata to detect the latest version of an image for incrementing in the Application Build Project and for version update detection in the Environment Deploment Project as depicted here:

gl-k8s-agent-least-config-least-privilege

GitOps: Least Privilege

Least Privilege - the two GitOps projects define the least possible shared privileges at the lowest possible group level. For instance the Application Build Project only defines a read registry permissions for a deployment token and only stores it high enough in the group heirarchy that any consuming Environment Deployment Projects can utilize it. The Environment Deployment Projects define a git read and write token back to themselves and only publish it at their own project level where it is used.

Reusable Patterns for Training

These exercises configure the Gitlab Agent for Kubernetes to function similarly to the depreciated certificate connection method in that configuring at a group level enabled the entire subgroup heirarchy of that group to be able to access the cluster and not have name uniqueness conflicts. This is highly desirable in a classroom context and may be desirable for production if the previous group level GitLab certificate cluster connections were leveraged by your organization.

To accomplish this:

A single Kubernetes Cluster is deployed and…
Integrated using a single Gitlab Agent for Kubernetes…
That has a management scope of a top level group and all its subgroups and…
That services both CI/CD Push AND GitOps scenarios…
Which have working Review Environments for participants to observe results of changes…
The small amount of code editing is specified as being done in the Web IDE - avoiding all challenges with getting repository cloning working to each participant workstation (but you can still have them do workstation cloning if desired)

This keeps classroom logistics simple.

It is also what leads to the limitation of having all projects be public - if a Kubernetes agent registration is done in the same project as the manifest files, then the project does not have to be public.

Warning

In a real world scenario there can be many GitLab Agents in many GitLab groups and projects integrating to the same Kubernetes cluster and/or agents integrating to many independent clusters. The agents can be registered at any group level and could be dedicated to just CI/CD Push or just GitOps.

Simple & Inexpensive EKS Pattern Reusable for Training