Czy są jakieś wady korzystania z pakietu deb tak, jakby to był kontener do wdrażania aplikacji?

Mój zespół obecnie próbuje zdecydować, czy powinniśmy wdrożyć naszą aplikację Nodejs jako pakiet deb zamiast próbować uruchomić ją w kontenerze, takim jak Docker.

Pomysł ten zaczerpnąłem z lektury tego bloga , który przedstawia kilka dobrych argumentów przemawiających za użyciem pakietu deb dla istniejącej aplikacji python. Głównym punktem tego bloga, który nam się podoba, jest kwestia utrzymania ekosystemu Docker (udostępnianie portów, uprawnienia, hosting obrazów Docker itp.)

Wydaje się, że „dep-paczki jako oryginalne kontenery” mają sens w przypadku małych usług, w których nie ma obaw o konflikty portów i gdzie wszystkie zależności są utrzymywane w środowisku wirtualnym.

Jednak mam przeczucie, że jeśli pakiety deb byłyby dobrze dopasowane, byłoby to bardziej powszechne i dokerowanie byłoby reklamowane jako rozwiązanie bardziej specyficzne dla języka. Czy są jakieś wady korzystania z czegoś takiego jak pakiety deb do wdrażania naszych usług, zamiast korzystania z pełnego systemu, takiego jak doker?

Po pierwsze, chociaż Docker jest czasem postrzegany i używany jako system pakowania ad hoc , w rzeczywistości rozwiązuje on zupełnie inny problem: Docker polega na uruchamianiu programów. System Docker pozwala opisywać usługi, które można dowolnie skalować i kontrolować roje kontenerów. Pakiety Debiana służą do instalowania programów i są w stanie obsłużyć zależności między wersjami oprogramowania. Doker z pewnością nie kwalifikuje się jako system pakowania zstępującego: każdy „pakiet” może mieć tylko jedną zależność, system nie ma opcji „kompilacji rekurencyjnej” i nie obsługuje złożonych ograniczeń wersji!

Możliwą odpowiedzią byłoby, że jeśli chcesz napisać pakiet Debian dla swojej aplikacji, możesz także użyć Dockera do wdrożenia aplikacji. Można to osiągnąć za pomocą skryptu konfiguracyjnego, apt_setup.shktóry wyglądałby

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

i a Dockerfilewzdłuż linii

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(W twojej konkretnej sytuacji apt_setup.shbyłoby to bardziej skomplikowane, dodając repozytoria nodesource i niektóre pakiety pomocnicze, takie jak apt-transport-https .)

Dlatego naprawdę możliwe jest jednoczesne korzystanie z pakietów Debiana i Dockera , jednak…

Moje przeczucie […] mówi mi, że gdyby pakiety deb były dobrze dopasowane, byłoby to bardziej powszechne

Jest to prawidłowy problem, który prowadzi nas do pytania, dlaczego Docker jest popularny jako system pakowania ad hoc , podczas gdy nie jest nim przeznaczony. (Patrz wyżej.)

„Oficjalny” system pakowania z danej dystrybucji to tylko jedna z wielu możliwości zainstalowania oprogramowania w niektórych środowiskach komputerowych. Istnieje wiele innych dostępnych źródeł, takich jak specyficzne dla społeczności menedżery pakietów, takie jak npm lub opam, drzewa portów, takie jak pkgsrc i zwykła dystrybucja kodu źródłowego. Z tej perspektywy łatwo jest zrozumieć sukces Dockera jako systemu pakowania ad hoc :

• Specyfikacje Dockera są bardzo zbliżone do skryptu powłoki i niezależnie od źródła, z którego pochodzi, instalujemy oprogramowanie za pomocą powłoki.

• Docker ma „wbudowaną” (płatną) usługę do hostowania produkowanych przez siebie artefaktów, Docker Hub .

Jaka jest siła pakietów Debiana nad obrazami Docker jako systemem pakietów? Ścisła kontrola nad zależnościami podczas instalacji. (Istnieje również możliwość uaktualnienia i obniżenia wersji, ale nie ma praktycznego znaczenia, jeśli wdrażamy wzorzec niezmiennego serwera ). Prowadzi to do

Wniosek

Jeśli masz tylko jeden produkt wdrożony w jednej wersji (co jest typowe dla SaaS), twoje potrzeby zarządzania wersjami są bardzo proste, a używanie Dockera jako menedżera pakietów ad hoc nie powinno mieć żadnych poważnych wad. Gdy tylko pracujesz z kilkoma wersjami jednego produktu lub kilku produktów, złożoność problemu ograniczeń wersji, którą musisz rozwiązać, wzrasta i potrzebujesz odpowiedniego narzędzia do tego, którym mogą być pakiety Debiana lub jakiś system zarządzania konfiguracją, jeśli jesteś mieszanie oprogramowania z różnych źródeł.

Tak, są wady.

Dzięki pakietowi .deb nie będziesz mieć dwóch wersji tej samej aplikacji na tym samym hoście. Będziesz musiał polegać na dostępnych pakietach dystrybucyjnych, jeśli na przykład aplikacja będzie polegać na nodejs, albo utkniesz z wersją dystrybucyjną, albo będziesz musiał zainstalować własną.

Teraz, gdy chcesz hostować wiele aplikacji na tym samym hoście, bardzo szybko uderzysz o ścianę, gdy zależą od tego samego (zatrzymajmy tutaj nodejs) w dwóch różnych wersjach.

Głównym celem dokera jest odizolowanie każdej aplikacji od systemu hosta i innych aplikacji na tym samym hoście. izolacja ma dwa powody: 1. aby uniknąć komplikacji aplikacji, aby móc przejąć hosta lub wpłynąć na inną aplikację 2. podać dokładną zależność aplikacji i zapobiec wpływowi aktualizacji systemu lub innej aplikacji zależność.

Pakiet Debian (lub RedHat) do instalowania aplikacji jest dobrą praktyką, jeśli jest wykonany poprawnie. Pakiety są używane do wdrażania aplikacji, które są rzadko zmieniane. Pakiety Debiana zawierają pewne koszty ogólne, takie jak zarządzanie wersjami, zarządzanie zależnościami, skrypty przed instalacją i po instalacji itp.

W wielu przypadkach aktualizacja ze starszej wersji do nowej wersji wymaga starannego pisania skryptów, dbałości o szczegóły w wersji itp. Ponieważ mutacja istniejącego stanu jest trudna. Znacznie łatwiej byłoby całkowicie zastąpić obecny stan nowym stanem, bez mutowania czegokolwiek.

Gdy zdecydujesz się całkowicie zastąpić konfigurację, zależności lub aplikację przy każdym wdrożeniu, ponieważ jest to łatwiejsze i mniej podatne na błędy. Większość organizacji (kiedyś) przełącza się na zupełnie nową instancję maszyny wirtualnej lub chmury. Co oznacza, że ​​instalacja pakietu zostałaby wykonana na „czystym” serwerze, a mutacja plików i konfiguracji na serwerze nie stanowi już problemu.

Ci programiści, którzy stworzyli pakiety i nie rozumieli błędności i złożoności mutacji, napotkali na to sporo trudności.

Zastąpienie maszyn wirtualnych nie jest optymalne, gdy wszystko, czego potrzebujesz, to zastąpienie aplikacji, dlatego w odpowiedzi wprowadzono lekkie pojemniki. Za pomocą Dockera (lub innego LWC) możesz zastąpić bazę użytkowników, w tym wszystkie zależności, bez wymiany samego serwera. Możesz także hostować wiele wersji tej samej aplikacji, z różnymi zależnościami, na tym samym serwerze i przełączać przychodzący ruch sieciowy tylko podczas aktualizacji. Oprócz przywracania ruchu sieciowego po przywróceniu (niebiesko-zielony), było to niezwykle trudne w przypadku zarządzania wdrożeniami za pomocą pakietów.

Kontenery wprowadzają sposób pakowania całego kodu aplikacji oraz zależności i konfiguracji w obraz. Ten obraz ma wiele właściwości, dzięki czemu jest znacznie lepszy niż tradycyjne pakiety systemu operacyjnego. Na przykład ma znaczniki, które umożliwiają wersjonowanie, ale ma także warstwy, które pozwalają zaoszczędzić miejsce. Umożliwia łatwy sposób przesyłania tych obrazów na serwery i środowiska programistyczne za pomocą rejestru. Obrazy te mogą być wykonywane jako kontenery w dowolnym środowisku i na dowolnym serwerze, prawie identycznie. Dotyczy to zarówno laptopa programisty, jak i środowiska produkcyjnego. Ponownie, coś, co było znacznie trudniejsze do zrobienia w przypadku maszyn wirtualnych i / lub wersji oprogramowania na podstawie pakietu. Testowanie tego samego obrazu na laptopie dewelopera i pozostawanie w produkcji na tych samych bitach i bajtach usuwa wiele „

Mówiąc konkretnie o kawałku Dockera do pakowania obrazów, a nie o czasie działania kontenera, jest kilka drobnych bitów. Największe jest to, że obraz Dockera przypomina bardziej chroota, co oznacza, że ​​nie można przypadkowo uzależnić go od stanu współużytkowanego systemu, ponieważ każdy używany plik musi być wyraźnie dołączony do obrazu, podczas gdy pakiet systemowy może pobierać dynamiczne łącza, których nie spodziewaj się lub w inny sposób połącz się bardziej z innymi pakietami. Może to powodować skomplikowane zależności C ładowane bez Twojej wiedzy, na przykład OpenSSL. Dodatkowo, używając pakietów deb, nie usuwaj duplikatów współdzielonych bitów w systemie pamięci Docker. Dla niektórych może to być dobra rzecz, lepsza wydajność we / wy i mniej ruchomych elementów, ale dla innych może to stanowić problem.