GitOps Essential Training

• GitOps is not infrastructure as code.
• GitOps doesn't replace continuous integration (CI).

Use Weave Flux and Helm to implement GitOps methodologies in an AWS-hosted Kubernetes application by using Git as a single source of truth for Kubernetes deployments.

• Logging in to the Amazon Web Services Console
• Connecting to the CloudAcademy Web based Containers IDE Port 8080
• Reviewing a DevOps Pipeline for Kubernetes in AWS
• Deploying a Kubernetes Application with AWS CodePipeline
• Implementing GitOps for Kubernetes in AWS
• Validating GitOps for Kubernetes in AWS

• In advance: Setting up a cluster from scratch is time-consuming, even if you use a managed solution like EKS. Pre-allocating a cluster per person is something you can do in advance.

• Every participant should have credentials to connect to the cluster using kubectl.

• Check running pods.
• Check deployments.

• An empty repository in GitHub/GitLab to use for deploying infrastructure

• Strictly speaking, you don't need to separate the application and infrastructure, but it's easier to understand what goes where this way.
• A sample application that serves a web server with a hello world response as the baseline (NodeJS-based, for instance)

• ArgoCD is tightly integrated with Kubernetes and closely follows the GitOps mindset. Therefore, it's a good tool to showcase GitOps.

• Create namespace.
• Deploy ArgoCD to the cluster.
• Access ArgoCD using the CLI.

• Build sample application as a Docker container (Dockerfile can be provided in advance)
• Push service to a Docker registry (cloud-native, docker.io, or quay.io)

• Create a Kubernetes deployment definition in code for the application (here's a sample).
• Push code to infrastructure repository.
• Create an application in ArgoCD.
• This time, you'll use the ArgoCD CLI so you can see that part. You'll move to use Git from here on, which is more aligned to GitOps.
• Sync the application.
• Again, use the CLI.
• Test: Use kubectl check to ensure that deployment works.

• Pull versus push: How ArgoCD can read from a repository and automatically apply the changes
• Exercise: Activate synchronization so that further changes happen when you push code to the infrastructure repository.

• Create service definition.

• This is an opportunity to introduce the pull request aspect of the flow. You can extend pull requests so that extra checks are performed, using something like GitHub Actions.
• Implementing CI with something like GitHub Actions isn't part of the exercise, although it's something that you can complete as an extra exercise. (See the bonus section at the end of this post.)
• Test: Carry out a kubectl check to prove that service was deployed.

• Create loadbalancer k8s definition for cloud provider.
• Pull request
• Test: Curl to load balancer address to ensure that service is actually online.

• Change something in the application, such as the body of the response of a route in the application.
• Rebuild container with a new tag and push it to Docker registry.
• Update k8s deployment to use new tag.
• Pull request
• Test: New version of the app should be deployed.

• Update k8s deployment to be highly available (more than one replica).
• Pull request
• Test: kubectl shows that there are multiple pods running.

• This is the core of GitOps!
• There are also other, more advanced use cases to cover.

• As with the first cluster, this is something to have prepared in advance.

• Which options are there to represent different stages?
• This is an open discussion, as there's no set recipe to do environment promotion, with different options:
• Use different infrastructure repositories.
• Use different folders in the same infrastructure repository.
• Use branches.

• Set up a second cluster (production) to read from a different folder.
• Copy the infrastructure created for the first folder into this one.
• Pull request
• Test: Second cluster should have the service available as well.

• Enable Argo Rollouts in cluster.
• Test: Observe rolling deployment with kubectl.
• Install argo-rollouts plugin for kubectl.
• Create rollout to apply to existing microservice.

• Theory only (This can be a good lead-in to a discussion of the merits and tradeoffs of different deployment strategies.)

• Introduce an error in the hello world application (this results in a thrown exception instead of starting the webserver).
• Rebuild the container with a new tag and push it to Docker registry.
• Update k8s deployment to use new tag.
• Pull request
• Test: Confirm with kubectl that deployment is failing.
• Revert a failed change through code.

• kubectl shouldn't replace observability, such as logging and monitoring (similar to secure shell—SSH—into a production server)

• No plaintext secrets should ever be stored in Git.

• This is theory only because it's probably too much to do for a practical exercise.

• Depending on time, this can be treated as theory or as an exercise. Furthermore, you can split it in two depending on how much time you have.
• Modify microservice to read the secret and make it available through a request.
• Provision secrets in the infrastructure repository.
• Use secrets from either the cluster or the application.
• Install the sealed secrets controller.
• Inject an encrypted secret in the infrastructure repository.
• Modify Kubernetes deployment to inject a secret into the microservice.

• In advance: Setting up a cluster from scratch is time-consuming, even if you use a managed solution like EKS. Pre-allocating a cluster per person is something you can do in advance.

• Automated promotion (If a deployment to a staging environment succeeds, then trigger a deployment to production.)
• Observability (microservices that export metrics, logging aggregator, and monitoring)

• Check deployments.