Kopia środowiska produkcyjnego na serwerze testowym. Jeżeli nie docker to co?

Odpowiedz Nowy wątek
2017-03-16 18:21
Administrator

Rejestracja: 18 lat temu

Ostatnio: 9 godzin temu

0

Potrzebuje na serwerze testowym mieć kopię środowiska produkcyjnego (te same wersje softu itp). Również na komputerze lokalnym potrzebowałbym kopię takiego środowiska, tak, aby ewentualna zmiany (nowa wersja softu, pakietów itp) w łatwy sposób znalazła się na serwerze testowym, lokalnym i produkcyjnym. Wydaje się że docker byłby do tego idelny. Czytałem jednak watek Docker i microserwisy na produkcji i już sam nie wiem...

Jeżeli nie docker to co? chef, puppet? Osobiście nie miałem z tym wiele wspólnego. Jak to ogarnąć?

Pozostało 580 znaków

2017-03-16 20:46

Rejestracja: 17 lat temu

Ostatnio: 1 tydzień temu

0

Docker zapewni Ci kopie na poziomie binarnym, puppet, chef, ansible, itd są ok do budowania i instalowania softu ale ciężko zapewnić aby dev i produkcja były identyczne, dlatego pod tym względem docker jest prostszy w użyciu. Co do produkcji, Dockera zaadoptowały duże firmy i da się go utrzymywać, zasada 80/20, 80% systemów możesz opakować Dockerem, pozostałe 20% to przypadki brzegowe.
Póki co najwygodniej mi się używa docker compose z override dla dev.


Pozostało 580 znaków

Złoty Wąż
2017-03-21 12:13
Złoty Wąż
0

Jeżeli środowisko będzie "niemutowalne" to ansible spokojnie wystarczy.
Przez niemutowalne rozumiem to, że nie będzie żadnych zmian robionych ręcznie poza plikami ansiblowymi.
Jeżeli będzą ręczne zmiany to docker też problemu nie rozwiązuje.

Nic nie stoi na przeszkodzie żeby dockera też ogarniać ansiblem.

Jedno co jest istotne to żeby pod żadnym względem nie używać dockera do produkcyjnej bazy danych.

Pozostało 580 znaków

meh
2017-03-21 16:39
meh
0
Złoty Wąż napisał(a):

Jedno co jest istotne to żeby pod żadnym względem nie używać dockera do produkcyjnej bazy danych.

A niby dlaczemu? Montujesz dane pod kontener i proces dziala? MySQL czy Mongo dzialaja bez problemu.

edytowany 1x, ostatnio: Adam Boduch, 2017-03-21 18:34

Pozostało 580 znaków

Biały Kot
2017-03-22 09:15
Biały Kot
0

@meh
To, że coś się da zrobić nie znaczy jeszcze, że to jest dobry pomysł.
Jaka jest zaleta posiadania bazy danych na dockerze?
Żadna, bo i tak nie możesz ubić kontenera i później go uruchomić bo stracisz dane które doszły.
Możesz mieć niby dockera, a na nim bazę i nigdy go nie wyłączać, ale po co Ci w tedy docker?

Docker zwyczajnie do tego nie złuży by design.
Właśnie o to chodzi, że kontener ma się nie zmieniać poza skryptem go tworzącym żeby dało się go bez problemu zabijać i podnosić.

Pewniem, że można skrypt napisać tak, że najpierw leci dump, później dopiero zabijamy dockera i później go odtwarzamy, ale w takim wypadku lepiej sprawdzi się coś ala salt lub ansible.

Jedyne kiedy to może mieć sens to w przypadku nosqlowych baz danych gdzie shardy będą sensownie podzielone.

Żeby nie było, że mam coś do baz danych na dockerze napiszę tylko, że docker jako miejsce na bazę dla developmentu czy testów nadaje się idealnie.

Pozostało 580 znaków

meh
2017-03-22 12:36
meh
0

Wut?

Docker to tylko i wylacznie izolacja procesu plus minimalny overhead na sieci, ba to nakladka na LXC. Super sprawa, zeby miec kontrole nad softem na poziomie binarnym, moge opakowac caly soft bazy danych + konfiguracje, duzo prosciej niz robiac to puppetem czy chefem czy ansible.

Ubic dockera jak najbardziej mozesz, to zaden argument, tak samo mozesz ubic serwer bazy danych bez dockera, zadna roznica. Jezeli masz jeden serwer bazy danych to 1. Ty masz problem by design, nie docker, 2. masz maly lub bardzo maly system. Od tego jest replikacja i ewentualnei dodatkowe mechanizmy jak cqrs, kolejkowanie czy logi transakcji zeby moc wylaczac live baze danych (nawet, a zwlaszcza relacyjna). Docker nie ma nic do tego.

Dump bazy? Brawo... stosunkowo niewielka baza danych to kilkadziesiac GB, sam dump i import to moga byc godziny downtime.

Tak czy siak, mamy produkcyjnie klastry z dockerem w chmurze i on-prem, stoi to glownie na Mesosie i idzie to w tysiace kontenerow zeby zwiekszyc utylizacje serwerow na maksa. Bazy danych przewaznie dzialaja albo na dedykowanym sprzecie albo na dedykowanych instancjach ale nie zmienia to faktu, ze docker przydaje sie do wyizolowania nie tylko konfiguracji ale calego obrazu serwera bazy danych.

Puppetem / Chefem / Ansiblem powiniennes i tak zbudowac obraz bazowy serwera i dopiero z niego klonowac, wiec defakto efekt podobny do eksportu obrazu dockera, a nie konfigurowac na zywca produkcje bo ryzyko ze sie zjebie jest duzo wyzsze niz przy dockerze, nie wspominajac o pierdyliardzie zaleznosci w paczkach czy w modulach np w puppecie.

Pozostało 580 znaków

Nieposkromiony Samiec
2017-03-22 13:36
Nieposkromiony Samiec
0

@meh

Jezeli masz jeden serwer bazy danych to 1. Ty masz problem by design, nie docker,

To oczywiste, i nie pisałem inaczej, ja pisałem, że docker nie po to jest.

Dump bazy? Brawo...

Nie pisałem, że to mądre, nawet odradzałem, ale widać za mało czytelnie.

Ubic dockera jak najbardziej mozesz, to zaden argument, tak samo mozesz ubic serwer bazy danych bez dockera, zadna roznica.

Zależy jak ubijesz.
Jak zatrzymasz i wznowisz to tak, nie ma żadnej różnicy więc po co?
Jak ubijesz tak żeby postawić go od nowa, to tracisz znacznie więcej niż tylko dane z downtime.

Tak czy siak, mamy produkcyjnie klastry z dockerem w chmurze i on-prem, stoi to glownie na Mesosie

I to jest sedno sprawy.
Nie robisz tego gołym dockerem co było prawdopodobne w tym konkretnym wątku.
Jak ktoś pyta o dockera, to na 99% nie będzie od razu robił kubernetesa/mesosa czy serwerów po tysiące kontenerów.
Ja dobrze wiem, że np taki Amazon to na dockerach ostro jedzie, ale to jest zypełnie co innego niż robić to samemu.

Podsumowując żeby nie robić flame:
Jeżli projekt nie jest spory, zaczynasz z dockerem, nie znasz kubernetesa/mesosa i nie masz doświadczenia z czymś takim, to nie rób produkcyjnej bazy na dockerze.

Jak już wiesz co robisz i używasz np AWS to nie sugeruj się gośćmi z forów internetowych, tylko poszukaj case sudy i przeanalizuj kilka.

Pozostało 580 znaków

2017-03-22 19:15
Moderator

Rejestracja: 12 lat temu

Ostatnio: 28 minut temu

0

Docker to taka nowsza wersja WARa/JARa, która ma tą przewagę, że przenosi ze sobą zależności. Więc możesz używać Dokera w devie jeśli używasz go również na produkcji, inaczej IMHO nie ma sensu. Zamiast tego polecam spróbować Vagranta i tam postawić sobie całą infrastrukturę 1:1 jak potem na produkcji.

Jednak jeśli mocno chcesz użyć kontenerów zamiast pełnej wirtualki to użyj LXC zamiast Dockera. Większość ludzi nie ogarnia kiedy należy używać jednego, a kiedy drugiego i najczęściej na hype używają Dockera tak jakby to była maszyna wirtualna/kontener LXC i potem słychać jak rzycie pękają krzycząc "kontenery to zuo, bo XYZ".


edytowany 1x, ostatnio: hauleth, 2017-03-22 19:17

Pozostało 580 znaków

2017-03-22 19:41

Rejestracja: 4 lata temu

Ostatnio: 1 dzień temu

0

Co mu da użycie lxc (bo rozumiem, że nie miałeś na myśli lxd) zamiast dockera?

LXD to tylko daemon obsługujący kontenery LXC. A da mu to, że będzie miał kontener zachowujący się jak maszyna wirtualna, która z kolei zachowuje się identycznie do maszyny produkcyjnej. - hauleth 2017-03-23 14:32
Rozumiem, że chciałeś przekazać koledze, iż lxc to "chroot i spółka na sterydach" z takimi możliwościami jak snapshoty, nastawiony na zarządzanie i rekonfiguracji czegoś co ma długo chodzić/istnieć, podczas gdy docker skupia sie na instancjanowaniu i zarządzaniu aplikacjami w srodowiskach wysokiej skalowalności, których czas życia może być krótki, mogą być często ubijane i stawiane od nowa. - nalik 2017-03-23 15:13
Docker początkowo był nakładką na LXC a aktualnie jest UI do libcontainer jednak zasada działania obu tych narzędzi. Docker sprowadza się do teko, że 1 kontener to 1 aplikacja, gdzie LXC raczej stara się odpalić cały system razem z init. Różnica jest zasadnicza. Dodatkowo IMHO rkt jest zdecydowanie lepszym rozwiązaniem niż Docker, który jest strasznie przekombinowany bez sensu. - hauleth 2017-03-23 15:19
1 kontener 1 aplikacja to tylko oficjalna filozofia, nie ograniczenie, bo jednak możesz odpalić 2 aplikacje jeżeli się uprzesz. Init też możesz sobie dodac. Libcontainer to tylko inna warstwa abstrakcji, a pod spodem oba mechanizmy i tak korzystają z tych samych mechanizmów kernela. Nie chodzi mi o czepianie się, a o dokładniejszą odpowiedź na oryginalne pytanie. - nalik 2017-03-23 15:33
https://www.flockport.com/lxc-vs-docker/ I tak możesz odpalić 2 aplikacje, ale wtedy ryzykujesz tym, że nikt nie będzie zbierał procesów zombie, co może być uciążliwe. - hauleth 2017-03-23 21:35

Pozostało 580 znaków

Odpowiedz

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