Entity Framework Core + Docker - podejście do migracji bazy na produkcji.

0

Cześć,

Mam pytanie z pogranicza teorii i prkatyki związane z migracją bazy danych. W projekcie (ASP.NET Core 2.0) wykorzystuję Entity Framework Core. Cała aplikacja deployowana jest jako kontener dockera. Chciałbym oczywiście móc wygenerowac migracje z poziomu EF Core. Zastanawiam się jakie powinno być prawidłowe podejście do dodawania takich migracji na produkcji. Opcje które przyszły mi do głowy:

  • Dajemy po prostu podczas startu aplikacji Database.Migrate() - starszinie słabe, niebezpieczne i ogólnie MS nawet w swojej dokumentacji przed tym ostrzega
  • Logujemy się do kontenera aplikacji i wewnątrz tego kontenera odpalamy:
dotnet ef database update
  • ogólnie brzmi nieźle ale nie wiem czy to prawdiłowe podejście
  • Wygenerować SQL na podstawie migracji i odpalić "z ręki " - chyba najbardziej tradycyjne i poprawne (?) podejście, ale jakoś śrenio mi się widzi przeklejanie i odpalanie skryptów
  • Wygenerować SQL i spreparować kontener z bazą danych w taki sposób że skrypty odpalają się automatycznie jak tylko kontener wstanie

Jakieś inne pomysły w tej kwestii ? Ew ktory sposób byście wybrali ?

Pozdrawiam,
W2K

0

Nie mam doświadczenia z .NET Core, EF Core, migracjami ani dockerem, ale wybrałbym ten sposób, który najłatwiej zintegrować z CI, czyli pewnie wywołanie dotnet ef database update.

0

Nic nie powinieneś robić ręcznie, nie od tego jest bash czy inny shell. nie od tego jest docker żeby musieć na niego wchodzić.

Powinieneś to zrobić z systemu kontenera dockera a nie z aplikacji. Powinno iść automatycznie na starcie kontenera, sprawdzasz czy masz aktualne migracje i wtedy je wykonujesz.
Tak to robi wiele aplikacji np. Gitlab, nextcloud.
To powoduje że za każdym razem jak updatujesz obraz kontenera (czyli w sumie tworzysz do nowa kontener) to za każdy razem wywołuje się update.

Jak w ogóle przekazujecie dane do ConnectionStringa ? Budujecie go z Envów?

0

Tylko czy w tej sytuacji masz na myśli kontener aplikacji, czy kontener z bazą (zakłądam setup z docker compose i jedną maszynę na którym stoją baza+ api) . A jak by to miało wyglądać w przypadku bazy na fizycznie innej maszynie.

0

miałem na myśli kontener z aplikacją, bo tylko na nim możesz zrobić dotnet ef database update. Kontener bazy nie musi być świadomy z czym obcuje :D

0

Bardziej chodziło mi o to czy wywołanie dotnet ef database update na produkcji jest porpawnym podejściem. Kontrola nad całym procesem jest mizerna w tym wypadku. A idąc w tym kierunku jesteśmy już tylko o krok od Database.Migrate() odpalanego z aplikacji ;-)

0

a jak to robicie w przypadku aplikacji, które nie są dystrybuowane przez dockera ? tak samo, tylko że wszystko robisz ręcznie, albo faktycznie puszczasz to z aplikacji (ale jak dla mnie to złe).

0

Generalnie spotkałem się z 2 podejściami. Albo skrypty wygenerowane do SQLa i potem odpalane ręcznie przed deploymentem - niezbyt lubię to rozwiązanie.
ALbo skrpyty wygenerowane do SQL + osobna aplikacja zarządzająca migracjami odpalana w ściśle określonym momenice deploymentu, ale niebędąca częścią API . Ogólnie zapewnia to lepsza kontrole niż fire and forget. Najbliżej temu rzwiązaiu do dotnet ef update database

0

To wszystko zależy od rodzaju dostępu do bazy i od odbiorcy aplikacji. Jeśli to jest aplikacja nazwijmy to generyczna - to znaczy robisz masę deployów w miesiącu został bym przy tym co pisałem. Drugim ekstremum jest dostęp gdzie klient robi wszystko samo - administrator bazy przegląda skrypty i sam je wrzuca - wtedy jak najbardziej lepsze i jedyny w sumie rozwiązanie to wygenerowanie skryptów SQL i wgranie ich ręcznie.
Ale to i tak nigdy nie jest, nie powinna być docelowa produkcja, tylko preprodukcja czy inne środowisko pośrednie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1