wiki/structured/challenges.suse-cloud-native-fundamentals-scholarship-program.org

Solutions to SUSE Cloud native fundamentals scholarship exercises

• Note on my personal setup
• Trade-offs for monoliths and microservices
  • Solution
• Endpoints for an application status
  • Solution
  • Findings after solution
• Application logging
  • Solution
• Docker for application packaging
  • First working solution
  • Findings after solution
• Deploy your first Kubernetes cluster
  • Solution
  • Findings after solution
• Kubernetes resources
  • Solution
• Declarative Kubernetes manifests
  • Solution
  • Findings after solution

I'll attempt to archive my answers to exercise here in one Org mode document. Let's see the reproducibility capability of this thing.

For future references, the lessons have their repo.

• Lesson 1 exercises

Note on my personal setup

For this program, I'm using Podman instead of Docker. There are subtle differences when using with Podman — the biggest difference being it is not attached to the Docker registry by default.

Docker	Podman
docker pull alpine	podman pull docker.io/alpine
docker search alpine	podman search docker.io/alpine

Since Podman is not attached to the Docker registry by default, you also have to specify this in Dockerfiles.

FROM docker.io/alpine

You can make Podman search through DockerHub by setting it as one of the fallback registries. Just set unqualified-search-registries from your container configuration (see containers-registries.conf.5 manual page for more details).

unqualified-search-registries = ['docker.io']

Don't forget to login to DockerHub (e.g., podman login docker.io).

Trade-offs for monoliths and microservices

From the early stages of application development, it is fundamental to understand the requirements and available resources. Overall, these will contour the architecture decisions.

Imagine this scenario: you are part of the team that needs to outline the structure of a centralized system to book flight tickets for different airlines. At this stage, the clients require the front-end(UI), payment, and customer functionalities to be designed. Also, these are the individual requirements of each airline:

• Airline A - payments should be allowed only through PayPal
• Airline B - payments should be disabled (bookings will be exclusively in person or via telephone)
• Airline C - payments should be allowed to use PayPal and debit cards

Using the above requirements, outline the application architecture. Also, elaborate your reasoning on choosing a microservice or monolith based approach.

Solution

Considering that the airlines has an overlap of use cases particularly with Airline A and C both allowing Paypal, we're leaning into considering a microservice architecture. Each component in the service can then be configured individually by the development team of each airline. We could also take in the factor if one of the airline changes its requirements, we would only have to inspect one component. Having an monolith would be nice that all of the requirements of the airlines is wrapped in one package but if one team would have to maintain it, it would require them to go through the entire stack of each airline. In this case, they would have to do it three times.

In my opinion, microservices would be a better choice.

Here's the summarized outline of the application design we're going to develop.

• Each component of the application would have to be stored with their own repository.
• The front-end can be developed in parallel as we prioritize the payment system. We can then improve it as we develop the other and ideally make it easy for the clients to modify it for their own needs.
• The payment system can then be configured to integrate with different services or be disabled entirely.
• Set up individual pipelines for each component as we can test them individually at different pace.

Endpoints for an application status

This exercise can be located in the Lesson 1 exercise repo at exercises/python-helloworld.

Extend the Python Flask application with /status and /metrics endpoints, considering the following requirements:

• Both endpoints should return an HTTP 200 status code
• Both endpoints should return a JSON response e.g. {"user": "admin"}. (Note: the JSON response can be hardcoded at this stage)
• The /status endpoint should return a response similar to this example: result: OK - healthy
• The /metrics endpoint should return a response similar to this example: data: {UserCount: 140, UserCountActive: 23}

Solution

For the prerequisites, you can just install Flask and you're mostly done. For future references, here are the version of the tools I've used at the time.

nix-shell -p 'python3Packages.flask' entr --run 'flask --version'

Python 3.8.9
Flask 1.1.2
Werkzeug 1.0.1

As for the solution:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

@app.route("/status")
def health_check():
    return { "result": "OK - healthy" }

@app.route("/metrics")
def metrics():
    return { "data": { "UserCount": 140, "UserCountActive": 23} }

if __name__ == "__main__":
    app.run(host='0.0.0.0')

Findings after solution

Comparing my solution from the solution shown in the video, I found out that Flask converts Python dictionaries into JSON. We're still good on that note.

Application logging

Logging is a core factor in increasing the visibility and transparency of an application. When in troubleshooting or debugging scenarios, it is paramount to pin-point the functionality that impacted the service. This exercise will focus on bringing the logging capabilities to an application.

At this stage, you have extended the Hello World application to handle different endpoints. Once an endpoint is reached, a log line should be recorded showcasing this operation. In this exercise, you need to further develop the Hello World application collect logs, with the following requirements:

• A log line should be recorded the timestamp and the requested endpoint e.g. "{{TIMESTAMP}}, {{ ENDPOINT_NAME}} endpoint was reached".
• The logs should be stored in a file with the name app.log. Refer to the logging Python module for more details.
• Enable the collection of Python logs at the DEBUG level. Refer to the logging Python module for more details.

Solution

Continuing from /foodogsquared/wiki/src/commit/e05076a0c9cbdcbaa9679cee7e6fa8f74764b453/structured/Endpoints%20for%20an%20application%20status, here is the resulting Python code.

import logging
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    logging.info("/ endpoint was reached")
    return "Hello World!"

@app.route("/status")
def health_check():
    logging.info("/status endpoint was reached")
    return { "result": "OK - healthy" }

@app.route("/metrics")
def metrics():
    logging.info("/metrics endpoint was reached")
    return { "data": { "UserCount": 140, "UserCountActive": 23} }

if __name__ == "__main__":
    logging.basicConfig(format="%(asctime)s, %(message)s", level=logging.DEBUG, filename="app.log")
    app.run(host='0.0.0.0')

Docker for application packaging

Create the Docker image for the Go web application and push it to DockerHub, considering the following requirements:

Dockerfile:

• use the golang:alpine base image
• set the working directory to /go/src/app
• make sure to copy all the files from the current directory to the container working directory (e.g. /go/src/app)
• to build the application, use go build -o helloworld command, where -o helloworld will create the binary of the application with the name helloworld
• the application should be accessible on port 6111
• and lastly, the command to start the container is to invoke the binary created earlier, which is ./helloworld

Docker image:

• should have the name go-helloworld
• should have a valid tag, and a version with a major, minor, and patch included
• should be available in DockerHub, under your username e.g. pixelpotato/go-helloworld

Docker container:

• should be running on your local machine, by referencing the image from the DockerHub with a valid tag e.g. pixelpotato/go-helloworld:v5.12.3

First working solution

This should be simple enough as we can see from the file structure.

go-helloworld
├── main.go
└── README.md

As for the Dockerfile, I've made the following:

FROM docker.io/golang:alpine

COPY . /go/src/app
WORKDIR /go/src/app
RUN go build -o helloworld main.go
CMD ["./helloworld"]

As for the requirements of the images and running the containerized app, we'll summarize it with the following Bash script.

OWNER="foodogsquared"
IMG="go-helloworld"
VERSION="1.0.0"
REMOTE_IMG="${OWNER}/${IMG}:v${VERSION}"

# Build the image with the tag already in place.
podman build --tag "$IMG" .

# Run the packaged app.
podman run -d -p 6111:6111 "$IMG"

# Verify it's running.
podman ps

# Create another image to push it into the Docker registry with the proper naming.
podman tag "$IMG" "$REMOTE_IMG"

# Push the image to the Docker registry.
podman push "$REMOTE_IMG"

Findings after solution

I guess my solution is close enough, I didn't realize the application should be configured its port to be exposed already in the Dockerfile and not when running the containerized app. Whoops!

Apparently, there is the EXPOSE instruction, just requiring a port number. I also tested the Dockerfile from the solution and it still gave me an error from build time.

I also didn't realize the solution is pretty much how the instructions laid it out. At the end, it should look like the following code.

FROM docker.io/golang:alpine

WORKDIR /go/src/app
ADD . .

RUN go build -o helloworld main.go
EXPOSE 6111
CMD ["./helloworld"]

Deploy your first Kubernetes cluster

Now you should have a Kubernetes cluster up and running. Examine the cluster and identity of the following details.

From the kubeconfig, identify:

• the IP and port of the API server
• authentication mechanism

From the cluster using kubectl commands to identify:

• endpoints of the control plane and add-ons
• amount of nodes
• node internal IP
• the pod CIDR allocate to the node

Solution

From my setup with the given Vagrantfile from the lesson repo — i.e., after installing k3s in the virtual machine — you can inspect the kubeconfig located at /etc/rancher/k3s/k3s.yaml.

The IP and the port of the API server is visible from there. In my case, it is 127.0.0.1 at port 6443.

As for the authentication mechanism, I'm not sure. Both the cluster and the user have an attached certificate data. It seems to be using matching certificate data from the user and the cluster.

As for getting cluster-related information.

• Getting the endpoints of the control plane and the add-ons through kubectl cluster-info.
• One way of getting the amount of nodes is through kubectl get nodes where it will print the nodes and their information one line at a time.
• For the node's internal IP and the pod CIDR, both of them can be extracted with kubectl describe node ${NODE_NAME}.

Findings after solution

I mostly got it right. It turns out there are different methods for authentication. While the solution gave it as user and passwords, the kubeconfig I have seem to be using keys and certificates. ¹

Also, you can get the configuration of the cluster with kubectl config view. Pretty handy.

Kubernetes resources

Now you have learned many Kubernetes recourses, in this exercise, you will deploy the following resources using the kubectl command.

• a namespace

  • name: demo
  • label: tier: test

• a deployment:

  • image: nginx:alpine
  • name: nginx-apline
  • namespace: demo
  • replicas: 3
  • labels: app: nginx, tag: alpine

• a service:

  • expose the above deployment on port 8111
  • namespace: demo

• a configmap:

  • name: nginx-version
  • containing key-value pair: version=alpine
  • namespace: demo

Solution

This is practical test but it can summarized with a shell script.

# Create the namespace with the specified label.
kubectl create namespaces demo
kubectl label namespaces demo tier=test

# Create the specified deployment.
kubectl create deployment nginx-alpine --image=nginx:alpine --replicas=3 --namespace=demo
kubectl label deployment nginx-alpine app=nginx tag=alpine --namespace=demo

# Expose the deployment as a service.
kubectl expose deployment nginx-alpine --namespace=demo --port=8111

# Create the config map.
kubectl create configmaps nginx-version --namespace=demo --from-literal=version=alpine

Declarative Kubernetes manifests

Kubernetes is widely known for its imperative and declarative management techniques. In the previous exercise, you have deployed the following resources using the imperative approach. Now deploy them using the declarative approach.

• a namespace

  • name: demo
  • label: tier: test

• a deployment:

  • image: nginx:alpine
  • name:nginx-apline
  • namespace: demo
  • replicas: 3
  • labels: app: nginx, tag: alpine

• a service:

  • expose the above deployment on port 8111
  • namespace: demo

• a configmap:

  • name: nginx-version
  • containing key-value pair: version=alpine
  • namespace: demo

Solution

Since they ask for 4 resources, we need 4 manifests. We'll create four YAML manifests for this exercise.

The following manifests are created with the option to print the resources in YAML format with some modifications.

Here's one for the namespace. The command used to make the template is kubectl create namespace demo --dry-run=client --output=yaml.

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: demo
  labels:
    tier: test
spec: {}
status: {}

The manifest for the deployment. The command used to create the starting template is kubectl create deployment nginx-alpine --namespace=demo --replicas=3 --image=nginx:alpine --dry-run=client --output=yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
    tag: alpine
  name: nginx-alpine
  namespace: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-alpine
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-alpine
    spec:
      containers:
      - image: nginx:alpine
        name: nginx
        resources: {}
status: {}

The service manifest should be created after the deployment manifest is applied (i.e., kubectl apply -f deployment.yaml). It is created with kubectl expose deploy nginx-alpine --port=8111 --dry-run=client --output=yaml --namespace=demo.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: nginx
    tag: alpine
  name: nginx-alpine
  namespace: demo
spec:
  ports:
  - port: 8111
    protocol: TCP
    targetPort: 8111
  selector:
    app: nginx-alpine
status:
  loadBalancer: {}

The resulting YAML output is from running the command (i.e., kubectl create configmap nginx-version --from-literal=version=alpine --dry-run=client --output=yaml --namespace=demo). No cleaning up is required.

apiVersion: v1
data:
  version: alpine
kind: ConfigMap
metadata:
  creationTimestamp: null
  name: nginx-version
  namespace: demo

Findings after solution

Aside from the mostly correct answers, I also found out kubectl get all -n demo to get all of the resources in the specified namespace. Pretty handy for inspecting application-specific resources.

---

¹

I'm using the default installation from k3s for future references.