• Wendy Arango - [email protected]
• Manuela Carrasco - [email protected]
• Juan Manuel Ciro - [email protected]
• Juan José Suárez - [email protected]

The site is available at http://st0263.tk/

• Wendy Arango --> Database deployment.
  • Deploying MongoDB in Google Cloud with Google Kubernetes Engine (GKE).
• Manuela Carrasco --> Load balancer deployment.
  • Deploying Load Balancer and NGINX Server in Google Cloud with Google Kubernetes Engine (GKE).
• Juan Manuel Ciro --> Front end deployment.
  • Organizing application so it can be understandable for any user.
• Juan José Suárez --> Back end deployment.
  • Developing application functionalities.

1. Availability: There is a guarantee the application is going to be up 99.99% of the time. (High availability). In this project, availability is reflected in:

   • For application: There are two instances of NGINX server that store a Docker container which has the application and all its dependencies. There is a load balancer which sends users requests to both instances. Each processes the requests depending on the actual number of users. If there is a failover of one of the instances, then the other starts to take the load until the problem is solved and the one which failed gets up again.
   • For database: there is a cluster in GKE with three pods containing MongoDB. One is a Primary node, in which all writing requests are performed. The other one is a Secondary node, which is a replica of the Primary. There is also an Arbiter node, that ensures Secondary it's going to get up if Primary fails. The database was created by using StatefulSets that, according to Kubernetes Docs, help to create pods from the same specification, "(...)but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling".

2. Performance: Refers to low Response Time, Throughput, etc.

   In this project, performance is reflected in: While having various instances of the project in different machines, there is not only guarantee the app is going to be available, but also more requests can be processed. This means the app can handle more users and it's going to be answer faster to users petitions.

3. Security: Under any unsafe environment or conditions application should work, and it should not break by sudden attacks from internal or external source.

   In this project, security is reflected in:

   • For application: The application uses https as the protocol and also the comunication between the front end and the data base is through Jason Web Token.
   • For database: writing to database is only possible by accessing with user and password. Besides, database is no exposed through internet. Instead, it can be accessed only from inside the cluster to communicate with the pods that need it.

• Cloud:
  • Google Cloud with Google Kubernetes Engine (GKE)
• FrontEnd:
  • Nodejs
  • Vue
• BackEnd:
  • Ruby on Rails
• Database:
  • MongoDB

In the first project, the application was just a docker container with a local database.

For this project, we redisign the application in different ways:

• We use Google Cloud with Google Kubernetes Engine (GKE) that allow us to deploy and manage with more efficiency the different services and application for this project.
• The frontend and the backend are separate with the objective that the application is stateless so it allow us to have different intances of the application.
• We made a load balancer, this increase the availability and the performance of the application.
• The database has two instaces of it (primary and secondary), the secondary is a replica of the primary and they are manage by "referee" that if the primary goes down it will set the secondary as a primary until the primary could be up again.

It is important to note that both database, frontend and backend can scale to have as much replicas as the developer wants.

For this architecture your fisrt deployment should be the database then the application images and finally the ingress controler with nginx.

To deploy this project, you have to install:

• gcloud
• kubectl
• helm

All the yaml files for the database are in the MongoConf directory. Refer to our Mongo Deployment file to set up your database in your K8s cluster.

All the yaml files for the ingress controller and application images are in the IngressConf directory.

Before installing the application images, install Tiller with RBCA enabled into the Kubernetes cluster.

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller

Then set up the image as a deployment.

kubectl apply -f geolocation app.yaml

Deploy the geolocation app as a service.

kubectl expose deployment geolocation-app

All the yaml files for the ingress controller and application images are in the IngressConf directory.

Firts, deploy a NGINX controller Deployment and Service.

helm install --name nginx-ingress stable/nginx-ingress --set rbac.create=true --set controller.publishService.enabled=true

After that, configure your ingress resource

kubectl apply -f ingress.yaml

To enter into the application, run the follow command and wait to Google Cloud gives you an IP.

kubectl get ingress ingress