## Configuring Django Settings

Django project can have a lot of environments during the real world production process:

• local,
• dev,
• ci,
• qa,
• staging,
• production,

We need a way to arrange all those environments settings. so to protect sensitive data like secret keys, passwords, API tokens etc. also, settings can be easily shared by team members so everyone can be at the same page during development.

This article shares some popular approaches.

• settings_local.py: this is an all-in-one approach that we used during our pass labs.
  • pros: stay local ignored by VCS(version control system)
  • cons: gradually loss info during development; can be obstract since it’s still python code.
• one an env, settings/: create individual setting file for each environment, and hold them in one folder.
  • pros: all in VCS, can be easily share among members.
  • cons: need special way to handle sensitive data(e.g. use env variables ), and hard to inherit.
• 12 factors: Heroku introduced this concept for deploying cloud based distributed web apps. each point describes a recommended a way to implement that specific aspect of settings.
  • Codebase
  • Dependencies
  • Config
  • Backing services
  • Build, release, run
  • Processes
  • Port binding
  • Concurrency
  • Disposability
  • Dev/prod parity
  • Logs
  • Admin processes
• Django-envrion: usingos.environ toolkit to store settings by wrapping them in env variables. this can be the best way to store settings.

setting structure

project/
├── apps/
├── settings/
│   ├── project
│   │   ├── __init__.py
│   │   ├── custom_module_foo.py
│   │   ├── custom_module_bar.py
│   │   └── custom_module_xyz.py
│   ├── third_party
│   │   ├── __init__.py
│   │   ├── celery.py
│   │   ├── email.py
│   │   └── rest_framework.py
│   ├── __init__.py
│   └── django.py
└── manage.py

****This is from the article****

conclusion

Best practices will keep your project a long run.

• Don’t hard code your settings, using variables.
• use default values and naming conventions for common practice.
• group and serialize settings to make your code/setting file nice and neat.

SSH

SSH stands for secure shell protocol, it’s a pretty old yet popular protocol that used to securely communicate with remote servers. using SSH is pretty simple after installation: it’s normally used in shell env.

• format is: ssh {user}@{host} or
• example: ssh testuser@10.0.0.55
  • this basically tells that testuser will connect to server ip address 10.0.0.55. prompted with type in password will grant access/connection.
• ssh package come with a lot of script command as well, ssh --help have all there.

SSH is a secure trasmitting protocol with Encryption techniques:

• Symmetrical encryption: use shared secret key used for both encry/decry of msg by both client/host.
• Asymmetrical encryption: use public/private keys instead of a shared key.
• Hashing: one way hashing, client generate hash code for verifying purpose. not the other way back.

Things I want to know more?

The os.enrion practice.