Yksi mielenkiintoisimmista ilmoituksista Microsoftin vuoden 2019 Ignite-konferenssissa oli Azure Arc, uusi hallintatyökalu hybridipilvesovellusten infrastruktuureille. Azure-konseptien pohjalta Arc on suunniteltu antamaan sinun hallita paikallisia resursseja Azure-portaalista, sijoittamalla käytäntöjä ja palveluita virtuaalikoneisiin ja Kubernetesiin. Se sisältää myös Azuren SQL-tietokannan ja PostgreSQL Hyperscale -säilöintiversiot Kubernetes-pohjaisten hybridisovellusten antamiseksi Azure-yhdenmukaisille tietovaihtoehdoille.
Azure Arc laajentaa Azure Resource Manager -mallin palvelimiin ja Kubernetes-klustereihin. Se on suunniteltu hallitsemaan resursseja pilvimaisesti missä tahansa, käsittelemällä Azurin resurssityökaluja ohjaustasona. Se asettaa sen paljon korkeammalle tasolle kuin useimmat hallintatyökalut. Jos esimerkiksi käytät sitä virtuaalikoneiden kanssa, jotka ovat käynnissä Windows Server -verkossa, hallinnoit virtuaalikoneita Hyper-V-hallintatyökaluilla sekä palvelinten määrityksiä ja niissä suoritettavia sovelluksia Azure Arcilla.
Azure Arc -palvelimen käyttö palvelimien kanssa
"Missä tahansa ovatkin" on Azure Arcin keskeinen periaate. Sovellusten hallinnan painopiste on infrastruktuurin agnostikko. Ne hallitsemansa virtuaalikoneet voivat toimia tietokeskuksessa, isännöintipalvelussa tai virtuaalipalvelimina hallitussa jaetussa ympäristössä.
Azure Arc -palvelimen hallinta on nyt julkisessa esikatselussa, ja siihen on yhdistetty Windows- ja Linux-koneen agentti yhteyden muodostamiseksi Azure Arc -palveluun. Kun olet muodostanut yhteyden pilveen, voit aloittaa sen hallinnan ikään kuin se olisi Azure-resurssi, osa resurssiryhmää. Tämän avulla voit ottaa PowerShell-pohjaiset käytännöt yhdistettyihin palvelimiin hyödyntäen tehtyä työtä, jotta hallinta ja haluttu tilakokoonpano saadaan aikaan oikeaan aikaan. Hallinnoidut palvelimet tarvitsevat yhteyden Azure Arciin SSL: n kautta.
Azure Arcin hallinnoimien palvelimien ei tarvitse olla fyysisiä palvelimia; ne voivat olla virtuaalikoneita. Tämän avulla voit ladata agentin valmiiksi virtuaalikoneen peruskuviin ennen niiden käyttöönottoa. Osana palvelun määrittämistä Azure Arc luo mukautetun komentosarjan, joka toimii yhdistämättömillä palvelimilla, lataamalla ja asentamalla agentin ennen yhteyden muodostamista Azureen ja palvelimen lisäämistä resurssina.
Kubernetes-sovellusten hallinta Azure Arcissa
Microsoft ei ole vielä asettanut Azure Arcin Kubernetes-tukea julkiseen esikatseluun; se on edelleen rajoitettu palvelun yksityisen pääsyn esikatseluun. Azure Application Platform -tuotepäällikkö Gabe Monroy antoi kuitenkin lyhyen esittelyn siitä Ignite-sovelluksessa.
Azroy-portaalia käyttämällä Monroy näytti ensin käynnissä olevan Kubernetes-klusterin, jota hallittiin Azure ARM -perusteisten käytäntöjen avulla. Alkuperäinen käytäntö, jota hän käytti, hallitsi klusterin käyttämiä verkkoportteja lukitsemalla tarpeettomat portit klusterin hyökkäyspinnan vähentämiseksi. Samaa käytäntöä voitaisiin käyttää kaikkien klustereiden hallinnassa yrityksen globaalissa infrastruktuurissa. Kun kirjoitat käytäntöjä kerran ja käytät niitä monta kertaa, virheriski on mahdollisimman pieni; testaamalla kaikki käytännöt etukäteen, voit olla varma, että ne toimivat, kun ne otetaan käyttöön maailmanlaajuisesti.
Toinen käytäntöön perustuvan lähestymistavan etu on, että voit lukita klusterit, jos ne eivät ole vaatimusten mukaisia. Ennen kuin klusteri ilmoittaa, että se on kaikkien käytäntöjen mukainen, sovelluskehitystiimisi ei voi ottaa koodia käyttöön. Kun Azure Arc -agentti on asennettu kaikkiin verkon Kubernetes-klustereihin, sinulla on yksi lasiruutu kaikkien käytäntöjen ja kaikkien käyttöönottojen hallitsemiseksi.
On tärkeää huomata, että sinulla ei ole tapaa hallita fyysisiä palvelimia ja Kubernetes-asennusta suoraan. Kaikki Azure-portaali antaa sinulle klusterissa käytettävät käytännöt ja koodin. Voit määrittää käytännön määrittelemään klusterin toiminnan, mutta et voi ottaa käyttöön uusia solmuja, ellei Kubernetes-ajonaikaista ja Azure Arc -agenttia ole asennettu. Heti kun uusi klusteri on otettu käyttöön ja yhdistetty Azure Arciin, käytäntöjä sovelletaan automaattisesti, mikä varmistaa, että tietoturvakäytännöt ovat paikallaan määrittämättä kaikkea manuaalisesti.
Yksi mielenkiintoinen näkökohta demonstraatiossa oli käytäntö, joka yhdisti Azure Arcin GitHubiin, kohdistamalla joko Kubernetes-nimiavaruuksiin tai klustereihin ja käsittelemällä käyttöönottoja tietystä arkistosta. Tätä käytäntöä käytettäessä kaikki vetopyynnöt arkistoon käynnistävät päivitetyn sovelluksen. Samaa käytäntöä voidaan käyttää koodin lataamiseen uuteen klusteriin heti, kun se on määritetty. Koodin kaikki tulevat päivitykset otetaan automaattisesti käyttöön, jolloin kaikki sivustosi pitävät uusimpia versioita.
On helppo kuvitella, että uudet palvelinsarjat, esiladatut Kubernetesilla ja Azure Arc -agentilla, toimitetaan uudelle reunasivustolle. Kun yhteys WAN-verkkoon on kytketty ja virta kytketty päälle, he lataavat automaattisesti uusimmat käytännöt, ja kun ne noudattavat vaatimuksia, ne lataavat sovelluksensa ja alkavat toimia mahdollisimman vähän ihmisten kanssa.
Esittelyssä uusi pilvikeskeinen, sovelluksen ensimmäinen hallintamalli
On ehkä parasta ajatella Azure Arcia ensimmäisenä käytäntöohjattujen sovellusten hallintatyökalujen ensimmäisenä sukupolvena, varsinkin kun sitä käytetään sovellusten käyttöönoton automatisointiin globaalissa verkossa. Sen integroiminen gitops-virtaan on järkevää, Arc-ohjelman avulla käynnistetään sovellusten käyttöönotot, kun vetopyyntö yhdistetään, ja varmistamalla, että asianmukaisia tietoturvakäytäntöjä sovelletaan isäntä Kubernetes-klusteriin tai virtuaalikoneisiin.
Microsoftin näkemys pilvestä on, että paikalliset järjestelmät eivät häviä, ja kun reuna-asennusten merkitys kasvaa, paikallisten määritelmät kasvavat vain, mikä ei tarkoita, että näiden paikallisten järjestelmien ei pitäisi ei hyödy pilvitekniikoista ja pilvipohjaisista työskentelytavoista. Azure Arc on keskittynyt sovelluksen infrastruktuurin automatisointiin käytännön avulla tietoturvan noudattamisen varmistamiseksi.
Kun ajattelet sitä, tämä on looginen jatko devopsille ja osa liikkumista kolmannelle hallinnointitasolle pilviympäristössä. Kun Azure Arc keskittyy sovellusten virtuaalisiin infrastruktuureihin, olivatpa ne virtuaalikoneita tai konttipohjaisia, sovellusohjelmat ja infrastruktuuritoiminnot erotetaan toisistaan.
Hybridipilviympäristössä sovellustiimin ei tarvitse tietää mitään taustalla olevasta fyysisestä infrastruktuurista. Sen sijaan erillinen tiimi on vastuussa fyysisistä palvelimista, isäntäkäyttöjärjestelmistä, hypervisoreista ja Kubernetes-asennuksista työkaluilla, kuten Azure Arc, jota sovellusryhmä käyttää sovellusten hallintaan reunalla, hyperyhdistyneissä järjestelmissä, perinteisissä palvelinkeskuksissa ja pilvi, kaikki samasta pilvi-isännöitystä konsolista.
Olemme muuttaneet tapaa, jolla ylläpidämme infrastruktuuria säilöillä ja virtualisoinnilla, sekä tapaa, jolla rakennamme ja hallitsemme sovelluksia devops-sovelluksella. Mikset tarjoaisi työkaluja näiden kahden lähestymistavan yhdistämiseksi? Azure Arc -sovelluksen avulla Devops-yhtälön ops-puoli saa alustan erottaa sovellukset infrastruktuurista, ja kyky hallita ja hallita näitä sovelluksia uudelta, pilvi-isännöityltä ohjaustasolta. Se on houkutteleva visio, ja on mielenkiintoista seurata, kuinka Microsoft toimittaa sen.
