Aplikacje Elixir/Erlang z Dockerem w produkcji?

Question

Chciałbym wiedzieć, jakie są silne powody, dla których warto pójść z Dockerem za pomocą aplikacji Elixir/Erlang w produkcji. To pierwszy raz, kiedy jestem proszony o rozpoczęcie pracy z Dockerem w produkcji. Pracowałem nad produkcją bez Dockera. Jestem programistą Erlang/Elixir. Pracowałem na serwerach o dużym natężeniu ruchu z milionami transakcji na sekundę, które działają bez Dockera. Spędziłem jeden dzień na tworzeniu i uruchomieniu obrazu aplikacji Elixir z wieloma problemami z siecią Musiałem wykonać wiele konfiguracji konfiguracji DNS itp. Po tym zacząłem myśleć Jakie są mocne powody dalszego postępowania. Czy są jakieś poważne powody, aby iść z Dockerem z aplikacjami Elixir/Erlang w produkcji.

Przeszedłem przez niektóre z powodów na forach, ale nadal Nie jestem przekonany. Wszystkie zalety, które zapewnia dokowanie, jest już w maszynie Erlang VM. Czy którykolwiek z Erlang Expert w formularzu proszę mi pomóc.

Answer 1

Może to zależy od serwera, którego chcesz użyć. Z tego, co wiem, Docker na przykład ułatwia wdrażanie aplikacji Phoenix na AWS Elastic Beanstalk, ale nie jestem wystarczająco kompetentny, aby podać w tej chwili konkretne powody.

Może ktoś może rozwinąć więcej.

Answer 2

Docker jest przede wszystkim narzędziem do wdrażania i dystrybucji. Z dokumentacji Docker:

Docker usprawnia cykl rozwoju oprogramowania, umożliwiając programistom pracę w standardowych środowiskach z wykorzystaniem lokalnych kontenerów, które udostępniają aplikacje i usługi. Pojemniki są idealne do ciągłej integracji i ciągłego rozwoju (CI/CD).

Jeśli aplikacja ma zależności zewnętrzne (na przykład biblioteka kryptografii), współdziała z inną aplikacją napisaną w innym języku (na przykład z bazą danych działającą jako oddzielny proces) lub jeśli jest zależna od określonego systemu operacyjnego/konfiguracja środowiska (wspomniałeś, że musiałaś wykonać konfigurację DNS), a następnie pakowanie aplikacji w kontener dokowania pomaga uniknąć duplikowania pracy podczas instalowania zależności i konfigurowania środowiska. Pomaga to uniknąć dodatkowej pracy, utrzymując synchronizację środowiska testowego i produkcyjnego pod kątem zależności lub badając, dlaczego aplikacja działa na jednym komputerze w jednym środowisku, ale nie na innym.

Powyższe nie jest specyficzne dla aplikacji Erlang, ale mogę zgodzić się, że Erlang pomaga wyeliminować niektóre problemy będące międzyplatformami i abstrahując niektóre zależności, a obsługa zwolnień OTP pomaga spakować aplikację.

Skoro wspomniałeś jesteś programistą, to warto wspomnieć, że Docker oferuje więcej korzyści dla administratora lub zespołu prowadzącego infrastruktury aniżeli ma to miejsce dla dewelopera.

Answer 3

Wdrażam pakiet Elixir spakowany w Docker na AWS w produkcji. To był mój ulubiony sposób robienia rzeczy, ale teraz jestem bardziej skłonny do tworzenia własnego AMI przy użyciu Packera z preinstalowanym wszystkim.

Sprawa centralny w wdrożeń jest to, że kontroli, które w pewnym stopniu czuję się zrzekła gdy wykorzystując Döcker.

Główną wadą Docker jest to, że ogranicza możliwości Erlanga/Elixira, takie jak połączenie międzywęzłowe powyżej epmd. Oznacza to również, że remsh jest praktycznie wykluczone i chłodne :observer.start jest nie-nie.Jeśli kiedykolwiek zechcesz wejść w interakcję z węzłem produkcyjnym, istnieje dodatkowa bariera wejścia na serwer do pierwszego ssh-ing, wejścia do Docker itp. Dobra, gdy chodzi o sprawdzanie czegoś, frustrujące, gdy produkcja jest paląca w agonii. Uruchomienie wielu kontenerów w jednym węźle jest trochę bezużyteczne, ponieważ BEAM zapewnia efektywne wykorzystanie wszystkich rdzeni. Gorące aktualizacje są praktycznie wykluczone, ale to nie jest funkcja, którą osobiście potrzebujemy.

Wysiłek polegał na tym, aby epmd pracował w konfiguracji kontenera, na przykład: https://github.com/Random-Liu/Erlang-In-Docker, ale będzie to wymagało przebudowania Erlanga dla niestandardowych modyfikacji net_kernel.

Firma Amazon opublikowała niedawno nową funkcję trybu AWS ECS, AWS VPC Networking, która być może ułatwi komunikację między kontenerami epmd, a tym samym bezpośrednio do danego węzła. Nie potwierdziłem tego jeszcze.

Poza kwestią epmd komunikacja jest kwestią czasu wdrożenia. Tworzenie obrazu za pomocą Docker, nawet jeśli masz obrazy, które mają tylko 5 MB, szybko przyniesie 300 MB, a 200 MB to tylko dla wszystkich zależności, które pozwolą na stworzenie twojego wydania. Mogą istnieć sposoby na zmniejszenie tego, ale wymaga to specjalistycznej wiedzy i poświęconego wysiłku. Chciałbym zaklasyfikować tę dodatkową przestrzeń bardziej jako rozdrażnienie, w przeciwieństwie do łamacza umów, ale uwierz mi, jeśli musisz czekać 25 minut na zakończenie niezmiennych wdrożeń, każda minuta, którą możesz zgolić, byłaby warta zachodu.

Z punktu widzenia wydajności nie zauważyłem znaczącej różnicy między nieuzasadnionymi wdrożeniami metalowymi a wdrożeniami w portach. AWS EB Docker ładnie rozszerza zasoby kontenera do zasobów instancji EC2.

Zaletą jest oczywiście możliwość przenoszenia. Jeśli masz inżyniera z przodu, który musi trafić na interfejs API JSON, to pod względem rozwoju lokalnego jest to ogromna wygrana, która dzięki starannej konfiguracji może odrodzić najnowsze api działające na lokalnym komputerze bez konieczności bycia informowanym o Erlang/Elixir./Rserve/Postgres.

Również Vendor lock-in jest znacznie zmniejszona, zwłaszcza odkąd AWS rozpoczęła swoje poparcie dla Kubernetes

Jest to kwestia kompromisów, jeśli jesteś programistą, który musi dostać się do produkcji i mają bardzo małe devops wiedzy, być może wdrożenie Docker może być uzasadnione. Jeśli znasz lepiej infrastrukturę, wdrożenia itp., To jako programista uważam, że tworzenie własnego AMI zapewnia lepszą kontrolę nad środowiskiem. W sumie zachęcałbym przynajmniej do zabawy z Docker i eksperymentowania z nim, może otworzyć nowe królestwo możliwości.