Czy Docker jest zabawką, czy nie? A może to nadal prawda?

Witam wszystkich!

Bardzo chcę od razu przejść do tematu, ale bardziej poprawne byłoby opowiedzenie trochę o mojej historii:

Wejście

Jestem programistą z doświadczeniem w tworzeniu aplikacji frontendowych typu single page, scala/java i nodejs na serwerze.

Przez dość długi czas (na pewno kilka, trzy lata) byłem zdania, że ​​Docker to manna z nieba i ogólnie bardzo fajne narzędzie i absolutnie każdy programista powinien móc z niego korzystać. A z tego wynika, że ​​każdy programista powinien mieć zainstalowanego Dockera na swojej lokalnej maszynie. A co z moim zdaniem, przejrzyj oferty pracy, które są opublikowane na tym samym hh. Co drugi zawiera wzmiankę o dokerze, a jeśli go posiadasz, będzie to Twoja przewaga konkurencyjna 😉

Na swojej drodze spotkałem wiele osób o różnym podejściu do Dockera i jego ekosystemu. Niektórzy twierdzili, że jest to wygodna rzecz, która gwarantuje funkcjonalność na wielu platformach. Ci drudzy nie rozumieli po co mają biegać w kontenerach i jaki będzie z tego zysk, trzeci zupełnie się tym nie przejmował i nie zawracał sobie głowy (po prostu napisali kod i poszli do domu - zazdroszczę im, po sposób :)

Powody użycia

Dlaczego użyłem okna dokowanego? Prawdopodobnie z następujących powodów:

• uruchomienie bazy danych, 99% aplikacji z nich korzysta
• uruchomienie Nginx do dystrybucji frontendu i proxy do backendu
• możesz spakować aplikację w obraz dokujący, w ten sposób moja aplikacja będzie działać wszędzie tam, gdzie istnieje doker, problem z dystrybucją zostanie natychmiast rozwiązany
• odkrywanie usług od razu po wyjęciu z pudełka, możesz tworzyć mikrousługi, każdy kontener (podłączony do wspólnej sieci) może łatwo połączyć się z innym poprzez alias, bardzo wygodne
• Fajnie jest stworzyć kontener i „bawić się” w nim.

Czego zawsze NIE lubię w oknie dokowanym:

• Aby moja aplikacja działała potrzebuję samego Dockera na serwerze. Po co mi to, jeśli moje aplikacje działają w środowisku jre lub nodejs, a środowisko dla nich znajduje się już na serwerze?
• jeśli chcę uruchomić mój (prywatny) lokalnie zbudowany obraz na zdalnym serwerze, potrzebuję własnego repozytorium dokerów, potrzebuję rejestru, aby gdzieś działał, a także muszę skonfigurować https, ponieważ docker cli działa tylko przez https. O cholera... istnieją oczywiście opcje zapisania obrazu lokalnie poprzez docker save i po prostu wyślij obraz przez scp... Ale to dużo ruchów ciała. Poza tym wygląda to na rozwiązanie „podstawowe”, dopóki nie pojawi się własne repozytorium
• docker-compose. Jest potrzebny jedynie do obsługi kontenerów. To wszystko. Nie może zrobić nic innego. Docker-compose ma kilka wersji swoich plików, własną składnię. Bez względu na to, jak bardzo jest to deklaratywne, nie chcę czytać ich dokumentacji. Nie będzie mi to potrzebne nigdzie indziej.
• pracując w zespole, większość ludzi pisze plik Dockerfile bardzo krzywo, nie rozumie, w jaki sposób jest on buforowany, dodaje do obrazu wszystko, czego potrzebuje i czego nie potrzebuje, dziedziczy z obrazów, których nie ma w Dockerhub lub prywatnym repozytorium, tworzy niektóre docker-compose pliki z bazami danych i nic nie zostaje. Jednocześnie programiści z dumą deklarują, że Docker jest fajny, wszystko u nich lokalnie działa, a HR co ważne pisze w ogłoszeniu: „Używamy Dockera i potrzebujemy kandydata z takim doświadczeniem zawodowym”.
• Ciągle prześladują mnie myśli o podniesieniu wszystkiego w Dockerze: postgresql, kafka, redis. Szkoda, że ​​nie wszystko działa w kontenerach, nie wszystko jest łatwe w konfiguracji i uruchomieniu. Jest to obsługiwane przez zewnętrznych programistów, a nie przez samych dostawców. A swoją drogą od razu pojawia się pytanie: dostawcy nie martwią się utrzymaniem swoich produktów w Dockerze, dlaczego tak się dzieje, może oni coś wiedzą?
• Zawsze pojawia się pytanie o trwałość danych kontenera. i wtedy myślisz, czy powinienem po prostu zamontować katalog hosta, utworzyć wolumin dokowany lub utworzyć kontener danych, który jest teraz deprecated? Jeśli zamontuję katalog, muszę się upewnić, że identyfikator uid i gid użytkownika w kontenerze są zgodne z identyfikatorem użytkownika, który uruchomił kontener, w przeciwnym razie pliki utworzone przez kontener zostaną utworzone z prawami roota. Jeśli użyję volume wtedy dane zostaną po prostu utworzone w niektórych /usr/* i będzie taka sama historia z uid i gid jak w pierwszym przypadku. Jeśli uruchamiasz komponent innej firmy, musisz zapoznać się z dokumentacją i poszukać odpowiedzi na pytanie: „w jakich katalogach kontenerów komponent zapisuje pliki?”

Zawsze nie podobało mi się to, że musiałem zbyt długo majstrować przy Dockerze na początkowym etapie: Wymyśliłem, jak uruchamiać kontenery, z jakich obrazów uruchamiać, stworzyłem pliki Makefile zawierające aliasy do długich poleceń Dockera. Nienawidziłem tworzenia dokerów, ponieważ nie chciałem uczyć się innego narzędzia w ekosystemie dokerów. I docker-compose up Martwiło mnie to, zwłaszcza, że ​​nadal się tam spotykali build konstrukcje, a nie już zmontowane obrazy. Jedyne, czego naprawdę chciałem, to po prostu stworzyć produkt sprawnie i szybko. Ale nie mogłem wymyślić, jak używać okna dokowanego.

Przedstawiamy Ansible

Niedawno (trzy miesiące temu) współpracowałem z zespołem DevOps, którego prawie każdy członek był negatywnie nastawiony do Dockera. Z powodów:

• docker rządzi iptables (chociaż możesz to wyłączyć w daemon.json)
• okno dokowane zawiera błędy i nie będziemy go uruchamiać w środowisku produkcyjnym
• jeśli demon dokera ulegnie awarii, wówczas wszystkie kontenery z infrastrukturą odpowiednio ulegną awarii
• nie ma potrzeby korzystania z okna dokowanego
• po co doker, skoro jest Ansible i maszyny wirtualne

W tej samej pracy zapoznałem się z innym narzędziem - Ansible. Kiedyś o tym słyszałem, ale nie próbowałem pisać własnych podręczników. A teraz zacząłem pisać swoje zadania i wtedy moja wizja całkowicie się zmieniła! Ponieważ zdałem sobie sprawę: Ansible ma moduły do ​​uruchamiania tych samych kontenerów dokowanych, budowania obrazów, sieci itp., A kontenery można uruchamiać nie tylko lokalnie, ale także na zdalnych serwerach! Moja radość nie znała granic - znalazłem NORMALNE narzędzie i wyrzuciłem pliki Makefile i pliki docker-compose, zastąpiono je zadaniami yaml. Kod został zredukowany poprzez użycie konstrukcji takich jak loop, when, itp.

Docker do uruchamiania komponentów innych firm, takich jak bazy danych

Niedawno zapoznałem się z tunelami ssh. Okazało się, że bardzo łatwo jest „przekierować” port zdalnego serwera na port lokalny. Serwerem zdalnym może być maszyna w chmurze lub maszyna wirtualna działająca w VirtualBox. Jeśli mój kolega lub ja potrzebujemy bazy danych (lub innego komponentu strony trzeciej), możemy po prostu uruchomić serwer z tym komponentem i wyłączyć go, gdy serwer nie będzie potrzebny. Przekierowanie portów daje taki sam efekt jak baza danych działająca w kontenerze dokowanym.

To polecenie przekazuje mój port lokalny do zdalnego serwera z uruchomionym postgresql:

ssh -L 9000:localhost:5432 [email chroniony]

Korzystanie ze zdalnego serwera rozwiązuje problem rozwoju zespołu. Z takiego serwera może korzystać kilku programistów jednocześnie, nie muszą oni umieć konfigurować postgresql, rozumieć Dockera i innych zawiłości. Na zdalnym serwerze możesz zainstalować tę samą bazę danych w samym Dockerze, jeśli trudno jest zainstalować konkretną wersję. Wszystko, czego potrzebują programiści, to zapewnienie dostępu przez SSH!

Niedawno przeczytałem, że tunele SSH stanowią ograniczoną funkcjonalność zwykłej sieci VPN! Możesz po prostu zainstalować OpenVPN lub inne implementacje VPN, skonfigurować infrastrukturę i przekazać ją programistom do użytku. To jest takie fajne!

Na szczęście AWS, GoogleCloud i inne dają Ci rok darmowego użytkowania, więc korzystaj z nich! Są tanie, jeśli je wyłączysz, gdy nie są używane. Zawsze zastanawiałem się, dlaczego miałbym potrzebować zdalnego serwera, takiego jak gcloud, wygląda na to, że je znalazłem.

Jako lokalna maszyna wirtualna możesz wykorzystać tę samą Alpine, która jest aktywnie wykorzystywana w kontenerach dokowanych. Cóż, lub inne lekkie dystrybucje, aby komputer uruchamiał się szybciej.

Konkluzja: możesz i powinieneś uruchamiać bazy danych i inne elementy infrastruktury na zdalnych serwerach lub w wirtualnej skrzynce. Do tych celów nie potrzebuję okna dokowanego.

Trochę o obrazach doków i dystrybucji

już napisałem статью w którym chciałem przekazać, że używanie obrazów dokowanych nie daje żadnej gwarancji. Obrazy Dockera są potrzebne tylko do utworzenia kontenera Dockera. Jeśli dokonujesz aktualizacji do obrazu dokowanego, oznacza to, że dokonujesz aktualizacji w celu korzystania z kontenerów dokowanych i będziesz używać tylko ich.

Czy widziałeś gdziekolwiek, gdzie twórcy oprogramowania przenoszą swoje produkty tylko w obrazie okna dokowanego?
Wynikiem większości produktów są pliki binarne dla konkretnej platformy; są one po prostu dodawane do obrazu okna dokowanego, który jest dziedziczony z żądanej platformy. Czy zastanawiałeś się kiedyś, dlaczego w serwisie dockerhub znajduje się tak wiele podobnych obrazów? Wpisz na przykład nginx, zobaczysz 100500 XNUMX zdjęć różnych osób. Ci ludzie nie opracowali samego nginx, po prostu dodali oficjalny nginx do swojego obrazu dokera i doprawili go własnymi konfiguracjami dla wygody uruchamiania kontenerów.

Ogólnie rzecz biorąc, możesz po prostu przechowywać go w tgz, jeśli ktoś potrzebuje uruchomić go w oknie dokowanym, to pozwolić mu dodać tgz do pliku Dockerfile, dziedziczyć z żądanego środowiska i utworzyć dodatkowe bułki, które nie zmieniają samej aplikacji w tgz. Każdy, kto będzie tworzył obraz dokera, będzie wiedział, czym jest tgz i czego potrzebuje do pracy. W ten sposób używam dockera tutaj

Konkluzja: nie potrzebuję rejestru dokerów, użyję jakiegoś S3 lub po prostu przechowywania plików, takiego jak Dysk Google/dropbox

Docker w CI

Wszystkie firmy, w których pracowałem, są podobne. Zwykle są spożywcze. Oznacza to, że mają jedną aplikację, jeden stos technologii (no, może kilka lub trzy języki programowania).

Firmy te używają dokera na swoich serwerach, na których działa proces CI. Pytanie: Dlaczego musisz budować projekty w kontenerze dokowanym na swoich serwerach? Dlaczego po prostu nie przygotować środowiska do kompilacji, np. napisać playbook Ansible, który zainstaluje niezbędne wersje nodejs, php, jdk, skopiuje klucze ssh itp. na serwer, na którym będzie odbywać się kompilacja?

Teraz rozumiem, że to strzelanie sobie w stopę, bo docker na swojej izolacji nie przynosi żadnych zysków. Problemy, które napotkałem z CI w oknie dokowanym:

• ponownie potrzebujesz obrazu dokowanego do zbudowania. musisz poszukać obrazu lub napisać własny plik dokowany.
• W 90% przypadków musisz przesłać dalej niektóre klucze SSH, czyli tajne dane, których nie chcesz zapisywać w obrazie okna dokowanego.
• kontener jest tworzony i umiera, a wraz z nim wszystkie pamięci podręczne są tracone. następna kompilacja spowoduje ponowne pobranie wszystkich zależności projektu, co jest czasochłonne i nieefektywne, a czas to pieniądz.

Deweloperzy nie budują projektów w kontenerach dokowanych (kiedyś byłem takim fanem, naprawdę, żal mi siebie w przeszłości xD). W Javie można mieć kilka wersji i zmieniać je jednym poleceniem na tę, której aktualnie potrzebujesz. To samo w nodejs, jest nvm.

Wniosek

Uważam, że doker jest bardzo potężnym i elastycznym narzędziem, to jest jego wada (brzmi dziwnie, tak). Z jego pomocą firmy mogą łatwo się od niego uzależnić i używać go tam, gdzie jest to potrzebne i nie potrzebne. Deweloperzy uruchamiają swoje kontenery, część swoich środowisk, następnie wszystko płynnie przechodzi do CI i produkcji. Zespół DevOps pisze jakiś kod do uruchamiania tych kontenerów.

Używaj tylko okna dokowanego ostatnie etapie przepływu pracy, nie przeciągaj go do projektu na początku. To nie rozwiąże Twoich problemów biznesowych. On jedynie przeniesie problemy na INNĄ poziom i zaproponuje własne rozwiązania, a ty wykonasz podwójną pracę.

Kiedy potrzebny jest doker: Doszedłem do wniosku, że docker bardzo dobrze radzi sobie z optymalizacją danego procesu, ale nie z budowaniem podstawowej funkcjonalności

Jeśli nadal decydujesz się na użycie okna dokowanego, to:

• bądź bardzo ostrożny
• nie zmuszaj programistów do korzystania z okna dokowanego
• lokalizuj jego użycie w jednym miejscu, nie rozpowszechniaj go we wszystkich repozytoriach Dockefile i docker-compose

PS:

• Niedawno natknąłem się pakowacz i mówią, że bardzo dobrze współpracuje z Ansible i pozwala ujednolicić proces budowania obrazów (w tym obrazu dokera)
• także o dockerze, ciekawy artykuł

Dziękuję za przeczytanie, życzę przejrzystych decyzji w swoich sprawach i produktywnych dni pracy!

Źródło: www.habr.com