Programmering

Forståelse af Azure Arc

En af de mere interessante meddelelser på Microsofts Ignite-konference i 2019 var Azure Arc, et nyt styringsværktøj til hybrid cloud-applikationsinfrastrukturer. Baseret på Azure-koncepter er Arc designet til at give dig mulighed for at administrere lokale ressourcer fra Azure Portal, implementere politikker og tjenester til virtuelle maskiner og Kubernetes. Det inkluderer også containeriserede versioner af Azure's SQL Database og PostgreSQL Hyperscale for at give dine Kubernetes-baserede hybridapplikationer Azure-konsistente dataindstillinger.

Azure Arc udvider Azure Resource Manager-modellen ned til servere og Kubernetes-klynger. Det er designet til at administrere ressourcer på en skylignende måde, uanset hvor de er, og behandle Azures ressourceværktøj som dit kontrolplan. Det sætter det på et meget højere niveau end de fleste styringsværktøjer. For eksempel, hvis du bruger det med virtuelle maskiner, der kører på et Windows Server-netværk, vil du administrere VM'erne med Hyper-V-styringsværktøjer og serverkonfigurationen og applikationer, der kører på dem med Azure Arc.

Brug af Azure Arc med servere

"Hvor de end er" er et nøgleprincip bag Azure Arc. Med sit applikationsadministrationsfokus er det agnostisk infrastruktur. De virtuelle computere, den administrerer, kan køre i dit datacenter, i en hostingfacilitet eller som virtuelle servere i et administreret, delt miljø.

Serveradministration med Azure Arc er nu i offentlig forhåndsvisning med en tilsluttet maskinagent til Windows og Linux til at håndtere forbindelse til Azure Arc-tjenesten. Når du har oprettet forbindelse til skyen, kan du begynde at administrere den, som om den var en Azure-ressource, en del af en ressourcegruppe. Dette giver dig mulighed for at distribuere PowerShell-baserede politikker til tilsluttede servere og udnytte det arbejde, der er udført for at levere just-in-time management og ønsket tilstandskonfiguration. Administrerede servere skal have forbindelse til Azure Arc via SSL.

Servere, der administreres af Azure Arc, behøver ikke at være fysiske servere; de kan være virtuelle maskiner. Dette giver dig mulighed for at forudindlæse agenten i VM-basisbilleder, før de implementeres. Som en del af opsætningen af ​​tjenesten genererer Azure Arc et brugerdefineret script, der kører på ikke-tilsluttede servere, downloader og installerer agenten, før den opretter forbindelse til Azure og tilføjer serveren som en ressource.

Administration af Kubernetes-applikationer i Azure Arc

Microsoft har endnu ikke gjort Azure Arc's Kubernetes-support tilgængelig i den offentlige forhåndsvisning; det er stadig begrænset til tjenestens forhåndsvisning af privat adgang. Gabe Monroy, direktør for produkt for Azure Application Platform, gav dog en kort demonstration af det på Ignite.

Ved hjælp af Azure Portal viste Monroy først en kørende Kubernetes-klynge, der blev administreret ved hjælp af Azure ARM-baserede politikker. Den oprindelige politik, han brugte, kontrollerede netværksporte, der blev brugt af klyngen, og låste unødvendige porte ned for at reducere klyngens angrebsflade. Den samme politik kunne bruges til at styre alle klynger på tværs af en virksomheds globale infrastruktur. At skrive politikker en gang og bruge dem mange gange som dette holder risikoen for fejl på et minimum; ved at teste alle dine politikker på forhånd kan du være sikker på, at de fungerer, når de implementeres globalt.

Den anden fordel ved en politikbaseret tilgang er, at du kan låse klynger ned, hvis de ikke er kompatible. Indtil en klynge rapporterer, at den er i overensstemmelse med alle dine politikker, kan dit applikationsudviklingsteam ikke implementere kode. Med Azure Arc-agenten implementeret i alle Kubernetes-klynger i dit netværk har du en rude med glas til at styre alle politikker og alle implementeringer.

Det er vigtigt at bemærke, at du ikke har en måde at administrere de fysiske servere og Kubernetes-installationen direkte på. Alt Azure Portal giver dig er de politikker og koden, der kører på klyngen. Du kan bruge politikker til at definere, hvordan en klynge opfører sig, men du kan ikke distribuere nye noder, medmindre Kubernetes-runtime og Azure Arc-agenten er installeret. Så snart en ny klynge er implementeret og forbundet til Azure Arc, anvendes politikker automatisk, hvilket sikrer, at dine sikkerhedspolitikker er på plads uden manuelt at konfigurere alt.

Et interessant aspekt af demonstrationen var en politik, der forbandt Azure Arc til GitHub, målrettet mod enten Kubernetes navneområder eller klynger og håndterede implementeringer fra et specifikt lager. Ved hjælp af denne politik vil enhver pull-anmodning til lageret udløse en implementering af en opdateret applikation. Den samme politik kunne bruges til at indlæse din kode i en ny klynge, så snart den blev konfigureret. Enhver fremtidig opdatering af koden distribueres automatisk, så alle dine sider kører de nyeste versioner.

Det er let at forestille sig, at et nyt sæt servere, forudindlæst med Kubernetes og Azure Arc-agenten, leveres til et nyt kantsted. Når de er tilsluttet et WAN og tændt, indlæser de automatisk de nyeste politikker, og når de overholder kravene, vil de downloade deres applikationer og begynde at fungere med minimal menneskelig interaktion.

Vi introducerer en ny sky-centreret, app-første styringsmodel

Det er måske bedst at tænke på Azure Arc som den første af en ny generation af policy-driven applikationsadministrationsværktøjer, især når den bruges til at automatisere applikationsimplementeringer på tværs af et globalt netværk. Det er fornuftigt at integrere det i din gitops-strøm ved at bruge Arc til at udløse applikationsinstallationer, når en pull-anmodning flettes, og sikre, at de relevante sikkerhedspolitikker anvendes på værts-Kubernetes-klyngen eller virtuelle maskiner.

Microsofts opfattelse af skyen er, at lokale systemer ikke forsvinder, og med den voksende betydning af kantimplementeringer vil definitionen af ​​lokale kun vokse, det betyder ikke, at disse lokale systemer ikke burde ikke drage fordel af cloud-teknologier og cloud-informerede måder at arbejde på. Azure Arc er fokuseret på at automatisere infrastrukturen til en applikation ved hjælp af politik for at sikre overholdelse af sikkerhed.

Når du tænker over det, er dette en logisk udvidelse af devops og en del af bevægelsen til et tredje niveau af ledelse i et skymiljø. Med fokus på virtuelle applikationsinfrastrukturer, hvad enten det er VM eller containerbaseret, adskiller Azure Arc applikationshandlinger fra infrastrukturoperationer.

I et hybrid-cloud-miljø er der ikke behov for, at applikationsteamet ved noget om den underliggende fysiske infrastruktur. I stedet vil et separat team have ansvaret for fysiske servere, værtsoperativsystemer, hypervisorer og Kubernetes-installation med værktøjer som Azure Arc, der bruges af applikationsteamet til at administrere deres applikationer i udkanten, i hyperkonvergerede systemer, i traditionelle datacentre og i skyen, alt fra den samme cloud-hostede konsol.

Vi har ændret den måde, vi kører infrastruktur med containere og virtualisering på, og måden vi bygger og administrerer applikationer med devops på. Hvorfor ikke give værktøjer til at samle de to tilgange? Med Azure Arc får opsiden af ​​devops-ligningen en platform til at adskille applikationer fra infrastruktur med evnen til at administrere og kontrollere disse applikationer fra et nyt, skyhostet kontrolplan. Det er en attraktiv vision, og det vil være interessant at se, hvordan Microsoft leverer det.