0

コミュニティがこの特定のシナリオをどのように処理するのかと思います。Djangoの移行:sqlite3開発データベース、Amazon Elastic Beanstalk、Amazon RDS postgresqlライブデータベース

開発データベースとしてSQLite3データベースを使用してローカルに開発するDjangoアプリケーションがあります。 ライブアプリケーションはAmazon Elastic Beanstalkでホストされ、Amazon RDS PostgreSQLデータベースを使用してプロダクションを行います。

アプリをデプロイするには、Djangoアプリをeb deploy(ローカルのgitリポジトリから最新のコミット済みバージョンをプッシュする)でElastic Beanstalkにプッシュするだけです。環境はとても似ライブである場合に

settings.pyは、データベースとのチェックを設定します。

DATABASES = { 
    'default': { 
     'ENGINE': 'django.db.backends.sqlite3', 
     'NAME':  os.path.join(BASE_DIR, 'db.sqlite3'), 
    } 
} 
if 'RDS_DB_NAME' in os.environ: 
    from settings_live import * 

settings_live.pyはそうのような生産設定にデータベース構成を変更します。

DATABASES = { 
    'default': { 
     'ENGINE': 'django.db.backends.postgresql_psycopg2', 
     'NAME':  os.environ['RDS_DB_NAME'], 
     'USER':  os.environ['RDS_USERNAME'], 
     'PASSWORD': CREDENTIALS['RDS_PASSWORD'], 
     'HOST':  os.environ['RDS_HOSTNAME'], 
     'PORT':  os.environ['RDS_PORT'], 
    } 
} 

このすべてが正常に動作し、移行に関しては問題が発生します。たとえば、私の開発環境では、新しいモデルをアプリケーションのmodels.pyに作成します。変更後、私はmanage.py makemigrations myappmanage.py migrateを実行します。マイグレーションは私のsqlite3開発データベースに適切に適用されます。問題はありません。

次に、ライブ展開に備えて変更をコミットします。私の.gitignoreファイルはdb.sqlite3*/migrationsを無視するように設定されています(これらの移行は開発データベースのみに適用されるため)。

次に、私の最新のコミット(私のdevデータベースや関連する移行を含まない)をeb deployのElastic Beanstalkにプッシュします。ここで

03_makemigrations: 
    command: "django-admin.py makemigrations myapp1 myapp2" 
    leader_only: true 

04_migrate: 
    command: "django-admin.py migrate" 
    leader_only: true 

が問題だ: makemigrationsとElastic Beanstalkで環境で生成された以前の移行は、もはや以来 app/migrationsに存在していない私はそうのような本番データベースの移行を実行するために.ebextentionsファイル( .ebextensions/02_commands.config)を設定しています eb deployデプロイメントプロセスは古いアプリケーションを新しいアプリケーションで上書きします(ブランク migrationsディレクトリのみが含まれます)。これにより、本番データベースにテーブルが作成されないなどの予期しない動作が発生します。私はと考えられてきた(それでも実装し始めていない)

一つの解決策は、*/migrationsにS3バケットからコピー移行ファイルのスクリプトを作成し、前makemigrationsmigrateを実行しているにこれを実行するために02_commands.configを設定することです。その後、別のスクリプトを実行して、新しい移行ファイルをS3バケットにコピーします。私の全体のワークフローが間違っているのではないかと思います。

答えて

1

あなたの間違いは、移行が開発データベースにのみ適用されるということです。それはちょうど偽です。移行のポイントは、開発と運用のデータベースを正確に同期させることです。それらはあなたのコードの一部です。コードの残りの部分とともにコミットし、プロダクションに展開して実行する必要があります。

+2

私は完全にマイグレーションの仕組みに間違った考え方を持っていました。あなたの応答を読んでから、DjangoのWebサイトにあるMigrationsのドキュメントに戻ってみると、はるかに理にかなっています。ありがとう! –

関連する問題