Skip to content

Assignment 2

Jump to bottom
Paritosh Morparia edited this page Mar 7, 2019 · 20 revisions

ProjectHub

Project Description: A portal to showcase projects/work using posts and people can seek advice or help from experts in the corresponding fields. Connect with the best. This portal can also be used as a project portfolio. Showcase your portfolio and get hired.

Napkin Diagram

Napkin Diagram

Architecture

Architecture Diagram

Updated Architecture Diagram

Revised Architecture Diagram

Main Goals

  • Implement continuous integration and deployment (CI/CD)
  • Deploy all on JetStream Virtual Machines
  • Service Registration and Discovery
  • Functionality Improvement

Tasks Done

  • Implemented the service registration discovery feature using Consul.
  • Developed pipelines in Jenkins for continuous integration and deployment (CI/CD)

Continuous Integration and Delivery (CI/CD)

  • All the services are currently deployed on production servers. Below mentioned steps are just to tell how services are built and deployed through Jenkins. To test the application, you can directly skip to "Application Access/Testing" section below.
  • Steps to test our CI/CD:
    • Login to our Jenkins
    • Once all the build are completed the application goes live at ProjectHub
  • As soon as any changes are pushed to a microservice branch in Github, it's associated pipeline is triggered in Jenkins where it is build and tested on the dev instance and deployed to the microservice's production instance.
  • Build History Jenkins Build History
  • Fetch Service
    • To build and deploy this service, please go to item named "fetch_service_2_ci" and click on "Build Now" in the left pane.
    • This service was developed using Spring Boot and Maven
    • It is running on jetstream at Fetch
    • Integration: A pipeline project was created in Jenkins which used to build the application every time a commit is made on GitHub. A jenkins file was configured in such a way that it build the entire project first and on successful build, it called another project to build as the last stage of pipeline.
    • Deployment: A freestyle Jenkins project was created which was triggered when integration was successfully completed (previous step). This project published the contents of last successful build over ssh. It then builds the maven project again. The last step was to check if the JAR is already running. It was running, commands are run over ssh to kill the corresponding process and then run the new JAR else directly run the JAR.
  • Frontend
    • This service was developed using ReactJS and Redux.
    • To build and deploy this service, please go to item named "frontend" and click on "Build Now" in the left pane.
    • This service is running at Frontend
  • Login Service
    • This service was developed using NodeJS.
    • To build and deploy this service, please go to item named "login_service" and click on "Build Now" in the left pane.
    • This service is running at Login
  • Upload Service
    • This service was developed using GoLang.
    • To build and deploy this service, please go to item named "go_basic" and click on "Build Now" in the left pane.
    • This service is running at Upload
  • Gateway Service
    • This service was developed using NodeJS.
    • To build and deploy this service, please go to item named "gateway" and click on "Build Now" in the left pane.

Service Registration , Discovery and Configuration management

  • Consul by HashiCorp is used for service discovery. Salient features of Consul used in the project are listed below
  1. We are eliminating the use of hard-coded API calls to servers by using using Consul's discovery feature. A Generic API call which looks like this http://149.165.169.30:9090/getLinks becomes http://fetchservice.service.consul:9090/getLinks Thus masking the IP addresses so that even if we install the fetch service in another instance having a different public IP, there wont be any code change in the API call definition. Name resolution will be done in all the consul cluster members.
  2. Load Balancing - By using consul's service discovery, we are able to have multiple instances of same service running simultaneously and also share the load among them. Though right now only single instances of each services are running, load balancing capability was tested extensively with satisfactory results.
  3. All the service registration to consul agents are done automatically by the services (Go, Node and Java services) once it starts thus eliminating static configuration files.
  4. All the services have health check setup which hits the health API endpoint on the service. And if the health is critical(i.e. service fails to work or crashes), service will be automatically be de-registered by consul thus eliminating failures in the application.
  5. Consul's inbuilt KV store is used to load DB configuration in the various services interacting with Database. KV store provides an encrypted Key Value store off which values can be accessed by accessing consul agent's localhost endpoint. This is an example of such GET call to fetch configuration from config store http://127.0.0.1:8500/v1/kv/database/username?raw

Application Access/Testing

  • To access the application, go to Main Page
  • Features to validate:
    • Any user should be able to sign up or login if the user already has an account.
    • Once the user has logged in, the user should be able to create a post either using text or by selecting an image from local system or both. After this the user should also select the tag from the drop down menu.
    • The user won't be allowed to create a post when both text and image are missing.
    • After this step, the user should be able to see posts from other people (Project Feed).
Clone this wiki locally