Conferences and conventions are hotspots for making connections. Professionals in attendance often share the same interests and can make valuable business and personal connections with one another. At the same time, these events draw a large crowd and it's often hard to make these connections in the midst of all of these events' excitement and energy. To help attendees make connections, we are building the infrastructure for a service that can inform attendees if they have attended the same booths and presentations at an event.
You work for a company that is building a app that uses location data from mobile devices. Your company has built a POC application to ingest location data named UdaTracker. This POC was built with the core functionality of ingesting location and identifying individuals who have shared a close geographic proximity.
Management loved the POC so now that there is buy-in, we want to enhance this application. You have been tasked to enhance the POC application into a MVP to handle the large volume of location data that will be ingested.
To do so, you will refactor this application into a microservice architecture using message passing techniques that you have learned in this course. It’s easy to get lost in the countless optimizations and changes that can be made: your priority should be to approach the task as an architect and refactor the application into microservices. File organization, code linting -- these are important but don’t affect the core functionality and can possibly be tagged as TODO’s for now!
- Flask - API webserver
- SQLAlchemy - Database ORM
- PostgreSQL - Relational database
- PostGIS - Spatial plug-in for PostgreSQL enabling geographic queries]
- Vagrant - Tool for managing virtual deployed environments
- VirtualBox - Hypervisor allowing you to run multiple operating systems
- K3s - Lightweight distribution of K8s to easily develop against a local cluster
The project has been set up such that you should be able to have the project up and running with Kubernetes.
We will be installing the tools that we'll need to use for getting our environment set up properly.
- Install Docker
- Set up a DockerHub account
- Set up
kubectl
- Install VirtualBox with at least version 6.0
- Install Vagrant with at least version 2.0
To run the application, you will need a K8s cluster running locally and to interface with it via kubectl
. We will be using Vagrant with VirtualBox to run K3s.
In this project's root, run vagrant up
.
$ vagrant up
The command will take a while and will leverage VirtualBox to load an openSUSE OS and automatically install K3s. When we are taking a break from development, we can run vagrant suspend
to conserve some ouf our system's resources and vagrant resume
when we want to bring our resources back up. Some useful vagrant commands can be found in this cheatsheet.
After vagrant up
is done, you will SSH into the Vagrant environment and retrieve the Kubernetes config file used by kubectl
. We want to copy the contents of this file into our local environment so that kubectl
knows how to communicate with the K3s cluster.
$ vagrant ssh
You will now be connected inside of the virtual OS. Run sudo cat /etc/rancher/k3s/k3s.yaml
to print out the contents of the file. You should see output similar to the one that I've shown below. Note that the output below is just for your reference: every configuration is unique and you should NOT copy the output I have below.
Copy the contents from the output issued from your own command into your clipboard -- we will be pasting it somewhere soon!
$ sudo cat /etc/rancher/k3s/k3s.yaml
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJWekNCL3FBREFnRUNBZ0VBTUFvR0NDcUdTTTQ5QkFNQ01DTXhJVEFmQmdOVkJBTU1HR3N6Y3kxelpYSjIKWlhJdFkyRkFNVFU1T1RrNE9EYzFNekFlRncweU1EQTVNVE13T1RFNU1UTmFGdzB6TURBNU1URXdPVEU1TVROYQpNQ014SVRBZkJnTlZCQU1NR0dzemN5MXpaWEoyWlhJdFkyRkFNVFU1T1RrNE9EYzFNekJaTUJNR0J5cUdTTTQ5CkFnRUdDQ3FHU000OUF3RUhBMElBQk9rc2IvV1FEVVVXczJacUlJWlF4alN2MHFseE9rZXdvRWdBMGtSN2gzZHEKUzFhRjN3L3pnZ0FNNEZNOU1jbFBSMW1sNXZINUVsZUFOV0VTQWRZUnhJeWpJekFoTUE0R0ExVWREd0VCL3dRRQpBd0lDcERBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSVFERjczbWZ4YXBwCmZNS2RnMTF1dCswd3BXcWQvMk5pWE9HL0RvZUo0SnpOYlFJZ1JPcnlvRXMrMnFKUkZ5WC8xQmIydnoyZXpwOHkKZ1dKMkxNYUxrMGJzNXcwPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://127.0.0.1:6443
name: default
contexts:
- context:
cluster: default
user: default
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: default
user:
password: 485084ed2cc05d84494d5893160836c9
username: admin
Type exit
to exit the virtual OS and you will find yourself back in your computer's session. Create the file (or replace if it already exists) ~/.kube/config
and paste the contents of the k3s.yaml
output here.
Afterwards, you can test that kubectl
works by running a command like kubectl describe services
. It should not return any errors.
kubectl apply -f deployment/db-configmap.yaml
- Set up database environment variables for the podskubectl apply -f deployment/kafka-configmap.yaml
- Set up queue environment variables for the podskubectl apply -f deployment/db-secret.yaml
- Set up secrets for the podskubectl apply -f deployment/postgres.yaml
- Set up a Postgres database running PostGISkubectl apply -f deployment/udaconnect-api.yaml
- Set up the service and deployment for the legacy APIkubectl apply -f deployment/udaconnect-persons-api.yaml
- Set up the service and deployment for the Persons APIkubectl apply -f deployment/udaconnect-connections-api.yaml
- Set up the service and deployment for the Connections APIkubectl apply -f deployment/udaconnect-app.yaml
- Set up the service and deployment for the web appsh scripts/run_db_command.sh <POD_NAME>
- Seed your database against thepostgres
pod. (kubectl get pods
will give you thePOD_NAME
)- Setup the messaging queue as follows
helm repo add kafka-repo https://sir5kong.github.io/kafka-docker
helm upgrade --install udaconnect-kafka \
--create-namespace \
--set broker.persistence.size="20Gi" \
kafka-repo/kafka
-
kubectl apply -f deployment/udaconnect-location-service.yaml
- Set up the location service -
kubectl apply -f deployment/udaconnect-location-ingester.yaml
- Set up the location ingester service -
Confirm that all the pods and services are in the running state before proceeding with your test
kubectl get pods kubectl get svc
-
Insert sample locations via gRPC using the sample gRPC client
export LOCATION_INGESTER_POD=$(kubectl get pods --namespace default -l "app=udaconnect-location-ingester" -o jsonpath="{.items[0].metadata.name}") kubectl exec -it $LOCATION_INGESTER_POD sh
Once you are inside the shell, execute the grpc client with the command below (you can run this several times, as it randomly generates location data for various users):
python grpc_client.py
N.B: You can observe the progress of location ingestion by observing the logs of the
location-service
andlocation-ingester
microservice using the commands belo:kubectl logs -f <location-service-pod-name> kubectl logs -f <location-ingester-pod-name>
Manually applying each of the individual yaml
files is cumbersome but going through each step provides some context on the content of the starter project. In practice, we would have reduced the number of steps by running the command against a directory to apply of the contents: kubectl apply -f deployment/
.
Note: The first time you run this project, you will need to seed the database with dummy data. Use the command sh scripts/run_db_command.sh <POD_NAME>
against the postgres
pod. (kubectl get pods
will give you the POD_NAME
). Subsequent runs of kubectl apply
for making changes to deployments or services shouldn't require you to seed the database again!
Once the project is up and running, you should be able to see 9 deployments and 9+ services in Kubernetes:
-
kubectl get pods
should return a list similar to the image below: -
kubectl get services
should return a list similar to the image below:
These pages should also load on your web browser:
http://localhost:30000/
- Frontend ReactJS Applicationhttp://localhost:30001/
- OpenAPI Documentation for legacy APIhttp://localhost:30001/api/
- Base path for legacy APIhttp://localhost:30002/
- OpenAPI Documentation for Persons APIhttp://localhost:30002/api/
- Base path for Persons APIhttp://localhost:30003/
- OpenAPI Documentation for Connections APIhttp://localhost:30003/api/
- Base path for Connections API
You may notice the odd port numbers being served to localhost
. By default, Kubernetes services are only exposed to one another in an internal network. This means that udaconnect-app
and udaconnect-api
can talk to one another. For us to connect to the cluster as an "outsider", we need to a way to expose these services to localhost
.
Connections to the Kubernetes services have been set up through a NodePort. (While we would use a technology like an Ingress Controller to expose our Kubernetes services in deployment, a NodePort will suffice for development.)
New services can be created inside of the modules/
subfolder. You can choose to write something new with Flask, copy and rework the modules/api
service into something new, or just create a very simple Python application.
As a reminder, each module should have:
Dockerfile
- Its own corresponding DockerHub repository
requirements.txt
forpip
packages__init__.py
udaconnect-app
and udaconnect-api
use docker images from udacity/nd064-udaconnect-app
and udacity/nd064-udaconnect-api
. To make changes to the application, build your own Docker image and push it to your own DockerHub repository. Replace the existing container registry path with your own.
In deployment/db-secret.yaml
, the secret variable is d293aW1zb3NlY3VyZQ==
. The value is simply encoded and not encrypted -- this is not secure! Anyone can decode it to see what it is.
# Decodes the value into plaintext
echo "d293aW1zb3NlY3VyZQ==" | base64 -d
# Encodes the value to base64 encoding. K8s expects your secrets passed in with base64
echo "hotdogsfordinner" | base64
This is okay for development against an exclusively local environment and we want to keep the setup simple so that you can focus on the project tasks. However, in practice we should not commit our code with secret values into our repository. A CI/CD pipeline can help prevent that.
The database uses a plug-in named PostGIS that supports geographic queries. It introduces GEOMETRY
types and functions that we leverage to calculate distance between ST_POINT
's which represent latitude and longitude.
You may find it helpful to be able to connect to the database. In general, most of the database complexity is abstracted from you. The Docker container in the starter should be configured with PostGIS. Seed scripts are provided to set up the database table and some rows.
While the Kubernetes service for postgres
is running (you can use kubectl get services
to check), you can expose the service to connect locally:
kubectl port-forward svc/postgres 5432:5432
This will enable you to connect to the database at localhost
. You should then be able to connect to postgresql://localhost:5432/geoconnections
. This is assuming you use the built-in values in the deployment config map.
To manually connect to the database, you will need software compatible with PostgreSQL.
- CLI users will find psql to be the industry standard.
- GUI users will find pgAdmin to be a popular open-source solution.
- We can access a running Docker container using
kubectl exec -it <pod_id> sh
. From there, we cancurl
an endpoint to debug network issues.