Verwaltete DevOps Pools: Vereinfachung der Azure DevOps-Einrichtung

Mussten Sie jemals Ihre eigenen DevOps-Agenten bereitstellen, konfigurieren und pflegen, sei es für Azure DevOps oder GitHub? Wenn ja, dann haben Sie wahrscheinlich festgestellt, dass es sehr mühsam ist, alles auf dem neuesten Stand zu halten und am Laufen zu halten.

Managed DevOps Pools wurde kürzlich als Public Preview angekündigt. In diesem Artikel gehen wir auf die wichtigsten Funktionen und Möglichkeiten des neuen Dienstes ein und zeigen anhand von Beispielen, wie Sie diesen mit Infrastructure as Code mit Terraform implementieren können.

Managed DevOps Pools, was sind sie?

Managed DevOps Pools sind von Microsoft gehostete Agenten, die für die Nutzung privater Netzwerke konfiguriert werden können. Dadurch können die Agenten private DNS-Zonen, private Endpunkte, Ihre eigene Azure Firewall (oder eine Appliance) nutzen und haben den zusätzlichen Vorteil, dass diese Ressourcen von Microsoft verwaltet werden.

Mit den Managed DevOps Pools können Sie auch festlegen, welche SKU, Festplatten und Betriebssystem-Images Sie verwenden möchten. Ganz gleich, ob Sie eine bestimmte Rechenleistung, viel Festplattenspeicher oder ein bestimmtes Betriebssystem-Image (sogar aus dem Azure Marketplace) benötigen, mit Managed DevOps Pools können Sie den Agentenpool an Ihre Bedürfnisse anpassen.

Für das private Netzwerk gibt es zwei Optionen. Es kann so konfiguriert werden, dass ein isoliertes Netzwerk verwendet wird, das von Microsoft bereitgestellt und verwaltet wird, oder es kann ein bestehendes virtuelles Netzwerk innerhalb des Azure-Mieters verwendet werden. Letzteres hat den zusätzlichen Vorteil, dass Sie das Routing, die DNS-Serverkonfiguration und die Netzwerksicherheitsgruppen konfigurieren und so den erlaubten und verweigerten Datenverkehr spezifischer für Ihre Bedürfnisse verwalten können.

Es gibt noch eine weitere Option, die sehr leistungsstark ist: Sie können die Managed DevOps Pools für mehrere Azure DevOps-Organisationen und/oder mehrere Projekte innerhalb dieser Organisationen verwenden. Manche Unternehmen verwenden mehrere DevOps-Organisationen, d.h. eine (1) für die Produktion und eine (1) für Sandbox-Umgebungen. Diese können dann alle denselben Managed DevOps Pool verwenden.

Was ist denn nun der verwaltete Teil?

Obwohl Sie einige der Azure-Ressourcen selbst bereitstellen müssen, werden die Recheninstanzen hinter den Kulissen von Microsoft verwaltet. Das spart Ihnen eine Menge Zeit und Kopfschmerzen (in meinem Fall). Der Nachteil dieser Verwaltung hinter den Kulissen ist, dass Sie Teile der Lösung nicht sehen können und die Fehlersuche daher schwieriger werden könnte.

Zusammenfassung

Die Vorteile von Managed DevOps Pools sind, dass sie zwar von Microsoft verwaltet werden, aber direkt in Ihrem privaten Netzwerk genutzt werden können. Sie haben Zugriff auf eine Vielzahl von Images, die für die Agenten verwendet werden können, seien es die Microsoft-Images, Marketplace-Images oder sogar selbst erstellte Images.

Drei wichtige Erkenntnisse für den Einsatz von Managed DevOps-Pools

Durch den Einsatz von Managed DevOps Pools haben Sie mehr Zeit für Aufgaben, die einen geschäftlichen Nutzen bringen, und Sie erhalten das gleiche Maß an Komfort und Sicherheit wie bei selbst gehosteten Agenten.

1. Konzentration auf den geschäftlichen Nutzen - Mit diesem Service kann ich mich auf die Bereitstellung meines geschäftlichen Nutzens konzentrieren, anstatt meine selbst gehosteten Agenten zu pflegen und zu verwalten. Ich kann automatisch die neuesten Versionen der von Microsoft gehosteten Agenten verwenden, ohne das Repository auschecken und meine eigenen Images auf der Grundlage des Microsoft Image Repository erstellen zu müssen.

2. Vereinfachte Verwaltungsaufgaben - Sie müssen sich nicht um die Recheninstanzen des Virtual Machine Scale Set kümmern, da diese von Microsoft als Platform-as-a-Service (PaaS) Angebot gewartet und verwaltet werden. Außerdem wird die Konfiguration des Azure DevOps-Agentenpools durch die Erstellung des Managed DevOps Pools vorgenommen, so dass es nicht notwendig ist, Azure DevOps zu konfigurieren oder auf die Hilfe des Azure DevOps-Administrators zu warten.

3. Verwaltete Agenten, aber mit privatem Netzwerk - Die verwalteten DevOps Pools können direkt ein verfügbares virtuelles Netzwerk im Azure-Tenant nutzen, was einen besseren Zugang zu anderen Diensten ermöglicht, ohne dass Sie irgendwelche Dienste für das öffentliche Internet öffnen müssen, wie es bei von Microsoft gehosteten Agenten der Fall wäre.

   Implementierung von DevOps Pools mit Infrastructure as Code und Terraform

   Beginnen wir also damit, die einzelnen Dienste zu identifizieren, die wir benötigen, und wie sie alle zusammenarbeiten.

Unser Ziel ist es, einen Managed DevOps Pool einzurichten, der ein privates Netzwerk nutzen kann, das mit unserem Netzwerk-Hub verbunden ist und das gleiche (Ubuntu-)Image wie die von Microsoft gehosteten Agenten verwendet.

Wir bevorzugen den Einsatz von Infrastructure as Code (IaC), um menschliches Versagen zu minimieren und Lösungen zu schaffen, die auf konsistente und wiederholbare Weise erstellt, geändert und verwaltet werden können. Meine bevorzugte IaC-Sprache ist Terraform, daher werden wir Terraform für die Bereitstellung der Ressourcen verwenden.

Das bedeutet, dass wir die folgenden Aufgaben durchführen müssen:

1. Basic terraform setup - Wir müssen Terraform und das Basis-Repository initialisieren, um die Azure-Ressourcen bereitstellen zu können
2. Request or update Quotas - Die Quoten für Managed DevOps Pools sind standardmäßig auf 0 gesetzt. Wir müssen also eine Quotenerhöhung beantragen, um die Managed DevOps Pools nutzen zu können.
3. Create a resource group - Alle Azure-Ressourcen müssen in einer Ressourcengruppe bereitgestellt werden. Wir erstellen also eine Ressourcengruppe für die Managed DevOps Pool-Ressourcen
4. Create a DevCenter and create a project - DevCenter ist eine Sammlung von Projekten mit ähnlichen Einstellungen. Es kann verwendet werden, um Kataloge mit Infrastructure as Code-Vorlagen bereitzustellen, die für alle Projekte im DevCenter verfügbar sind, und um Entwicklungsumgebungen für Entwicklungsteams zu erstellen
5. Create a Virtual network, peering to the central hub and create a subnet - Um ein privates Netzwerk zu aktivieren, müssen wir ein virtuelles Netzwerk mit einem Subnetz erstellen
6. Create the Managed DevOps Pool - Der Managed DevOps Pool erstellt die Recheninstanzen, auf denen die Azure DevOps-Aufträge ausgeführt werden können, und wir stellen die richtige Ressourcenkonfiguration auf der Grundlage der vorherigen Schritte bereit

Grundlegende Terraform-Einrichtung

Bei der Verwendung von Terraform müssen wir die Anbieterinformationen und die Konfiguration bereitstellen. Wir werden sowohl den AzureRM als auch den AzAPI Anbieter verwenden. Einzelheiten zur Verwendung des Anbieters AzAPI werden in den entsprechenden Abschnitten beschrieben.

terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "4.0.1"
}
azapi = {
source = "Azure/azapi"
version = "1.15.0"
}
}
}

provider "azurerm" {
subscription_id = "{insert your subscription ID here}"
features {}

resource_provider_registrations = "Extended"
resource_providers_to_register = ["Microsoft.DevCenter", "Microsoft.DevopsInfrastructure"]
}

provider "azapi" {}

Beachten Sie die neue Anmerkung für Ressourcenanbieter, die in der neuesten Version von AzureRM eingeführt wurde.

Beachten Sie auch die Provider, die für das Abonnement festgelegt werden müssen, damit das Abonnement aktiviert wird, um die Ressourcen innerhalb des Abonnements zu nutzen:

• Der Anbieter Microsoft.DevCenter ermöglicht die Erstellung und Nutzung der DevCenter-Ressource und der Projekte im DevCenter.
• Der Anbieter Microsoft.DevOpsInfrastructure ermöglicht dem Abonnement die Erstellung und Bereitstellung der Managed DevOps Pools.

  Verwaltete DevOps Pools Quoten

  Eine wichtige Sache, die Sie vor der Bereitstellung verstehen sollten, ist, dass wir eine Quotenerhöhung beantragen müssen. Diese Kontingente gelten speziell für Managed DevOps Pools. Ihre normalen SKU-Kontingente für virtuelle Maschinen sind also für die SKUs von Managed DevOps Pools nicht gültig.

Sie können die Kontingente wie bei anderen Kontingenten auch über das Azure-Portal auf der Abonnement-Seite anfordern:

Stellen Sie sicher, dass Sie den Provider Managed DevOps Pools auswählen, um die Quoten zu sehen:

Wenn Sie nicht wissen, wie das geht, oder wenn die Schaltfläche New Quota Request ausgegraut ist, wenden Sie sich bitte an Ihre Plattformingenieure oder CSP, die Ihnen helfen können.

Variablen und Einheimische

Ich verwende eine variables.tf und locals.tf Datei, um bestimmte Werte für die Bereitstellung zu bestimmen, die ich in diesem Abschnitt kurz erläutern werde.

Die Datei variables.tf beschreibt alle Variablen, die für die Ausführung der Terraform-Bereitstellung angegeben werden müssen. Die vollständige Datei ist im GitHub-Repository verfügbar (im Abschnitt Links), aber unten sind zwei Variablen aufgeführt:

variable "scaffold_company_short_name" {
description = "Abbreviation of the company name to make all Azure resources unique within the Azure Tenant."
type = string

validation {
condition = length(var.scaffold_company_short_name) <= 6
error_message = "The company short name must be 6 characters or less."
}
}

variable "devops_organization_url" {
description = "The URL of the Azure DevOps organization to add the Managed DevOps Pool to."
type = string
}

Diese Variablen dienen als Input für die Wiederverwendung der Bereitstellung für mehrere Projekte, Kunden oder Zwecke.

Die Benennungskonvention finden Sie in der Datei locals.tf.

locals {
rgName = "rg-${var.scaffold_company_short_name}-devpool-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
vnetName = "vnet-${var.scaffold_company_short_name}-devpool-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
devCenterName = "devc-${var.scaffold_company_short_name}-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
devCenterProjectName = "devpr-${var.scaffold_company_short_name}-devpool-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
snetName = "snet-${var.scaffold_company_short_name}-devpool-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
poolName = "pool-${var.scaffold_company_short_name}-devpool-${var.scaffold_environment}-${var.scaffold_location_short_name}-001"
}

Beachten Sie, dass der Wert devCenterName nicht den Abschnitt -devpool enthält. Dies geschieht, um die Längenbeschränkung für Namen von 26 Zeichen einzuhalten. Wir haben die Variablen validiert, um sicherzustellen, dass diese Namenskonvention die Längenbeschränkung nicht überschreitet.

Die Einheimischen geben die Namenskonvention vor, die ich für diese Lösung verwenden möchte. Sie können sie nach Belieben an Ihre Bedürfnisse oder Vorlieben anpassen. Die Namenskonvention basiert auf der Namenskonvention für das Cloud Adoption Framework. Sie können diese gerne überschreiben, wenn andere Namenskonventionen gelten sollen.

Erstellen Sie die Ressourcengruppe

Wie bei jeder Bereitstellung von Azure-Ressourcen beginnen wir mit der Erstellung einer Resource Group, in der wir alle Azure-Ressourcen unterbringen.

resource "azurerm_resource_group" "rg" {
name = local.rgName
location = var.scaffold_location

lifecycle {
ignore_changes = [
tags
]
}
}

Dev Center Ressource und ein Dev Center Projekt erstellen

Die Basis der Managed DevOps Pools ist die Ressource Dev Center, zusammen mit einer DevCenter Project.

Wie bereits kurz beschrieben, ist das DevCenter eine Sammlung von Projekten mit ähnlichen Einstellungen. Es kann dazu verwendet werden, Kataloge mit Infrastructure as Code-Vorlagen zu versorgen, die für alle Projekte im DevCenter verfügbar sind, sowie Entwicklungsumgebungen zu erstellen, die von Entwicklungsteams genutzt werden können. Ein DevCenter-Projekt ist ein enthaltener Teil, der bestimmten Teams und Ressourcen zur Verfügung gestellt werden kann, z.B. Dev Boxes, Deployment Environments oder Managed DevOps Pools.

resource "azurerm_dev_center" "devcenter" {
name = local.devCenterName
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
}

Der DevCenter-Name darf nicht länger als 26 Zeichen sein. Da wir die Variablen mit Validierungen erstellt haben, sollten wir diese Zahl nicht erreichen. Wenn Sie jedoch den Beispielcode aktualisieren und die Namenskonvention oder die Variablen aktualisieren, sollten Sie sich darüber im Klaren sein, dass Sie diese Längenbeschränkung bei der Namensgebung erreichen könnten.

resource "azurerm_dev_center_project" "devcenter_project" {
name = local.devCenterProjectName
dev_center_id = azurerm_dev_center.devcenter.id
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
}

Erstellen Sie das virtuelle Netzwerk und Subnetz

Nachdem wir nun das Dev Center eingerichtet haben, können wir mit der Erstellung von virtual network und subnet fortfahren, die vom Managed DevOps Pool verwendet werden sollen, um eine private Vernetzung zu ermöglichen.

resource "azurerm_virtual_network" "vnet" {
name = local.vnetName
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
address_space = [var.vnet_devpool_ip_range]
dns_servers = var.vnet_dns_servers
}

# Optionally peer the virtual network to the Virtual Hub
resource "azurerm_virtual_hub_connection" "agents" {
depends_on = [azurerm_virtual_network.vnet]
count = var.virtual_hub_id != null ? 1 : 0

name = "conn-${local.vnetName}"
internet_security_enabled = true
virtual_hub_id = var.virtual_hub_id
remote_virtual_network_id = azurerm_virtual_network.vnet.id
}

Da ich immer eine Cloud-Plattform verwende, möchte ich mein virtuelles Netzwerk mit dem zentralisierten Hub verbinden. Sie können sich dafür entscheiden, diese Ressource nicht zu verwenden, indem Sie der Variablen virtual_hub_id keinen Wert (oder den Wert null) zuweisen, wenn Sie keine Verbindung mit einem virtuellen Hub verwenden möchten. Wenn Sie mehr darüber wissen möchten, was ein Hub ist, sehen Sie sich bitte die Microsoft Learn-Seiten über Hub-and-Spokes als Teil des Cloud Adoption Framework an.

resource "azapi_resource" "snet" {
depends_on = [azurerm_virtual_network.vnet]

name = local.snetName
type = "Microsoft.Network/virtualNetworks/subnets@2023-11-01"
parent_id = azurerm_virtual_network.vnet.id

body = jsonencode({
properties = {
addressPrefix = var.vnet_devpool_ip_range
delegations = [
{
name = "Microsoft.DevOpsInfrastructure/pools"
properties = {
serviceName = "Microsoft.DevOpsInfrastructure/pools"
}
}
]
}
})
}

Als nächstes verwenden wir die bereits erwähnte Ressource AzAPI, um ein delegiertes Subnetz für den Managed DevOps Pool zu erstellen. Wir benötigen diese AzAPI-Ressource, da der Anbieter AzureRM keine bekannte Terraform-Konfiguration für den Delegationsdienstnamen Microsoft.DevOpsInfrastructure/pools bereitstellt. Mit der Ressource AzAPI können wir unsere Delegationsinformationen bequem übergeben.

Erstellen der verwalteten DevOps-Pools

Jetzt, da wir die grundlegenden Ressourcen haben, erstellen wir den Managed DevOps Pool, wiederum unter Verwendung von AzAPI provider.

resource "azapi_resource" "pool" {
name = local.poolName
type = "microsoft.devopsinfrastructure/pools@2024-04-04-preview"
location = azurerm_resource_group.rg.location
parent_id = azurerm_resource_group.rg.id

body = jsonencode({
properties = {
organizationProfile = {
organizations = [
{
projects = var.devops_projects
url = var.devops_organization_url
parallelism = var.agent_maximumConcurrency
}
]
kind = "AzureDevOps" # Currently only AzureDevOps is supported
permissionProfile = {
kind = "CreatorOnly" # Can also be set to "Inherit" or "SpecificAccounts"
# If you want to use specific accounts, you can add them here using the users and groups properties
# users = [
# "Patrick.deKruijf@xebia.com"
# ]
# groups = []
}
}

devCenterProjectResourceId = azurerm_dev_center_project.devcenter_project.id

maximumConcurrency = var.agent_maximumConcurrency

agentProfile = {
kind = "Stateless" # I would recommend setting this to "Stateless", since this ensures a fresh agent is used for each job.
# kind = "Stateful"
# maxAgentLifetime = "7.00:00:00" # Property is required when set to "Stateful"

# If you do not want to turn off scaling, remove the complete resourcePredictionsProfile block
# There is also a "Manual" option, which allows you to set the minimum and maximum number of agents based on a schedule.
resourcePredictionsProfile = {
predictionPreference = "MostCostEffective" # There are 5 options, ranging from "MostCostEffective" to "MostPerformance"
kind = "Automatic" # Can also be set to Manual or
}

}

fabricProfile = {
sku = {
name = "Standard_D2ads_v5"
}

images = [
{
aliases = ["ubuntu-22.04"]
buffer = "*"
wellKnownImageName = "ubuntu-22.04/latest"
},
# You can add more images if needed, also referencing resource IDs for images
# {
# resourceId = "/Subscriptions/5ab24a52-44e0-4bdf-a879-cc38371a4403/Providers/Microsoft.Compute/Locations/westeurope/Publishers/canonical/ArtifactTypes/VMImage/Offers/0001-com-ubuntu-server-focal/Skus/20_04-lts-gen2/versions/latest",
# buffer = "*"
# }
]

osProfile = {
# Not much to configure here just yet, but Microsoft is working on adding Key Vault support too
secretsManagementSettings = {
observedCertificates = [],
keyExportable = false
},
logonType = "Service" # Can also be set to "Interactive"
},

# If you want to use an isolated network, remove the complete networkProfile block
networkProfile = {
subnetId = azapi_resource.snet.id
}

storageProfile = {
osDiskStorageAccountType = "Premium", # Standard, StandardSSD, Premium
dataDisks = [
# Create additional data disks if needed
# {
# diskSizeGiB = 100
# caching = "ReadWrite"
# storageAccountType = "StandardSSD_LRS"
# driveLetter = "Z"
# }
]
},

kind = "Vmss" # Currently only "Vmss" is supported
}
}
})
}

Für jede der Eigenschaften wird unten ein Abschnitt erstellt, in dem erklärt wird, was die jeweilige Einstellung erwartet, welche Optionen es gibt und wann Sie eine bestimmte Option verwenden sollten.

Verfügbare Immobilien

organisationProfil

organizationProfile = {
organizations = [
{
projects = var.devops_projects # This field accepts an Array[] of projects that should be able to use the Managed DevOps Pool
url = var.devops_organization_url # This should be the URL of a Azure DevOps organization (i.e. https://dev.azure.com/{organizationName})
parallelism = var.agent_maximumConcurrency # This setting sets the maximum amount of concurrent agents that can be used in parallel
}
]
kind = "AzureDevOps" # Currently only AzureDevOps is supported, hopefully we can see GitHub here soon too
permissionProfile = {
kind = "CreatorOnly" # Can also be set to "Inherit" or "SpecificAccounts"
users = [ # If you want to use specific accounts, you can add them here using the users and groups properties
"Patrick.deKruijf@xebia.com"
]
groups = [] # If you want to use specific accounts, you can add them here using the users and groups properties
}
}

devCenterProjectResourceId

devCenterProjectResourceId = azurerm_dev_center_project.devcenter_project.id

maximumConcurrency

maximumConcurrency = var.agent_maximumConcurrency

agentProfile

agentProfile = {
kind = "Stateless" # You can use either "Stateful" or "Stateless". I would recommend setting this to "Stateless", since this ensures a fresh agent is used for each job.
# maxAgentLifetime = "7.00:00:00" # Property is required when the kind property is set to "Stateful"

# If you do not want to turn off scaling, remove the complete resourcePredictionsProfile block
# There is also a "Manual" option, which allows you to set the minimum and maximum number of agents based on a schedule.
resourcePredictionsProfile = {
predictionPreference = "MostCostEffective" # There are 5 options, ranging from "MostCostEffective" to "MostPerformance"
kind = "Automatic" # Can also be set to Manual
}
}

fabricProfile = {
sku = {
name = "Standard_D2ads_v5" # Make sure this SKU is allowed based on the Managed DevOps Pool quotas
}

images = [
{
aliases = ["ubuntu-22.04"]
buffer = "*"
wellKnownImageName = "ubuntu-22.04/latest"
},
# You can add more images if needed, also referencing resource IDs for images
# {
# resourceId = "/Subscriptions/5ab24a52-44e0-4bdf-a879-cc38371a4403/Providers/Microsoft.Compute/Locations/westeurope/Publishers/canonical/ArtifactTypes/VMImage/Offers/0001-com-ubuntu-server-focal/Skus/20_04-lts-gen2/versions/latest",
# buffer = "*"
# }
]

osProfile = {
# Not much to configure here just yet, but Microsoft is working on adding Key Vault support too
secretsManagementSettings = {
observedCertificates = [],
keyExportable = false
},
logonType = "Service" # Can also be set to "Interactive"
},

# If you want to use an isolated network, remove the complete networkProfile block
networkProfile = {
subnetId = azapi_resource.snet.id # This is the resource ID of the virtual network you want to have the Managed DevOps Pool connect to
}

storageProfile = {
osDiskStorageAccountType = "Premium", # Standard, StandardSSD, Premium
dataDisks = [
# Create additional data disks if needed
{
diskSizeGiB = 100
caching = "ReadWrite"
storageAccountType = "StandardSSD_LRS"
driveLetter = "Z"
}
]
},

kind = "Vmss" # Currently only "Vmss" is supported
}

Erforderliche Verkehrsregeln (Firewall oder Netzwerksicherheitsgruppen)

Damit alle Ressourcen tatsächlich funktionieren, müssen Sie den Datenverkehr zu bestimmten Domänen zulassen. Diese Domänen müssen also aus der Netzwerkperspektive zugelassen werden, damit der Managed DevOps Pool funktioniert.

Endpunkte, von denen der Managed DevOps Pool-Dienst abhängt:

• *.prod.manageddevops.microsoft.com - Verwaltete DevOps Pools Endpunkt
• rmprodbuilds.azureedge.net - Worker-Binärdateien
• vstsagentpackage.azureedge.net - Azure DevOps Agent CDN Standort
• *.queue.core.windows.net - Worker-Warteschlange für die Kommunikation mit dem Dienst Managed DevOps Pools
• server.pipe.aria.microsoft.com - Gemeinsame clientseitige Telemetrielösung (u.a. verwendet von der Agent Pool Validation-Erweiterung)
• azure.archive.ubuntu.com - Bereitstellung von Linux-Rechnern - dies ist HTTP , nicht HTTPS
• www.microsoft.com - Bereitstellung von Linux-Rechnern
• packages.microsoft.com - Bereitstellung von Linux-Rechnern
• ppa.launchpad.net - Bereitstellung von Ubuntu-Maschinen
• dl.fedoraproject.org - Bereitstellung bestimmter Linux-Distributionen

Wird von Azure DevOps Agent benötigt:

• dev.azure.com
• *.services.visualstudio.com
• *.vsblob.visualstudio.com
• *.vssps.visualstudio.com
• *.visualstudio.com - Diese Einträge sind die erforderlichen Mindestdomänen. Wenn Sie Probleme haben, finden Sie die vollständige Liste der erforderlichen Domains unter Azure DevOps allowlist.

Weitere Informationen zum ausgehenden Datenverkehr finden Sie auf dieser Microsoft Lernseite.

Starten Sie die Bereitstellung

Um die Bereitstellung zu starten, müssen wir der Bereitstellung die Werte für die erforderlichen Variablen zur Verfügung stellen. Sehen Sie unten eine Beispieldatei:

scaffold_location = "westeurope"
scaffold_environment = "production"
scaffold_environment_short_name = "prod"
scaffold_location_short_name = "weu"
scaffold_company_short_name = "{insert-your-company-short-name}"

virtual_hub_id = "/subscriptions/{insert-your-hub-subscription-id}/resourceGroups/{insert-your-hub-resource-group-name}/providers/Microsoft.Network/virtualHubs/{insert-your-virtual-hub-name}"
vnet_devpool_ip_range = "{insert-your-ip-range}"
vnet_dns_servers = ["{insert-your-dns-server-ip}"]
agent_maximumConcurrency = 2 # This is the maximum number of agents that can run concurrently, keep in mind the SKU quota you have on your subscription
devops_organization_url = "https://dev.azure.com/{insert-your-organization-name}"
devops_projects = ["{inset-your-project-name}", "{insert another project name}"]

Da wir Terraform verwenden, können wir einfach die folgenden Befehle ausführen:

terraform init # This will initialize the backend settings and install the required providers
terraform validate # This will check if all
terraform plan --var-file=test.tfvars # This will execute a 'dry-run' to see what would be created, modified or removed, using the tfvars-file referenced
terraform apply --var-file=test.tfvars # This will firstly do another dry-run, asking a 'yes' to continue with the actual deployment, using the tfvars-file referenced

Beachten Sie, dass dadurch eine lokale Terraform-Statusdatei erstellt wird, was für meine Demozwecke ausreichend ist. Wenn Sie dies in einer Produktionsumgebung verwenden, aktualisieren Sie bitte das Status-Backend entsprechend.

Zur Erläuterung der Bereitstellung und der erforderlichen Schritte verwenden wir die Befehle direkt in einem Terminal. Wir bevorzugen und empfehlen die Verwendung von Azure Pipelines oder GitHub Actions zur Bereitstellung von Infrastructure as Code.

Kosten der Nutzung von DevOps Pools

Die Preise für Managed DevOps Pools richten sich nach den Kosten für die Azure-Dienste, die Ihr Pool nutzt, wie z.B. Compute, Storage und Datenexport, in Kombination mit den Standardpreisen für Azure DevOps Services für selbst gehostete Agenten.

• Azure Services - Der Managed DevOps Pool nutzt Azure-Ressourcen, um die Funktionalität bereitzustellen. Diese Ressourcen werden über Ihr Azure-Abonnement abgerechnet. Während der Public Preview fallen keine zusätzlichen Kosten für die Managed DevOps Pools Ressource selbst an.
• Azure DevOps Services - Die Kosten für die DevOps Services sind an die Kosten für selbst gehostete Agenten gebunden, d.h. Sie müssen für parallele Aufträge zahlen. Der erste parallele Auftrag ist kostenlos, danach wird für jeden weiteren parallelen Auftrag eine Gebühr von $15 erhoben.

Bitte beachten Sie, dass parallele Aufträge von allen Pipelines und Pools in Ihrem Unternehmen gemeinsam genutzt werden.

Fazit

Meiner Meinung nach lohnt sich der Einsatz von Managed DevOps Pools auf jeden Fall. Sie können sich entspannt zurücklehnen, da es sich um ein PaaS-Angebot handelt. Es lässt sich direkt in Ihr privates Netzwerk innerhalb Ihres Azure-Tenants integrieren und ermöglicht so bessere und sicherere Verbindungen. Und mit dem Code Repository erhalten Sie eine schnelle Einstiegsvorlage, um es nutzen zu können. Ein Managed DevOps Pool ist nur für die Teams verfügbar, die darauf Zugriff haben, und Sie können mehrere Pools mit unterschiedlichen Einstellungen erstellen, d.h. einen CPU-intensiven Pool und einen speicherintensiven Pool für verschiedene Teams.

Microsoft erwägt außerdem, Unterstützung für Container-basierte Agenten hinzuzufügen, um die Startzeiten bei Bedarf zu verbessern. Ich bin gespannt auf die Verbesserungen in der Zukunft!

Zusätzliche Informationen

Die Entstehungsgeschichte

Falls Sie mehr über die Entstehungsgeschichte lesen möchten, lesen Sie bitte die Geschichte von Suraj Gupta und Elize Tarasila

Links

• Code Repository
• Microsoft Lernen
• Die Entstehungsgeschichte
• Ankündigung der öffentlichen Vorschau

 

Dieser Artikel ist Teil von XPRT.#17. Laden Sie das Magazin hier herunter.