Distribuera containrar i Azure

Dricks

Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

Vi har diskuterat containrar i det här kapitlet och i kapitel 1. Vi har sett att containrar ger många fördelar för molnbaserade program, inklusive portabilitet. I Azure-molnet kan du distribuera samma containerbaserade tjänster i mellanlagrings- och produktionsmiljöer. Azure har flera alternativ för att hantera dessa containerbaserade arbetsbelastningar:

• Azure Kubernetes Services (AKS)
• Azure Container Instance (ACI)
• Azure Web Apps for Containers

Azure Container Registry

När du containeriserar en mikrotjänst skapar du först en container "avbildning". Avbildningen är en binär representation av tjänstkoden, beroenden och körning. Du kan skapa en avbildning manuellt med kommandot Docker Build från Docker-API:et, men en bättre metod är att skapa den som en del av en automatiserad byggprocess.

När de har skapats lagras containeravbildningar i containerregister. De gör att du kan skapa, lagra och hantera containeravbildningar. Det finns många tillgängliga register, både offentliga och privata. Azure Container Registry (ACR) är en fullständigt hanterad containerregistertjänst i Azure-molnet. Det bevarar dina avbildningar i Azure-nätverket, vilket minskar tiden för att distribuera dem till Azure-containervärdar. Du kan också skydda dem med samma säkerhets- och identitetsprocedurer som du använder för andra Azure-resurser.

Du skapar ett Azure Container Registry med hjälp av Azure-portalen, Azure CLI eller PowerShell-verktyg. Det är enkelt att skapa ett register i Azure. Det kräver en Azure-prenumeration, en resursgrupp och ett unikt namn. Bild 3–10 visar de grundläggande alternativen för att skapa ett register, som ska finnas på registryname.azurecr.io.

Bild 3-10. Skapa containerregister

När du har skapat registret måste du autentisera med det innan du kan använda det. Vanligtvis loggar du in i registret med hjälp av Azure CLI-kommandot:

az acr login --name *registryname*

När du har autentiserats kan du använda Docker-kommandon för att skicka containeravbildningar till den. Innan du kan göra det måste du dock tagga avbildningen med det fullständigt kvalificerade namnet (URL) för din ACR-inloggningsserver. Det har formatet registryname.azurecr.io.

docker tag mycontainer myregistry.azurecr.io/mycontainer:v1

När du har taggat avbildningen docker push använder du kommandot för att skicka avbildningen till din ACR-instans.

docker push myregistry.azurecr.io/mycontainer:v1

När du har push-överfört en avbildning till registret är det en bra idé att ta bort avbildningen från din lokala Docker-miljö med hjälp av det här kommandot:

docker rmi myregistry.azurecr.io/mycontainer:v1

Vi rekommenderar att du inte skickar avbildningar manuellt till ett containerregister. Använd i stället en byggpipeline som definierats i ett verktyg som GitHub eller Azure DevOps. Läs mer i det molnbaserade DevOps-kapitlet.

ACR-uppgifter

ACR Tasks är en uppsättning funktioner som är tillgängliga från Azure Container Registry. Den utökar utvecklingscykeln för inre loopar genom att skapa och hantera containeravbildningar i Azure-molnet. I stället för att anropa en docker build och docker push lokalt på utvecklingsdatorn hanteras de automatiskt av ACR Tasks i molnet.

Följande AZ CLI-kommando skapar både en containeravbildning och skickar den till ACR:

# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic

# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1  --registry myContainerRegistry008 --file Dockerfile .

Som du ser från föregående kommandoblock behöver du inte installera Docker Desktop på utvecklingsdatorn. Dessutom kan du konfigurera ACR-aktivitetsutlösare för att återskapa behållaravbildningar på både källkods- och basavbildningsuppdateringar.

Azure Kubernetes Service

Vi har diskuterat Azure Kubernetes Service (AKS) länge i det här kapitlet. Vi har sett att det är den de facto-containerorkestrerare som hanterar containerbaserade molnbaserade program.

När du distribuerar en avbildning till ett register, till exempel ACR, kan du konfigurera AKS för att automatiskt hämta och distribuera den. Med en CI/CD-pipeline på plats kan du konfigurera en strategi för kanariefrisättning för att minimera risken vid snabb distribution av uppdateringar. Den nya versionen av appen konfigureras ursprungligen i produktion utan trafik som dirigeras till den. Sedan dirigerar systemet en liten andel användare till den nyligen distribuerade versionen. När teamet får förtroende för den nya versionen kan det distribuera fler instanser och dra tillbaka det gamla. AKS stöder enkelt den här distributionsstilen.

Precis som med de flesta resurser i Azure kan du skapa ett Azure Kubernetes Service-kluster med hjälp av portalen, kommandoraden eller automatiseringsverktyg som Helm eller Terraform. För att komma igång med ett nytt kluster måste du ange följande information:

• Azure-prenumeration
• Resursgrupp
• Kubernetes-klusternamn
• Region
• Kubernetes-version
• Prefix för DNS-namn
• Nodstorlek
• Nodantal

Den här informationen räcker för att komma igång. Som en del av skapandeprocessen i Azure-portalen kan du även konfigurera alternativ för följande funktioner i klustret:

• Skala
• Autentisering
• Nätverk
• Övervakning
• Taggar

Den här snabbstarten går igenom hur du distribuerar ett AKS-kluster med hjälp av Azure-portalen.

Azure Bridge till Kubernetes

Molnbaserade program kan växa sig stora och komplexa, vilket kräver betydande beräkningsresurser för att köras. I dessa scenarier kan inte hela programmet finnas på en utvecklingsdator (särskilt en bärbar dator). Azure Bridge till Kubernetes åtgärdar bristen. Det gör det möjligt för utvecklare att arbeta med en lokal version av sin tjänst samtidigt som de är värdar för hela programmet i ett AKS-utvecklingskluster.

När de är klara testar utvecklarna sina ändringar lokalt när de körs mot det fullständiga programmet i AKS-klustret – utan att replikera beroenden. Under huven sammanfogar bryggan kod från den lokala datorn med tjänster i AKS. Utvecklare kan snabbt iterera och felsöka kod direkt i Kubernetes med hjälp av Visual Studio eller Visual Studio Code.

Gabe Monroy, tidigare vd för Product Management på Microsoft, beskriver det väl:

Anta att du är en ny anställd som försöker åtgärda ett fel i ett komplext mikrotjänstprogram som består av dussintals komponenter, var och en med sina egna konfigurations- och säkerhetskopieringstjänster. För att komma igång måste du konfigurera din lokala utvecklingsmiljö så att den kan efterlikna produktion, inklusive att konfigurera din IDE, skapa verktygskedja, beroenden för containerbaserade tjänster, en lokal Kubernetes-miljö, modeller för säkerhetskopiering av tjänster med mera. Med all tid som det tar att konfigurera utvecklingsmiljön kan det ta flera dagar att åtgärda den första buggen! Eller så kan du bara använda Bridge till Kubernetes och AKS.

FöregåendeNästa