[htfhere]

#programowanie czy sa tu ludzie uzywajacy #docker w pracy ? jakie jest "profesjonalne" podejscie do tworzenia tabel w bazie danych w kontenerze? Pisze sie je w dockerfile czy stawia sie kontener z czysta baza danych i ją się np. synchronizuje z bazą źródłową?

[PanWitold]

@htfhere: ZALEŻY

Zresztą, co to za różnica w tym przypadku czy baza jest "normalnie" czy w dockerze? Jakbyś to zrobił gdyby nie było dockera? Opisz szerzej problem.

[zakopiak]

@htfhere: Mówisz o devie, czy produkacja?

[htfhere]

@PanWitold: jakby nie było dockera to nie mógłbym korzystać z dockerfile, więc zostaje synchronizacja z bazą źródłową ;)

@zakopiak: dev

[ownadi]

@htfhere: normalnie, przez migracje.

[zakopiak]

@htfhere: To masz raczej dwie opcje.

1. Stawiając instancję projektu stawiasz czystą bazę (zwykle migracje) i ewentualnie ładujesz jakieś dane, jeśli masz taką potrzebę.
2. Budujesz sobie obrazy bazy juz z danymi. Wtedy przy zmianach w strukturze bazy trzeba budować nowe obrazy i dystrybuować w zespole.

U mnie w robo mamy dystrybucję takich obrazów z danymi w bazie i obrazów ElasticSearcha ze zbudowanymi indeksami tak, że te obrazy sobie odpowiadają wersjami.

[ImReally]

@htfhere: Przy pierwszym starcie kontenera ever, odpalam skrypt inicjalizujący bazę.

[PanWitold]

@ImReally: a później jak masz zmiany na schemacie?

[ImReally]

a później jak masz zmiany na schemacie?

@PanWitold: To już ogarniam z poziomu aplikacji. Umieszczam zmiany w osobnych plikach i przy starcie aplikacji sprawdzam, czy są nowe pliku do puszczenia w bazie i je puszczam. To gwarantuje spójność nawet na devie. EDIT: to jest fajne, bo jak robisz zmianę, to w commicie razem z kodem masz też plik do zmiany w bazie - wszystko spójne.

[v.....a]

@PanWitold: użyj flyway, jak ludzie ;)

[PanWitold]

@ImReally: no ale masz rozdzieloną odpowiedzialność, dlaczego w takim razie inicjalizacja bazy nie jest też w aplikacji?

@htfhere: A w ogóle macie sens trzymania bazy w kontenerze? Czy robicie coś z cyklu "DOCKERIZE IT ALL"?

[PanWitold]

@vayana: dokładnie, docker z bazą to tylko czysta instancja (o ile jest sens w ogóle trzymać to w dockerze), a odpowiedzialność za schemat jest w aplikacji która z niej korzysta (np. flyway, liquibase)

[ImReally]

no ale masz rozdzieloną odpowiedzialność, dlaczego w takim razie inicjalizacja bazy nie jest też w aplikacji?

@PanWitold: Poprzez inicjalizację rozumiem stworzenie bazy i zainstalowanie rozszerzeń (postgres). Efektem takiej inicjalizacji jest pusta baza i wtedy rzeczywiście struktura jest tworzona z poziomu aplikacji za mocą plików ze zmianami.

[PanWitold]

@ImReally: ok, w takim wypadku to ma sens i to też miałem na myśli w mojej poprzedniej wypowiedzi. :)

[htfhere]

"DOCKERIZE IT ALL"

@PanWitold: xD Podoba mi się hasło. O żadnym "macie" nie ma mowy, w pracy jestem zwykłym klepaczem kodu, dockerem się zainteresowałem ostatnio w celach hobbystycznych :)

[ImReally]

dockerem się zainteresowałem ostatnio w celach hobbystycznych

@htfhere: Docker jest świetny. Używam go w kilku projektach produkcyjnie. Jest kilka niuansów do ogarnięcia, ale potrafi się odwdzięczyć.

[htfhere]

@ImReally: o dzięki, że to napisałeś, bo od kiedy sobie czytam o dockerze to z tyłu głowy mam pytanie
"czy to na pewno jest wartościowa wiedza?". Mówisz o niuansach do ogarnięcia, na chwilę obecną "liznąłem" takie tematy jak dockerfile, docker hub, networking, volumes, swarm, czy są jeszcze jakieś hasła, którymi się powinienem zainteresować?

[ImReally]

Mówisz o niuansach do ogarnięcia, na chwilę obecną "liznąłem" takie tematy jak dockerfile, docker hub, networking, volumes, swarm, czy są jeszcze jakieś hasła, którymi się powinienem zainteresować?

@htfhere: docker-compose. tak naprawdę to trzeba dobrze kumać jak działają wolumeny, żeby sobie krzywdy nie zrobić, staram się doprowadzać konfigurację do momentu, gdy do odpalenia produkcyjnego wystarcza git clone i docker-compose up -d