Dockerを使用してDjangoおよびGunicornアプリケーションを構築する方法

Djangoは、Pythonアプリケーションをすぐに立ち上げるのに役立つ強力なWebフレームワークです。 これには、object-relational mapper、ユーザー認証、アプリケーションのカスタマイズ可能な管理インターフェイスなど、いくつかの便利な機能が含まれています。 また、caching frameworkが含まれており、URL DispatcherとTemplate systemを介してクリーンなアプリの設計を促進します。

このチュートリアルでは、Dockerコンテナを使用してスケーラブルでポータブルなDjangoPollsアプリを構築する方法を学習します。 すぐに使用できるDjangoアプリは、標準出力ストリームへのログ記録や、コンテナに渡された環境変数を使用した設定など、コンテナ内で効果的に実行するためにいくつかの変更が必要です。 さらに、JavaScriptやCSSスタイルシートなどの静的アセットをオブジェクトストレージにオフロードすると、マルチコンテナ環境でこれらのファイルの管理を合理化および一元化できます。

これらの変更は、スケーラブルなクラウドネイティブWebアプリを構築するためのTwelve-Factor手法に触発されて、サンプルのDjangoPollsアプリに実装します。 次に、アプリケーションイメージをビルドし、Dockerでコンテナー化されたアプリを実行します。

このチュートリアルの終わりまでに、セットアップをHow to Set Up a Scalable Django Appでコンテナ化したことになります。 このシリーズの後続のチュートリアルでは、Docker Composeを使用してDjangoコンテナをNginxリバースプロキシとペアリングし、このアーキテクチャをKubernetesクラスタにデプロイする方法を学習します。

チュートリアルを進めてアプリに加えている変更を理解することを強くお勧めしますが、先にスキップしたい場合は、PollsアプリのGitHubリポジトリのpolls-docker branchから変更されたコードを取得できます。

このチュートリアルに従うには、次のものが必要です。

[[step-1 -—- creating-the-postgresql-database-and-user]] ==ステップ1—PostgreSQLデータベースとユーザーの作成

まず、UbuntuインスタンスからPostgreSQLサーバーに接続します。 次に、DjangoアプリのPostgreSQLデータベースとユーザーを作成し、Djangoと効果的に連携するようにデータベースを構成します。

Ubuntuマシン（アプリコンテナーではない）からデータベースに接続する前に、Ubuntuリポジトリからpostgresql-clientパッケージをインストールする必要があります。 最初にローカルのaptパッケージインデックスを更新してから、パッケージをダウンロードしてインストールします。

パッケージのダウンロードとインストールを開始するように求められたら、Yを押してからENTERを押します。

クライアントをインストールしたので、これを使用して、Djangoアプリケーションのデータベースとデータベースユーザーを作成します。

まず、Cloud Control PanelからDatabasesに移動し、データベースをクリックして、クラスターのConnection Parametersを取得します。 クラスタのいくつかのConnection parametersを含むConnection Detailsボックスが表示されます。 これらに注意してください。

コマンドラインに戻り、次の認証情報とインストールしたばかりのpsqlPostgreSQLクライアントを使用してクラスターにログインします。

プロンプトが表示されたら、Postgresユーザー名の横に表示されているパスワードを入力し、ENTERを押します。

データベースを管理できるPostgreSQLプロンプトが表示されます。

まず、pollsという名前のプロジェクトのデータベースを作成します。

[.note]＃Note:すべてのPostgresステートメントはセミコロンで終了する必要があるため、問題が発生している場合は、コマンドがセミコロンで終了していることを確認してください。
＃

これで、pollsデータベースに切り替えることができます。

次に、プロジェクトのデータベースユーザーを作成します。 安全なパスワードを選択してください：

ここで、作成したユーザーの接続パラメーターのいくつかを変更します。 これにより、データベース操作が高速化されるため、接続が確立されるたびに正しい値を照会および設定する必要がなくなります。

Djangoが期待するデフォルトのエンコーディングをUTF-8に設定しています。 また、デフォルトのトランザクション分離スキームを「コミット済み読み取り」に設定しています。これは、コミットされていないトランザクションからの読み取りをブロックします。 最後に、タイムゾーンを設定しています。 デフォルトでは、DjangoプロジェクトはUTCを使用するように設定されます。 これらはすべてthe Django project itselfからの推奨事項です。

PostgreSQLプロンプトで次のコマンドを入力します。

これで、新しいユーザーに新しいデータベースを管理するアクセス権を与えることができます。

終了したら、次のように入力してPostgreSQLプロンプトを終了します。

適切に設定されたDjangoアプリは、このデータベースに接続して管理できるようになりました。 次のステップでは、GitHubからPollsアプリコードを複製し、Pythonパッケージの依存関係を明示的に定義します。

[[step-2 -—- cloning-app-repository-and-declaring-dependencies]] ==ステップ2—アプリリポジトリのクローンを作成して依存関係を宣言する

Django Pollsアプリをコンテナ化するプロセスを開始するには、最初にdjango-pollsリポジトリのクローンを作成します。このリポジトリには、DjangoプロジェクトのtutorialPollsアプリの完全なコードが含まれています。

サーバーにログインし、polls-projectというディレクトリを作成し、gitを使用してGitHubからdjango-pollsリポジトリのクローンを作成します。

django-pollsディレクトリにアクセスし、リポジトリの内容を一覧表示します。

次のオブジェクトが表示されるはずです。

プロジェクトの構造とファイルの詳細については、Djangoの公式ドキュメントのCreating a Projectを参照してください。

このディレクトリには、DjangoアプリのPython依存関係を含むrequirements.txtというファイルも作成します。

選択したエディターでrequirements.txtというファイルを開き、次のPython依存関係に貼り付けます。

polls-project/django-polls/requirements.txt

ここでは、静的アセットをオブジェクトストレージにオフロードするためのdjango-storagesプラグイン、gunicorn WSGIサーバー、psycopg2 PostgreSQLアダプター、およびいくつかの追加の依存関係パッケージであるDjangoをインストールします。 アプリで必要なすべてのPythonパッケージを明示的にリストおよびバージョン化することに注意してください。

ファイルを保存して閉じます。

アプリのクローンを作成し、その依存関係を定義したので、移植性を高めるために変更に進みます。

[[step-3 -—- making-django-configurable-by-environment-variables]] ==ステップ3—Djangoを環境変数で構成可能にする

the twelve-factor appの方法論からの最も重要な推奨事項の1つは、アプリケーションのコードベースからハードコードされた構成を抽出することです。 これにより、環境変数を変更することにより、実行時にアプリケーションの動作を簡単に変更できます。 DockerとKubernetesはどちらもこのコンテナ構成方法を提案しているため、このパターンを使用するようにアプリケーションの設定ファイルを調整します。

Djangoプロジェクトのメイン設定ファイル（django-polls/mysite/settings.py）は、ネイティブデータ構造を使用してアプリケーションを構成するPythonモジュールです。 デフォルトでは、ファイル内のほとんどの値はハードコーディングされています。つまり、構成ファイルを編集して、アプリケーションの動作を変更する必要があります。 osモジュールでPythonのgetenv関数を使用して、代わりにローカル環境変数から構成パラメーターを読み取るようにDjangoを構成できます。

これを行うには、settings.pyを調べて、実行時に設定する各変数のハードコードされた値をos.getenvの呼び出しに置き換えます。 os.getenv関数は、指定された環境変数名から値を読み取ります。 オプションで、環境変数が設定されていない場合に使用されるデフォルト値を持つ2番目のパラメーターを指定できます。

これにより、次のような変数を設定できます。

polls-project/django-polls/mysite/settings.py

SECRET_KEYの場合、DjangoはDJANGO_SECRET_KEYという環境変数を探します。 これはハードコードされてはならず、アプリケーションサーバー全体で同じである必要があるため、フォールバック値なしで外部で設定する必要があります。 これを提供しない場合、アプリケーションのさまざまなコピーが異なるキーを使用すると問題が発生する可能性があるため、アプリケーションが失敗するようにします。

DEBUGの場合、DjangoはDJANGO_DEBUGという環境変数を探します。 ただし、今回は、変数が設定されていない場合のフォールバックとして使用されるデフォルト値を提供しました。 この場合、変数が意図的に定義されてTrueに設定されていない限り、機密情報が誤って漏洩しないように、値が指定されていない場合はDEBUGをFalseに設定することを選択しました。 。

この手法を適用するには、選択したエディターでpolls-project/django-polls/mysite/settings.pyファイルを開き、ファイル内を移動して、提供されたデフォルト値で次の変数を外部化します。

ALLOWED_HOSTSの場合、DJANGO_ALLOWED_HOSTS環境変数をフェッチし、,を区切り文字として使用してPythonリストに分割します。 変数が設定されていない場合、ALLOWED_HOSTSは127.0.0.1に設定されます。

上記の変数を変更したら、DATABASES変数に移動し、次のように構成します。

polls-project/django-polls/mysite/settings.py

これにより、環境変数を使用してdefaultデータベースパラメータが設定されます。

DATABASES['default']['OPTIONS']の場合、json.loadsを使用して、DATABASE_OPTIONS環境変数を介して渡されたJSONオブジェクトを逆シリアル化しました。 ほとんどの場合、環境変数を単純な文字列として解釈すると、Django設定への変換が読みやすくなります。 ただし、この場合、任意のデータ構造を渡すことができることは有益です。 各データベースエンジンには固有の有効なオプションセットがあるため、適切なパラメーターを使用してJSONオブジェクトをエンコードできると、ある程度の読みやすさを犠牲にしてはるかに高い柔軟性が得られます。

jsonライブラリを利用するには、settings.pyの先頭にインポートします。

polls-project/django-polls/mysite/settings.py

特別な注意が必要な他の領域はDATABASES['default']['NAME']です。 ほとんどのデータベースエンジンでは、これはリレーショナルデータベース管理システム内のデータベース名です。 一方、SQLiteを使用している場合は、NAMEを使用してデータベースファイルを指定するため、このパラメータを適宜設定してください。

settings.pyファイルはPythonコードであるため、環境からの値の読み取りを処理する方法は多数あります。 ここで使用した方法は、コードベースから構成を外部化するための1つの可能な手法にすぎません。

このステップでは、データベースパラメータを含む一般的な移植可能な方法で、メインのDjango設定変数を設定しました。 次の手順では、JavascriptやCSSスタイルシートなどの静的ファイルの設定を引き続き行います。これらの設定は、S3互換のオブジェクトストレージサービスに集中してオフロードします。

[[step-4 -—- offloading-static-assets]] ==ステップ4—静的アセットのオフロード

実稼働環境で複数のDjangoコンテナーを実行している場合、実行中のコンテナー全体にわたって特定のバージョンの静的アセットとファイルを維持するのは面倒です。 このアーキテクチャを合理化するために、すべての共有要素と状態を外部ストレージにオフロードできます。 これらのアイテムをレプリカ間で同期させたり、バックアップおよびロードルーチンを実装してデータをローカルで利用できるようにする代わりに、これらの資産へのアクセスをネットワークアクセス可能なサービスとして実装できます。

最後のステップでは、環境変数を介してデータベース接続パラメーターを渡すことができるようにDjangoを構成しました。 このステップでは、Djangoコンテナで共有される静的アセットを保存するために使用するオブジェクトストレージサービスについても同じことを行います。

django-storagesパッケージは、Djangoがファイルをオフロードするために使用できるリモートストレージバックエンド（S3互換のオブジェクトストレージを含む）を提供します。 How to Set Up a Scalable Django App with DigitalOcean Managed Databases and Spacesのステップ7で概説されているように、django-storagesを使用して静的ファイルをDigitalOceanSpaceにアップロードするようにPollsアプリを構成します。 このガイドでは、DigitalOcean Spacesを使用しますが、S3互換のオブジェクトストレージプロバイダーを使用できます。

まず、前の手順で変更したのと同じdjango-polls/mysite/settings.pyファイルにいくつかの変更を加えます。

mysite/settings.pyファイルを開いて編集し、storagesアプリをDjangoのINSTALLED_APPSリストに追加することから始めます。

polls-project/django-polls/mysite/settings.py

storagesアプリは、手順1で定義したrequirements.txtファイルのdjango-storagesを介してインストールされます。

ここで、ファイルの下部にあるSTATIC_URL変数を見つけて、次のブロックに置き換えます。

polls-project/django-polls/mysite/settings.py

次の構成変数をハードコーディングします。

柔軟性と移植性を維持するために、以前と同様に、環境変数を使用して実行時に構成可能な多くのパラメーターを設定しました。 これらが含まれます：

settings.pyに変更を加えたら、ファイルを保存して閉じます。

今後、manage.py collectstaticを実行してプロジェクトの静的ファイルをアセンブルすると、Djangoはこれらをリモートオブジェクトストレージにアップロードします。 Djangoは、このオブジェクトストレージサービスから静的アセットを提供するように構成されました。

この時点で、DigitalOcean Spaceを使用している場合、必要に応じてSpaceのCDNを有効にできます。これにより、エッジサーバーの地理的に分散したネットワークにDjangoプロジェクトの静的ファイルをキャッシュすることで、配信を高速化できます。 オプションで、スペースのカスタムサブドメインを構成することもできます。 CDNの詳細については、Using a CDN to Speed Up Static Content Deliveryを参照してください。 CDNの構成はこのチュートリアルの範囲を超えていますが、手順はHow to Set Up a Scalable Django App with DigitalOcean Managed Databases and SpacesのEnabling CDNセクションの手順と非常によく一致しています。

次のステップでは、settings.pyに最終的な変更を加えます。これにより、DjangoがSTDOUTとSTDERRにログを記録できるようになり、これらのストリームをDocker Engineが取得して、docker logsを使用して検査できるようになります。

[[step-5 -—- configuring-logging]] ==ステップ5—ロギングの構成

デフォルトでは、Djangoは、開発HTTPサーバーを実行しているとき、またはDEBUGオプションがTrueに設定されているときに、情報を標準出力と標準エラーに記録します。 ただし、DEBUGがFalseに設定されている場合、または別のHTTPサーバーを使用している場合は、どちらも実稼働環境で当てはまる可能性があり、Djangoは別のログメカニズムを使用します。 優先度INFO以上のすべてを標準ストリームに記録する代わりに、優先度ERRORまたはCRITICALのメッセージを管理用電子メールアカウントに送信します。

これは多くの状況で理にかなっていますが、Kubernetesおよびコンテナー化された環境では、標準出力および標準エラーへのログ記録を強くお勧めします。 ロギングメッセージは、ノードのファイルシステム上の一元化されたディレクトリに収集され、kubectlおよびdockerコマンドを使用してインタラクティブにアクセスできます。 このノードレベルの集約は、運用チームが各ノードでプロセスを実行してログを監視および転送できるようにすることで、ログの収集を容易にします。 このアーキテクチャを活用するには、アプリケーションはこれらの標準シンクにログを書き込む必要があります。

幸い、Djangoにログインするには、Python標準ライブラリの高度に構成可能なloggingモジュールを使用するため、logging.config.dictConfigに渡す辞書を定義して、目的の出力とフォーマットを定義できます。 Djangoロギングを構成するためのこの手法やその他の手法の詳細については、Django Logging, The Right Wayを参照してください。

もう一度、エディターでdjango-polls/mysite/settings.pyを開きます。

まず、ログ構成を操作できるように、ファイルの先頭にimportステートメントを追加します。

polls-project/django-polls/mysite/settings.py

logging.configインポートを使用すると、新しいロギング構成のディクショナリをdictConfig関数に渡すことで、Djangoのデフォルトのロギング動作をオーバーライドできます。

次に、ファイルの下部に移動し、次のロギング構成コードのブロックを貼り付けます。

polls-project/django-polls/mysite/settings.py

ここでは、LOGGING_CONFIGをNoneに設定して、Djangoが提供するデフォルトのログ設定を無効にします。 デフォルトではLOGLEVELをINFOに設定していますが、必要に応じてオーバーライドできるように、DJANGO_LOGLEVEL環境変数を確認してください。

最後に、dictConfig関数を使用して、logging.configモジュールを使用して新しい構成ディクショナリを設定します。 辞書では、formattersを使用してテキスト形式を定義し、handlersを設定して出力を定義し、loggersを使用して各ハンドラーに送信するメッセージを構成します。

これは、DJANGO_LOGLEVELという環境変数を使用してログの重大度レベルを指定し、そのレベル以上のすべてのメッセージを標準ストリームにログに記録できる、非常に最小限の構成です。 Djangoのログメカニズムの詳細については、公式のDjangoドキュメントのLoggingを参照してください。

この構成では、アプリケーションをコンテナー化するときに、Dockerはdocker logsコマンドを介してこれらのログを公開します。 同様に、Kubernetesは出力をキャプチャし、kubectl logsコマンドを使用して公開します。

これで、Django Pollsアプリへのコードの変更は終わりです。 次のステップでは、アプリのDockerfileを作成してコンテナ化プロセスを開始します。

[[step-6 -—- writing-the-application-dockerfile]] ==ステップ6—アプリケーションDockerfileの書き込み

このステップでは、Djangoアプリを実行するコンテナーイメージと、それを提供するGunicorn WSGIサーバーを定義します。 ランタイム環境を定義してコンテナイメージを構築し、アプリケーションとその依存関係をインストールし、基本的な構成を完了する必要があります。 アプリケーションをコンテナイメージにカプセル化する方法は多数ありますが、この手順で実行するプラクティスにより、スリムで効率的なアプリイメージが生成されます。

このチュートリアルでは、コンテナベースのクラウドネイティブ環境で効果的に動作するようにDjango Webアプリを調整しました。 次に、コンテナイメージ用の最小限のDockerfileを作成し、ローカルでビルドして、Docker Engineを使用して実行しました。 PollsアプリのGitHubリポジトリのpolls-docker branchに実装した変更のdiffを確認できます。 このブランチには、このチュートリアルで説明されているすべての変更が含まれています。

ここから、Django / GunicornコンテナをNginxリバースプロキシコンテナと組み合わせて着信HTTPリクエストを処理およびルーティングし、CertbotコンテナをペアにしてTLS証明書を取得できます。 このマルチコンテナアーキテクチャは、Docker Composeを使用して管理できます。これについては、後続のチュートリアルで説明します。

低速のクライアントをバッファリングするためにHTTPプロキシの背後でGunicornを実行する必要があるため、このセットアップはそのままでnotの本番環境に対応していることに注意してください。 そうでない場合、Django WebアプリはDoS攻撃に対して脆弱になります。 このチュートリアルでは、Gunicornワーカーの任意の数として3を選択しました。 実稼働環境では、パフォーマンスベンチマークを使用してワーカーとスレッドの数を設定する必要があります。

このアーキテクチャでは、コンテナがこれらのアセットのバージョンをバンドルしてNginxを使用してサービスを提供する必要がないように、静的アセットをオブジェクトストレージにオフロードする設計上の選択を行いました。 。 ユースケースによっては、これは効果的な設計ではない可能性があるため、このチュートリアルの手順を適宜変更する必要があります。

最後に、Django Pollsアプリを完全にコンテナ化したので、イメージをDockerhubなどのコンテナレジストリにプッシュして、Dockerが利用可能なすべてのシステム（Ubuntuサーバー、仮想マシン、コンテナクラスター）で利用できるようにすることができます。 Kubernetesのように。