Angular — Django Seed Project

פוסט זה פורסם במקור ב medium.

Load Balancing Applications with HAProxy and Docker

A production ready Angular — Django RESTful seed repository

In the recent weeks I decided to build a repo that will contain a seed repo for a production ready Angular and Django RESTful apps: https://github.com/nirgn975/Angular-Django-Seed-Project.

Project Logo

 

What it means a “production ready” repo?

For me, it meant that the applications should contain a simple use case, but with all of the best practices from Django and Angular worlds, handle scalability, backups, logging, etc.

The use case I chose is to expose a users list form the Django app and show that list in the Angular app. I also want to use the best tooling in Angular and Django worlds so I use Angular-CLI, Angular Material as a design library, ngrx to handle state, and Django REST framework to build the server api.

 

Tests

Writing tests are the best practice, it’s known. So even though the django and angular apps are small, tests are a must! We test the client and server for lint errors and has a 90+ test coverage. We run it in Travis-CI and calculate coverage with codecov for every commit.

Tests are best practice, it’s known.

 

Load Tests

It’s essential to check how much requests our system can handle. We do it with Locust an open source tool to define user behaviour, and swarm our system with millions of simultaneous users. It has a nice web UI and can export the report in the end of the session.

Locust Web UI

 

Scalability

All the parts are in a separate Docker containers and we use Docker Swarm to manage them all. There is already a docker-compose.yml file to configure all the services and their relationships. For every service there is a deploy: replicas setting in the docker-compose.yml file, it gives us control on how many containers to start. And of course we can also scale it up (or down) even after we start the docker containers with the docker service scale command. We can also can do a rolling updates — update the code without downtime. And there is a special section in the README on how to do it.

But scalability is not just docker containers. Something need to handle and manage all the requests before the apps containers gets them. For that we use an HAProxy container to get all the requests and load balance them between the containers.

We also have a visualizer container to visualize where is each container is located at (on which server).

Docker Swarm Visualizer

 

Backups

Database backups are really important thing, and are something we forget to do until something goes wrong. So I really emphasis this part.

  • Each day a backup of the PostgreSQL database will be created. The daily backups are rotated weekly, so maximum 7 backup files will be at the daily directory at once.
  • Each Saturday morning a weekly backup will be created at the weekly directory. The weekly backups are rotated on a 5 week cycle.
  • Each month, at the 1st of the month a monthly backup will be created at the monthly directory. Monthly backups are NOT rotated

The backups are saved at /var/backups/postgres at the host machine via a shared volume. It can be configured in the docker-compose.yml at the volumes section of the database service.

 

Logging

We use the ELK Stack for logging. The server (Django app) logs are sent to Logstash, and saved in Elasticsearch. There is separate container for every part of this stack. And of course we also have a Kibana instance to check and analyze all the logs.

Kibana UI

 

Security

Security is a whole subject of itself. And although we already get the best practice from django world, we need to do something more in that case. Everybody knows Django Admin interface is on /admin and it is a security concern. So we use django-admin-honeypot to fake the admin login screen and log and notify admins of attempted unauthorized access.

We put the read admin screen at /secret-admin but you really need to change it once you clone and start writing you own project. This setting will be where you expect it to be, at the path server -> config -> urls.py.

 

Summary

At the end we have all we need to start a new project based on Angular and Django. But this is not the end, it’s only the beginning. We have more to do, like update ngrx to version 4.0, integrate redis as a cache layer, etc.

I would love to get your help on this and make this project the go to seed app for everyone who want to start building an Angular and Django RESTful apps.

GitHub repo: https://github.com/nirgn975/Angular-Django-Seed-Project