Migrations EF Core dans le conteneur Docker
J'installe un WebApi dans .NET Core 2.0. J'utiliserai Entity Framework Core comme ORM. Toute l'application sera déployée en tant que conteneur Docker. Ce qui me dérange un peu, c'est la façon de gérer les migrations de bases de données dans ce cas. Je veux dire environnement de PRODUCTION. Voici ce que j'ai réussi à rechercher:
- Nous lançons simplement Database.Migrate () dans l'application et nous commençons à oublier le monde entier - hmm je ne l'aime pas ;-)
- Database.Migrate () piloté par un paramètre de ligne de commande (exécuter le conteneur Docker une fois avec un paramètre spécifié pour migrer la base de données)
- Connectez-vous au conteneur d'application et exécutez
dotnet ef database update - Générez du SQL ancien en fonction des migrations et exécutez-le à partir de l'outil de gestion de base de données. Semble oldschool mais valide. Ce que je déteste, c'est de jouer avec l'exécution de scripts par moi-même.
- Préparez un conteneur de base de données qui aurait déjà des scripts générés à partir du code ci-dessus, et qui les exécuterait automatiquement.
D'autres suggestions ? Ou quelle est la meilleure solution, la plus appropriée?
Cordialement
à mon avis, c'est votre premier point (Database.Migrate () due startup) qui répond principalement à notre cas d'utilisation. Donc, pour moi, c'est actuellement la façon préférée de le faire.
Nous avons quelques constellations supplémentaires dans le processus de démarrage:
- Conteneur Docker localement uniquement (pour l'environnement de développement et les tests à coup sûr)
- Propre projet de démarrage qui exécute la partie Database.Migrate () (car nous avons plus d'un projet avec sa propre base de données)
- Projet supplémentaire avec le site web de l'API :)
Environnement de production avec Azure SQL Server (publié et déployé via le pipeline Azure DevOps
Les migrations sont créées dans son propre projet via dotnet ef ...
les migrations dotnet ef ajoutent "votre nom de migration" --startup-project "chemin à votre API réellement" --context "nom de contexte de base de données"
Important: vous devez d'abord changer le répertoire de travail en projet de migration afin d'utiliser un autre projet de démarrage mais générer les fichiers de migration dans le "projet de migration"
Dans notre cas, cela fonctionne très bien avec différentes API avec leurs propres bases de données derrière le szene.
Cordialement