Tagging Tracker Backend Services

These are the services that are powering the Tagging Tracker Application.

NOTE: To use the existing Azure and auth0 accounts that are applied to this code, you need to contact one of the developers on the team. Otherwise, you'll need to setup your own Azure account and auth0 instance to run this code.

Getting Started

In order to checkout the code, and run it locally, the following steps are needed.

1. Install docker and docker-compose

2. Checkout the repository

   git clone http://www.github.com/codeforkansascity/tagging_tracker_backend
   

3. Create a local.env file in the project directory. It should contain the following variables

   DEBUG - Whether the application is in debug mode. Defaults to 0 (False), set to 1 (True).
   DISABLE_AUTH - Whether or not the application will enforce JWT authentication.
   SECRET_KEY - The secret key of the application. You can generate one here. https://www.miniwebtool.com/django-secret-key-generator/
   DEPLOYED_URL - The URL of where the application is hosted at. This isn't need if you are running locally on your device.
   LOADBALANCER_URL - The URL of the loadbalancer for the application. This isn't needed if you are running locally on your device.
   DB_NAME - Name of the database. See below for running it locally.
   DB_USER - Name of the database user. See below for running it locally.
   DB_HOST - Host of the database. See below for running it locally.
   DB_PORT - Database port. See below for running it locally.
   DB_PASSWORD - Database Password. See below for running it locally.
   SSL_MODE - The SSL mode of the database connection. Defaults to disable.
   SSL_ROOT_CERT - The path of the SSL certificate. Defaults to empty string, and not used if SSL is disabled.
   AUTH0_URL - URL of the auth0 authentication engine.
   AUTH0_CLIENTID - ClientID of the auth0 authentication engine.
   AUTH0_SECRET - Secret of the auth0 authentication engine.
   LOG_LEVEL - Error/Reporting logging level. More information here https://docs.djangoproject.com/en/2.0/topics/logging/#configuring-logging
   AZURE_IMAGE_CONTAINER_NAME - Azure container name for file uploads.
   AZURE_IMAGE_CONTAINER_KEY - Azure container access key.
   

   To get you started and running locally, here is a local.env file you can use.

   DEBUG=1
   DISABLE_AUTH=1
   SECRET_KEY=<Your generated key>
   DB_NAME=dev
   DB_USER=tag_user
   DB_PASSWORD=somepass
   AUTH0_URL=<Create your own auth0 or ask developers for it>
   AUTH0_CLIENTID=<Create your own auth0 or ask developers for it>
   AUTH0_SECRET=<Create your own auth0 or ask developers for it>
   SSL_MODE=disable
   LOG_LEVEL=DEBUG
   AZURE_IMAGE_CONTAINER_NAME=taggingtrackerdevimages
   AZURE_IMAGE_CONTAINER_KEY=<Attend meetup to obtain>
   

There are 2 methods of running the development environment. First is via a virtualenv with a postgres docker image. Secondly you can use docker-compose.

Virtualenv instructions

These instructions assume you already have a virtualenv setup with a python 3.6 distribution.

NOTE: This tutorial provides good information on setting up a virtualenv for those that are unfamiliar with setting it up.

1. Run the following commands

# Install all the requirements
$ make reqs
# Start development server
$ make start
# After exiting dev server process stop and remove all containers
$ make stop
# to add superuser:
$ python manage.py createsuperuser
# then follow the prompts

Docker compose instructions

1. Run the following commands

   # build and runs all containers
   $ make && make up
   # in a seperate terminal
   $ make migratelocal
   # or run in detached mode
   $ make && make upd && make migratelocal
   # to add superuser:
   # connect to web container:
   $ make bashw
   # then run makesuperuser
   $ python manage.py createsuperuser
   # then follow the prompts

   Anytime you change application code run make reload to restart uwsgi in the container.

   When finished run make down to stop all services. There are other targets available in the Makefile that also help with development so feel free to look those over.

2. (Optional) Configure your own settings by creating a docker-compose.override.yml file. See Docker Compose for a list of additional settings.

   NOTE: To configure ports properly, docker-compose.override.yml must contain all settings from the docker-compose.yml. Refer to this for more details. To run, use docker-compose -f docker-compose.override.yml up

3. (Optional) Generate your own self signed certificate pointing to the localhost domain using make ssl.

Managing requirements

We use pip-tools to manage our requirements. High level application packages should be put in requirements.in and high level development/testing packages should be put in requirements-dev.in. Once there run make compile to generate new requirements files and then make reqs to install the updates.

Testing

All tests should be placed under test/ in order for pytest to pick them up. Currently the development requirements are not installed in the docker image and so ensure you have your virtualenv setup and run make reqs prior to testing.

# Runs entire test suite
$ make test
# Runs only unit tests
$ make unit
# Runs only integration tests
$ make integration
# Directly invoking pytest
$ pytest -k "some filter"

Contribution

Read the Contribution Guide

Deployment

Terraform

Terraform is still WIP. See README. Run cp secrets.template.sh secrets.sh to create a file to make working w/ Terraform variables easier.

Travis CI

Currently should run tests and check formatting on all PRs. This is a requirement for merging.

TODO

• Support release branch automatically deploying to staging resources
  • The current regex does not appear to work
• Auto deploy to production
  • This is pretty much dependent on Terraform having production setup