Django : Comment gérer les paramètres de développement et de production ?

Question

J'ai développé une application de base. Maintenant, au stade du déploiement, il est devenu clair que j'ai besoin de paramètres locaux et de paramètres de production.

Il serait bon de connaître les éléments suivants :

• Comment gérer au mieux les paramètres de développement et de production.
• Comment garder des applications telles que django-debug-toolbar uniquement dans un environnement de développement.
• Tout autre conseil et meilleure pratique pour les paramètres de développement et de déploiement.

Answer 1

Si vous souhaitez conserver un seul fichier de paramètres et que votre système d'exploitation de développement est différent de votre système d'exploitation de production, vous pouvez placer cette information au bas de votre fichier settings.py :

from sys import platform
if platform == "linux" or platform == "linux2":
    # linux
    # some special setting here for when I'm on my prod server
elif platform == "darwin":
    # OS X
    # some special setting here for when I'm developing on my mac
elif platform == "win32":
    # Windows...
    # some special setting here for when I'm developing on my pc

Lire la suite : Comment vérifier le système d'exploitation en Python ?

Answer 2

Il semble qu'on ait répondu à cette question, mais une méthode que j'utilise en combinaison avec le contrôle de version est la suivante :

Configurer un fichier env.py dans le même répertoire que les paramètres sur mon environnement de développement local que j'ajoute également à .gitignore :

env.py :

#!usr/bin/python

DJANGO_ENV = True
ALLOWED_HOSTS = ['127.0.0.1', 'dev.mywebsite.com']

.gitignore :

mywebsite/env.py

settings.py :

if os.path.exists(os.getcwd() + '/env.py'):
    #env.py is excluded using the .gitignore file - when moving to production we can automatically set debug mode to off:
    from env import *
else:
    DJANGO_ENV = False

DEBUG = DJANGO_ENV

Je trouve simplement que cela fonctionne et que c'est beaucoup plus élégant - avec env.py il est facile de voir nos variables d'environnement locales et nous pouvons gérer tout cela sans avoir à utiliser plusieurs fichiers settings.py ou autres. Cette méthode permet d'utiliser toutes sortes de variables d'environnement local que nous ne voudrions pas définir sur notre serveur de production. En utilisant le .gitignore via le contrôle de version, nous gardons également tout intégré de manière transparente.

Answer 3

Pour le problème de la mise en place des fichiers, je choisis de copier

Project
   |---__init__.py   [ write code to copy setting file from subdir to current dir]
   |---settings.py  (do not commit this file to git)
   |---setting1_dir
   |         |--  settings.py
   |---setting2_dir
   |         |--  settings.py

Lorsque vous lancez django, __init__py sera exécuté. À ce moment-là , settings.py in setting1_dir remplacera settings.py in Project .

Comment choisir les différents env ?

• modifier __init__.py directement.
• faire un fichier bash à modifier __init__.py .
• modifier env sous linux, et ensuite laisser __init__.py lire cette variable.

---

Pourquoi l'utiliser de cette façon ?

Parce que je n'aime pas qu'il y ait autant de fichiers dans le même répertoire, trop de fichiers vont perturber les autres partenaires et ne sont pas très utiles pour l'IDE (l'IDE ne peut pas trouver le fichier que nous utilisons).

Si vous ne voulez pas voir tous ces détails, vous pouvez diviser le projet en deux parties.

1. créer un petit outil comme Spring Initializr, juste pour configurer votre projet (faire quelque chose comme copier le fichier).
2. le code de votre projet

Answer 4

Vous voulez être en mesure de changer les paramètres, les secrets, les variables d'environnement et autres en fonction de la branche git dans laquelle vous vous trouvez et en vous appuyant sur différents fichiers de paramètres, c'est bien mais dans une situation d'entreprise, vous voudriez cacher toutes vos informations sensibles du repo. Ce n'est pas une bonne pratique de sécurité d'exposer toutes les variables d'environnement, les secrets de tous les environnements (développement, staging, production, qa etc.) à tous les développeurs. Ce qui suit devrait permettre d'atteindre 2.

1. isolement des paramètres en fonction de leur environnement de déploiement
2. cacher les informations sensibles du repo git

Mon run.sh

#!/bin/bash
# default environment
export DJANGO_ENVIRONMENT="develop"
BRANCH=$(git rev-parse --abbrev-ref HEAD)

if [ $BRANCH == "main" ]; then
    export DJANGO_ENVIRONMENT="production"
elif [ $BRANCH == "release/"* ]; then
    export DJANGO_ENVIRONMENT="staging"
else
    # for all other branches (feature, support, hotfix etc.,)
    echo ''
fi

echo "
BRANCH: $BRANCH
ENVIRONMENT: $DJANGO_ENVIRONMENT
"
python3 myapp/manage.py makemigrations
python3 myapp/manage.py migrate --noinput
python3 myapp/manage.py runserver 0:8000

Mon vars.py (ou secrets.py ou n'importe quel nom) dans le même dossier que settings.py de django

vars = {
    'develop': {
        'environment': 'develop',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "True"
        },
    'production': {
        'environment': 'production',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "False"
        },
    'staging': {
        'environment': 'staging',
        'SECRET_KEY': 'mysecretkey',
        "DEBUG": "True"
        }
    }

puis dans settings.py faites simplement ce qui suit

from . import vars # container environment specific vars
import os

DJANGO_ENVIRONMENT = os.getenv("DJANGO_ENVIRONMENT")  # declared in run.sh
envs = vars.vars[DJANGO_ENVIRONMENT] # SECURITY WARNING: keep the secret key 
used in production secret!
SECRET_KEY = envs["SECRET_KEY"]

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = envs["DEBUG"]

Laissez les développeurs avoir leurs propres vars.py dans leur machine locale mais pendant le déploiement, votre pipeline cicd peut insérer le vars.py réel avec les valures réelles ou un script devrait l'insérer. Si vous utilisez gitlab cicd, vous pouvez stocker l'intégralité de vars.py comme une variable d'environnement.

Answer 5

J'utilise un fichier app.yaml différent pour changer la configuration entre les environnements dans le moteur d'application google cloud.

Vous pouvez l'utiliser pour créer une connexion proxy dans votre commande terminal :

./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:1433

https://cloud.google.com/sql/docs/sqlserver/connect-admin-proxy#macos-64-bit

Fichier : app.yaml

# [START django_app]
service: development
runtime: python37

env_variables:
  DJANGO_DB_HOST: '/cloudsql/myproject:myregion:myinstance'
  DJANGO_DEBUG: True

handlers:
# This configures Google App Engine to serve the files in the app's static
# directory.
- url: /static
  static_dir: static/

# This handler routes all requests not caught above to your main app. It is
# required when static routes are defined, but can be omitted (along with
# the entire handlers section) when there are no static files defined.
- url: /.*
  script: auto
# [END django_app]