Docker i microserwisy na produkcji

1

Czy macie doświadczenia z produkcyjnym wdrożeniem oprogramowania opartego o microserwisy i dockery? Czy takowe doświadczenie jest pozytywne? Jeżeli były jakieś problemy, to z czym były one związane?

0

Mikroserwisy raczej nie są czymś co 'wybierasz bo jest fajne'.

Według mnie:

  1. Jeśli nie musisz to nie rób mikroserwisów
  2. Mikroserwisy rozwiązują sporo problemów organizacyjnych, tworzą problemy techniczne, ale te pierwsze są gorsze. Jak masz 1 team to raczej nie potrzebujesz mikroserwisów
  3. W 95% przypadków nie zaczynaj projektu od mikroserwisów.
  4. Docker jest fajny i wcale nie musisz mieć mikroserwisów
  5. Jak zze wszystkim poprawna odpowiedź to -> 'zależy'
  6. Mikroserwisy często występują w fimach gdzie masz gigantyczny własny produkt np. Netflix, Allegro.
7

Nie widzę związku microserwisów z dokerem.

Oczywiście microserwisy nie są jakimś golden bulletem, ale rozwiązują najgorszy rodzaj problemów - błędny wybór architektury i stosu technologicznego na początku projektu. W monolicie nic z tym nie zrobisz, mając mikroserwisy masz szanse na naukę na swoich błędach i wybór innej architektury i stosu dla następnego serwisu. Możesz też dobierać technologię do zadania - np. serwis współpracujący z Active Directory w .NET, prosty wrapper do systemu płatności w PHP, serwis biznesowy w Node.js, serwis zjadający RAM w Javie, itp.

Wielki Ogórek napisał(a):

Jak masz 1 team to raczej nie potrzebujesz mikroserwisów`

Ani kontroli wersji i programowania obiektowego! ;)

0
somekind napisał(a):

Jak masz 1 team to raczej nie potrzebujesz mikroserwisów`

Ani kontroli wersji i programowania obiektowego! ;)

Że co? Co to ma za związek z moją wypowiedzią?
Większość tych mikroserwisów powstałych na Hype to teraz micro monolity, którym daleko do takich prawdziwych micro.
Bo są po prostu... wymagające.

  • błędny wybór architektury i stosu technologicznego na początku projektu.

Według mnie rozwiązują inne problemy a te co wymieniłeś... raczej średnio.
W każdym talku pojawia się by nie zaczynać od mikroserwisów... no chyba, że masz ludzi z takim doświadczeniem na pokładzie.

2
Wielki Ogórek napisał(a):

Że co? Co to ma za związek z moją wypowiedzią?

Taki sam jak liczba programistów z opieraniem architektury o mikroserwisy.

Według mnie rozwiązują inne problemy a te co wymieniłeś... raczej średnio.

Mogę nie mieć racji, chociaż nie rozumiem jak możliwość napisania każdego nowego mikroserwisu inaczej nie rozwiązałaby problemu utknięcia w słabej architekturze całemu systemowi?

0

Zawężę temat. Mniej mi chodziło o microserwisy a bardziej o dockera. Niedługo ruszamy z dockerami na produkcji i mam pewne obawy, zwłaszcza jeżeli chodzi o stabliność rozwiązania.

0
somekind napisał(a):
Wielki Ogórek napisał(a):

Że co? Co to ma za związek z moją wypowiedzią?

Taki sam jak liczba programistów z opieraniem architektury o mikroserwisy.

Według mnie rozwiązują inne problemy a te co wymieniłeś... raczej średnio.

Mogę nie mieć racji, chociaż nie rozumiem jak możliwość napisania każdego nowego mikroserwisu inaczej nie rozwiązałaby problemu utknięcia w słabej architekturze całemu systemowi?

A czemu niby Mikroserwisy mają być dobrą architekturą prędzej niż cokolwiek innego ? To zawsze zależy.
Czemu 1 team i mikroserwisy nie pasują? Bo to całkiem jasne, że nie mierzysz się z taką skalą gdy potrzebne są mikroserwisy.

A na pewno nie powinien robić tego startup.

0
InterruptedException napisał(a):

Zawężę temat. Mniej mi chodziło o microserwisy a bardziej o dockera. Niedługo ruszamy z dockerami na produkcji i mam pewne obawy, zwłaszcza jeżeli chodzi o stabliność rozwiązania.

Nie chcę straszyć ale warto przeczytać https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/

Osobiscie słyszałem o problemach np. za pamięcią i kontrowersjach odnośnie security.

Czego używacie do orkiestracji, discovery itp. ?

0

I jeszcze np. https://engineering.linkedin.com/blog/2016/11/application-pauses-when-running-jvm-inside-linux-control-groups

o samych np. mikroserwisach

Z dockerem chyba najważniejsze jak robisz 'orchestration'.

0

Consul to tylko discovery a orchestration?
Kubernetes, docker swarm, compose, nomad, mesosphere?

Chwytaj:
https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/

0
Pijany Pomidor napisał(a):

A czemu niby Mikroserwisy mają być dobrą architekturą prędzej niż cokolwiek innego ?

Chyba już napisałem dlaczego. Bo każdy mikroserwis może mieć swoją architekturę i stos technologiczny dopasowane do swojego zadania i ilości konsumentów.

Czemu 1 team i mikroserwisy nie pasują? Bo to całkiem jasne, że nie mierzysz się z taką skalą gdy potrzebne są mikroserwisy.

Co ma skala do rzeczy? Łatwiejsze skalowanie to nie jest cel stosowania mikroserwisów, a jedynie efekt takiego podejścia.

0

Aplikacja monolityczna jest duzo prostsza technicznie niz mikroserwisy. ACID nie istnieje. Systemy rozproszone sa trudne. Zapewnienie fail safe jest trudne. Orchestration i zarzadzanie zasobami, devops tez. Itp.

Polyglot microservices fajnie fajnie ale nie jest to takie proste. Potrzebujesz jakos miec te serwisy zintegrowane. Moze sie okazac, ze to tez nie jest proste. A w przypadku jednego teamu? Rozumiem, ze masz specow od kazdej technologii w tym teamie.

A jak nie radzisz sobie z architektura monolitu... To architektura micro jest bardziej wymagajaca.

Jak juz mowilem wczesniej. Mikroserwisy glownie rozwiazuja problemy organizacyjne gdy np. Osobne teamy wchodza sobie w droge. Jest za duzy narzut na komunikacje. Prawda jest wieksza wolnosc technologiczna ale to nie jest az tak wazne. Z nowym projektem lepiej zaczac od monolitu a pozniej go podzielic.

0

Warto tez rozwazyc mesosa i marathon oraz Open Containers initiative. Ale mam slabe pojecie o tym.

Wie ktos jak najlatwiej wystartowac z mesosem? Jakies zrodla?

0

Używamy w pracy dokera na produkcji, jest całkiem spoko pod warunkiem spełnienia poniższych minimów:

  • żadnej bazy danych w dokerze
0
Pijany Bombowiec napisał(a):

Warto tez rozwazyc mesosa i marathon oraz Open Containers initiative. Ale mam slabe pojecie o tym.

Wie ktos jak najlatwiej wystartowac z mesosem? Jakies zrodla?

Uber używa mesosa. I z tego co kojarzę, dokera również.

Używamy w pracy dokera na produkcji, jest całkiem spoko pod warunkiem spełnienia kilku minimów

  • żadnej bazy danych w dokerze - niestety przekonaliśmy się o tym empirycznie :/
  • docker registry - może być własne ale bez tego to ani rusz
  • rewizja automatów do wykonywania testów i deplojmentu - trzeba wybadać jak łatwo można wpiąć dokera do infrastruktury
  • przeczytanie nistowej checklisty, <a href=https://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=589>przykład dla wersji 1.6</a>.

W zamian otrzymujesz możliwość łatwego replikowania środowiska - jedynym oprogramowaniem na serwerze powiązanym z aplikacją jest doker, niczego więcej nie powinieneś potrzebować. To ma znaczenie jeśli musisz przechodzić przez wiele etapów walidacji. W moim korpo apka musi przejść testy na trzech różnych środowiskach zanim trafi na produkcję, i teraz w przypadku awarii dużo mniej czasu traci się na przywrócenie środowiska do porządku jeśli jedynym softwarem jaki potrzebujesz jest SSH i doker. Minimalizujesz też ryzyko związane z jakimiś ukrytymi zależnościami (na środowiska A działało bo gdzieś w /etc zachował się stary moduł a na środowisku B już go nie i się wypieprza). Jeżeli masz tylko jedną preprodukcję i jedną produkcję to zastosowanie kontenerów wg. mnie wymaga dłuższego zastanowienia.

0

@several: Możesz napisać coś więcej o tych bazach danych? Moja firma właśnie wchodzi w dockera i mamy mieć bazę na nim (z tym że developerską). Dane powinny być na katalogu zewnętrznym, tak? http://severalnines.com/blog/mysql-docker-containers-understanding-basics

2
vpiotr napisał(a):

Dane powinny być na katalogu zewnętrznym, tak?

Dokładnie. Jeżeli potrzebujecie mieć bazę danych w dokerze to w konterze trzeba odpalić tylko proces, właściwych danych nie wciskajcie do kontenera tylko podmontujcie osobny wolumen z użyciem volume (albo czegoś analogicznego, nie wiem czy nie wprowadzili jakiegoś nowego wynalazku). Dodatkowo, jeśli baza jest skodzona w javie to zwróćcie uwagę na ustawienia sterty oraz przydzielonej pamięci dla kontenera - różne cyrki obserwowaliśmy aż w końcu daliśmy sobie spokój. Ale w internetach czytałem kilka szczęśliwych historii także da się, nam zabrakło cierpliwości albo kompetencji ;)

EDIT
volume polecam również zastosować do logów aplikacji.

0
Pijany Bombowiec napisał(a):

Aplikacja monolityczna jest duzo prostsza technicznie niz mikroserwisy.

Prostota zależy od skali, domeny i technologii, nie od typu architektury.

ACID nie istnieje. Systemy rozproszone sa trudne. Zapewnienie fail safe jest trudne. Orchestration i zarzadzanie zasobami, devops tez. Itp.

Hmm... Ok, chyba już rozumiem o co Ci chodzi... Tylko to, że rozbiliście sobie monolit na moduły i robicie międzymodułowe rozproszone transakcje biznesowe przez jakiś ESB i macie z tym problemy, to właśnie nie są mikroserwisy.

A w przypadku jednego teamu? Rozumiem, ze masz specow od kazdej technologii w tym teamie.

Tzn. u nas pracują programiści, nie paprotki, i jak się trzeba czegoś nauczyć, to się uczymy. No i nie mamy scruma, więc rozmiar teamu nie jest ograniczony do 6 devów i 3 scrum masterów.

A jak nie radzisz sobie z architektura monolitu... To architektura micro jest bardziej wymagajaca.

Tak, tak. :)

Jak juz mowilem wczesniej. Mikroserwisy glownie rozwiazuja problemy organizacyjne gdy np. Osobne teamy wchodza sobie w droge. Jest za duzy narzut na komunikacje.

Generalnie problemy komunikacyjne powodują różnice czasowe. Team w LA, team w Sydney, team u nas, no trudno zrobić jakiś monolityczny korpomeeting. :(
Jak trzeba zawołać jakiś serwis innego teamu, to po prostu się czyta na firmowej wiki. No, ale u fachofców od mikroserwisów to by za pewne było za proste. ;)

0

Czemu piszesz jak ignorant i pyszalek zamiast pisac normalnie? Bo merytoryczne to mocno nie jest. Tkwij sobie zatem w swojej zajebistosci.

Systemy rozproszone sa trudne i nie mozna tego bagatelizowac i o tym zapominac

0

Ostatni akapit co napisales to wlasnie przedstawienie, ze mikroserwisy to miedzy innymi lek na organizacje i komunikacje, pozwalajac teamom na prace zupelnie niezaleznie. Wiec o co Ci chodzi? Bo w zasadzie sie ze mna zgodziles jednoczesnie wyzywajac od 'fachfcow'...

0

Zdajesz się nie rozumieć, że ideą mikroserwisów jest to, że każdy może mieć swoją architekturę, i bagatelizujesz ten fakt ("wolność technologiczna nie jest aż taka ważna"). I owszem, monolityczne systemy rozproszone są trudne. Sensowne mikroserwisy rozwiązują sporo ich problemów. Mikroserwisy, a nie dzielenie monolitu na moduły.

Czy monolit jest prostszy? Na początku tak, potem wychodzą błędne pierwotne decyzje bez odwrotu, brak możliwości refaktoryzacji i wieczne hakowanie kodu ifami od przypadków brzegowych, finalnie prowadzące do kodu spaghetti. Widziałem już dziesiątki takich systemów.

No i trochę głupio to wygląda, gdy najpierw zarzucasz mi "nieradzenie sobie z monolitem", a potem zarzucasz, że "nie piszę normalnie". Ale przepraszam za tych "fachofców", poniosły mnie negatywne emocje związane ze wspomnieniami z czasów, gdy pisałem monolity.

0

Ja pisalem by zaczynac od monolitu. Pozniej mogac nakreslic wyrazne linie do pociecia mozna to podzielic na mniejsze czesci. Czasem i owszem pewne rzeczy moze byc widac od razu. Ale nie zawsze widac dobrze domeny. Ale jesli biznes nie jest zdecydowany dokladnie to co chce latwo skonczyc z rozproszonym monolitem.

A to by nie zaczynac od mikroservisow to rozumiem, ze rzucasz wyzwanie miedzy innymi slowom Martina Fowlera i wielu innym?

I nie. Nie zbudowalem nic co napisales. A brak ACID trzeba zaakceptowac. I ta uwaga o nie radzniu sobie z monolitem byla ogolna. Nie chcialem jej kierowac bezposrednio do Ciebie.

Wiele mikroserwisow wymaga przynajmniej czesci takich ficzerow :
http://blog-redhatdevelopers.rhcloud.com/wp-content/uploads/2016/12/screen-shot-2016-12-06-at-10-30-08.png

0

Poszedlbym w mikroserwisy na poczatku projektu jesli znalbym dobrze domeny, ludzie ze mna pracujacy rozumieliby dobrze idee mikro i mielibysmy kilka teamow.

Ja widzialem z kolei mkroserwisy bez discovery i bez dobrego zarzadzania konfigami oraz bez api gateway. A takze gdy niektore serwisy wyszly za duze. Sredniawka. Projekty Zaczynane jako mikro.

0
vpiotr napisał(a):

@several: Możesz napisać coś więcej o tych bazach danych? Moja firma właśnie wchodzi w dockera i mamy mieć bazę na nim (z tym że developerską). Dane powinny być na katalogu zewnętrznym, tak? http://severalnines.com/blog/mysql-docker-containers-understanding-basics

Tutaj jest napisane, ze to podmontowywanie volumes takie piekne nie jest
https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/

Mesos chyba nie musi uzywac dockera http://mesos.apache.org/documentation/latest/containerizer/

I jakos mam wrazenie, ze docker jest czesto uzywany dewelopersko. Ale produkcyjnie nie zawsze.

0
Pijany Bombowiec napisał(a):

Tutaj jest napisane, ze to podmontowywanie volumes takie piekne nie jest
https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/

Z własnego doświadczenia - podmontowywanie logów z użyciem volume nie sprawia żadnych problemów. Logi są rotowane ale katalog czasem rośnie do kilkunastu GB i nic złego się nie dzieje. Uber twierdzi, że używa cassandry w dokerze i podmontowanym dyskiem z danymi.

Pijany Bombowiec napisał(a):

Mesos chyba nie musi uzywac dockera http://mesos.apache.org/documentation/latest/containerizer/

Używając mesosa nie musisz używać żadnych kontenerów, to tylko jeden z jego ficzerów.

Pijany Bombowiec napisał(a):

I jakos mam wrazenie, ze docker jest czesto uzywany dewelopersko. Ale produkcyjnie nie zawsze.

Dewelopersko doker jest do bani, jako deweloper masz więcej roboty jeśli zamarzyło ci się użycie dokera. Jeżeli chcesz efektywnie debugować aplikację musi ona pozostać poza kontenerem co powoduje, że masz dodatkową ścieżkę budowania w projekcie. Dlatego wcześniej wspominałem o rewizji automatów deplojmentowych i testujących, wpięcie dokera do systemu trzeba dobrze przemyśleć. Znam zespół w moim korpo, który chcąc wpiąć dokera musiął praktycznie od zera przepisać swojego gradle'a i ansible'a. Nie każdy zespół może sobie pozwolić na luksus oddelegowania dwóch deweloperów na miesiąc by nie dostaraczali, żadnej wartości widzialnej dla klienta. Takie zmiany niemal na pewno dodadzą nowych bugów, które przez programistów są postrzegane jako najmniej seksowne do rozwiązywania.

Jeżeli doker ma dodać jakąś wartość, to na produkcji.

0

Dewelopersko to mi chodziło mi np. potrzebujesz do testów np. mysql / postgresa itp. to lokalnie na kompie docker jest wygodny w takiej sytuacji ;)

W sumie co innego też NoSQL a SQL w dockerze.

A masz jakieś doświadczenie z message brokerami w dockerze ?

0

Ja odniosłem wrażenie, że niektóre duże firmy często właśnie nie używają dockera a Mesos + brak kontenerów lub z OCI
http://mesos.apache.org/documentation/latest/powered-by-mesos/

0

Nie dotykałem niczego związanego z message brokerami w dockerze.

Pijany Bombowiec napisał(a):

Dewelopersko to mi chodziło mi np. potrzebujesz do testów np. mysql / postgresa itp. to lokalnie na kompie docker jest wygodny w takiej sytuacji ;)

Aa, tu masz rację. Zainstalowanie dokera i zaciągnięcie kontenera z zainstalowaną bazą jest całkiem proste i czyste ;) Łatwo się to potem czyści.

Pijany Bombowiec napisał(a):

Ja odniosłem wrażenie, że niektóre duże firmy często właśnie nie używają dockera a Mesos + brak kontenerów lub z OCI
http://mesos.apache.org/documentation/latest/powered-by-mesos/

Zależy co komu bardziej pasuje, google przerzucał swego czasu ogromne ilości dokerowych kontenerów, nie wiem jak to teraz wygląda gdy powstał Google Container Engine. Mesos to zupełnie inne podejście do separacji procesów i produkcji, podejścia te nie wykluczają siebie na wzajem. Moim subiektywnym zdaniem jakaś forma konteneryzacji będzie standardem w przyszłości, ale nie jestem przekonany czy to będzie doker. Doker w przyszłości będzie pewnie takim PHPem wśród kontenerów ;)

0

A no. Mimo wszystko bardzo ciekawe tematy ;)

http://thenewstack.io/oci-building-way-kubernetes-run-containers-without-docker/
https://www.opencontainers.org/
https://runc.io/

"Mesos uses containers for resource isolation between processes. In the context of Mesos, the two most important resource-isolation methods to know about are the control groups (cgroups) built into the Linux kernel, and Docker."

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