Programmering

Forstå Azure Arc

En av de mer interessante kunngjøringene på Microsofts 2019 Ignite-konferanse var Azure Arc, et nytt administrasjonsverktøy for hybrid skyapplikasjonsinfrastrukturer. Basert på Azure-konsepter, er Arc designet for å tillate deg å administrere lokale ressurser fra Azure Portal, distribuere policyer og tjenester til virtuelle maskiner og Kubernetes. Den inkluderer også containeriserte versjoner av Azure's SQL Database og PostgreSQL Hyperscale for å gi dine Kubernetes-baserte hybridapplikasjoner Azure-konsistente datalternativer.

Azure Arc utvider Azure Resource Manager-modellen ned til servere og Kubernetes-klynger. Den er designet for å administrere ressurser på en skylignende måte uansett hvor de er, og behandle Azures ressursverktøy som ditt kontrollplan. Det setter det på et mye høyere nivå enn de fleste styringsverktøy. Hvis du for eksempel bruker den med virtuelle maskiner som kjører på et Windows Server-nettverk, vil du administrere virtuelle maskiner med Hyper-V-styringsverktøy, og serverkonfigurasjonen og applikasjonene som kjører på dem med Azure Arc.

Bruker Azure Arc med servere

"Uansett hvor de er" er et sentralt prinsipp bak Azure Arc. Med sitt applikasjonsadministrasjonsfokus er det agnostisk infrastruktur. De virtuelle maskinene den administrerer, kan kjøre i datasenteret, i et vertsanlegg eller som virtuelle servere i et administrert, delt miljø.

Serveradministrasjon med Azure Arc er nå i offentlig forhåndsvisning, med en tilkoblet maskinagent for Windows og Linux for å håndtere tilkobling til Azure Arc-tjenesten. Når du er koblet til skyen, kan du begynne å administrere den som om det var en Azure-ressurs, en del av en ressursgruppe. Dette lar deg distribuere PowerShell-baserte policyer til tilkoblede servere, og dra nytte av arbeidet som er gjort for å levere just-in-time management og ønsket tilstandskonfigurasjon. Administrerte servere trenger tilkobling til Azure Arc over SSL.

Servere som administreres av Azure Arc trenger ikke å være fysiske servere; de kan være virtuelle maskiner. Dette lar deg forhåndslaste agenten i VM-basisbilder før de distribueres. Som en del av å konfigurere tjenesten, genererer Azure Arc et tilpasset skript som vil kjøre på ikke-tilkoblede servere, laste ned og installere agenten, før den kobles til Azure og legger til serveren som en ressurs.

Administrere Kubernetes-applikasjoner i Azure Arc

Microsoft har ikke gjort Azure Arc's Kubernetes-støtte tilgjengelig i offentlig forhåndsvisning ennå; det er fortsatt begrenset til tjenestens forhåndsvisning av privat tilgang. Imidlertid ga Gabe Monroy, direktør for produkt for Azure Application Platform, en kort demonstrasjon av det på Ignite.

Ved hjelp av Azure Portal viste Monroy først en løpende Kubernetes-klynge som ble administrert ved hjelp av Azure ARM-baserte policyer. Den opprinnelige policyen han brukte kontrollerte nettverksportene som ble brukt av klyngen, og låste unødvendige porter for å redusere klyngens angrepsflate. Den samme policyen kan brukes til å administrere alle klyngene på tvers av selskapets globale infrastruktur. Å skrive policyer én gang og bruke dem mange ganger som dette holder risikoen for feil på et minimum; ved å teste alle retningslinjene dine på forhånd, kan du være sikker på at de vil fungere når de brukes globalt.

Den andre fordelen med en policybasert tilnærming er at du kan låse klynger hvis de ikke er kompatible. Inntil en klynge rapporterer at den er i samsvar med alle retningslinjene dine, kan ikke programutviklingsteamet ditt distribuere kode. Med Azure Arc-agenten distribuert til alle Kubernetes-klyngene i nettverket ditt, har du ett glassrute for å administrere alle policyer og alle distribusjoner.

Det er viktig å merke seg at du ikke har en måte å administrere de fysiske serverne og Kubernetes-installasjonen direkte. Alt Azure Portal gir deg er retningslinjene og koden som kjører på klyngen. Du kan bruke policyer for å definere hvordan en klynge vil oppføre seg, men du kan ikke distribuere nye noder med mindre Kubernetes-kjøretiden og Azure Arc-agenten er installert. Så snart en ny klynge er distribuert og koblet til Azure Arc, blir policyer automatisk brukt, slik at sikkerhetspolicyene dine er på plass uten å manuelt konfigurere alt.

Et interessant aspekt av demonstrasjonen var en policy som koblet Azure Arc til GitHub, målrettet mot enten Kubernetes navnerom eller klynger og håndterte distribusjoner fra et bestemt depot. Ved å bruke denne policyen vil enhver pull-forespørsel til depotet utløse distribusjon av et oppdatert program. Den samme policyen kan brukes til å laste koden din inn i en ny klynge så snart den ble konfigurert. Enhver fremtidig oppdatering av koden vil automatisk distribueres, slik at alle nettstedene kjører de nyeste versjonene.

Det er lett å forestille seg at et nytt sett med servere, forhåndslastet med Kubernetes og Azure Arc-agenten, blir levert til et nytt kantsted. Når de er koblet til et WAN og slått på, laster de automatisk de siste retningslinjene, og når de overholder kravene, vil de laste ned applikasjonene og begynne å operere med minimal menneskelig interaksjon.

Vi presenterer en ny sky-sentrisk, app-første administrasjonsmodell

Det er kanskje best å tenke på Azure Arc som den første av en ny generasjon policystyrte applikasjonsadministrasjonsverktøy, spesielt når den brukes til å automatisere applikasjonsdistribusjoner over et globalt nettverk. Det er fornuftig å integrere det i gitops-strømmen, ved å bruke Arc for å utløse distribusjon av applikasjoner når en pull-forespørsel blir slått sammen og sikre at de riktige sikkerhetspolitikkene blir brukt på verts Kubernetes-klyngen eller virtuelle maskiner.

Microsofts syn på skyen er at lokale systemer ikke forsvinner, og med den økende betydningen av kantdistribusjoner, vil definisjonen av lokale bare vokse, det betyr ikke at de lokale systemene ikke burde ikke ha nytte av skyteknologier og skyinformerte måter å jobbe på. Azure Arc er fokusert på å automatisere infrastrukturen for en applikasjon, ved å bruke retningslinjer for å sikre samsvar med sikkerheten.

Når du tenker på det, er dette en logisk utvidelse av devops, og en del av bevegelsen til et tredje ledelsesnivå i et skymiljø. Med fokus på virtuelle applikasjonsapplikasjoner, enten VM eller containerbasert, skiller Azure Arc applikasjonsoperasjoner fra infrastrukturoperasjoner.

I et hybrid-sky-miljø trenger applikasjonsteamet ikke vite noe om den underliggende fysiske infrastrukturen. I stedet vil et eget team ha ansvar for fysiske servere, vertsoperativsystemer, hypervisorer og Kubernetes-installasjon, med verktøy som Azure Arc som brukes av applikasjonsteamet til å administrere applikasjonene på kanten, i hyperkonvergerte systemer, i tradisjonelle datasentre og i skyen, alt fra samme skyhostede konsoll.

Vi har endret måten vi driver infrastruktur med containere og virtualisering, og måten vi bygger og administrerer applikasjoner med devops på. Hvorfor ikke gi verktøy for å bringe de to tilnærmingene sammen? Med Azure Arc får opsiden av devops-ligningen en plattform for å skille applikasjoner fra infrastruktur, med muligheten til å administrere og kontrollere disse applikasjonene fra et nytt, skyhostet kontrollplan. Det er en attraktiv visjon, og det vil være interessant å se hvordan Microsoft leverer den.

$config[zx-auto] not found$config[zx-overlay] not found