Django モデルの変更を本番環境にデプロイするための初心者向けガイド

Django プロジェクトを本番環境に初めてデプロイする方法については、インターネット上で多くの記事を見つけることができます。しかし、プロジェクトがすでに本番環境にあり、展開中に関連システムの一貫性を確保すると同時に、製品の継続性を確保する必要がある場合はどうすればよいでしょうか?

プロダクションとは？

プロダクションは、エンド ユーザーが利用できるソフトウェアとハードウェアの複合体です。これには、安定したソフトウェアがインストールされたサーバー、仮想マシン、コンテナーが含まれます。

生産には多くの要件があります。ただし、この記事では、効率と継続性に焦点を当てます。

効率性とは、製品が本来の目的を果たすことを保証するものです。

継続性は、この製品を使用している間、効率的な作業を保証するものです。

つまり、ログイン試行が常にエラーを返す場合、これは効率が悪いということです。ただし、ユーザーがそのようなエラーをめったに受け取らない場合、これは継続性の違反です。

初期データ

アーキテクチャに応じて、いくつかのコンテナー、仮想マシン、またはサーバーが運用環境で使用されます。

通常の開発環境に似ているため、本番環境では 1 つのサーバーで 1 つのプロセスのみが動作している状況は考慮していません。

生産スキーム

一般に、複数のコンテナを含むスキームに最もよく遭遇します。それらはバランサーを介してアクセスされます。複数のバランサーが存在する場合があります。コンテナーからは 1 つのデータベースにアクセスしますが、シャーディングやレプリカを含む複数のデータベースが存在する場合があります。また、Kafka などのブローカーやその他のサービスにもアクセスできます。他のサービスも何らかの方法でバックエンドと情報を交換できます。

コードとデータベースの同時変更

たとえば、コードとデータベースへの変更のみを考えてみましょう。

これがデータベースに影響を与えるようにコードで行うことができる変更、およびその逆:

1. テーブルを追加/削除します。
2. 列を追加/削除します。
3. 列またはテーブルの名前を変更します。
4. 列タイプを変更します。
5. 列の属性 (インデックス) を変更します (NULL、一意、デフォルト)。

トリガーや関数を追加したり、スキームを変更したり、その他多数のこともできます。ただし、これを本番環境に適用するための一般的なアプローチは、まさにこれらの例に示されています。

詳細な例

モデル (テーブル) を開発環境でローカルにアプリケーションに追加する必要がある場合は、次の手順を実行する必要があります。

1. クラスを Django モデルに追加します。
2. コマンドを呼び出します: python manage.py makemigrations 。
3. 次に: python manage.py migrate 。
4. その後、アプリケーションを再起動します。

しかし、本番環境では、アプリケーション、git、および移行を実行するための個別のプロセスの多くのインスタンスがあります。

多くの場合、Prod に直接アクセスすることはありません。そして、これは良いです。たとえば、フローは次のようになります。

このようなスキームでは、移行が最初に実行されます。その後、ポッドが 1 つずつ再起動されます。

このようなアーキテクチャでは、移行が実行されたにもかかわらず、本番環境のコードが変更されていないという状況が常に発生する可能性があります。

その後、ポッドが交換されています。新しいコードを持つインスタンスもあれば、古いコードを持つインスタンスもあります。

さらに、ポッドの交換が完了したときに移行を実行すると、別の状況が発生します。サーバー上のコードは更新されますが、データベースは更新されません。

どちらの状況も、データベースとコードに一貫性がない期間があることを意味します。

幸いなことに、Django は整合性をチェックしません。ただし、必要な要素がない場合は、例外が発生します。

彼らです：

1. コードのモデルにはクラスが存在するが、データベースには存在しない
2. コード内のクラスにフィールドが存在するが、データベースには存在しない
3. コードとデータベースのテーブルと列の名前が異なる
4. コードとテーブル内のさまざまな種類のデータ
5. デフォルト値、NULL、およびその他の違い (使用する場合)
6. コードからアクセスしたときにデータベースが予期しないその他の相違点

ソリューション

これが意味する場合、コードを変更する前に移行を実行する必要があります。

1. テーブルの追加
2. 列の追加
3. フィールドに NULL を挿入する機能の追加

これが意味する場合、コードを変更した後に移行を実行する必要があります。

1. テーブルの削除
2. 列の削除
3. フィールドに NULL を挿入する機能の削除

名前の変更は、いくつかの手順で実行されます。

1. 新しいフィールドまたはテーブルの作成
2. 新旧のフィールドまたはテーブルの同期の追加
3. 必要に応じて履歴データをコピーする
4. 新しいフィールドまたはテーブルの使用開始
5. 同期に伴う古いフィールドまたはテーブルの削除

これはすべて複雑に思えます。しかし、上記のスキームを見てください。マルチポッド プロダクションでは、展開中に、コードの一部が古いデータベース スキームで動作し、他の部分が新しいデータベース スキームで動作することが常に発生します。これにより、例外が発生する場合があります。

したがって、Django モデルを扱うための基本的なアルゴリズムは、本番環境では機能しません。特定のケースで使用されるコード アーキテクチャと CI / CD フローに応じて、いくつかの手順で変更を展開する必要があります。

ただし、変更を加えるときは、データベースに要求を送信するときにコードが期待することをいつでもガイドできます。標準的なケース以外にも、さまざまな例外や障害があり、回避するには工夫が必要です。

今後の記事では、ここで言及したいくつかのケースについて詳しく説明します。