Wpis z mikrobloga

@Kris10: do developmentu jak złoto, ale z produkcją trzeba bardzo uważać.

Kontenery w swej naturze są ulotne - zwłaszcza w środowiskach typu Kubernetes gdzie kontener z różnych powodów może być zabity i odpalony na innym node.
Koniecznie należałoby trzymać dane poza kontenerem na podmountowanym zasobie żeby ich nie stracić w przypadku padu/restartu kontenera.
  • Odpowiedz
@Kris10: @indywidualny: @przepyszna_frytka: bo bazy danych nie są przewidziane do działania w takim środowisku. Kontenery ze swojej natury są tymczasowe, gdzie DB zakłada zdecydowanie większą kontrolę nad hostem. W developmencie to nie problem, bo jak się zepsuje to można zaorać całość i postawić na nowo, ale na produkcji to jebnie, prędzej lub pózniej, ale jebnie.
  • Odpowiedz
@Kris10:
Doświadczenie z dockera
Zależy jaka baza. Poza tym czasem jest problem, bo lokalnie wszystko działa,a ale jak postawisz taki sam stack dockerowy gdzie indziej, na innym systemie to potrafi mieć problemy z bazą.
Mój przykład: lokalnie cała appka w kontenerach, mariadb jako baza, w osobnym kontenerze, z volume'owymi plikami. Lokalnie śmiga aż miło - na serwerze - ok 1 - 1.5sek / query, a powinny być jakieś milisekundy. Finalnie wyszło,
  • Odpowiedz
konto usunięte via Wykop Mobilny (Android)
  • 1
@Kris10: mam na produkcji bazę z tysiącami operacji na sekundę i kilkadziesiąt milionów rekordów. Silnik jest w dockerze, dane host, baza postgres. Ale to nie jest tak, że uruchomisz i z głowy. Pod większe zastosowania trzeba zmieniać configi itp. i analizować czy docker ma jakieś swoje quirki dodatkowo. Więc docker w tym przypadku to dużo dodatkowej zabawy. Pod testing oczywiście docker wyłącznie polecam.
  • Odpowiedz