我正在.NET Core 2.0中设置WebApi。我将使用实体框架核心作为ORM。整个应用将部署为 Docker 容器。让我有点不安的是在这种情况下处理数据库迁移的方式。我的意思是生产环境。 这是我设法研究的内容：
- 我们只是在应用程序中触发Database.Migrate()开始忘记整个世界 - 嗯，不知何故我不喜欢它;-)
- 由命令行参数驱动的 Database.Migrate() (使用指定的参数运行一次 docker 容器以迁移数据库)
- 登录应用程序容器并执行
dotnet ef database update - 根据迁移生成普通的旧 SQL，并从数据库管理工具执行它。看似老派但有效。我讨厌的是自己执行脚本。
- 准备一个数据库容器，该容器已经具有从上述代码生成的脚本，并将自动执行它们。
还有其他建议吗？或者什么是最好，最合适的解决方案？
问候
在我看来，这是你的第一点(Database.Migrate()由于启动)主要满足我们的用例。所以对我来说，这是目前的首选方法。
我们在启动过程中还有一些额外的星座：
-
仅限本地 Docker 容器(用于开发环境和测试)
-
自己的启动项目，执行 Database.Migrate() 部分(因为我们有多个项目有自己的数据库)
-
具有实际 API 网站:)的附加项目
-
使用 Azure SQL 服务器的生产环境(通过 Azure DevOps 管道发布和部署)
-
迁移是通过 dotnet ef 在其自己的项目中创建的......
dotnet ef 迁移添加"迁移名称"--启动项目"实际 API 的路径"--上下文"数据库上下文名称">
重要： 您必须先将工作目录更改为迁移项目才能使用另一个启动项目，但在"迁移项目"中生成迁移文件
在我们的例子中，它可以很好地处理不同的API，并在幕后有自己的数据库。
问候