Zrozumieć Azure Arc

Jedną z ciekawszych zapowiedzi na konferencji Microsoft 2019 Ignite była Azure Arc, nowe narzędzie do zarządzania infrastrukturami aplikacji chmury hybrydowej. Opierając się na koncepcjach platformy Azure, Arc został zaprojektowany, aby umożliwić zarządzanie zasobami lokalnymi z witryny Azure Portal, wdrażanie zasad i usług na maszynach wirtualnych i platformie Kubernetes. Obejmuje również konteneryzowane wersje Azure SQL Database i PostgreSQL Hyperscale, aby zapewnić aplikacjom hybrydowym opartym na Kubernetes opcje danych spójne z Azure.

Azure Arc rozszerza model Azure Resource Manager na serwery i klastry Kubernetes. Został zaprojektowany do zarządzania zasobami w sposób podobny do chmury, gdziekolwiek się znajdują, traktując narzędzia zasobów platformy Azure jako płaszczyznę kontroli. To stawia go na znacznie wyższym poziomie niż większość narzędzi do zarządzania. Na przykład, jeśli używasz go z maszynami wirtualnymi działającymi w sieci Windows Server, możesz zarządzać maszynami wirtualnymi za pomocą narzędzi do zarządzania Hyper-V oraz konfiguracją serwera i uruchomionymi na nich aplikacjami za pomocą Azure Arc.

Używanie Azure Arc z serwerami

„Gdziekolwiek są” to kluczowa zasada Azure Arc. Skupiając się na zarządzaniu aplikacjami, jest niezależny od infrastruktury. Zarządzane przez niego maszyny wirtualne mogą działać w Twoim centrum danych, w obiekcie hostingowym lub jako serwery wirtualne w zarządzanym, współdzielonym środowisku.

Zarządzanie serwerem za pomocą Azure Arc jest teraz dostępne w publicznej wersji zapoznawczej, z agentem połączonego komputera dla systemu Windows i Linux do obsługi połączenia z usługą Azure Arc. Po nawiązaniu połączenia z chmurą można rozpocząć zarządzanie nią tak, jakby była zasobem platformy Azure, częścią grupy zasobów. Umożliwia to wdrażanie zasad opartych na programie PowerShell na połączonych serwerach, wykorzystując pracę wykonaną w celu zapewnienia zarządzania just in time i żądanej konfiguracji stanu. Zarządzane serwery będą wymagały łączności z Azure Arc za pośrednictwem protokołu SSL.

Serwery zarządzane przez Azure Arc nie muszą być serwerami fizycznymi; mogą to być maszyny wirtualne. Umożliwia to wstępne załadowanie agenta do obrazów podstawowych maszyn wirtualnych przed ich wdrożeniem. W ramach konfigurowania usługi Azure Arc generuje niestandardowy skrypt, który będzie działał na niepołączonych serwerach, pobierając i instalując agenta przed połączeniem się z platformą Azure i dodaniem serwera jako zasobu.

Zarządzanie aplikacjami Kubernetes w Azure Arc

Firma Microsoft nie udostępniła jeszcze obsługi Kubernetes platformy Azure Arc w publicznej wersji zapoznawczej; nadal ogranicza się do prywatnego podglądu dostępu do usługi. Jednak Gabe Monroy, dyrektor produktu platformy Azure Application Platform, zademonstrował to krótko podczas konferencji Ignite.

Korzystając z portalu Azure, firma Monroy po raz pierwszy pokazała działający klaster Kubernetes, który był zarządzany przy użyciu zasad opartych na platformie Azure ARM. Początkowa polityka, której użył, kontrolowała porty sieciowe używane przez klaster, blokując niepotrzebne porty, aby zmniejszyć powierzchnię ataku klastra. Tej samej zasady można użyć do zarządzania wszystkimi klastrami w globalnej infrastrukturze firmy. Pisanie polityk raz i używanie ich wiele razy w ten sposób ogranicza do minimum ryzyko błędów; testując wszystkie zasady z wyprzedzeniem, możesz mieć pewność, że będą działać po wdrożeniu na całym świecie.

Inną zaletą podejścia opartego na zasadach jest to, że można zablokować klastry, jeśli nie są one zgodne. Dopóki klaster nie zgłosi, że jest zgodny ze wszystkimi zasadami, zespół programistów aplikacji nie może wdrożyć kodu. Dzięki agentowi Azure Arc wdrożonemu we wszystkich klastrach Kubernetes w Twojej sieci masz jeden panel do zarządzania wszystkimi zasadami i wszystkimi wdrożeniami.

Należy pamiętać, że nie masz możliwości bezpośredniego zarządzania serwerami fizycznymi i instalacją Kubernetes. Wszystkie podane w witrynie Azure Portal zasady i kod działający w klastrze. Możesz użyć zasad, aby zdefiniować zachowanie klastra, ale nie możesz wdrażać nowych węzłów, chyba że zainstalowano środowisko wykonawcze Kubernetes i agenta Azure Arc. Gdy tylko nowy klaster zostanie wdrożony i połączony z Azure Arc, zasady są stosowane automatycznie, zapewniając, że zasady bezpieczeństwa są na miejscu bez ręcznego konfigurowania wszystkiego.

Jednym z interesujących aspektów demonstracji była polityka, która łączyła Azure Arc z GitHub, celując w przestrzenie nazw Kubernetes lub klastry i obsługując wdrożenia z określonego repozytorium. Korzystając z tej zasady, każde żądanie ściągnięcia skierowane do repozytorium spowodowałoby wdrożenie zaktualizowanej aplikacji. Tej samej zasady można użyć do załadowania kodu do nowego klastra zaraz po jego skonfigurowaniu. Każda przyszła aktualizacja kodu zostanie wdrożona automatycznie, zachowując najnowsze wersje we wszystkich witrynach.

Łatwo sobie wyobrazić nowy zestaw serwerów, wstępnie załadowany Kubernetes i agent Azure Arc, dostarczany do nowej lokalizacji brzegowej. Po podłączeniu do sieci WAN i włączeniu, automatycznie ładowali najnowsze zasady, a gdy były zgodne, pobierały swoje aplikacje i zaczynały działać przy minimalnej interakcji człowieka.

Przedstawiamy nowy model zarządzania zorientowany na chmurę, który polega na pierwszym uruchomieniu aplikacji

Być może najlepiej jest pomyśleć o Azure Arc jako o pierwszym z nowej generacji narzędzi do zarządzania aplikacjami opartymi na zasadach, zwłaszcza gdy jest używany do automatyzacji wdrażania aplikacji w sieci globalnej. Zintegrowanie go z przepływem gitops ma sens, używając Arc do wyzwalania wdrożeń aplikacji po scaleniu żądania ściągnięcia i zapewnienia, że ​​odpowiednie zasady bezpieczeństwa są stosowane do klastra Kubernetes lub maszyn wirtualnych hosta.

Zdaniem firmy Microsoft na temat chmury systemy lokalne nie znikają, a wraz ze wzrostem znaczenia wdrożeń brzegowych definicja lokalnego będzie się tylko rozszerzać. Nie oznacza to, że te systemy lokalne nie powinny nie czerpać korzyści z technologii chmurowych i sposobów pracy opartych na chmurze. Azure Arc koncentruje się na automatyzacji infrastruktury aplikacji przy użyciu zasad w celu zapewnienia zgodności zabezpieczeń.

Kiedy się nad tym zastanowić, jest to logiczne rozszerzenie DevOps i część przejścia do trzeciego poziomu zarządzania w środowisku chmurowym. Koncentrując się na wirtualnych infrastrukturach aplikacji, niezależnie od tego, czy są to maszyny wirtualne czy oparte na kontenerach, Azure Arc oddziela operacje aplikacji od operacji infrastrukturalnych.

W środowisku chmury hybrydowej nie ma potrzeby, aby zespół ds. Aplikacji wiedział cokolwiek o podstawowej infrastrukturze fizycznej. Zamiast tego oddzielny zespół będzie odpowiedzialny za fizyczne serwery, systemy operacyjne hosta, hiperwizory i instalację Kubernetes, z narzędziami takimi jak Azure Arc używanymi przez zespół aplikacji do zarządzania swoimi aplikacjami na krawędzi, w systemach hiperkonwergentnych, w tradycyjnych centrach danych i chmura, wszystko z tej samej konsoli hostowanej w chmurze.

Zmieniliśmy sposób, w jaki obsługujemy infrastrukturę z kontenerami i wirtualizacją, a także budujemy aplikacje i zarządzamy nimi za pomocą DevOps. Dlaczego nie zapewnić narzędzi do połączenia tych dwóch podejść? Dzięki Azure Arc strona ops równania devops otrzymuje platformę do oddzielania aplikacji od infrastruktury, z możliwością zarządzania tymi aplikacjami i kontrolowania ich z nowej płaszczyzny sterowania hostowanej w chmurze. To atrakcyjna wizja i ciekawie będzie obserwować, jak dostarcza ją Microsoft.