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
Odpowiedzi:
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.
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.
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.
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.
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.
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:
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.
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/
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.
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.
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 :)