Czy Docker jest odpowiedni dla mojego przypadku użycia?

Moja firma ma sprzedawany przez nas system, który składa się zasadniczo z mini-komputera „Smartbox” z systemem Ubuntu 12.04. To okno uruchamia aplikację Django oraz szereg różnych związanych z nią procesów upstartowania. Niewiele więcej. Mamy tysiące takich pudeł na polu. Zarządzamy zależnościami pakietów, rejestracją procesów itp. Poprzez pakiet deb z różnym powodzeniem.

Potrzebujemy sposobu na wydajne i niezawodne przekazywanie aktualizacji naszym użytkownikom w terenie. Potrzebujemy również czegoś, co, gdy aktualizujemy system operacyjny (jesteśmy o wiele za późno na aktualizację Ubuntu, jak można powiedzieć), możemy czuć się stosunkowo bezpiecznie, gdy nasze pakiety „po prostu działają”.

Nie wiem dużo o Dockerze, ale kiedy po raz pierwszy usłyszałem o naszym problemie (jestem nowym najemcą), Docker był moją pierwszą myślą. Ale im więcej o tym myślałem, czułem się, jakby to nie było, ponieważ te pudełka są nasze, kontrolujemy na nim system operacyjny, który jest dużą częścią oferty wartości Dockera, a przynajmniej tak rozumiem. Więc jeśli WIEMY, nasze urządzenia zawsze będą Ubuntu i po prostu mamy tylko aplikację Django oraz kilka procesów do uruchomienia, czy Docker jest lepszy od pakietu deb?

TL; DR: Pakiety Docker vs deb dla rozproszonego urządzenia, które zawsze będzie działało na Ubuntu, więc niezależność platformy nie jest tak ważna.

Nie jestem w 100% pewien, że rozumiem z pytania, ale wygląda na to, że rozwiązaniem Dockera byłoby przejście od posiadania (fizycznego?) Urządzenia z systemem operacyjnym i zainstalowaną aplikacją, do posiadania urządzenia z systemem operacyjnym i Dokuj na nim, uruchamiając pojedynczy kontener z aplikacją. Nie eliminuje to potrzeby aktualizacji systemu operacyjnego na hoście i dodaje warstwę złożoności (i więcej aktualizacji, z którymi trzeba się zmagać, ponieważ teraz będziesz musiał utrzymywać łatanie Dockera i systemu operacyjnego) bez widocznych korzyści jeśli chodzi o konkretne obszary wymienione w pytaniu.

Jeśli jednak mówisz o przejściu z urządzenia wirtualnego do kontenera Docker, może to potencjalnie ułatwić Ci rozwiązanie, ale dodaje Docker jako zależność dla Twojego produktu; odcinasz każdego, kto nie używa Dockera i nie chce dodawać go do swojego stosu tylko po to, aby użyć twojego produktu. Możesz nadal wspierać tych, którzy nie używają Dockera, kontynuując wysyłanie (teraz „starszego”) urządzenia wirtualnego, jak wcześniej, ale teraz podwoiłeś swoje obciążenie, ponieważ masz dwie dystrybucje do obsługi zamiast jeden.

Pracowałem z Dockerem od dłuższego czasu. Niezależność od platformy jest dobra, ale nie jest to, co uważam za najbardziej przydatne w Docker.

Przede wszystkim zyskujesz powtarzalność. Możesz utworzyć plik Docker, debugować w kontenerze na komputerze dewelopera, przeprowadzić testy na serwerze ciągłej integracji, a następnie w produkcie końcowym, i wiesz, że będzie on zachowywał się tak samo we wszystkich tych środowiskach. Nie można zapominać o zależności, którą programista zainstalował na swoim komputerze. Twoi programiści nie muszą też używać Ubuntu przy biurku. Ważne, aby nas zadowolić użytkownicy Arch Linux :-)

Po drugie, w przypadku scenariusza aktualizacji możesz mieć kilka wersji jednocześnie ściągniętych na komputer. Jeśli zrobisz to przez docker pull myapp:2.0chwilę 1.0, możesz zamienić się na 2.0bardzo szybko. Zwykle trwa to znacznie szybciej niż wykonanie pełnej aktualizacji systemu operacyjnego. Jeśli używasz orkiestratora z wieloma wystąpieniami mikrousług, możesz nawet wykonywać uaktualnienia ciągłe, które w ogóle nie przerywają usługi.

Jeśli korzystasz z modelu mikrousług, Docker zapewnia również piaskownice, które mogą ograniczyć liczbę obrażeń, które atakujący mogą wyrządzić w przypadku exploita. Zamiast przejmować kontrolę nad całą maszyną, uzyskują kontrolę tylko nad jednym pojemnikiem.

Główną wadą jest to, że potrzebujesz systemu operacyjnego hosta i jakiejś aranżacji. Jest na to wiele możliwości, ale nie lekceważ ilości pracy, jaką trzeba wykonać, aby je ocenić, umieścić i utrzymać.

Zasadniczo doker zapewnia wiele korzyści zarówno dla programistów, jak i personelu operacyjnego. Używam dokera do niektórych moich aplikacji i uważam, że jest to bardzo niezawodne i niezawodne podejście.

Mój problem z przyjęciem dokera polega na tym, że nie słyszę, abyś zadawał właściwe pytania i że potencjalnie możesz skomplikować swoje życie bez spełnienia najważniejszych wymagań.

Pierwsze pytanie, które powinieneś zadać (powiedziałeś, że jesteś nowy), to w jaki sposób obsługiwane są teraz aktualizacje systemu operacyjnego i aplikacji? Czy obecna metodologia działa dla Ciebie (Twojej firmy)? Co działa dobrze? Co można poprawić? Czy możesz przeprowadzić fizyczny audyt konfiguracji na komputerach docelowych w terenie, aby sprawdzić, czy mają one odpowiednie poprawki systemu operacyjnego, aplikacji i czy były tam nieautoryzowane zmiany.

Uwielbiam dokera, ale nie wskoczyłbym na modę dokera bez uprzedniej oceny, gdzie jesteś teraz, w tym, co działa dobrze i co należy poprawić.

Chociaż istnieje niewielki nakładający się region Docker i systemy pakietów Debiana zasadniczo rozwiązują dwa bardzo różne problemy :

• System pakowania Debiana jest zbudowany w celu instalowania oprogramowania na hoście i aktualizacji go tak łatwo, jak to możliwe. Jest w stanie obsłużyć złożone wzorce zależności i ograniczeń między komponentami oprogramowania, np. „Oprogramowanie X w wersji A wymaga oprogramowania Y z zainstalowaną wersją B lub nowszą” lub „oprogramowanie X nigdy nie powinno być instalowane z oprogramowaniem Z w wersji C”.

• System Docker ma na celu łatwe opisywanie i wdrażanie usług, zwłaszcza mikrousług, prawdopodobnie na kilku hostach - np. Roju Docker lub klastrze Kubernetes.

Te dwa problemy są zasadniczo ortogonalne, co oznacza, że ​​biorąc pod uwagę problem z wdrożeniem do rozwiązania, można użyć jednego z nich, obu, a może nawet żadnego z nich, jako części rozwiązania. Podczas korzystania z obu z nich, pakiet Debian jest używany do produkcji obrazu Docker, a Twój plik Docker (przepisy użyte do przygotowania obrazu Docker opisującego „zwirtualizowany system” działający w kontenerze) zasadniczo rejestrowałyby Twoje repozytorium Debian w źródła systemu pakietów Debiana i zainstaluj swój pakiet.

Mając to na uwadze, wydaje mi się, że tak naprawdę szukasz implementacji niezmiennego wzorca serwera. Niedawny rozwój technologii w chmurze umożliwił aktualizację oprogramowania nie przy użyciu klasycznego systemu aktualizacji oprogramowania z systemu pakietów oprogramowania (takiego jak system pakietów Debiana), ale po prostu przez zastąpienie całego serwera jednocześnie. (Niektóre osoby zrobiły to przed tym opracowaniem, mając trzy systemy operacyjne na serwerze, dwa używane alternatywnie do uruchamiania urządzenia i mini-system operacyjny przeznaczony do wymiany urządzenia. Chociaż nie jest to zbyt skomplikowane, wydaje się, że zawsze pozostawało nisza.) Ta technika może być dla Ciebie interesująca, ponieważ jeśli jesteś przyzwyczajony do aktualizacji oprogramowania na serwerze za pomocą menedżera pakietów, ostateczny stan serwera zależy od „historii aktualizacji” serwera - szczególnie jeśli wystąpią błędy w proces aktualizacji. Ta heterogeniczność jest zła,

Mamy tysiące takich pudeł na polu. Zarządzamy zależnościami pakietów, rejestracją procesów itp. Poprzez pakiet deb z różnym powodzeniem.

może odnosić się do tego. Niezmienny wzorzec serwera usuwa to źródło błędów, zasadniczo niszcząc pojęcie „historii aktualizacji” od problemu.

Teraz istnieją różne opcje implementacji niezmiennego wzorca serwera, dwie popularne opcje to użycie obrazów Docker, obrazów lub użycie „obrazów instancji wzorcowych” od dostawcy chmury (są to AMI w AWS i tylko obrazy niestandardowe w Google Compute Engine) . Twój przypadek użycia zabrania stosowania technik opartych na chmurze, dlatego przyjmuję obrazy Docker jako jedyny kwalifikujący się wybór. (Ze względu na zakończenie z pewnością możliwe jest zastosowanie innych podejść, na przykład za pomocą Virtual Box lub podobnego rozwiązania do wirtualizacji, jako alternatywy dla Dockera).

Korzystając z niezmiennej techniki wzorców serwerów, wprowadzasz nowy artefakt (obraz Docker) reprezentujący Twój serwer, a ten artefakt można również przetestować, a bardzo łatwo jest uzyskać konfigurację dokładnie odzwierciedlającą ustawienia produkcji - oprócz obciążenia serwisowego.

Teraz, aby rozważyć konkretny opisany problem, załóżmy, że implementacja niezmiennego wzorca serwera za pomocą Dockera jest właśnie tym, czego chcesz. Ponieważ system Docker i system pakietów Debiana uzupełniają się, a nie wzajemnie wykluczają (por. Wprowadzenie), nadal musimy odpowiedzieć na pytanie, czy powinieneś przygotować pakiet Debian dla swojego oprogramowania.

Znaczenie użycia pakietu Debian do zainstalowania oprogramowania (na obrazku Docker lub na hoście) polega na złożoności problemu z wersjonowaniem, który należy rozwiązać. Jeśli uruchamiasz w tym samym czasie kilka wersji oprogramowania, od czasu do czasu musisz obniżyć wersję i masz złożone wymagania dotyczące wersji, które musisz dokładnie udokumentować, posiadanie pakietu Debian jest koniecznością. W przeciwnym razie ten krok można pominąć - ale ponieważ już starasz się wyprodukować i wdrożyć te pakiety, nie ma prawdziwej wartości w porzucaniu pracy. Dlatego sugerowałbym kontynuowanie produkcji pakietów Debiana.

Myślę, że może to być dobra opcja (konieczne są dalsze testy)

Możesz podać adres URL ze wszystkimi tagami / wersjami kontenera, który utworzyłeś, a klienci przeczytają ten adres URL, aby sprawdzić, czy jest nowa wersja kontenera.

Możesz przechowywać osobiste pliki / ustawienia na poziomie lokalnym i nigdy nie stracisz tych informacji w aktualizacjach i zapewnisz, że to, co stworzyłeś i przetestowałeś, będzie działać dla wszystkich w ten sam sposób.

Nawet ty możesz dać użytkownikom możliwość wyboru wersji z dostępnych, których chcą używać (jeśli chcesz dać taką możliwość).

Będzie to jak „tylko zaktualizuj jeden pakiet”, mówiąc o pobraniu nowej wersji kontenera, znacznie lepiej niż w przypadku pakietów debianowych;)

Docker brzmi dla mnie rozsądnie, ponieważ możesz wprowadzać i testować zmiany w kontenerze we własnym zakresie, a następnie, w zależności od procesu wydania, restartuj kontenery zawsze ciągnąc: najnowszy lub coś podobnego, co zapewni przetestowane uaktualnienie.

Zagadnienia, z którymi trzeba by się zmierzyć, obejmują przechowywanie danych, ponieważ kontenery nie zachowują zmian po ponownym uruchomieniu, więc chcesz mieć wolumin danych. Prawdopodobnie jest o wiele więcej czynników, które powinieneś wziąć pod uwagę, gdy się w to zagłębisz. System, z którym obecnie pracuję (wszystkie oparte na dokerach) jest rozwijany od ponad roku i wciąż znajdujemy obszary, w których musimy wprowadzić zmiany w kontenerze, konfiguracjach itp.