Når du kommer til slutningen af en devops build-pipeline, har du et sæt artefakter: binære filer, konfigurationsfiler, websider, endda virtuelle maskiner og containere. De er de komponenter, der går sammen om at konstruere en moderne applikation. Indpakning af så mange af disse komponenter som muligt i en container giver meget mening, hvilket giver dig en enklere implementeringsmodel. Men det efterlader et nyt sæt spørgsmål: Hvordan administrerer du disse containere, og hvordan distribuerer du dem på tværs af en global applikation i skyen?
Tjenester som GitHub tilbyder private og offentlige registre til dine build-artefakter ved hjælp af åbne standarder og open source-kode. Azure har gjort det samme ved hjælp af open source Docker Registry 2.0 som basis for sit eget containerregister, der er i overensstemmelse med Open Container Initiative. Det er ikke beregnet til kun at være til containere; med den stigende betydning af Kubernetes-baserede cloud-native applikationer er det meningen at være et one-stop-lager for alle dine OCI-kompatible build-artefakter. Det inkluderer nu Helm-diagrammer, så du kan bruge Azure's Container Registry (ACR) som implementeringshub for dine applikationer ved hjælp af Helm 3.0 til levering til Kubernetes-forekomster.
Kom godt i gang med ACR
Værktøjer som Azure Container Registry betragtes bedst som private registre. Kun du og dit team og tjenester har adgang til din registreringsdatabase, hvilket automatiserer levering til Azure-tjenester, der bruger containere. Kendte værktøjer som Azure DevOps og Jenkins kan konfigureres til at bruge registreringsdatabasen som et build-slutpunkt, så du kan gå direkte fra at flette en pull-anmodning til en container på Azure, klar til implementering.
Microsoft tilbyder i øjeblikket tre versioner af ACR: Basic, Standard og Premium til tre forskellige prispunkter. De arbejder alle med webhooks, bruger Azure Active Directory til godkendelse og har mulighed for at slette billeder. Basic har den laveste kapacitet; Premium inkluderer understøttelse af replikering på tværs af regioner og tilføjer understøttelse af billedsignering. Du bruger mest sandsynligt Standard, hvilket giver dig 100 GB lagerplads, 60 Mbps downloadbåndbredde og understøtter så mange som 10 webhooks. Priserne er pr. Registreringsdatabase pr. Dag med ekstra netværksomkostninger og et separat gebyr for CPU-brug ved opbygning af nye containerbilleder.
Oprettelse af en ny containerregistrering er relativt let ved hjælp af enten Azure CLI eller Portal. ACR-forekomster er bundet til ressourcegrupper, så du kan have et separat register til hver applikation, du kører på Azure. Når en registreringsdatabase er oprettet, får du URL'en til en loginserver. Dette er slutpunktet for integration med devops-værktøjer eller dine udviklers desktop-Docker-forekomster.
Interagerer med et ACR-register
Azure CLI'erne acr kommando er sandsynligvis den mest nyttige måde at interagere med en registreringsdatabase på. Log ind, og du kan begynde at skubbe containerbilleder til det. Det er en god ide at starte fra skrivebordet for at få en fornemmelse for, hvordan det fungerer, tagge et lokalt Docker-billede med ACR-loginservernavnet og derefter bruge docker skub kommando til at sende billedet til ACR-registreringsdatabasen og automatisk oprette det relevante lager i Azure. Når et billede er i et ACR-lager, skal du bruge kommandolinjeværktøjerne til at liste filer, fjerne dem og endda bruge Docker-kommandoer til at køre dem.
Automatisering af ACR kan reducere din arbejdsbyrde betydeligt ved hjælp af ACR-opgaver. Opgaver samler det, der ville have været et sæt Azure CLI-scripts, i enkle arbejdsgange, der styrer almindelige operationer. For eksempel tilbyder de en række udløsere, der automatiserer opbygning af nye billeder, når der sker ændringer i din build-pipeline eller i dit kontinuerlige integrations- / kontinuerlige leveringssystem (CI / CD).
En mulighed, den hurtige opgave, indpakker alle de faser, der bruges til at opbygge et sæt filer i en container i en enkelt kommando. Alt hvad du behøver er en fungerende mappe med dine filer og en eksisterende ACR-registreringsdatabase og en Dockerfile. En enkelt kommando tager disse filer og bruger Dockerfile til at oprette et billede og gemmer det automatisk i et ACR-lager. En anden hurtig opgave kører billedet på din valgte vært.
Sæt dem sammen, og du har et grundlæggende sæt værktøjer til test af containerbilleder. Mere komplekse implementeringer har brug for mere komplekse scripts - for eksempel implementering af en container til en administreret Kubernetes-instans ved hjælp af AKS. Alternativt kan du automatisere hele processen ved at oprette en opgave, der overvåger en GitHub-repo for ændringer i en installationsgren, opbygge et nyt billede, når du fletter en pull-anmodning ind i grenen eller forpligter dig.
Sikring af containere i ACR
Der er sikkerhedsfordele ved at arbejde med ACR. Et af de store problemer for enhver, der bygger moderne applikationer, er forståelse og styring af dit afhængighedstræ. Hvordan ved du, om en ny version af et nøglebibliotek eller en tilsløret komponent er sikker at bruge? Du skal være i stand til at stole på dine containere, og ACR tilbyder to måder at sikre, at du altid implementerer betroet kode.
For det første giver det signerede containerbilleder, så din Kubernetes-klynge kan kontrollere, at den kode, den kører, er den kode, du skubbede til din registreringsdatabase fra dit build-system. Signerede billeder sikrer, at ingen har manipuleret med en containers indhold, mens den bliver implementeret. For det andet kan ACR integreres med Azure's Security Center. Dette giver dig mulighed for at scanne billeder, da de er gemt i registreringsdatabasen, og kontrollere ikke kun for sårbarheder i din kode og i basisbilledet, men også i eventuelle afhængigheder, der er inkluderet eller henvises fra billedfilen. Ved hjælp af Qualys scanner hjælper Security Center-rapporter dig med at identificere sårbarheder med anbefalinger til rettelser.
Ting bliver interessante, når du begynder at bruge dine ACR-forekomster til mere end containere. OCI er begyndt at åbne registreringsdatabasestandarden for artefakter med Helm, det de facto-værktøj til Kubernetes-applikationsinstallation, ved at bruge det i den seneste udgivelse. Branchen har set en spredning af registre og opbevaringssteder, og det giver mening at standardisere på en til alle dine applikationskomponenter, især når de alle er en del af den samme cloud-native applikation.
ACR understøtter nu OCI Registry As Storage (ORAS). Ved hjælp af et ORAS-værktøj kan du skubbe og trække alle dine artefakter fra det samme ACR-arkiv. Installer ORAS på dine udviklingsmaskiner eller tilføj support til din build-pipeline. Når du er logget ind på din registreringsdatabase med en Azure Active Directory-tjenestehoved, der har push-rettigheder, skal du bruge ORAS-kommandolinjeværktøjet til at skubbe nye artefakter til registreringsdatabasen.
Brug af et kommandolinjeværktøj i Azure CLI giver dig fleksibiliteten til at opbygge ORAS-skub i dit valg af buildværktøjer, som et script, der kan kaldes efter behov. Det samme kommandolinjeværktøj kan trække artefakter, og du kan bygge det i dine implementeringsskripter, så alle de komponenter, der udgør dine applikationer, automatisk kan implementeres, når en ny build skubber til dine ACR-arkiver.
Privat kode har brug for private opbevaringssteder, og ved at opbevare dine containere og andre byggenstande i Azure placeres dem, hvor de er nødvendige. En komplet devops-byggeproces skal gå fra kodeforpligtelse til kørende applikation uden menneskelig indgriben, hvilket gør værktøjer som Azure Container Registry og dets tilknyttede opgaveautomatisering til væsentlige komponenter i enhver Azure-målrettet pipeline. Ikke kun gemmes og distribueres kode automatisk på global skala, den scannes for sikkerhedsrisici, hver gang der er en ændring.
