Difficulty: Beginner
Estimated Time: 10 minutes

Test Playground

In this scenario, you will take the role of Basia, a developer who recently joined the team. Basia has the responsibility of deploying a change to the companies' shop, Sock Shop. As this is her first deployment, Basia needs to understand how the application is deployed, use the existing continuous integration and deployment pipeline to make a change and before verifying everything is working by viewing the application metrics.

Weave Cloud has been suggested as a solution to enable Basia to get up to speed and complete the requirements quickly. Weave Cloud provides a container platform agnostic solution allowing you to deploy, secure and visualise your Microservice deployments.

Weave Scope allows developers to visualise application deployments and the dependencies.

Weave Flux manages the automation of deployments, automatically rolling out new versions if the Docker Image changes.

Prometheus and Weave Cortex automatically aggregate to push application metrics.

Weave Net enables secure cross-cloud communication between containers.

Step 1 - Running Kubernetes

The Sock Shop application that Basia needs to change is running on a Kubernetes cluster.

Kubernetes is a container orchestration platform that can manage 1000s of containers across multiple hosts. With the command line tool kubectl, it is possible to manage the entire cluster and deployed applications.

To view the current cluster, use the command kubectl get nodes

In this case, it shows that there are two nodes. One is the master, the other is a node running the application. The cluster was initially configured and deployed using kubeadm.

Step 2 - Visualize with Weave Scope

To make changes, Basia first needs to understand how the application is structured and deployed. Basia has been told the URL for the running application is available at https://[[HOST3_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com

To help understand how the application is deployed, Basia uses Weave Scope on the Kubernetes cluster.

kubectl apply -f 'https://cloud.weave.works/launch/k8s/weavescope.yaml?service-token=aqdpi5zm4rnf5mwkxdub9o9pmgjpsch9'

Once deployed, Scope can be accessed via https://cloud.weave.works/

Weave Scope highlights which components are deployed, their dependencies and insights such as CPU usage, Memory Usage and deployed versions. From here, Basia could monitor and debug if the containers are working as expected.

Step 3 - Management deployment using Weave Flux

By using Weave Scope, Basia understands that the change needs to happen to the frontend service. Before completing the change, Basia wants to verify which version of the frontend has been deployed.

Part of Weave Cloud includes Weave Flux. Weave Flux connects a Continuous Integration and Deployment pipeline to a Kubernetes cluster.

To find out the version, use the fluxctl to list the images for a particular version.

POD=$(docker ps | grep fluxd| tr -s ' ' | cut -d ' ' -f 1)
docker exec -it $POD bash -c 'echo "172.17.0.44 registry.test.training.katacoda.com" >> /etc/hosts'
docker exec -it $POD cat /etc/hosts
export FLUX_URL=http://localhost:8080/api/v1/proxy/namespaces/default/services/flux
fluxctl list-images --service=sock-shop/front-end

To ensure that new changes can be released, Basia is going to make a simple change and test how to redeploy. The change edits XYZ and pushes the commit to the Gitlab repository. Gitlab is a Git repository, with an integrated CI pipeline and Docker Registry.

Execute the command below to manage the change and push to the repository to trigger the build:

cd ~/weave-front-end/ && \ sed -i 's/WeaveSocks/Sock Shop/' public/index.html && \ git add . && \ git commit -m "Change title" && \ git push

Gitlab's dashboard can be viewed at https://[[HOST2_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com. The build status is on https://[[HOST2_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/root/front-end/pipelines

Once the image has been built, it can be deployed using fluxctl release --service=sock-shop/front-end --update-all-images

Step 4 - Automating deployment using Weave Flux

By using Weave Flux, Basia is confident of that it is suitable for future deployments. Basia has been told that it is possible to automate the release process, meaning as soon as an image is changed, it is automatically redeployed.

Automated deployments are enabled via fluxctl automate --service=sock-shop/front-end

Automating the release produce instantly come in handy for Basia. As it happens, a new urgent requirement to change all the button colours from Blue to Red. Upper management is confident this will lead to a 4000% increase in sock purchase so needs to happen without delay.

With Gitlab and Weave Flux, Basia is confident about how the application is deployed and knows new changes will be automatically deployed.

Execute the command below to complete the task.

cd ~/weave-front-end/ && \ sed -i 's/4993e4/e44949/g' public/css/style.blue.css && \ git add . && \ git commit -m "Change button colour" && \ git push

Step 5 - Collect metrics with Prometheus and Weave Cortex

kubectl apply -f 'http://frontend.dev.weave.works/k8s/cortex.json?t=aqdpi5zm4rnf5mwkxdub9o9pmgjpsch9'

With the deployments happening, Basia is concerned about how the application is performing and wants to make sure she has not introduced any problems. As part of the deployment, Basia knows that Prometheus is automatically pushing metrics to Weave Cloud via their service Cortex.

View the application metrics at https://cloud.weave.works/prom

rate(microservices_demo_user_request_latency_microseconds_count[1m])

Step 6 - Secure using Weave Net

Before breaking for lunch, Basia identified a security issue when looking at the Weave Scope visualisation. Basia noticed that certain Microservices are capable of accessing others directly. If one of the services was exploited, it could lead to hackers accessing sensitive parts of the system.

During her investigations, she noticed that kubeadm automatically configured the container networking using Weave Net, part of Weave Cloud. Basia noticed that Weave Net could define network policies that define firewalls between services. An example of this is...TODO

To ensure only allowed services can communicate, Weave Net can block all traffic.

kubectl apply -f ~/micro/deploy/kubernetes/manifests/netpol-default-deny.yaml

With an understanding of the structure, thanks to Weave Scope, Basia opens the required dependencies and communication paths leaving the others blocked. This ensures that the network is secure and systems cannot accidentally communicate and share data.

kubectl apply -f ~/micro/deploy/kubernetes/netpol-complete-demo.yaml

Running the previous security example now fails...TODO

Basia can now head to lunch knowing how the application is deployed thanks to Weave Scope, new features automatically being pushed out using Weave Flux and the network running securely via Weave Net while being monitored with Weave Cortex. A good start to her first morning, I wonder what the afternoon will bring...