web-dev-qa-db-ja.com

DockerコンテナーでのEF Coreの移行

.NET Core 2.0でWebApiをセットアップしています。 ORMとしてEntity Framework Coreを使用します。アプリ全体がDocker Containerとしてデプロイされます。私を少し邪魔するのは、この場合のDB移行の処理方法です。私は生産環境を意味します。私が研究したものは次のとおりです。

  • Database.Migrate()を起動するだけで、全世界を忘れ始めます-どういうわけか私はそれが好きではありません;-)
  • コマンドラインパラメーターで駆動されるDatabase.Migrate()(指定されたパラメーターでdockerコンテナーを1回実行してDBを移行します)
  • アプリケーションコンテナにログインし、dotnet ef database updateを実行します
  • 移行に基づいて単純な古いSQLを生成し、DB管理ツールから実行します。オールドスクールのようですが有効です。私が嫌いなのは、自分でスクリプトを実行することを台無しにすることです。
  • 上記のコードからすでにスクリプトが生成され、自動的に実行されるデータベースコンテナーを準備します。

他の提案はありますか?または、最良かつ最も適切なソリューションは何ですか?

よろしく

34
user1658223

私の意見では、ユースケースにほぼ合致する最初のポイント(Database.Migrate()によるスタートアップ)です。だから、私にとっては、現在それが好ましい方法です。

起動プロセスにはいくつかの追加の星座があります。

  • Dockerコンテナーはローカルのみ(開発環境およびテスト用)
  • Database.Migrate()部分を実行する独自のスタートアッププロジェクト(独自のデータベースを持つプロジェクトが複数あるため)
  • 実際のAPI Webサイトを使用した追加プロジェクト:)
  • Azure SQLサーバーを使用した運用環境(Azure DevOpsパイプラインを介して公開およびデプロイされます)

  • 移行は、dotnet efを介して独自のプロジェクトで作成されます...

    dotnet ef migrations add "移行名" --startup-project "実際のAPIへのパス" --context "データベースコンテキスト名"

重要:別のスタートアッププロジェクトを使用し、「移行プロジェクト」で移行ファイルを生成するには、まず作業ディレクトリを移行プロジェクトに変更する必要があります

私たちのケースでは、szeneの背後にある独自のデータベースを持つさまざまなAPIで正常に動作します。

よろしく

1
Leonhard