Korzystanie z kontenerów i orkiestratorów

Wskazówka

Ta zawartość jest fragmentem e-książki, Architektura Cloud Native .NET Applications for Azure, dostępnej w .NET Docs lub jako bezpłatny plik PDF do pobrania, który można czytać offline.

Pobierz plik PDF

Kontenery i orkiestratory są przeznaczone do rozwiązywania problemów typowych dla monolitycznych podejść wdrażania.

Wyzwania związane z wdrożeniami monolitycznymi

Tradycyjnie większość aplikacji została wdrożona jako pojedyncza jednostka. Takie aplikacje są określane jako monolit. To ogólne podejście do wdrażania aplikacji jako pojedynczych jednostek, nawet jeśli składają się z wielu modułów lub zestawów, jest nazywane architekturą monolityczną, jak pokazano na rysunku 3–1.

Rysunek 3–1. Architektura monolityczna.

Mimo że mają one zalety prostoty, architektury monolityczne stoją przed wieloma wyzwaniami:

Wdrożenie

Ponadto wymagają ponownego uruchomienia aplikacji, co może tymczasowo wpłynąć na dostępność, jeśli techniki bez przestojów nie są stosowane podczas wdrażania.

Skalowanie

Aplikacja monolityczna jest hostowana w całości na pojedynczej instancji maszyny, często wymagającej sprzętu o wysokich możliwościach. Jeśli jakakolwiek część monolitu wymaga skalowania, na innej maszynie musi zostać wdrożona inna kopia całej aplikacji. Dzięki monolicie nie można pojedynczo skalować składników aplikacji — to wszystko lub nic. Skalowanie składników, które nie wymagają skalowania, powoduje nieefektywne i kosztowne użycie zasobów.

Środowisko

Aplikacje monolityczne są zwykle wdrażane w środowisku hostingu ze wstępnie zainstalowanym systemem operacyjnym, środowiskiem uruchomieniowym i zależnościami biblioteki. To środowisko może nie odpowiadać temu, na którym aplikacja została opracowana lub przetestowana. Niespójności w środowiskach aplikacji są typowym źródłem problemów z wdrożeniami monolitycznymi.

Sprzęg

Aplikacja monolityczna może mieć duże sprzężenie między składnikami funkcjonalnymi. Bez trudnych granic zmiany systemowe często powodują niezamierzone i kosztowne skutki uboczne. Nowe funkcje/poprawki stają się trudne, czasochłonne i kosztowne do zaimplementowania. Aktualizacje wymagają rozbudowanego testowania. Sprzęganie utrudnia również refaktoryzację składników lub zamianę w implementacjach alternatywnych. Nawet przy ścisłym rozdzieleniu funkcji, erozja architektury pojawia się, gdy baza kodu monolitycznego pogarsza się z powodu niekończących się "wyjątkowych przypadków".

Blokada platformy

Aplikacja monolityczna jest tworzona przy użyciu pojedynczego stosu technologicznego. Oferując jednolitość, to zobowiązanie może stać się barierą dla innowacji. Nowe funkcje i składniki zostaną utworzone przy użyciu bieżącego stosu aplikacji — nawet wtedy, gdy bardziej nowoczesne technologie mogą być lepszym wyborem. Długoterminowe ryzyko polega na tym, że twój stos technologiczny staje się przestarzały i nieaktualny. Zmiana architektury całej aplikacji na nową, bardziej nowoczesną platformę jest najbardziej kosztowna i ryzykowna.

Jakie są zalety kontenerów i orkiestratorów?

Wprowadziliśmy kontenery w rozdziale 1. Podkreśliliśmy, jak fundacja Cloud Native Computing Foundation (CNCF) plasuje konteneryzację jako pierwszy krok w Cloud-Native Trail Map — wskazówki dla przedsiębiorstw rozpoczynających swoją podróż w chmurze. W tej sekcji omówiono zalety kontenerów.

Platforma Docker jest najpopularniejszą platformą do zarządzania kontenerami. Działa z kontenerami zarówno w systemie Linux, jak i Windows. Kontenery zapewniają oddzielne, ale powtarzalne środowiska aplikacji, które działają w taki sam sposób w dowolnym systemie. Ten aspekt sprawia, że doskonale nadają się do tworzenia i hostowania usług natywnych dla chmury. Kontenery są odizolowane od siebie. Dwa kontenery na tym samym sprzęcie hosta mogą mieć różne wersje oprogramowania bez powodowania konfliktów.

Kontenery są definiowane przez proste pliki tekstowe, które stają się artefaktami projektu i są sprawdzane w kontroli źródła. Chociaż pełne serwery i maszyny wirtualne wymagają ręcznego wysiłku do aktualizacji, kontenery są łatwo zarządzane wersjami. Aplikacje przeznaczone do uruchamiania w kontenerach można opracowywać, testować i wdrażać przy użyciu zautomatyzowanych narzędzi w ramach pipeline'u budowania.

Kontenery są niezmienne. Po zdefiniowaniu kontenera można go ponownie utworzyć i uruchomić w taki sam sposób. Ta niezmienność nadaje się do projektowania opartego na składnikach. Jeśli niektóre części aplikacji ewoluują inaczej niż inne, dlaczego ponownie wdrożysz całą aplikację, gdy możesz po prostu wdrożyć części, które zmieniają się najczęściej? Różne funkcje i przekrojowe kwestie aplikacji można rozbić na oddzielne jednostki. Rysunek 3–2 pokazuje, jak aplikacja monolityczna może korzystać z kontenerów i mikroserwisów przez delegowanie niektórych funkcji lub możliwości. Pozostałe funkcje w samej aplikacji również zostały skoeneryzowane.

Rysunek 3–2. Dekompozycja aplikacji monolitycznej w celu przyjęcia mikrousług.

Każda usługa natywna dla chmury jest kompilowana i wdrażana w osobnym kontenerze. Każda z nich może być aktualizowana zgodnie z potrzebami. Poszczególne usługi mogą być hostowane w węzłach z zasobami odpowiednimi dla każdej usługi. Środowisko, w których działa każda usługa, jest niezmienne, współużytkowane w środowiskach deweloperskich, testowych i produkcyjnych oraz łatwe wersjonowane. Sprzężenie między różnymi obszarami aplikacji odbywa się jawnie jako wywołania lub komunikaty między usługami, a nie zależności czasu kompilacji w monolicie. Możesz również wybrać technologię, która najlepiej ustawia daną możliwość bez konieczności wprowadzania zmian w pozostałej części aplikacji.

Usługi konteneryzowane wymagają zautomatyzowanego zarządzania. Nie byłoby możliwe ręczne administrowanie dużym zestawem niezależnych wdrożonych kontenerów. Rozważmy na przykład następujące zadania:

• W jaki sposób wystąpienia kontenerów będą aprowizowane w klastrze wielu maszyn?
• Jak kontenery odnajdują się i komunikują się ze sobą po wdrożeniu?
• Jak kontenery mogą być skalowane na żądanie do wewnątrz lub na zewnątrz?
• Jak monitorować kondycję każdego kontenera?
• Jak chronić kontener przed awariami sprzętu i oprogramowania?
• Jak uaktualnić kontenery dla aplikacji na żywo z zerowym przestojem?

Koordynatorzy kontenerów adresują i automatyzują te i inne problemy.

W natywnym dla chmury systemie ekologicznym platforma Kubernetes stała się de facto orkiestratorem kontenerów. Jest to platforma typu open source zarządzana przez Cloud Native Computing Foundation (CNCF). Platforma Kubernetes automatyzuje wdrażanie, skalowanie i problemy operacyjne związane z konteneryzowanymi obciążeniami w klastrze maszynowym. Jednak instalowanie platformy Kubernetes i zarządzanie nią jest notorycznie złożone.

Znacznie lepszym podejściem jest wykorzystanie platformy Kubernetes jako usługi zarządzanej od dostawcy chmury. Chmura platformy Azure oferuje w pełni zarządzaną platformę Kubernetes zatytułowaną Azure Kubernetes Service (AKS). Usługa AKS upraszcza zarządzanie platformą Kubernetes, redukując złożoność i obciążenia operacyjne. Używasz platformy Kubernetes jako usługi w chmurze; Firma Microsoft ponosi odpowiedzialność za zarządzanie nim i wspieranie go. Usługa AKS ściśle integruje się również z innymi usługami platformy Azure i narzędziami deweloperskimi.

Usługa AKS to technologia oparta na klastrze. Pula federacyjnych maszyn wirtualnych lub węzłów jest wdrażana w chmurze platformy Azure. Razem tworzą środowisko o wysokiej dostępności lub klaster. Klaster jest wyświetlany jako spójna, pojedyncza jednostka w aplikacji chmurowej. Usługa AKS wdraża konteneryzowane usługi na tych węzłach zgodnie ze wstępnie zdefiniowaną strategią równomiernego rozłożenia obciążenia.

Jakie są korzyści ze skalowania?

Usługi oparte na kontenerach mogą korzystać z korzyści ze skalowania zapewnianych przez narzędzia orkiestracji, takie jak Kubernetes. Kontenery z założenia wiedzą tylko o sobie. Po utworzeniu wielu kontenerów, które muszą współpracować, należy zorganizować je na wyższym poziomie. Organizowanie dużej liczby kontenerów i ich współużytkowanych zależności, takich jak konfiguracja sieci, to właśnie miejsce, gdzie narzędzia orkiestracji przychodzą z pomocą! Platforma Kubernetes tworzy warstwę abstrakcji na grupach kontenerów i organizuje je w zasobniki. Pody są uruchamiane na maszynach roboczych nazywanych węzłami. Ta zorganizowana struktura jest określana jako klaster. Rysunek 3–3 przedstawia różne składniki klastra Kubernetes.

Rysunek 3–3. Składniki klastra Kubernetes.

Skalowanie konteneryzowanych obciążeń to kluczowa funkcja orkiestratorów kontenerów. Usługa AKS obsługuje automatyczne skalowanie w dwóch aspektach: instancje kontenerów oraz węzły obliczeniowe. Razem zapewniają usłudze AKS możliwość szybkiego i wydajnego reagowania na wzrost zapotrzebowania i dodawania dodatkowych zasobów. W dalszej części tego rozdziału omówimy skalowanie w usłudze AKS.

Deklaratywne a imperatywne

Platforma Kubernetes obsługuje zarówno konfigurację deklaratywną, jak i imperatywne. Podejście imperatywne polega na uruchomieniu różnych poleceń, które informują platformę Kubernetes o tym, co należy zrobić w każdym kroku. Uruchom ten obraz. Usuń ten kontener. Uwidocznij ten port. W przypadku podejścia deklaratywnego należy utworzyć plik konfiguracji nazywany manifestem, aby opisać, co chcesz zrobić, zamiast tego, co należy zrobić. Platforma Kubernetes odczytuje manifest i przekształca żądany stan końcowy na rzeczywisty stan zakończenia.

Polecenia imperatywne doskonale nadają się do uczenia się i interakcyjnego eksperymentowania. Jednak należy deklaratywnie utworzyć pliki manifestu Kubernetes, aby zastosować podejście infrastruktury jako kodeksu, zapewniając niezawodne i powtarzalne wdrożenia. Plik manifestu staje się artefaktem projektu i jest używany w potoku CI/CD do automatyzacji wdrożeń Kubernetes.

Jeśli klaster został już skonfigurowany przy użyciu poleceń imperatywnych, możesz wyeksportować manifest deklaratywny przy użyciu polecenia kubectl get svc SERVICENAME -o yaml > service.yaml. To polecenie tworzy manifest podobny do przedstawionego poniżej:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-09-13T13:58:47Z"
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
  resourceVersion: "153"
  selfLink: /api/v1/namespaces/default/services/kubernetes
  uid: 9b1fac62-d62e-11e9-8968-00155d38010d
spec:
  clusterIP: 10.96.0.1
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 6443
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

W przypadku korzystania z konfiguracji deklaratywnej można wyświetlić podgląd zmian, które mają zostać wprowadzone przed ich zatwierdzeniem przez użycie kubectl diff -f FOLDERNAME w folderze, w którym znajdują się pliki konfiguracji. Gdy na pewno chcesz zastosować zmiany, uruchom polecenie kubectl apply -f FOLDERNAME. Dodaj -R element , aby rekursywnie przetwarzać hierarchię folderów.

Można również użyć konfiguracji deklaratywnej z innymi funkcjami platformy Kubernetes, z których jednym z nich są wdrożenia. Wdrożenia deklaratywne ułatwiają zarządzanie wydaniami, aktualizacjami i skalowaniem. Instruują kontroler zasobu wdrożeniowego Kubernetes na temat wdrażania nowych zmian, skalowania zasobów według potrzeby lub wycofania do poprzedniej wersji. Jeśli klaster jest niestabilny, wdrożenie deklaratywne automatycznie zwróci klaster z powrotem do żądanego stanu. Jeśli na przykład węzeł przypadkowo ulegnie awarii, mechanizm wdrażania ponownie wdroży jego zastąpienie w celu osiągnięcia żądanego stanu.

Użycie konfiguracji deklaratywnej umożliwia reprezentowanie infrastruktury jako kodu, który można zaewidencjonować i wersjonować wraz z kodem aplikacji. Zapewnia lepsze zarządzanie zmianami i lepszą obsługę ciągłego wdrażania przy użyciu pipeline kompilacji i wdrażania.

Jakie scenariusze są idealne dla kontenerów i orchestratorów?

Poniższe scenariusze są idealne do stosowania kontenerów i orkiestratorów.

Aplikacje wymagające wysokiej dostępności i skalowalności

Poszczególne aplikacje, które mają wymagania dotyczące wysokiej dostępności i skalowalności, są idealnymi kandydatami do architektur natywnych dla chmury przy użyciu mikrousług, kontenerów i orkiestratorów. Można je opracowywać w kontenerach, testować w wersjonowanych środowiskach i wdrażać w środowisku produkcyjnym bez przestojów. Użycie klastrów Kubernetes zapewnia, że takie aplikacje mogą być również skalowane na żądanie i automatycznie odzyskiwane po awariach węzłów.

Duża liczba aplikacji

Organizacje, które wdrażają i utrzymują dużą liczbę aplikacji, korzystają z kontenerów i koordynatorów. Nakład pracy z góry podczas konfigurowania konteneryzowanych środowisk i klastrów Kubernetes jest przede wszystkim kosztem stałym. Wdrażanie, konserwowanie i aktualizowanie poszczególnych aplikacji ma koszt, który różni się w zależności od liczby aplikacji. Poza kilkoma aplikacjami złożoność obsługi niestandardowych aplikacji ręcznie przekracza koszt implementacji rozwiązania przy użyciu kontenerów i koordynatorów.

Kiedy należy unikać używania kontenerów i orchestratorów?

Jeśli nie możesz zbudować aplikacji zgodnie z zasadami aplikacji Twelve-Factor, rozważ uniknięcie kontenerów i orchestratorów. W takich przypadkach należy rozważyć platformę hostingu opartą na maszynie wirtualnej lub ewentualnie jakiś system hybrydowy. Za jego pomocą można zawsze wydzielić niektóre moduły funkcjonalne do oddzielnych kontenerów, a nawet funkcji bezserwerowych.

Zasoby rozwojowe

W tej sekcji przedstawiono krótką listę zasobów programistycznych, które mogą ułatwić rozpoczęcie korzystania z kontenerów i koordynatorów dla następnej aplikacji. Jeśli szukasz wskazówek dotyczących projektowania aplikacji architektury mikrousług natywnych dla chmury, przeczytaj towarzysza tej książki , .NET Microservices: Architecture for Containerized .NET Applications (Architektura konteneryzowanych aplikacji platformy .NET).

Tworzenie lokalnego rozwiązania Kubernetes

Wdrożenia platformy Kubernetes zapewniają dużą wartość w środowiskach produkcyjnych, ale mogą być również uruchamiane lokalnie na maszynie deweloperów. Mimo że poszczególne mikrousługi mogą działać niezależnie, czasami konieczne będzie uruchomienie całego systemu lokalnie — tak samo jak po wdrożeniu w środowisku produkcyjnym. Istnieje kilka narzędzi, które mogą pomóc: Minikube i Docker Desktop. Program Visual Studio udostępnia również narzędzia do programowania na platformie Docker.

Minikube

Co to jest Minikube? Projekt Minikube mówi: "Minikube implementuje lokalny klaster Kubernetes w systemach macOS, Linux i Windows". Jego głównymi celami są "najlepsze narzędzie do tworzenia lokalnych aplikacji Kubernetes i obsługa wszystkich funkcji platformy Kubernetes pasujących do tych potrzeb". Instalowanie aplikacji Minikube jest oddzielone od platformy Docker, ale aplikacja Minikube obsługuje różne funkcje hypervisor niż obsługuje program Docker Desktop. Następujące funkcje platformy Kubernetes są obecnie obsługiwane przez firmę Minikube:

• System Nazw Domenowych (DNS)
• NodePorts
• ConfigMaps i wpisy tajne
• Panele informacyjne
• Środowiska uruchomieniowe kontenerów: Docker, rkt, CRI-O i containerd
• Włączanie interfejsu sieciowego kontenera (CNI)
• Wejście

Po zainstalowaniu aplikacji Minikube możesz szybko rozpocząć korzystanie z niego, uruchamiając minikube start polecenie , które pobiera obraz i uruchamia lokalny klaster Kubernetes. Po uruchomieniu klastra będziesz z nim korzystać przy użyciu standardowych poleceń platformy Kubernetes kubectl .

Docker Desktop

Możesz również pracować z platformą Kubernetes bezpośrednio z poziomu programu Docker Desktop w systemie Windows. Jest to jedyna opcja, jeśli używasz kontenerów systemu Windows i jest doskonałym wyborem dla kontenerów innych niż Windows. Rysunek 3–4 przedstawia sposób włączania obsługi lokalnej platformy Kubernetes podczas uruchamiania programu Docker Desktop.

Rysunek 3–4. Konfigurowanie platformy Kubernetes w programie Docker Desktop.

Docker Desktop jest najpopularniejszym narzędziem do konfigurowania i uruchamiania aplikacji konteneryzowanych lokalnie. Podczas pracy z usługą Docker Desktop można opracowywać lokalnie na dokładnie tym samym zestawie obrazów kontenerów platformy Docker, które zostaną wdrożone w środowisku produkcyjnym. Program Docker Desktop jest przeznaczony do lokalnego tworzenia, testowania i dostarczania konteneryzowanych aplikacji. Obsługuje zarówno kontenery systemu Linux, jak i Windows. Po przesłaniu obrazów do rejestru obrazów, takiego jak Azure Container Registry lub Docker Hub, AKS może je pobrać i wdrożyć w środowisku produkcyjnym.

Narzędzia Dockera w Visual Studio

Program Visual Studio obsługuje tworzenie aplikacji internetowych na platformie Docker. Podczas tworzenia nowej aplikacji ASP.NET Core możesz ją skonfigurować przy użyciu obsługi platformy Docker, jak pokazano na rysunku 3–5.

Rysunek 3–5. Włącz obsługę Docker w programie Visual Studio

Po wybraniu tej opcji projekt zostanie utworzony za pomocą elementu Dockerfile w katalogu głównym, który może służyć do kompilowania i hostowania aplikacji w kontenerze platformy Docker. Przykładowy plik Dockerfile jest wyświetlany na rysunku 3–6.

FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["eShopWeb/eShopWeb.csproj", "eShopWeb/"]
RUN dotnet restore "eShopWeb/eShopWeb.csproj"
COPY . .
WORKDIR "/src/eShopWeb"
RUN dotnet build "eShopWeb.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "eShopWeb.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "eShopWeb.dll"]

Rysunek 3–6. Plik Dockerfile wygenerowany w programie Visual Studio

Po dodaniu obsługi możesz uruchomić aplikację w kontenerze platformy Docker w programie Visual Studio. Rysunek 3–7 przedstawia różne opcje uruchamiania dostępne w nowym projekcie ASP.NET Core utworzonym przy użyciu dodanej obsługi platformy Docker.

Rysunek 3–7. Opcje uruchamiania platformy Docker programu Visual Studio

Ponadto w dowolnym momencie możesz dodać obsługę platformy Docker do istniejącej aplikacji ASP.NET Core. W Eksploratorze rozwiązań programu Visual Studio kliknij prawym przyciskiem myszy projekt i wybierz polecenie Dodaj>obsługę platformy Docker, jak pokazano na rysunku 3-8.

Rysunek 3–8. Dodawanie obsługi platformy Docker do programu Visual Studio

Narzędzia Dockera w Visual Studio Code

Istnieje wiele rozszerzeń dostępnych dla programu Visual Studio Code, które obsługują programowanie na platformie Docker.

Firma Microsoft udostępnia rozszerzenie Docker for Visual Studio Code. To rozszerzenie upraszcza proces dodawania obsługi kontenerów do aplikacji. Tworzy szkielet wymaganych plików, kompiluje obrazy platformy Docker i umożliwia debugowanie aplikacji wewnątrz kontenera. Rozszerzenie zawiera eksploratora wizualizacji, który ułatwia wykonywanie akcji dotyczących kontenerów i obrazów, takich jak uruchamianie, zatrzymywanie, inspekcja, usuwanie i nie tylko. Rozszerzenie obsługuje również platformę Docker Compose, umożliwiając zarządzanie wieloma uruchomionymi kontenerami jako pojedynczą jednostką.

PoprzedniNastępny