docker - realne zastosowanie

Odpowiedz Nowy wątek
2019-01-07 17:04
0

Na wstępie napiszę - tak szukałem i czytałem w sieci artykuły, ale dalej nie rozumiem do czego Docker może być przydatny jak mamy aplikację napisaną, np. w ASP. NET MVC, która musi stać na windowsie.
W artykułach były opisane aplikacje napisane w php, gdzie trzeba zainstalować apache, mysql itd. - to na Dockerze to można zainstalować to to rozumiem. A aplikacja ASP.NET MVC?

Pozostało 580 znaków

2019-01-11 11:16
Bambaryła
0

Mandrivą 10.

Płakałem...

Pozostało 580 znaków

2019-01-11 11:34
2
somekind napisał(a):

Ile by to trwało z dockerem? Stawiam, że jakieś dwa tygodnie. Bo to byłby specjalny, zaprojektowany przez najlepszych korporacyjnych architektów docker, który działa tylko na maszynach VMWare z zainstalowaną Mandrivą 10, pod warunkiem, że serwer fizyczny ma dostępną stację dyskietek 5,25" oraz na stałe zwarte styki 2 i 6 w porcie COM2.

Żadne z tych wymagań nie jest podyktowane Dockerem - jeśli ktoś zaprojektował aplikację w taki sposób, że przed odpaleniem trzeba recytować na stojąco Tuwima, no to sry - Docker niewiele pomoże.

Warto jednak zauważyć, że - o ile nie jest stosowany bezmyślnie - też nie zaszkodzi, a przynajmniej nie w taki przerysowany sposób, w jaki to próbujesz zobrazować.

Ideologicznie do wystartowania projektu od zera powinno wystarczyć ustawienie kluczy SSH, docker-compose up / lxc launch i wsio; fakt, że ktoś może źle zaprojektować kontener nie ma nic wspólnego z samą technologią, ponieważ równie dobrze ta sama osoba może np. źle przygotować migracje bazy danych i odpalenie od zera Postgresa będzie wymagało przebrnięcia przez dziesięć skryptów bashowych, trzy batche, odpalenie czegoś przez Wine i pobranie połowicznego dumpa danych z produkcji ("no bo jakoś tak wyszło, że mamy rozjazd między migracjami a produkcją - ja tam się nie do końca na tym znam").

Nie przedstawiłeś IMO nic sensownego w kontekście samego Dockera - ot: źle stosowane technologie są źle stosowane i tyle.

A nie można po prostu wysyłać requestów do jakiegoś backendu na środowisku testowym?

I tak, i nie - jeśli pracujesz razem z frontendowcem nad nowym zadaniem i nie chcesz aby wysyłał żądania na Twój komputer (ponieważ co chwilę zmieniasz kod), kontenery są stosunkowo prostym rozwiązaniem. Instalujesz taki kontener u frontendowca, robisz checkouta na ostatnim stabilnym commicie ze wspólnego brancha i niech sobie robi co dusza zapragnie.


edytowany 3x, ostatnio: Patryk27, 2019-01-11 11:35

Pozostało 580 znaków

2019-01-11 11:44
0
Patryk27 napisał(a):

Żadne z tych wymagań nie jest podyktowane Dockerem - jeśli ktoś zaprojektował aplikację w taki sposób, że przed odpaleniem trzeba recytować na stojąco Tuwima, no to sry - Docker niewiele pomoże.

Warto jednak zauważyć, że - o ile nie jest stosowany bezmyślnie - też nie zaszkodzi, a przynajmniej nie w taki przerysowany sposób, w jaki to próbujesz zobrazować.

Ja nie pisałem, że docker zaszkodzi ani, że ma takie wymagania. Ja pisałem, że jeśli ktoś dopuścił do wielogodzinnego i skomplikowanego stawiania środowiska bez dockera, to czemu miałby nie dopuścić do tego z dockerem? Jak ktoś jest brudasem, to przeprowadzka z chlewu do pałacu nie pomoże. Jeśli ktoś jest bezmyślny, to dockera też będzie używał bezmyślnie.

Ideologicznie do wystartowania projektu od zera powinno wystarczyć ustawienie kluczy SSH, docker-compose up / lxc launch i wsio; fakt, że ktoś może źle zaprojektować kontener nie ma nic wspólnego z samą technologią, ponieważ równie dobrze ta sama osoba może np. źle przygotować migracje bazy danych i odpalenie od zera Postgresa będzie wymagało przebrnięcia przez dziesięć skryptów bashowych, trzy batche, odpalenie czegoś przez Wine i pobranie połowicznego dumpa danych z produkcji ("no bo jakoś tak wyszło, że mamy rozjazd między migracjami a produkcją - ja tam się nie do końca na tym znam").

Dokładnie o to mi chodzi!

Nie przedstawiłeś IMO nic sensownego w kontekście samego Dockera - ot: źle stosowane technologie są źle stosowane i tyle.

Ale ja nie miałem zamiaru argumentować przeciwko dockerowi, tylko przeciwko takiemu hurraoptymistycznemu podejściu, jakoby on sam magicznie coś sprawiał, i był jedynym rozwiązaniem dla długiej konfiguracji środowiska pracy.

I tak, i nie - jeśli pracujesz razem z frontendowcem nad nowym zadaniem i nie chcesz aby wysyłał żądania na Twój komputer (ponieważ co chwilę zmieniasz kod), kontenery są stosunkowo prostym rozwiązaniem. Instalujesz taki kontener u frontendowca, robisz checkouta na ostatnim stabilnym commicie ze wspólnego brancha i niech sobie robi co dusza zapragnie.

No na pewno bym nie chciał, żeby wysyłał na mój komputer, dlatego właśnie stabilna wersja backendu powinna być na serwerze testowym.


"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

2019-01-11 11:47
0

Ale ja nie miałem zamiaru argumentować przeciwko dockerowi, tylko przeciwko takiemu hurraoptymistycznemu podejściu, jakoby on sam magicznie coś sprawiał, i był jedynym rozwiązaniem dla długiej konfiguracji środowiska pracy.

Ano ok, w takim razie nie zrozumiałem intencji ;-)

No na pewno bym nie chciał, żeby wysyłał na mój komputer, dlatego właśnie stabilna wersja backendu powinna być na serwerze testowym.

Co w sytuacji, gdy jednocześnie masz kilka osobnnych zadań w drodze (zarówno frontendowych, jak i backendowych, jak i frontendowo-backendowych)?
Do którego brancha powinni bić frontendowcy pracujący w parze z backendowcami nad nowymi zadaniami?


Pozostało 580 znaków

2019-01-11 14:01
3
Patryk27 napisał(a):

Co w sytuacji, gdy jednocześnie masz kilka osobnnych zadań w drodze (zarówno frontendowych, jak i backendowych, jak i frontendowo-backendowych)?

Ale co to jest zadanie frontendowo-backendowe? Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić. Potrzebne są dwa zadania. Najpierw robimy backend, testujemy go, potem frontendowcy mogą się zająć swoją robotą współpracując ze stabilnym backendem na serwerze testowym.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić Jak w innym temacie napisałem ci mniej więcej to samo, to się pytałeś na który bootcampie tak mówią.... - sss 2019-01-16 07:55
Jak widać oprócz erystycznych sztuczek oraz manipulacji zbyt wiele nie potrafisz. - sss 2019-01-16 07:56

Pozostało 580 znaków

2019-01-11 18:52
1

Najpierw robimy backend, testujemy go, potem frontendowcy mogą się zająć swoją robotą współpracując ze stabilnym backendem na serwerze testowym.

W idealnym świecie może i tak. W rzeczywistości często można spotkać się z sytuacją, którą można by krótko opisać: Daj mi cokolwiek, co mniej więcej działa, żebym mógł zacząć prace nad moją częścią. Powodem może być deadline, ale też np. sytuacja, w której frontendowiec nie ma nic innego do roboty i już chciałby ruszać właśnie z tym.

Pozostało 580 znaków

2019-01-11 18:57
1

To by znaczyło, że frontend jest obrobiony z taskami przed backendem, co jest mało możliwe.
Ale jak tak bardzo chce pracować, to ja nie bardzo rozumiem w czym problem. Niech sobie frontend jakieś fejkowe dane zahardcoduje po prostu.


"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

2019-01-12 17:11
2

Ja lubię w dockerze dwie rzeczy: izolację i odtwarzalność.
Izolacja jest spoko, mogę mieć w każdym kontenerze zupełnie inne środowisko i ciągle mogę to odpalić na jednym i tym samym systemie, nie muszę przejmować się niekompatybilnymi wersjami i zależnościami, a ni tym, że aktualizując paczkę dla aplikacji A zepsuję aplikację B.

Odtwarzalność jest świetna, bo mogę bez obaw grzebać w konfiguracjach, paczkach, ustawieniach, wersjach, a jak coś zepsuję, to cofam zmiany gitem i po problemie. To dotyczy też wszystkich zależności i aplikacji dookoła. Ponadto przy wdrażaniu na różne środowiska wiem, że mam ten sam stan, niezależnie od hosta.

somekind napisał(a):

To by znaczyło, że frontend jest obrobiony z taskami przed backendem, co jest mało możliwe.
Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić.

Macie jakąś dziwną organizację, frontend spokojnie może pracować bez backendu.

Pozostało 580 znaków

2019-01-12 17:16
0
Afish napisał(a):

Macie jakąś dziwną organizację, frontend spokojnie może pracować bez backendu.

I czyta dane z bazy, wysyła przelewy do banków, a klientom towar bezpośrednio?
To taki frontend chyba też jest backendem.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Np. na Reakc'ie Możesz sobie zrobić "Fake Backend". Teoretyk pewnie o tym nie wie. - sss 2019-01-16 08:04

Pozostało 580 znaków

2019-01-12 17:18
0

Nie, frontend robi to, co do niego należy, a robotę backendową zostawia backendowi.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Googlebot