Clever Geek Handbook

ネイティブ設定モジュール

前文



このモジュールは、Djangoの公式Webサイトに投稿されたこの長いドキュメント： 設定ファイルの分割について、私がここで再考（または誤解）した結果として生まれました。



問題の声明



DjangoでWebアプリケーションを起動すると（デバッグサーバーを起動することにより、WSGIアプリケーションとして）、フレームワークは最初にプロジェクトの初期設定を設定するモジュールを実行します。 コードのソースはDJANGO_SETTINGS_MODULE環境変数によって指定されます 。 Djangoプロジェクトを標準的な方法で作成する場合、たとえば： 

$ django-admin startproject myproject
設定モジュールも作成されます。 これはファイル「myproject / myproject / settings.py」です。 プログラマーは、プロジェクトを変更および補足して、プロジェクトをセットアップし、独自のコンポーネントとサードパーティのコンポーネントを追加します。



1人のバックエンドプログラマによって開発された単純なプロジェクトでは、そのような設定モジュールに自分自身を制限することは非常に合理的です。 ただし、プロジェクトが大きくなるにつれて、次のようになります 問題：



  1. 戦闘またはテスト環境で展開するためのプロジェクト設定は、開発者がプロ​​ジェクトを起動する設定とは大きく異なります。 たとえば、戦闘では、アプリケーションには「大規模な」SQLサーバー（PostgreSQLまたはMySQL）とキャッシュデータ（memcachedまたはRedis）を格納するための追加のキーと値のデータベースが必要ですが、コンピューターの開発者はSQLiteの使用に慣れています。 ただし、開発者の設定には、プロジェクトをデバッグするための追加モジュール（debug_toolbarなど）が含まれており、本番環境に含めるべきではありません。
  2. Djangoのデバッグモードを設定する変数（ DEBUG 、TEMPLATE_DEBUGなど）、およびサードパーティコンポーネントの同様の変数は、開発中にオンにし、本番環境でオフにする必要があります。 これは、コミット時に追跡するのが非常に面倒です。
  3. 設定モジュールは機密データ（ SECRET_KEY 、さまざまなサービスでアプリケーションを認証するための秘密/パスワードなど）を保存しますが、これはコードと同じリポジトリに保存するには安全ではなくなります。 これは、多くの開発者がコードベースにアクセスできる大規模なプロジェクトと同様に、オープンソースプロジェクトにとって特に重要です。


問題1と2は、いくつかの設定ファイルを異なる機会にリポジトリに保存し、DJANGO_SETTINGS_MODULE変数を設定して適切なファイルを選択することで部分的に解決されます。 このソリューションの欠点は、これらのファイルのデータがほぼ完全に複製されることです。 プロジェクトの開発に伴い、開発者はいくつかの異なる構成ファイルに同じ変更を加える必要があります。これは、 DRYの原則に反して、 手間がかかり、エラーなどにつながります。



解決策



私の設定モジュールには、デフォルトの 'my​​project / myproject / settings.py'との最大の後方互換性があります。myproject.settingsへのすべてのリンクは、本当に必要な場合は有効のままです。 同時に、私のソリューションにより、プロジェクト管理者は個人データを保護でき、開発者は同僚に関係なく、自分の好みに合わせて最も快適な環境を編成できます。 追加の利点は、設定の継承メカニズムです。ローカル設定では、一般設定にアクセスできます。



マイナス：ローカル設定を保存するには、リポジトリを使用できないため、別の方法を考え出す必要があります。 この問題の解決策は、通常、組織面にあります。経験豊富な同僚から経験の浅い同僚に秘密を移す、プライベートwikiセクションでサンプルlocal.pyを公開するなどです。



しかし、私の方法は非常に簡単で高速であり、フレームワークによる設定の解析プロセスに干渉せず、特別な* .ini / *などの不要なエンティティを作成しません。パーサー、設定クラス、または関数の設定の変更を含むConfファイル。



ハンズオン



以下は、クラシック設定モジュールを「アップグレード」するための一連のアクションです（コードはgitリポジトリに格納されていることが理解されています）。



  1. メインアプリケーションディレクトリにサブディレクトリ「settings」を作成します。 パスは、「myproject / myproject / settings /」のようになります。
  2. 古い「settings.py」を手順1で作成したディレクトリ「myproject / myproject / settings /」に移動し、名前を「common.py」に変更します。 将来このファイルを「一般設定」と呼びます。



    プロジェクトの設定ファイルからの相対パスを使用する場合は、1つのディレクトリ分だけネストの深さを増やします。 たとえば、次のようなコード： 

     BASE_DIR = dirname(dirname(abspath(__file__)))
    になるはずです 

     BASE_DIR = dirname(dirname(dirname(abspath(__file__))))
  3. ファイル「myproject / myproject / settings / local.py」を作成します。 次のコードをすぐに追加します。 

     from myproject.settings.common import *
    次の行からローカル設定を追加できます。



    たとえば、開発者が優れたDjango Debug Toolbarを使用する場合、次の行を追加できます。 

     INSTALLED_APPS += ('debug_toolbar', )
  4. ファイル「myproject / myproject / settings / __ init__.py」を作成し、次のコードを貼り付けます。 

     try: from myproject.settings.local import * except ImportError: from myproject.settings.common import *
    このオプションは、common.pyに含まれる設定でプロジェクトを開始するのに十分な場合に設計されています。 これは、大規模なプロジェクトでは当てはまりそうにありません。 セキュリティ上の理由から、少なくともSECRET_KEYは一般設定から削除する必要があります。



    ローカル設定ファイルなしではプロジェクトの開始が意味をなさない場合、グローバル設定で対処しようとすることはできませんが、例外をスローします。 

     try: from myproject.settings.local import * except ImportError: raise Exception('Please create local.py file')
  5. ファイル 'myproject / myproject / settings / local.py'をgit例外に追加します。 これは最後の手順ですが、重要な手順です。


できた！ 設定ファイルを、共通のプロトタイプ部分（common.py）と、一般的な設定を継承するローカル部分（local.py）に分割します。 設定の正しい分解次第です。


More articles:


All Articles