Udostępnij przez

Zmiana architektury aplikacji internetowej PLATFORMy AWS EKS dla usługi Azure Kubernetes Service (AKS)

Teraz, gdy masz lepsze zrozumienie różnic między platformami AWS i Azure, przyjrzyjmy się architekturze aplikacji internetowej na platformie AWS i modyfikacjom potrzebnym do zapewnienia zgodności z usługą Azure Kubernetes Service (AKS).

Architektura aplikacji Yelb

Przykładowa aplikacja internetowa Yelb składa się ze składnika frontonu o nazwie yelb-ui i składnika aplikacji o nazwie yelb-appserver.

Diagram architektury aplikacji internetowej Yelb.

Element yelb-ui obsługuje kod JavaScript w przeglądarce. Ten kod jest kompilowany z aplikacji Angular . Składnik yelb-ui może również zawierać nginx serwer proxy w zależności od modelu wdrażania. yelb-appserver jest aplikacją Sinatra, która współpracuje z serwerem pamięci podręcznej (redis-server) i bazą danych Postgres na warstwie zaplecza (yelb-db). Usługa Redis Cache przechowuje liczbę wyświetleń stron, podczas gdy usługa PostgreSQL utrwala głosy. Obie usługi są wdrażane na platformie Kubernetes bez używania żadnej zarządzanej usługi do przechowywania danych na platformie AWS lub na platformie Azure.

Oryginalna aplikacja Yelb jest samodzielna i nie korzysta z usług zewnętrznych, więc możesz migrować ją z platformy AWS na platformę Azure bez żadnych zmian w kodzie. Na platformie Azure możesz użyć usług Azure Cache for Redis i Azure Database for PostgreSQL jako zamienników usług Redis Cache i PostgreSQL wdrożonych w usłudze AKS.

Przykładowa aplikacja Yelb umożliwia użytkownikom głosowanie nad zestawem alternatyw (restauracji) i dynamicznie aktualizuje wykresy kołowe na podstawie liczby odebranych głosów. Aplikacja także śledzi liczbę wyświetleń stron i wyświetla nazwę hosta obsługującego wystąpienia yelb-appserver żądania API w trakcie głosowania lub odświeżania strony. Ta funkcja umożliwia niezależne lub wspólne pokazy aplikacji.

Zrzut ekranu interfejsu usługi Yelb.

Architektura na platformie AWS

Aby ułatwić ochronę aplikacji internetowych i interfejsów API przed typowymi programami wykorzystującymi luki w sieci Web, platforma AWS oferuje zaporę aplikacji internetowej platformy AWS iusługę AWS Firewall Manager.

Mapuj usługi AWS na usługi platformy Azure

Aby ponownie utworzyć obciążenie platformy AWS na platformie Azure z minimalnymi zmianami, użyj odpowiednika platformy Azure dla każdej usługi AWS. Poniższa tabela zawiera podsumowanie mapowań usług:

Mapowanie usług Usługa AWS Usługa platformy Azure
Zapora dostępu do internetu Zapora aplikacji internetowej platformy AWS (WAF) Zapora aplikacji internetowej platformy Azure (WAF)
Równoważenie obciążenia aplikacji Moduł równoważenia obciążenia aplikacji (ALB) Usługa Azure Application GatewayUsługa Application Gateway dla kontenerów (AGC)
Sieć dystrybucji treści Amazon CloudFront Azure Front Door (AFD)
Orkiestracja Elastic Kubernetes Service (EKS) Azure Kubernetes Service (AKS)
Skarbiec tajemnic Usługa zarządzania kluczami platformy AWS (KMS) Azure Key Vault
Rejestr kontenerów Amazon Elastic Container Registry (ECR) Azure Container Registry (ACR)
System nazw domen (DNS) Amazon Route 53 Azure DNS
Cache'owanie Amazon ElastiCache Azure Cache for Redis
NoSQL Amazon DynamoDB Azure Database for PostgreSQL

Aby uzyskać kompleksowe porównanie usług Azure i AWS, zobacz Porównanie usług AWS i Azure.

Architektura na platformie Azure

W tym rozwiązaniu aplikacja Yelb jest wdrażana w klastrze usługi AKS i jest widoczna za pośrednictwem kontrolera ruchu przychodzącego, takiego jak kontroler ruchu przychodzącego NGINX. Usługa kontrolera ruchu przychodzącego jest uwidaczniona za pośrednictwem wewnętrznego (lub prywatnego) modułu równoważenia obciążenia. Aby uzyskać więcej informacji na temat używania wewnętrznego modułu równoważenia obciążenia w celu ograniczenia dostępu do aplikacji w usłudze AKS, zobacz Używanie wewnętrznego modułu równoważenia obciążenia z usługą Azure Kubernetes Service (AKS).

Ten przykład obsługuje instalowanie zarządzanego kontrolera ruchu przychodzącego NGINX z dodatkiem routingu aplikacji lub niezarządzanym kontrolerem ruchu przychodzącego NGINX przy użyciu wykresu Helm. Dodatek routingu aplikacji z kontrolerem ruchu przychodzącego NGINX zapewnia następujące funkcje:

Inne konfiguracje można znaleźć w następujących artykułach:

Aplikacja Yelb jest zabezpieczona za pomocą zasobu usługi Azure Application Gateway wdrożonego w dedykowanej podsieci w tej samej sieci wirtualnej co klaster usługi AKS lub w równorzędnej sieci wirtualnej. Dostęp do aplikacji Yelb można zabezpieczyć przy użyciu usługi Azure Web Application Firewall (WAF), która zapewnia scentralizowaną ochronę aplikacji internetowych przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach.

Projekt architektury rozwiązania

Na poniższym diagramie przedstawiono zalecaną architekturę na platformie Azure:

Diagram rozwiązania na podstawie WAFv2 bramy aplikacyjnej i kontrolera wejściowego NGINX.

Architektura rozwiązania składa się z następujących elementów:

  1. Usługa Application Gateway obsługuje kończenie żądań PROTOKOŁU TLS i komunikuje się z aplikacją zaplecza za pośrednictwem protokołu HTTPS.
  2. Odbiornik usługi Application Gateway używa certyfikatu SSL uzyskanego z usługi Azure Key Vault.
  3. Zasady zapory sieci aplikacyjnej platformy Azure skojarzone z nasłuchującym stosują reguły OWASP i reguły niestandardowe do przychodzących żądań i blokują złośliwe ataki.
  4. Ustawienia HTTP zaplecza usługi Application Gateway wywołują aplikację Yelb za pośrednictwem protokołu HTTPS na porcie 443.
  5. Pula zaplecza usługi Application Gateway i sonda kondycji wywołają kontroler ruchu przychodzącego NGINX za pośrednictwem wewnętrznego modułu równoważenia obciążenia usługi AKS przy użyciu protokołu HTTPS.
  6. Kontroler ingress NGINX używa wewnętrznego load balancera AKS.
  7. Klaster AKS jest skonfigurowany z użyciem dostawcy usługi Azure Key Vault dla dodatku CSI Driver do magazynu tajemnic, aby pobierać tajemnice, certyfikaty i klucze z Azure Key Vault przez wolumen CSI.
  8. Klasa SecretProviderClass pobiera ten sam certyfikat używany przez usługę Application Gateway z usługi Azure Key Vault.
  9. Obiekt ingresa Kubernetes wykorzystuje kontroler ingresa NGINX do wystawienia aplikacji przez HTTPS za pomocą wewnętrznego modułu równoważenia obciążenia AKS.
  10. Usługa Yelb jest typu ClusterIP i jest uwidoczniona za pośrednictwem kontrolera ruchu przychodzącego NGINX.

Aby uzyskać kompleksowe instrukcje dotyczące wdrażania aplikacji Yelb w usłudze AKS przy użyciu tej architektury, zobacz przykład towarzyszący.

Rozwiązania alternatywne

Platforma Azure oferuje kilka opcji wdrażania aplikacji internetowej w klastrze usługi AKS i zabezpieczania jej za pomocą zapory aplikacji internetowej:

Kontroler ruchu przychodzącego usługi Application Gateway (AGIC) to aplikacja Kubernetes, dzięki czemu możesz wykorzystać natywny moduł równoważenia obciążenia usługi Application Gateway L7 platformy Azure w celu uwidocznienia oprogramowania w chmurze dla obciążeń usługi Azure Kubernetes Service (AKS). Usługa AGIC monitoruje klaster Kubernetes, w ramach którego jest hostowany i stale aktualizuje usługę Application Gateway, tak aby wybrane usługi były uwidocznione w Internecie.

Diagram rozwiązania opartego na kontrolerze wejściowym usługi Azure Application Gateway.

Kontroler wejściowy działa w swoim własnym zasobniku w klastrze AKS. Narzędzie AGIC monitoruje podzestaw zasobów Kubernetes pod kątem zmian, tłumaczy stan klastra na konkretną konfigurację usługi Application Gateway i stosuje go do usługi Azure Resource Manager (ARM). Aby uzyskać więcej informacji, zobacz Co to jest kontroler Ingress dla Application Gateway?.

W poniższej tabeli przedstawiono zasadnicze zalety i wady kontrolera wejściowego Application Gateway (AGIC):

Zalety Niekorzyści
* Integracja natywna: AGIC zapewnia natywną integrację z usługami platformy Azure, w szczególności z usługą Azure Application Gateway, która umożliwia bezproblemowe i wydajne kierowanie ruchu do usług działających na AKS.
* Uproszczone wdrożenia: Wdrażanie dodatku AGIC jako dodatku AKS jest proste i prostsze w porównaniu z innymi metodami. Umożliwia szybką i łatwą konfigurację Application Gateway i klastra AKS z włączonym AGIC.
* W pełni zarządzana usługa: AGIC jako dodatek jest w pełni zarządzaną usługą, zapewniając korzyści, takie jak aktualizacje automatyczne i zwiększona obsługa firmy Microsoft. Zapewnia to, że kontroler Ingress pozostaje up-to-date i dodaje kolejną warstwę wsparcia.		 * Podejście pojedynczej chmury: AGIC jest przede wszystkim wdrażane przez klientów, którzy stosują podejście z jedną chmurą. Może to nie być najlepszy wybór, jeśli potrzebujesz architektury wielochmurowej, w której wdrożenie na różnych platformach w chmurze jest wymagane. W takim przypadku możesz chcieć użyć niezależnego od chmury kontrolera ruchu przychodzącego, takiego jak NGINX, Traefik lub HAProxy, aby uniknąć problemów z vendo-lockin.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

  • Last updated on