Dlaczego deweloper powinien dbać o Docker?

11

Zasadniczo programista dba o spełnienie wymagań biznesowych. Może on / ona posiadać wiedzę specjalistyczną w zakresie konkretnego stosu lub struktury. Ale czy powinien postarać się nauczyć dokera i różnych metod wdrażania (rój, kube, mesos itp.)?

Mówiąc wprost, dlaczego deweloper powinien przejmować się dokerem?

PS: Nadrzędnym pytaniem do tego postu jest implikacja wprowadzenia dokera do zespołu programistów

docker project-management orchestration Abhay Pai
źródło

Odpowiedzi:

7

Prawdopodobnie nie odpowiedź, której szukasz, ale odpowiedź :)

Poznanie dokera i metod jego wdrażania może faktycznie zostać uwzględnione w wymaganiach biznesowych poprzez włączenie go do środowiska projektowego lub zespołu, podobnie jak język (i) kodu, system kontroli wersji, kompilatory, infrastruktura testowa itp. - do pracy w zespół lub projekt musi wiedzieć o nich wszystkich i z nich korzystać, nie może „przynieść własnego” (w większości przypadków).

Sprawy stają się nieco bardziej skomplikowane, jeśli przez „programistę” masz na myśli większość, a nawet cały zespół programistów. Przekazywanie narzędzia w środowisku programistycznym bez faktycznego wspierania go przez programistów będzie naprawdę trudne. Poświęć czas, aby najpierw stworzyć jednego z takich kibiców kierownictwa technicznego zespołu.

Uwaga dodatkowa: może nie być konieczne, aby każdy programista w zespole został ekspertem od dokerów. Z góry ustalone przepisy dotyczące użycia zawarte w prostych, gotowych do użycia kartach poleceń często pozwalają programistom korzystać z rozwiązań opartych na dokerach, nie wiedząc zbyt wiele o ich wewnętrznych działaniach, co może być dość akceptowalne, szczególnie w dużych zespołach. Podobnie jak możliwość dodawania kodu bez znajomości wszystkich szczegółów na temat budowy produktu końcowego.

Dan Cornilescu
źródło
Ponadto możesz korzystać z dowolnej technologii, co daje mniejsze ograniczenia i mniejszy ból głowy dla administratorów systemów w celu obsługi wszystkich różnych technologii. A ponieważ „dev” decyduje o technologii, konfiguracja środowiska dokera powinno zależeć od niego.
DarkMukke,
@DarkMukke „Dev” nie zawsze decyduje o technologii ... W większych zespołach deweloperów jest wręcz odwrotnie - „dev” po prostu korzysta z dowolnej technologii, z której korzysta zespół. Wyjątki mogą być tolerowane, jeśli nie zakłócają ani nie wpływają negatywnie na działania zespołu.
Dan Cornilescu,
Częściowo się zgadzam, ale widziałem, jak duże (ponad 200) firmy deweloperskie pracują z dokerem w sposób, który opisałem. Myślę, że jest to kwestia osobistych wyborów nie tylko zespołów programistów, ale także kadry zarządzającej ponad nimi. Jeśli istnieje przyzwoita liczba deweloperów, ilość dokera, której potrzebuje programista, jest zwykle trywialna.
DarkMukke,
6

Dam ci moją perspektywę. Deweloperzy powinni dbać o okno dokowane, ponieważ są inni programiści, którzy chętnie korzystają z okna dokowanego i mają już w tym wiedzę. Są gotowi podjąć się roli inżyniera DevOps wraz z byciem programistą. Więc część OpO w DevOps jest tym, na czym teraz buduje wiedzę specjalistyczną.

W dzisiejszych czasach będzie coraz więcej facetów, którzy mogą opracowywać, organizować, automatyzować testy, automatyzować zadania i budować narzędzia do monitorowania i przenoszenia tego kompletnego pakietu samodzielnie. To są ludzie, którzy pchają dokera i inne narzędzia wśród społeczności programistów.

Fala rynku zmierza także w kierunku wirtualizacji, automatycznego skalowania, automatyzacji, uczenia maszynowego i dokerów. Korzystanie z okna dokowanego stało się bardzo konieczne. Firmy są skłonne zapłacić 2x za jednego faceta, który bierze na siebie te wszystkie obowiązki, a gdy pojawi się popyt na takich facetów, zapasy również się zaczną. Jest to z punktu widzenia pracownika-pracodawcy.

Technicznie w organizacjach, w których pracowałem, istnieją osobne zespoły programistów i DevOps, chociaż ściśle współpracują w zakresie dostaw. Inżynierowie i programiści DevOps dzielą tutaj ogromną większość zestawów umiejętności, dlatego czasami dochodzi do negocjacji obowiązków.

Absolutne minimum, które może zrobić programista, to udostępnianie swoich plików binarnych, ale musi zrozumieć, że pliki binarne będą używane do uruchamiania w kontenerze dokera, a do tego musi zrozumieć, jak działa doker. W przypadku kubów, rojów, mesów itp. Deweloper może nawet nie dbać o to, co jest używane, ale deweloper powinien dobrze zrozumieć podstawy dokera, a od samego początku powinien być nastawiony na zbudowanie aplikacji luźno powiązanej do ponownego użycia jako mikrousługi. Jeśli aplikacja jest zbudowana na podstawie tego sposobu myślenia (który wymaga podstaw dokera), inżynierowie DevOps mogą wziąć ją stąd do automatycznego skalowania, koordynowania, testowania, wdrażania i monitorowania.

Ponadto w większości przypadków nie ma jednego rozmiaru pasującego do wszystkiego. Deweloper nie wie wyraźnie, jak zbudować aplikację przyjazną dla dokerów, a inżynier DevOps całkiem słusznie nie zna wewnętrznych elementów procesu tworzenia aplikacji. Dlatego w większości przypadków organizacje wolą oddać oba te zadania temu samemu facetowi, aby przyspieszyć. Jeśli istnieją osobne rzeczy, wymagany jest mechanizm ciągłego sprzężenia zwrotnego od zespołu DevOps do zespołu deweloperów, aby uczynić aplikacje bardziej futurystycznymi i gotowymi na dokowanie / chmurę / skalowanie.

lakshayk
źródło
5

Nie chodzi o Docker ani inne technologie konteneryzacji.

Kontenery takie jak Docker, rkt itp. To tylko sposób na dostarczenie aplikacji w podobny sposób jak statyczny plik binarny. Budujesz swoje wdrożenie, które zawiera wszystko, czego potrzebuje w środku, a użytkownik końcowy nie potrzebuje niczego więcej niż środowiska wykonawczego.

Te rozwiązania są podobne do grubych plików JAR w Javie, gdzie wszystko, czego potrzebujesz (teoretycznie), to po prostu preinstalowane środowisko uruchomieniowe (JRE) i wszystko, co Just Works ™.

Powodem, dla którego programiści muszą zrozumieć (nie muszą nauczyć się obsługi takiego narzędzia, tylko dlatego, że jest to potrzebne) narzędzia do aranżacji, jest to, że pozwala to mieć pewne zalety w porównaniu z „tradycyjnym” wdrożeniem.

Bydło, nie zwierzęta domowe

EngineYard napisał na ten temat dobry artykuł. Chodzi o to, że kiedy twój serwer umiera, to wzruszasz ramionami i czekasz, aż pojawi się nowy. Traktujesz je jak bydło, masz dziesiątki, setki, tysiące z nich biegających, a kiedy jeden padnie, ani ty, ani twoi klienci nie powinniście być tego świadomi.

Narzędzia do aranżacji osiągają to poprzez monitorowanie statusu wszystkich aplikacji (zbiorników / zadań, cokolwiek) w klastrze, a gdy zobaczy, że jeden z serwerów przestaje odpowiadać (przestaje działać), automatycznie przenosi wszystkie aplikacje działające na tym serwerze w inne miejsce.

Lepsze wykorzystanie zasobów

Dzięki aranżacji możesz uruchamiać wiele aplikacji na jednym serwerze, a orkiestrator będzie śledził Twoje zasoby. W razie potrzeby zmieni układ aplikacji.

Niezmienna infrastruktura

Dzięki automatycznej obsłudze przełączania awaryjnego w orkiestratorach możesz uruchamiać własne obrazy w chmurze bez zmian. Kiedy będziesz potrzebować aktualizacji, po prostu zbuduj nowy obraz, ustaw konfigurację uruchamiania, aby używała tego teraz i po prostu rzuć. Wszystko zostanie załatwione za Ciebie:

  1. Utwórz nowy serwer z nową konfiguracją.
  2. Zabij jeden działający serwer.
  3. Twój orkiestrator przeniesie wszystko na inne maszyny (w tym nowe).
  4. Jeśli pozostały jakieś stare serwery, przejdź do 1.

Prostsze operacje

  • Niewystarczające zasoby? Dodaj nową maszynę do klastra.
  • Potrzebujesz więcej instancji aplikacji? Zwiększ liczbę i idź dalej.
  • Monitorowanie? Gotowe.
  • Zarządzanie logami? Gotowe.
  • Tajniki? Zgadnij co.

TL; DR Cały punkt nie dotyczy Dockera, ale orkiestracji. Docker jest tylko rozszerzoną wersją plików JAR tarball / fat, która jest wymagana do prawidłowej aranżacji.

Hauleth
źródło
Teraz o to pytam i o to chodzi w całym pytaniu. Czy programiści powinni dbać o lepsze wykorzystanie zasobów, niezmienną infrastrukturę i prostsze operacje? ... Uważam, że powinni skupić się na dostarczaniu wymagań biznesowych i optymalizacji kodu, które doprowadziłyby do lepszego wykorzystania zasobów. Nawet doker nie pomoże w lepszym wykorzystaniu, jeśli jest to źle / średnio napisany kod. Zaakceptujmy fakt, że wymagania biznesowe sprawiają, że deweloperzy dostarczają rzeczy szybciej. Dzięki temu nie mają czasu na optymalizację kodu. Po co dodawać na nich odpowiedzialność dokerów?
Abhay Pai,
Chodzi o to, że przegląd całego stosu, od testów, przez implementację, aż po wdrożenie, pozwoli ci zobaczyć, w jaki sposób używane jest twoje oprogramowanie, jakie są skrajne przypadki, co ulega awarii. Spowolni cię w LOC, które piszesz, ale znacznie poprawi ich jakość. W dłuższej perspektywie oszczędność czasu
Moritz
4

Oto na przykład niektóre argumenty z posta na blogu opublikowanego w 2014 r. I zatytułowanego w sposób dość pasujący do Twojej odpowiedzi:

  • Znacznie bardziej elastyczny zastrzyk nowych technologii do środowiska
  • nadal istnieje ogromny problem między zatwierdzeniem końcowego przetestowanego kodu a uruchomieniem go na końcowych serwerach produkcyjnych. Docker znacznie upraszcza ten ostatni krok
  • Docker sprawia, że ​​utrzymanie starszego systemu operacyjnego jest proste, bez względu na to, jaki smak ma Linux

Od: https://thenewstack.io/why-you-should-care-about-docker/

Peter Muryshkin
źródło
Zgadzam się na zastrzyk nowych technologii. Ale są też z tym pewne problemy. Jak korzystanie z dokera do baz danych ( percona.com/blog/2016/11/16/is-docker-for-your-database ). Obecnie nie są stabilne i prawdopodobnie będą stabilne w przyszłości. Miejmy nadzieję na najlepsze. W każdym razie możemy osiągnąć wypchnięcie przetestowanego kodu do produkcji przy użyciu CI / CD. Dlaczego więc doker? Programiści nie dbają o system operacyjny, na którym działamy. Dlaczego w ogóle mieliby zawracać sobie głowę nauką dokera? Aby ułatwić życie devom?
Abhay Pai,
w pierwszej kolejności myślę o następującym scenariuszu „MVP”: dev wypróbowuje nową konfigurację / narzędzie dla środowiska jako komponentu infrastruktury, powiedzmy imagemagick. Bez Dockera informacje te mogą zostać zgubione lub zapomniane lub wymagać komunikacji wraz z wieloma innymi drobiazgami. Udostępnianie pliku Docker to konfigurowalna działająca rzecz, którą można sprawdzić na maszynie, a nawet użycie jej do stworzenia konfiguracji bez infrastruktury Docker jest cenniejsze niż tylko dokumentacja. Pewnie, że możesz też wybrać Puppet; miłą rzeczą w Docker jest to, że IMHO pozwala na samodzielne scenariusze.
Peter Muryshkin
Zgoda. Ale problem pojawia się podczas aranżacji. Deweloper musi posiadać wiedzę specjalistyczną w zakresie dokowania, aby stosować się do najlepszych praktyk i spełniać wymagania biznesowe. Zastanów się nad scenariuszem, w którym programista potrzebuje imagemagick jako usługi. Teraz podczas budowania pliku dokera uzyskuje pełną kontrolę nad pakietami, które może zainstalować na obrazie dokera. Co jeśli zainstalują sshd do ssh w oknie dokowanym zamiast za pomocą dzienników dokowanych? Co jeśli zainstalują narzędzia, które nie mają nic wspólnego z logiką biznesową, ale zagrażają bezpieczeństwu? Czy deweloperzy potrzebują wiedzy dokera?
Abhay Pai
hm, ale co jeśli wdrożą backdoor oparty na gniazdach? doker nie zastępuje zapory ogniowej
Enteprise,
Prawdziwe. W każdym razie byłby to złośliwy zamiar dewelopera. Czy to doker, czy nie. Ale gdy doktor zostaje wprowadzony do deweloperów, mogą powodować wpadki tylko dlatego, że nie mają odpowiedniej wiedzy. Dlaczego mieliby nawet zadawać sobie trud, aby nauczyć się dokera (biorąc pod uwagę, że orkiestrator zwiększy również jego złożoność), skoro może to powodować nieszczęścia i komplikacje? Proszę, nie przejmuj się moimi pytaniami. Nawet ja kocham dokera. Ale staram się zrozumieć perspektywę programisty. Sam byłem programistą przez ostatnie 3 lata, a teraz jestem inżynierem DevOps.
Abhay Pai
4

Jeśli prowadzisz produkcję w kontenerze dokowanym, bardzo ważne jest, aby ten kontener był tworzony przez tych samych programistów, którzy zbudowali działającą na nich aplikację. Kto jeszcze jest lepszym miejscem, aby dowiedzieć się, jakie zależności zewnętrzne są potrzebne i tak dalej ...?

Potok może się również nie powieść na dowolnym etapie CD, szczególnie gdy jest to etap kompilacji obrazu dokera, czasem brakuje pliku lub potrzebna jest biblioteka lib.

W pracy zapoznaliśmy wszystkich programistów z dokerem, wyjaśniając im podstawy budowania pliku dokera w celu obsługi aplikacji, a także ułatwiliśmy proces tworzenia potoku, dzięki czemu można tylko dodać nazwę i plik dokera, a jego aplikacja zostanie automatycznie zbudowana na następny push niezależnie od technologii, która go obsługuje.

Szybki start Dockera jest naprawdę świetnym wprowadzeniem do tego, po tym, jak zespół devOps prowadzi dewelopera w wyborze dystrybucji (wiele z nich nie wie takich rzeczy alpine).

Naszym zadaniem jest zapewnienie im łatwego dostępu do narzędzi. Robią resztę, aby naprawić to, gdy coś jest nie tak. Docker jest naprawdę częścią procesu rozwoju, a zespół devOps zapewnia obrazy dokerów, które odpowiadają naszym potrzebom i są wystarczająco łatwe, więc stworzenie nowej aplikacji i wdrożenie jej bez pomocy zajmuje tylko kilka minut.

Juub
źródło
Więc według deweloperów użycie dokera w projekcie powinno zostać podjęte tylko wtedy, gdy projekt wymaga zewnętrznej zależności? Myślę, że docker stał się częścią naszego procesu rozwoju, ponieważ narzuciliśmy go deweloperom lub dlatego, że uważamy to za fajne. Problem pojawia się również podczas aranżacji. Czy muszą uczyć się orkiestratora jak rój, kubernetes lub mesos? Realizacja wszystkich tych aranżacji jest inna. Co się stanie, jeśli nastąpi awaria orkiestracji z powodu złej implementacji? Kogo winić? PS: Nie przejmuj się moimi pytaniami. Po prostu gram adwokata Devli. Ja też uwielbiam dokera :)
Abhay Pai
2

Docker dostaje wiele wzmianek w prasie i blogu, co prowadzi do zainteresowania deweloperów korzystaniem z niego. Dla niektórych osób chodzi o zabawę z nową technologią lub zrozumienie, jak to działa. Dla innych jest chęć dodania słów kluczowych do ich CV. Tak czy inaczej, im więcej programistów wie o tym, jak działają rzeczy i jak się je wdraża, tym mniej będą zaskoczeni. Z tego, co widziałem, istnieje spore zainteresowanie wcześniejszym zainteresowaniem, więc zachęcanie do dalszego działania nie powinno być trudne.

pisklęta
źródło
0

Cóż, jeśli kiedykolwiek używałeś maszyn wirtualnych do testowania, możesz spróbować użyć kontenerów, a dokerowanie jest w rzeczywistości świetnym narzędziem do testowania i jest znacznie prostsze w użyciu zamiast LXC :)

YV
źródło
Zgoda. Nie jestem przeciwny używaniu dokera lub różnych narzędzi do aranżacji. Też ich kocham. To, co próbuję zrozumieć, jest proste. Kto jest właścicielem konteneryzacji aplikacji. Devs? Lub DevOps? Lub obie ? Jeśli oba, to ile każdy z nich powinien wnieść? Kiedy coś się nie powiedzie z powodu dokera lub organizacji dokera, kto powinien zostać pociągnięty do odpowiedzialności? Wydajność kodu a pomaganie programistom w ułatwianiu ich życia. Moje pytanie dotyczy raczej roli jednostki niż samej technologii.
Abhay Pai,