- [Instructor] Okay, welcome back. In the previous demo I completed the installation of the Flux operator and configured it to use the CloudAcademy Gitops Demo Github repo. The flux operator, once given the permissions to read from this repo, went ahead and automatically deployed the resources within it for us into the Kubernetes cluster. It's now worth pausing for a moment to review the design or structure of the resources declared within the CloudAcademy Gitops Demo Github repo. 

This will allow us to understand and appreciate what has just been deployed into the cloudacademy namespace within the cluster. Okay, navigating into the GitOps repo, I'll jump into the Flask app directory first. Here we can see it consists of the following two files. Opening up the main Python file, we can see that it implements a simple Python Flask app. The Flask app reads in two environmental variables, app_name and app_version, and then creates a response that concatenates hello world with the respective values assigned to the previous two environment variables, nice and simple. 

Navigating into the Dockerfile, we can see that this provides the build instructions that docker will use to build and package a docker image based off the Python 3 base image. The dockerfile simply copies in the previous displayed main Python file. The Dockerfile sets default values for the app_name and app_version environment variables. Finally, the dockerfile provides a default startup command, to start up the Flask app and bind it to listen for traffic originating from 127.0.0.1 only. 

The reason for using 127.0.0.1 will become clear soon. Okay, jumping back into the Kubernetes directory, we can now see that it has the following two files, a deployment.yaml file and a nginx.config.yaml file. Let's first jump into the nginx.config.yaml file. This file is used to declare a ConfigMap resource named nginx-conf. This config map resource contains a basic Nginx configuration setup. You'll see that it is configured to proxy incoming requests downstream to localhost port 5000. This will be a container running the Flask app that we previously just reviewed. 

Jumping now into the deployment.yaml file, we can see that it is used to create a deployment resource. The deployment is configured to roll out one replica consisting of a single pod containing two containers. The first container is an Nginx web server, which listens on port 80, and mounts the previously shown configmap, meaning that it will be configured to proxy incoming HTTP port 80 traffic to? Yes, you guessed it, the second Flask app-based container, which is configured to listen on port 5000. 

The Flask app-based container also explicitly reconfigures the app_name and app_version environment variables. Now one final but important piece of configuration to draw your attention to, is configured on lines seven, eight, and nine. Here you'll see two flux-based annotations are provided. The annotation on line nine tells flux to automatically edit, commit, and push this file anytime that it detects a newer version of any docker image used elsewhere within this file, and for which has a tag that matches the tag matching scheme declared in the previous annotation. 

Therefore, in this scenario if you look at line 35, you'll see that the Flask app is configured to use a docker image that has a tag that matches the glob pattern declared in the annotation on line eight. This means that if Flux discovers a newer docker image in the docker registry for the tag specified, it will edit, commit, and update the deployment.yaml file, and then resync the cluster to reflect the change. 

Okay, so now that you know what is configured and declared within the repo, let's now move on and perform some quick HTTP curl requests against the deployment.