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

Odpowiedz Nowy wątek
2018-02-05 08:33
W2K
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

Pozostało 580 znaków

2018-02-05 09:04
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2018-02-05 17:16
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?


Bydgoszcz, Senior .Net Developer

Pozostało 580 znaków

2018-02-05 17:23
W2K
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.

Pozostało 580 znaków

2018-02-05 17:25
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


Bydgoszcz, Senior .Net Developer
edytowany 1x, ostatnio: Slepiec, 2018-02-05 17:25

Pozostało 580 znaków

2018-02-05 17:40
W2K
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 ;-)

Pozostało 580 znaków

2018-02-05 17:45
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).


Bydgoszcz, Senior .Net Developer

Pozostało 580 znaków

2018-02-05 17:53
W2K
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

Pozostało 580 znaków

2018-02-05 18:35
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.


Bydgoszcz, Senior .Net Developer

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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