Product-Manager/z2/Readme.md

# Overview of the APP

This is a product management application for admin. Here you can upload, edit, delete products. Probably a front-end
will show these products to the user if future.

_Edit functionality is not implemented at this moment_

![homepage](images/product-manager-homepage.png?raw=true 'System Architecture')

# Requirements

The basic system requirements are as follows

- Any OS, preferably Linux
- Docker
- Kubernetes

# Architecture

![System design diagram](images/product-manager.jpg?raw=true 'System Architecture')

### Technology used

- Django (Backend Rest API)
- React (Frontend)
- Postgres - as persistent database
- kubernetes
- Docker

# Kubernetes environment

For shipping and deploying the application kubernetes is used. All the configurations are in the k8s folder.

Key points of the the kubernetes objects is given below.

### Namespace

- **Namespace**: We used namespace to group our project resources together and isolate theme.

### Deployment

Deployment is used for managing the application pods.

- **production-manager-backend:** runs the Django web API.
- **production-manager-frontend** run front-end application

### Services

The kubernetes services are used to expose our application as a network service.

- **backend-service:** service used to communicate with the backend APO.
- **mysql-service** runs the mysql database service required for the backend API
- **front-service** this is the entrypoint for the front-end application

### Statefulset:

PostgreSQL database is deployed as a statefulset kuebernetes object. StatefulSet is used to manage stateful applications with persistent storage. Storage stays associated with replacement pods. Volumes persist when pods are deleted.. You can find more information about statefulset [here](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)

### ConfigMap:

A ConfigMap is used to store nginx configuration file. The front pod will consume the ConfigMaps as the default configuration files for nginx web server. This ConfigMap contains the rules for mapping the `/api` request to the backend service.

### PersistentVolumeClaim:

PVC is binding between a Pod and PV. Pod request the Volume through the PVC.PVC is the request to provision persistent storage with a specific type and configuration.PVCs describe the storage capacity and characteristics a pod requires, and the cluster attempts to match the request and provision the desired persistent volume.

### PersistentVolume:

We used a persitent volume in order to save the database data in a persistent volume which is independent of the lifecycle of the Pods. It means that data represented by a PV continue to exist as the cluster changes and as Pods are deleted and recreated.

## Virtual networks

We used the internal kubernets network , and we used services to expose the backend, frontend and postgreSQL databases as a network services.

## Volumes

For persisting the data of the db container, we used a persistent volume using the kubernetes host localfile as we do not have any NFS for this purpose. This persistent volume is mapped to the local `/mnt/pg` folder.

## A description of the container configuration performed.

Two configuration was made to adapt the application to new architecture.

- Connection between database and the backend :
  The credentials for PostgreSQL in the statefulset.yml file are also passed as environement variables in the deployment.yml file for the products manager backend deployment.

- Connection between the frontend and the backend: Nginx based image is used to serve the frontend files. A ConfigMap is used to store nginx configuration file to forward all the `/api` request to the products manager backend service.

### Prepare the app

As We used minikube the local docker registry is not reachable for it, we should proxy the docker daemon to the minikube registry before building our application images, for this we have to run the following command.

```
eval $(minikube docker-env)
```

Now I can build the images and they will be accessible for minikube. To prepare the application you have to run the command :

```
sh prepare-app.sh
```

The script will build the frontend and the backend images.

### Run the app

To run the app you have to run:

```
sh start-app.sh
```

the script which will create a namespace and all the required kubernetes object of the application.

### To stop the app

The `stop-app.sh` script will remove the namespace and its resources also it will remove the persistent volume we created in the run script.

# Viewing the app

After deploying the app. We need to expose the application service outside the kubernetes we used the `kubectl port-forwading` to forward the front end service localy .

```
POD_NAME=$(kubectl get pods --namespace vinayakrao -l "app=product-manager-frontend" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 3000:80 --namespace vinayakrao

```

Then visit [http://localhost:3000](http://localhost:3000) to view the app