Når du kommer til slutten av en devops-rørledning, sitter du igjen med et sett med gjenstander: binærfiler, konfigurasjonsfiler, websider, til og med virtuelle maskiner og containere. De er komponentene som går sammen for å lage en moderne applikasjon. Å pakke så mange av disse komponentene som mulig i en container er veldig fornuftig, noe som gir deg en enklere distribusjonsmodell. Men det etterlater et nytt sett med spørsmål: Hvordan administrerer du disse containerne og hvordan distribuerer du dem over et globalt skyprogram?
Tjenester som GitHub tilbyr private og offentlige registre for byggeartefakter, ved hjelp av åpne standarder og åpen kildekode. Azure har gjort det samme ved å bruke åpen kildekode Docker Registry 2.0 som grunnlag for sitt eget containerregister, i samsvar med Open Container Initiative. Det er ikke ment bare for containere; med den økende betydningen av Kubernetes-baserte nettskyprogrammer, er det ment å være et one-stop-lager for alle dine OCI-kompatible bygningsgjenstander. Dette inkluderer nå Helm-diagrammer, slik at du kan bruke Azure's Container Registry (ACR) som distribusjonsnav for applikasjonene dine ved å bruke Helm 3.0 for levering til Kubernetes-forekomster.
Komme i gang med ACR
Verktøy som Azure Container Registry er best tenkt på som private registre. Bare du og teamet ditt og tjenestene dine har tilgang til registeret ditt, og automatiserer levering til Azure-tjenester som bruker containere. Kjente verktøy som Azure DevOps og Jenkins kan konfigureres til å bruke registeret som et byggepunkt, slik at du kan gå rett fra å slå sammen en pull-forespørsel til en container på Azure, klar til distribusjon.
Microsoft tilbyr for tiden tre versjoner av ACR: Basic, Standard og Premium, til tre forskjellige prispunkter. De jobber alle med nettkroker, bruker Azure Active Directory for autentisering og har muligheten til å slette bilder. Basic har lavest kapasitet; Premium inkluderer støtte for replikering på tvers av regioner og legger til støtte for bildesignering. Det er mest sannsynlig at du bruker Standard, som gir deg 100 GB lagringsplass, nedlastingsbåndbredde på 60 MB, og støtter så mange som 10 nettkroker. Priser er per register per dag, med ekstra nettverkskostnader og en separat kostnad for CPU-bruk når du bygger nye containerbilder.
Det er relativt enkelt å lage et nytt containerregister ved hjelp av enten Azure CLI eller Portal. ACR-forekomster er knyttet til ressursgrupper, slik at du kan ha et eget register for hvert program du kjører på Azure. Når et register er opprettet, får du URL-adressen til en påloggingsserver. Dette er sluttpunktet for integrering med devops-verktøy eller utviklerens desktop-Docker-forekomster.
Samhandler med et ACR-register
Azure CLI-ene acr kommando er trolig den mest nyttige måten å samhandle med et register på. Logg inn og du kan begynne å skyve containerbilder til den. Det er en god ide å starte fra skrivebordet for å få en følelse av hvordan det fungerer, merke et lokalt Docker-bilde med ACR-påloggingsservernavnet og deretter bruke docker push kommando for å sende bildet til ACR-registeret, og automatisk opprette riktig lager i Azure. Når et bilde er i et ACR-arkiv, bruker du kommandolinjeverktøyene til å liste opp filer, fjerne dem og til og med bruke Docker-kommandoer for å kjøre dem.
Automatisering av ACR kan redusere arbeidsbelastningen betydelig ved hjelp av ACR-oppgaver. Oppgaver samler det som hadde vært et sett med Azure CLI-skript, i enkle arbeidsflyter som administrerer vanlige operasjoner. For eksempel tilbyr de en rekke utløsere som automatiserer å bygge nye bilder når det skjer endringer i din bygningsrørledning eller i ditt kontinuerlige integrasjons- / kontinuerlige leveringssystem (CI / CD).
Ett alternativ, den raske oppgaven, bryter alle trinnene som brukes til å bygge et sett med filer i en container i en enkelt kommando. Alt du trenger er en fungerende katalog med filene dine og et eksisterende ACR-register og en Dockerfile. En enkelt kommando tar disse filene og bruker Dockerfile til å lage et bilde, og lagrer det automatisk i et ACR-arkiv. En annen rask oppgave kjører bildet på den valgte verten.
Sett dem sammen, og du har et grunnleggende sett med verktøy for å teste containerbilder. Mer komplekse distribusjoner vil trenge mer komplekse skript - for eksempel distribuere en container til en administrert Kubernetes-forekomst ved hjelp av AKS. Alternativt kan du automatisere hele prosessen, opprette en oppgave som overvåker en GitHub repo for endringer i en distribusjonsgren, bygge et nytt bilde når du slår sammen en pull-forespørsel i grenen eller forplikter deg.
Sikring av containere i ACR
Det er sikkerhetsfordeler ved å jobbe med ACR. Et av de store problemene for alle som bygger moderne applikasjoner, er å forstå og administrere ditt avhengighetstre. Hvordan vet du om en ny versjon av et nøkkelbibliotek eller en forvirret komponent er trygt å bruke? Du må kunne stole på containerne dine, og ACR tilbyr to måter å sikre at du alltid distribuerer klarert kode.
For det første gir den signerte containerbilder, slik at Kubernetes-klyngen din kan bekrefte at koden den kjører er koden du presset til registeret ditt fra ditt byggesystem. Signerte bilder sørger for at ingen har tuklet med innholdet på en container mens den distribueres. For det andre kan ACR integreres med Azure Security Center. Dette lar deg skanne bilder slik de er lagret i registret, og ikke bare sjekke om det er sårbarheter i koden din og i basisbildet, men også i eventuelle avhengigheter som er inkludert eller blir henvist fra bildefilen. Ved å bruke Qualys skanner vil Security Center-rapporter hjelpe deg med å identifisere sårbarheter med anbefalinger for reparasjoner.
Ting blir interessante når du begynner å bruke ACR-forekomster for mer enn containere. OCI har begynt å åpne registerstandarden for gjenstander, med Helm, de facto-verktøyet for distribusjon av Kubernetes-applikasjoner, og bruker det i den siste utgivelsen. Bransjen har sett en økning i registre og arkiver, og det er fornuftig å standardisere på en for alle applikasjonskomponentene dine, spesielt når de alle er en del av samme sky-native applikasjon.
ACR støtter nå OCI Registry As Storage (ORAS). Ved å bruke et ORAS-verktøy kan du skyve og hente alle gjenstandene dine fra samme ACR-arkiv. Installer ORAS på utviklermaskiner eller legg til støtte for bygningsrørledningen. Når du er logget på registeret ditt med en Azure Active Directory-tjenesteprinsipp som har push-rettigheter, bruker du ORAS-kommandolinjeverktøyet til å skyve nye gjenstander til registret.
Ved å bruke et kommandolinjeverktøy i Azure CLI gir du deg fleksibilitet til å bygge ORAS-push inn i ditt valg av byggeverktøy, som et skript som kan kalles etter behov. Det samme kommandolinjeverktøyet kan trekke gjenstander, og du kan bygge det inn i distribusjonsskriptene dine, slik at alle komponentene som utgjør applikasjonene dine, automatisk kan distribueres når en ny versjon skyver til ACR-arkivene dine.
Privat kode trenger private arkiver, og når du holder containere og andre byggeartefakter i Azure, plasseres de der de trengs. En fullstendig devops-byggeprosess bør gå fra kodeforpliktelse til å kjøre applikasjon uten menneskelig inngripen, noe som gjør verktøy som Azure Container Registry og tilhørende oppgaveautomatisering viktige komponenter i enhver Azure-målrettet rørledning. Ikke bare lagres og distribueres koden automatisk på en global skala, den skannes for sikkerhetsrisiko hver gang det er en endring.
