Azure ARC est une solution proposée par Microsoft permettant de manager des ressources non-Azure depuis Azure (Cad : hébergées sur d’autres Clouds tels que AWS ou On-Premise).
Azure ARC permet de manager plusieurs types de ressources entre autres :
- Serveurs (Windows et Linux).
- SQL server.
- Clusters Kubernetes.
- …
Pour le moment, nous allons nous orienter sur la gestion des ressources de type serveur.
Sommaire
Quelques explications
Le service Azure ARC n’est pas encore disponible sur l’ensemble des régions Azure pour l’instant, celui-ci est disponible sur les régions suivantes :
- East Asia
- Southeast Asia
- Australia East
- Canada Central
- North Europe
- West Europe
- France Central
- Japan East
- Korea Central
- UK South
- UK West
- Central US
- East US
- East US 2
- North Central US
- South Central US
- West Central US
- West US
- West US
- West US 3
Le service ne stocke pas de données à proprement parler, mais uniquement les metadatas.
Les systèmes d’exploitation supportés au moment où cet article est écrit sont :
- Windows Server 2008 R2 SP1
- Windows Server 2012 R2 et versions ultérieures (y compris Server Core)
- Ubuntu 16.04, 18.04 et 20.04 LTS (x64)
- CentOS Linux 7 et 8 (x64)
- SUSE Linux Enterprise Server (SLES) 12 et 15 (x64)
- Red Hat Enterprise Linux (RHEL) 7 et 8 (x64)
- Amazon Linux 2 (x64)
- Oracle Linux 7
cf: https://docs.microsoft.com/fr-fr/azure/azure-arc/servers/agent-overview#supported-operating-systems
Concernant la partie serveur Azure ARC va apporter entre autres les fonctionnalités Azure suivantes :
- Azure Policy
- Azure Security Center
- Azure Sentinel
- Azure Monitor
- Azure Automation (patch management)
- Azure Automanage
- VM extensions
cf : https://docs.microsoft.com/en-us/azure/azure-arc/servers/overview#supported-cloud-operations
Pour enregistrer un serveur dans la solution Azure ARC, il convient d’installer un agent “Azure Connected Machine Agent”. Cet agent permet d’enregistrer le serveur dans Azure puis de réaliser les déploiements additionnels tel que l’agent Log Analytics.
Du côté interconnexion, la communication entre les serveurs et Azure ARC passe pas le réseau public. La notion de “private endpoint” est actuellement en preview.
Préparation coté Azure
Comme souvent avant chaque déploiement de nouveau produit, une petite phase d’architecture est nécessaire.
L’idée globale pour Azure ARC est de dédier une Subscription pour cette solution, et de construire à l’intérieur de cette Subscription l’ensemble des composants annexes à ARC.
L’utilisation d’une Subscription dédiée permet de simplifier considérablement l’administration, notamment pour l’utilisation d’ASC.
Un autre débat peut-être organisé autour de l’usage d’un “Log Analytics Workspace” et d’un “Automation Account” dédié aussi. Bien que diverses méthodes permettent d’identifier les composants liés à une ou une autre solution, l’exploitation quotidienne de ce type de composant est plus simple si ceux-ci sont dédiés à une seule et unique solution.
Subscriptions et Ressources group
Afin de simplifier l’administration et de limiter la portée de certain service, je vous conseille de créer une Subscription dédiée pour Azure ARC (notamment pour l’utilisation d’Azure Policy et d’Azure Defender).
Microsoft recommande à minima la création du “Ressources Group” dédié pour Azure ARC.
Dans cette maquette, c’est ce qui sera utilisé :
- Sub : AzureARC – Pay-As-You-Go
- RG : we-AzureArc
SPN
Bien que cette étape ne soit pas obligatoire, et dépende du type de déploiement qui sera réalisé.
Il est nécessaire pour les déploiements industrialisés de créer un SPN dans Azure AD et attribuer le droit “Azure Connected Machine Onboarding” soit sur la “Subscription” ou sur le “Ressources group”.
Dans cette maquette, une “Subscription” est dédiée pour Azure ARC, les autorisations sont accordées au niveau de la “Subscription”.
Le SPN est créé à l’aide du script ci-dessous.
Récupérer impérativement les informations ci-dessous dans le retour de prompt du script :
- AppID
- AppSecret
Import-Module -Name Az.Resources
Import-Module -Name Az.Accounts
$strSubID = "EnterSubID"
$param = @{
DisplayName = "spn-zurearc-enrolment-servers";
Role = "Azure Connected Machine Onboarding"
Scope = "/subscriptions/$strSubID"
EndDate = $(Get-Date).AddMonths(1)
}
Connect-AzAccount
Set-AzContext -Subscription $strSubID
$objSPN = New-AzADServicePrincipal @param
$credential = New-Object pscredential -ArgumentList "temp", $objSPN.Secret
Write-Warning "AppID: $($objSPN.ApplicationId)"
Write-Warning "AppSecret: $($credential.GetNetworkCredential().password)"
Les SPN liés à Azure ARC peuvent être managés depuis la console Azure ARC.
En fonction des autorisations que vous possédez sur Azure AD, il vous sera possible de créer un SPN de manière graphique ou de gérer les secrets de celui-ci.
Log Analytics Workspaces et Automation Accounts
Énormément de composants de la solution Azure ARC reposent sur le couple “Log Analytics workspaces” et “Automation Accounts”.
Je fais le choix de suivre la même logique pour ces composants et les créé de manière dédiée à l’environnement Azure ARC :
- Log Analytics workspaces : law-we-azurearc
- Automation Accounts : aa-we-azurearc
Pour terminer la configuration, il est nécessaire de lier le “Log Analytics Workspace” au “Automation Accounts”.
Pour ce faire se rendre dans la section “Update management” de “l’Automation Accounts” et séléctionner le “Log Analytics Workspace” à lier.
Optionnel : après avoir lié le compte, il est possible de configurer la politique autour de “l’Update Management”, pour cette maquette, je choisi “Enable on all available and future machines”. Ce sera fait pour plus tard.
Réaliser la même opération pour “Change tracking” :
Optionnel : après avoir lié le compte, il est possible de configurer la politique autour du “Change tracking”, pour cette maquette, je choisi “Enable on all available and future machines”. Ce sera aussi fait pour plus tard.
Toutes les régions ne proposent pas la possibilitée de réaliser cette opération, se référer à :
Après quelques secondes, les deux composants sont liés.
Accèder à Azure ARC
Maintenant que quelques prérequis ont été réalisés, nous allons pouvoir nous rendre dans la console Azure ARC.
Pour se faire, se rendre dans “All services” et rechercher “ARC”.
Préparer l'enregistrement des serveurs
La console “Azure ARC” est maintenant ouverte, se rendre dans le blade “Servers” pour enregistrer notre premier serveur.
En cliquant sur “Add”, plusieurs possibilités d’ajout de serveur sont disponibles :
- Add a single server –> génère un script PowerShell pour l’installation de l’agent (demande authentification).
- Add multiple servers –> génère un script pour l’installation de l’agent et base l’authentification sur un SPN AAD.
- Add Update Management servers (preview) –> permet d’importer les serveurs déjà enrôlé dans le service “Update Management” + création d’un SPN AAD pour authentification.
Dans le cadre de cette maquette nous allons utiliser l’option “Add multiple servers” qui est très proche de “Add a single server”, mais permet un déploiement en masse (la différence se situe au niveau de l’authentification pour inscrire le serveur dans Azure. D’un côté une authentification est demandée pour chaque serveur de l’autre un secret est généré pour utiliser un SPN).
Quelque prérequis côté serveurs sont nécessaires à savoir :
- Les serveurs doivent accèder en https (443) aux URL suivantes :
- management.azure.com
- login.windows.net
- dc.services.visualstudio.com
- agentserviceapi.azure-automation.net
- *-agentservice-prod-1.azure-automation.net
- *.guestconfiguration.azure.com
- *.his.arc.azure.com
- Pour accèder à l’environnement Azure, l’agent peut utiliser :
- Accès direct à internet (le cas dans cette maquette ^^)
- Un proxy.
- Un private endpoint (preview) (pas encore testé).
- Etre administrateur /root de la machine.
- Avoir un SPN avec les droits “Azure Connected Machine Onboarding”. Action réalisée en prérequis ici.
Renseigner les informations concernant :
- La subscription /ressources group à utiliser.
- Les propriétés du client (ici : Windows).
- La méthode de connection (ici : Public)
Comme déjà évoqué précédement, la connexion utilise le réseau publique (pour cette maquette). Il est possible de configurer un proxy au besoin ou en version preview utiliser un private endpoint.
Séléctionner l’UPN précédement créé.
Puis pour finir, il est possible de configurer des Tags qui seront appliquées sur les objects Azure corespondant aux serveurs enregistrés dans Azure ARC.
Maintenant que l’ensemble des informations nécessaire à l’enregistrement des serveurs sont complétées, il est possible de déployer l’agent à l’aide du script fournis.
Télécharger le script et renseigner le secret généré lors de la création du SPN dans le champs :
$servicePrincipalSecret=”<ENTER SECRET HERE>”
# Add the service principal application ID and secret here
$servicePrincipalClientId="<ENTER APP ID>"
$servicePrincipalSecret="<ENTER SECRET HERE>"
# Download the package
function download() {$ProgressPreference="SilentlyContinue"; Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi}
download
# Install the package
$exitCode = (Start-Process -FilePath msiexec.exe -ArgumentList @("/i", "AzureConnectedMachineAgent.msi" ,"/l*v", "installationlog.txt", "/qn") -Wait -Passthru).ExitCode
if($exitCode -ne 0) {
$message=(net helpmsg $exitCode)
throw "Installation failed: $message See installationlog.txt for additional details."
}
# Run connect command
& "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect --service-principal-id "$servicePrincipalClientId" --service-principal-secret "$servicePrincipalSecret" --resource-group "we-AzureArc" --tenant-id "XXXXXXXXXXXXXXXXXXXX" --location "westeurope" --subscription-id XXXXXXXXXXXXXXXXXXXXXXXXX" --cloud "AzureCloud" --tags "Datacenter=Maison,City=LYON,StateOrDistrict=RHONE,CountryOrRegion=FRANCE" --correlation-id "1848f605-06f2-4c5d-9eee-8128684f8000"
if($LastExitCode -eq 0){Write-Host -ForegroundColor yellow "To view your onboarded server(s), navigate to https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.HybridCompute%2Fmachines"}Maintenant que le script est pret, nous allons pouvoir enregister notrce premier serveur.
Pour les personne qui souhaiterai déployer l’agent via un outil tel que SCCM, le script est découpé en 3 parties :
- Téléchargement de l’agent (https://aka.ms/AzureConnectedMachineAgent).
- Installation de l’agent (msiexec.exe /i AzureConnectedMachineAgent.msi /l*v installationlog.txt /qn).
- Connexion de l’agent à Azure ($env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe” connect –service-principal-id …).
Enregistrement des serveurs de type Windows
Pour enroller un serveur à Azure ARC, se rendre sur celui-ci, se connecté avec un compte ayant les droits administrateur.
Et exécuter le script précédement généré.
Après quelques minutes, le serveur est présent dans Azure ARC.
Sur le client, l’agent apparait dans la listes des applications installées sur la machine sous le nom “Azure Connected Machine Agent”.
Enregistrement des serveurs de type Linux
Concernant les serveurs de type Linux, réaliser les même opérations pour générer le script d’enrolment à la seule différence qu’il est nécessaire de séléctionner Linux et non Windows.
Puis exécuter le script “Bach” sur les serveurs à enregistrer.
chmod 777 ./OnboardingScript.sh
./OnboardingScript.sh
rm -rf ./OnboardingScript.sh
Résumé
Pour le moment, nous avons commencé à “mettre la lumière” sur l’infrastructure Azure ARC, enregistrer quelques serveurs et mis le doigt sur l’architecture cible à mettre en place pour héberger une production. Certes pas grand-chose de fonctionnel, mais les bases sont construite pour continuer à avancer et découvrir les fonctionnalités qu’offre Azure ARC.
Point de vue Architecture, si l’on se base sur la preview, l’utilisation d’un “Private-Endpoint” lorsque les différentes infrastructures sont interconnectées peut apporter une optimisation au niveau des flux réseau et une sécurité accrue afin de ne plus utiliser le réseau public.
Si vos serveurs utilisent déjà la fonctionalité “Update Management” ou autre, il convient de faire attention à la configuration des agents “Log Analytics Workspace”. Donc attention lors des phases d’architecture à prendre en compte l’ensemble des précédentes configurations.
Le déploiement est facilement industrialisable à l’aide d’outil tel que SCCM, Ansible ou autre.
Pour la partie prix, sauf erreur de ma part, Azure ARC ne coute pas plus cher que le service “Update Management”.
