GitOps w/ FluxCD: GitOps w/ FluxCD: Organize Sequence for Deployments using DependsOn.

In a real-world use case for any data-driven application, the data storage component can, practically, be considered critical. The vote app, as far as the first two articles were concerned, did not have a storage mechanism. This article will introduce the next part of our learning puzzle and the redis cache app.

A Quick Reminder: Instavote's Application Architecture

A voter will vote between options, and their selected option will be saved to a Redis cache and is eventually picked up and shown via a NodeJS front end.

Strictly speaking, the vote app depends upon redis for in-memory caching of votes cast.

We will now introduce the redis app into our stack and extend our application code base.

Demo: Making Vote UI Depend on Redis

The first thing to do is create a Kustomization and Source object for redis.

The Source Object

Since the vote UI and redis apps are part of the same repo (instavote), the already created Source object for the vote UI can be used here.

The Kustomization Object

We will, however, need a Kustomization object for redis (since its the Kustomizations that end up deploying code changes) and currently there is no Kustomization for redis. However, we still make it a dependency for vote UI; the vote UI will keep waiting on redis to work (which will not happen).

Create the Kustomization for redis

The YAML manifest below is for creating a Kustomization for the redis app.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: redis-dev
  namespace: flux-system
spec:
  healthChecks:
  - kind: Deployment
    name: redis
    namespace: instavote
  interval: 1m0s
  path: ./deploy/redis
  prune: true
  sourceRef:
    kind: GitRepository
    name: instavote
  targetNamespace: instavote
  timeout: 2m0s

Save the code with the name redis-dev-kustomization.yaml in /flux-infra/cluster/dev

For now, check redis-dev-kustomization.yaml to flux-infra repo and after a minute, run the commands to show the list of Kustomizations currently ready and available.

As is noticeable in the image above, the redis-dev Kustomization has been created and is now ready for updating the redis app whenever a change has to be made in its deployment.

Where is the dependency? I don't see any.

And you are right. If we place the manifests for vote-dev and redis-dev side by side, we see no attribute anywhere in either of them that imposes a dependency check.

Let's edit the vote-dev Kustomization and make it depend upon the redis-dev Kustomization.

Modify the YAML manifest for vote-dev (code below).

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: vote-dev
  namespace: flux-system
spec:
  # Added the dependsOn attribute.
  dependsOn:
  - name: redis-dev
  healthChecks:
  - kind: Deployment
    name: vote
    namespace: instavote
  interval: 1m0s
  path: ./deploy/vote
  prune: true
  sourceRef:
    kind: GitRepository
    name: instavote
  targetNamespace: instavote

For testing, let's introduce an error in our redis-dev.

We can mistype the name of the image being used by our redis deployment and check the changed file into github.

After a few minutes, list the Kustomizations (flux get kustomizations) and notice the record for vote-dev Kustomization.

As soon as the edited (with error, of course) Kustomization manifest was checked in, FluxCD energized its reconciliation process which found the deliberate error introduced in the redis Deployment manifest. The health probe in the redis-dev Kustomization will stop the reconciliation because of the incorrect image name for redis Deployment.

And how do I fix this error?

The same way you introduced it. Edit the redis Deployment manifest, correct the image name and check-in the edited Deployment manifest back into source control.

Run flux get kustomizations after a minute, and the error message witnessed earlier will no longer be shown.

Architecturally Speaking

Summary: What and Why?

Instavote Application Components Deployed So Far

GitHub Folder Structure

I write to remember, and if, in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.