Konteneryzowanie aplikacji monolitycznych

Wskazówka

Ta treść jest fragmentem eBooka "Architektura mikrousług .NET dla konteneryzowanych aplikacji .NET", dostępnego na .NET Docs lub jako bezpłatny plik PDF do pobrania i czytania w trybie offline.

Pobierz plik PDF

Możesz utworzyć pojedynczą, monolityczną aplikację internetową lub usługę i wdrożyć ją jako kontener. Sama aplikacja może nie być wewnętrznie monolityczna, ale ustrukturyzowana jako kilka bibliotek, składników, a nawet warstw (warstwa aplikacji, warstwa domeny, warstwa dostępu do danych itp.). Zewnętrznie jest to jednak pojedynczy kontener — pojedynczy proces, pojedyncza aplikacja internetowa lub pojedyncza usługa.

Aby zarządzać tym modelem, należy wdrożyć pojedynczy kontener reprezentujący aplikację. Aby zwiększyć pojemność, można skalować w poziomie, czyli po prostu dodać więcej kopii z modułem równoważenia obciążenia z przodu. Prostota pochodzi z zarządzania pojedynczym wdrożeniem w jednym kontenerze lub maszynie wirtualnej.

Rysunek 4–1. Przykład architektury konteneryzowanej aplikacji monolitycznej

W każdym kontenerze można uwzględnić wiele składników, bibliotek lub warstw wewnętrznych, jak pokazano na rysunku 4–1. Monolityczna aplikacja w kontenerze ma większość swojej funkcjonalności w jednym kontenerze, które zawierają warstwy wewnętrzne lub biblioteki, i rozszerza swoją skalowalność przez sklonowanie kontenera na wielu serwerach lub maszynach wirtualnych. Jednak ten wzorzec monolityczny może powodować konflikt z zasadą kontenera "kontener wykonuje jedną rzecz i wykonuje go w jednym procesie", ale może być ok w niektórych przypadkach.

Wadą tego podejścia staje się widoczna, jeśli aplikacja się rozwinie, co wymaga skalowania. Jeśli cała aplikacja może być skalowana, tak naprawdę nie jest to problem. Jednak w większości przypadków tylko kilka części aplikacji to punkty dławiające, które wymagają skalowania, podczas gdy inne składniki są używane mniej.

Na przykład w typowej aplikacji do handlu elektronicznego prawdopodobnie trzeba skalować podsystem informacji o produkcie, ponieważ wiele innych klientów przegląda produkty niż je kupować. Więcej klientów korzysta z koszyka niż używa potoku płatności. Mniej klientów dodaje komentarze lub wyświetla historię zakupów. Możesz mieć tylko kilku pracowników, którzy muszą zarządzać treściami i kampaniami marketingowymi. Jeśli skaluje się projekt monolityczny, cały kod dla tych różnych zadań jest wdrażany wielokrotnie i skalowany w tym samym stopniu.

Istnieje wiele sposobów skalowania duplikacji w poziomie aplikacji, dzielenia różnych obszarów aplikacji i partycjonowania podobnych pojęć biznesowych lub danych. Oprócz problemu skalowania wszystkich składników zmiany w jednym składniku wymagają całkowitego ponownego testowania całej aplikacji i całkowitego ponownego wdrożenia wszystkich wystąpień.

Jednak podejście monolityczne jest powszechne, ponieważ opracowywanie aplikacji jest początkowo łatwiejsze niż w przypadku metod mikrousług. W związku z tym wiele organizacji rozwija się według tego podejścia architektonicznego. Podczas gdy niektóre organizacje miały wystarczająco dobre wyniki, inne osiągają limity. Wiele organizacji zaprojektowało swoje aplikacje przy użyciu tego modelu, ponieważ narzędzia i infrastruktura utrudniały tworzenie architektur zorientowanych na usługi (SOA) lat temu i nie widziały potrzeby aż do wzrostu aplikacji.

Z perspektywy infrastruktury każdy serwer może uruchamiać wiele aplikacji na tym samym hoście i mieć akceptowalny stosunek wydajności do użycia zasobów, jak pokazano na rysunku 4–2.

Rysunek 4–2. Podejście monolityczne: Hostowanie wielu aplikacji, z których każda działa jako kontener

Aplikacje monolityczne na platformie Microsoft Azure można wdrażać przy użyciu dedykowanych maszyn wirtualnych dla każdego wystąpienia. Ponadto przy użyciu zestawów skalowania maszyn wirtualnych platformy Azure można łatwo skalować maszyny wirtualne. Usługa Azure App Service może również uruchamiać aplikacje monolityczne i łatwo skalować wystąpienia bez konieczności zarządzania maszynami wirtualnymi. Od 2016 r. usługi Azure App Services mogą również uruchamiać pojedyncze wystąpienia kontenerów platformy Docker, upraszczając wdrażanie.

Jako środowisko kontroli jakości lub ograniczone środowisko produkcyjne można wdrożyć wiele maszyn wirtualnych hosta platformy Docker i zrównoważyć je przy użyciu modułu równoważenia obciążenia platformy Azure, jak pokazano na rysunku 4–3. Dzięki temu można zarządzać skalowaniem przy użyciu podejścia gruboziarnistego, ponieważ cała aplikacja znajduje się w jednym kontenerze.

Rysunek 4–3 Przykład skalowania aplikacji kontenera na wielu hostach

Wdrożenie na różnych hostach można zarządzać przy użyciu tradycyjnych technik wdrażania. Hostami platformy Docker można zarządzać za pomocą poleceń, takich jak docker run lub docker-compose wykonywanych ręcznie, lub za pośrednictwem automatyzacji, takich jak ścieżki ciągłego dostarczania (CD).

Wdrażanie aplikacji monolitycznej jako kontenera

Istnieją korzyści wynikające z używania kontenerów do zarządzania wdrożeniami aplikacji monolitycznych. Skalowanie instancji kontenerów jest znacznie szybsze i łatwiejsze niż uruchamianie dodatkowych maszyn wirtualnych. Nawet jeśli używasz zestawów skalowania maszyn wirtualnych, uruchomienie maszyn wirtualnych zajmuje trochę czasu. Po wdrożeniu jako tradycyjne wystąpienia aplikacji zamiast kontenerów konfiguracja aplikacji jest zarządzana jako część maszyny wirtualnej, co nie jest idealne.

Wdrażanie aktualizacji jako obrazów Docker jest znacznie szybsze i bardziej efektywne pod względem sieci. Obrazy Docker zwykle rozpoczynają działanie w sekundach, co przyspiesza wdrażanie. Usunięcie instancji obrazu Dockera jest tak łatwe, jak wykonanie polecenia docker stop i zwykle zajmuje mniej niż sekundę.

Ponieważ kontenery są niezmienne zgodnie z projektem, nigdy nie musisz martwić się o uszkodzone maszyny wirtualne. Z kolei skrypty aktualizacji maszyny wirtualnej mogą zapominać o uwzględnieniu określonej konfiguracji lub pliku pozostawionego na dysku.

Chociaż aplikacje monolityczne mogą korzystać z platformy Docker, skupiamy się wyłącznie na korzyściach. Dodatkowe korzyści z zarządzania kontenerami wynikają z wdrażania za pomocą orkiestratorów kontenerów, które zarządzają różnymi instancjami i cyklem życia każdej instancji kontenera. Podział aplikacji monolitycznej na podsystemy, które można skalować, opracowywać i wdrażać indywidualnie, to punkt wejścia do obszaru mikrousług.

Publikowanie jednokontenerowej aplikacji w usłudze Azure App Service

Niezależnie od tego, czy chcesz uzyskać weryfikację kontenera wdrożonego na platformie Azure, czy gdy aplikacja jest po prostu aplikacją z jednym kontenerem, usługa Azure App Service zapewnia doskonały sposób zapewnienia skalowalnych usług opartych na jednym kontenerze. Korzystanie z usługi Azure App Service jest proste. Zapewnia doskonałą integrację z usługą Git, aby ułatwić wykonywanie kodu, kompilowanie go w programie Visual Studio i wdrażanie go bezpośrednio na platformie Azure.

Rysunek 4–4. Publikowanie aplikacji jednopojemnikowej w usłudze Azure App Service z Visual Studio 2022

Bez platformy Docker, jeśli potrzebujesz innych możliwości, struktur lub zależności, które nie są obsługiwane w usłudze Azure App Service, musisz poczekać, aż zespół platformy Azure zaktualizował te zależności w usłudze App Service. Możesz też przełączyć się na inne usługi, takie jak Azure Cloud Services lub maszyny wirtualne, gdzie masz dalszą kontrolę i możesz zainstalować wymagany składnik lub platformę dla aplikacji.

Obsługa kontenerów w programie Visual Studio 2017 i nowszych umożliwia uwzględnienie dowolnych elementów w środowisku aplikacji, jak pokazano na rysunku 4–4. Ponieważ używasz go w kontenerze, jeśli dodasz zależność do aplikacji, możesz uwzględnić zależność w pliku Dockerfile lub obrazie platformy Docker.

Jak pokazano również na rysunku 4–4, proces publikacji przeprowadza obraz przez rejestr kontenerów. Może to być usługa Azure Container Registry (rejestr zbliżony do wdrożeń na platformie Azure i zabezpieczony przez grupy i konta usługi Azure Active Directory) lub dowolny inny rejestr platformy Docker, taki jak Docker Hub lub rejestr lokalny.

PoprzedniNastępny