El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Vas tancar el mòdul 1 amb els fonaments posats: el compte, la jerarquia de facturació, els grups de recursos rg-contoso-reservas-dev i rg-contoso-reservas-pro, l'esquema d'etiquetatge obligatori i un script d'Azure CLI que desplega tot això de manera idempotent. Ara comença la construcció real de la plataforma, i ho fem per la peça menys glamurosa i més inevitable: una màquina virtual.

Contoso Airlines té un problema molt comú en qualsevol migració. El seu motor de disponibilitat heretat —el procés que calcula quines places queden lliures a cada vol i a quin preu— és una aplicació Java monolítica escrita fa onze anys, amb dependències del sistema operatiu, rutes absolutes i un servei que arrenca amb un script propi. Ningú de l'equip no gosa reescriure'l abans de la temporada alta. En Diego Salas ho resumeix en una frase: «funciona, no l'entén ningú del tot, i si el toquem ara no venem bitllets al juliol».

Aquesta aplicació encara no pot anar a un servei de plataforma. Necessita un servidor amb accés al sistema operatiu. A Azure, això és una màquina virtual. En aquesta lliçó aprendràs quan una VM és la resposta correcta i quan és una mandra cara, quins recursos arrossega, com triar mida i disc sense arruïnar-te, com crear-la i configurar-la des d'Azure CLI i —sobretot— com aturar-la de manera que deixi de facturar de debò, que és un matís que sorprèn gairebé tothom el primer cop.

Avís de cost: aquesta lliçó crea recursos que es facturen per hora. Una mida Standard_B1s amb disc Standard SSD costa molt poc al dia, però no costa zero. Al final de la lliçó tens la neteja completa; executa-la si no continuaràs fent servir la VM.

Contingut

VM davant de PaaS: quan té sentit cadascun
Anatomia d'una màquina virtual a Azure
Famílies i mides de VM: com llegir la nomenclatura
Discos: tipus, rendiment i cost
Imatges: marketplace, imatges pròpies i galeries
Crear la VM del motor de disponibilitat amb Azure CLI
Connectar-s'hi per SSH i instal·lar el servei
Configuració inicial automàtica: cloud-init i extensions
Estats d'una VM i què es factura en cadascun
Instantànies i imatges: còpies i clons
Neteja en acabar
Errors Comuns i Consells
Exercicis
Conclusió

VM davant de PaaS: quan té sentit cadascun

A la lliçó 01-02 vas veure el model de responsabilitat compartida: amb IaaS gestiones el sistema operatiu cap amunt; amb PaaS, només la teva aplicació i les seves dades. La pregunta pràctica no és quin és «millor», sinó què t'obliga a quedar-te a baix.

Situació	Elecció raonable	Per què
Programari heretat amb dependències del SO, serveis propis, rutes fixes	Màquina virtual	Necessites control total del sistema operatiu
Llicència de tercers que exigeix instal·lació en servidor	Màquina virtual	El fabricant no dona suport a cap altre model
Aplicació web moderna (Java, .NET, Node, Python) empaquetable	App Service (02-03)	Menys superfície per administrar i pedaçar
Procés per esdeveniments, execució curta i intermitent	Azure Functions (06-03)	Pagues per execució, no per servidor encès
Aplicació ja contenidoritzada	Container Apps / AKS (06-01, 06-02)	Portabilitat i densitat
Necessites GPU, nucli personalitzat o programari de xarxa de baix nivell	Màquina virtual	Només IaaS et dona aquest nivell

El cost real d'una VM no és la factura mensual: és la feina recurrent que comporta. Pedaços del sistema operatiu, còpies de seguretat, enduriment de la configuració, supervisió de l'agent, rotació de claus. Amb App Service, bona part d'això desapareix de la teva llista.

Per això la decisió de Contoso queda registrada així, i convé que la interioritzis perquè marca tot el mòdul:

El motor de disponibilitat heretat va a VM, com a pas intermedi i explícitament temporal.
Contoso Reserves (web pública) i la nova API de Disponibilitat van a App Service (lliçó 02-03).
La VM es modernitza més endavant, quan l'equip pugui reescriure el motor; al mòdul 6 veuràs on acaba anant.

Això és exactament el que el Cloud Adoption Framework anomena rehost («lift and shift»): mous primer, optimitzes després. És una estratègia legítima sempre que el «després» tingui data. Si no en té, la VM s'hi queda deu anys.

Anatomia d'una màquina virtual a Azure

Quan al portal prems «Crear màquina virtual», Azure no crea un recurs: en crea uns quants, cadascun amb el seu propi cicle de vida i la seva pròpia línia a la factura. Entendre-ho evita la sorpresa clàssica d'esborrar la VM i continuar pagant.

graph TD
    RG["Grup de recursos<br/>rg-contoso-reservas-dev"] --> VM["Maquina virtual<br/>vm-motor-disponibilidad-dev"]
    VM --> OSD["Disc de SO gestionat<br/>(persistent)"]
    VM --> TMP["Disc temporal /mnt<br/>(volatil, no es factura a part)"]
    VM --> DAT["Discos de dades<br/>(opcionals, persistents)"]
    VM --> NIC["Interficie de xarxa (NIC)"]
    NIC --> SUBNET["Subxarxa d'una xarxa virtual"]
    NIC --> PIP["IP publica<br/>(opcional)"]
    NIC --> NSG["Grup de seguretat de xarxa<br/>(filtra el transit)"]

Els recursos que arrossega una VM:

Disc de sistema operatiu: disc gestionat, persistent. Sobreviu a la VM si no en marques l'esborrat.
Disc temporal: espai local de l'amfitrió físic, muntat normalment a /mnt (Linux) o D: (Windows). El seu contingut es perd si la VM es desassigna o es mou d'amfitrió. Serveix per a fitxers d'intercanvi i fitxers de treball llencívols. Mai per a dades.
Discos de dades: opcionals, persistents, es connecten i desconnecten en calent.
NIC: la targeta de xarxa virtual. Viu dins d'una subxarxa d'una xarxa virtual.
IP pública: opcional. Si és estàtica, es factura encara que la VM estigui apagada.
NSG: el tallafoc de nivell de xarxa. Es pot associar a la NIC o a la subxarxa (lliçó 02-05).

La regla mental útil: la VM és el còmput; tota la resta sobreviu a la VM. Per això el mòdul 1 acabava amb aquella consulta de discos orfes i IP públiques sense associar.

Famílies i mides de VM: com llegir la nomenclatura

Azure ofereix centenars de mides agrupades en famílies, cadascuna optimitzada per a un perfil de càrrega.

Família	Perfil	Quan fer-la servir	Exemple típic a Contoso
B (ràfegues)	Acumula crèdits de CPU quan està ociosa i els gasta als pics	Entorns de desenvolupament, servidors poc carregats amb pics curts	La VM de proves del motor de disponibilitat
D (ús general)	Equilibri CPU/memòria (≈4 GB per vCPU)	Servidors d'aplicació, web, càrregues normals	El motor de disponibilitat en producció
E (memòria)	≈8 GB per vCPU	Bases de dades, memòries cau, anàlisi en memòria	Un servidor d'informes heretat
F (còmput)	≈2 GB per vCPU, CPU més ràpida	Càlcul intensiu, processament per lots	Càlcul nocturn de tarifes
L (emmagatzematge)	Discos NVMe locals molt ràpids	Bases NoSQL, magatzems de dades grans	No aplica avui
N (GPU)	Acceleració gràfica o d'IA	Entrenament de models, render	No aplica avui
M (memòria massiva)	Centenars de GB o TB de RAM	SAP HANA, bases enormes	No aplica avui

Llegir un nom de mida

Un nom com Standard_D4ds_v5 es descompon així:

Standard_D 4 d s _v5
          │ │ │ │  │
          │ │ │ │  └── versio de la generacio (v5, v6...)
          │ │ │ └───── s = admet emmagatzematge premium (Premium SSD)
          │ │ └─────── d = inclou disc temporal local
          │ └───────── nombre de vCPU (4)
          └─────────── familia (D = us general)

Altres sufixos que apareixen sovint:

Sufix	Significat
`a`	Processador AMD
`p`	Processador Arm (Ampere); més barat, però requereix binaris Arm
`s`	Compatible amb emmagatzematge premium
`d`	Amb disc temporal local
`i`	Instància aïllada (amfitrió físic dedicat)
`m`	Variant amb més memòria dins de la família

Exemples concrets per orientar-te:

Standard_B1s: 1 vCPU, 1 GB de RAM. Ideal per provar i per a laboratoris com el d'aquesta lliçó.
Standard_B2ms: 2 vCPU, 8 GB. Un entorn de desenvolupament decent.
Standard_D4ds_v5: 4 vCPU, 16 GB. Un servidor d'aplicació de producció modest.
Standard_E8ds_v5: 8 vCPU, 64 GB. Una base de dades en VM.

Per veure què hi ha disponible a la teva regió i amb quin preu orientatiu, la CLI t'ajuda:

# Mides disponibles a West Europe, filtrant la serie B i mostrant
# nomes el que importa per decidir: nom, vCPU i memoria.
az vm list-sizes \
  --location westeurope \
  --query "[?starts_with(name, 'Standard_B')].{Mida:name, vCPU:numberOfCores, MemoriaMB:memoryInMb}" \
  --output table

az vm list-sizes retorna el catàleg de la regió; el --query amb JMESPath que vas aprendre a 01-06 filtra per prefix i reanomena les columnes. Compte: no totes les mides estan disponibles a totes les regions ni a totes les subscripcions (hi ha quotes, com vas veure a 01-05).

Consell de dimensionament: comença petit. Canviar la mida d'una VM a Azure és una operació de minuts (az vm resize), no un projecte. Sobredimensionar «per si de cas» és l'error de cost número u de les migracions, i Azure Advisor t'ho recordarà al mòdul 8.

Discos: tipus, rendiment i cost

Els discos d'Azure són discos gestionats: tu crees un recurs de disc i Azure s'ocupa dels comptes d'emmagatzematge, la replicació i la disponibilitat per sota. Abans existien els discos no gestionats en comptes propis; avui no hi ha cap raó per fer-los servir.

Tipus	Tecnologia	Rendiment	Casos d'ús	Cost relatiu
Standard HDD	Disc magnètic	Baix, latència variable (ms)	Còpies, arxius, càrregues d'accés esporàdic	€
Standard SSD	SSD	Moderat i més consistent	Desenvolupament, proves, servidors web lleugers	€€
Premium SSD	SSD, IOPS garantides	Alt, latència d'un dígit en ms	Producció, bases de dades, aplicacions sensibles	€€€
Premium SSD v2	SSD, IOPS i rendiment configurables a part de la mida	Alt i ajustable amb precisió	Producció amb necessitats fines	€€€
Ultra Disk	SSD de latència submil·lisegon	Molt alt, IOPS i MB/s ajustables en calent	SAP HANA, bases OLTP extremes	€€€€

Detalls que convé tenir clars des del principi:

El rendiment depèn de la mida en Standard i Premium SSD clàssics: un disc P10 (128 GB) dona menys IOPS que un P30 (1 TB). Si necessites més IOPS, de vegades la solució és un disc més gran, no un de més car.
Només les mides de VM amb s al nom admeten Premium SSD.
L'SLA d'instància única del 99,9 % exigeix discos Premium SSD (o superiors) a tots els discos de la VM. Amb discos Standard no hi ha SLA d'instància única; per a això calen zones o conjunts de disponibilitat, i d'això tracta la lliçó 02-02.
El disc temporal no es factura per separat, però és volàtil: es perd en desassignar la VM o si Azure la mou d'amfitrió físic. Tracta'l com una carpeta /tmp gran.
Els discos es facturen per capacitat aprovisionada, no per espai utilitzat: un disc d'1 TB amb 10 GB escrits costa com 1 TB. I continua costant encara que la VM estigui apagada.

Decisió de Contoso Airlines per al motor de disponibilitat:

Desenvolupament: Standard_B1s + disc de SO Standard SSD de 30 GB. Suficient per validar el desplegament.
Producció (quan arribi el moment): Standard_D4ds_v5 + Premium SSD, per tenir SLA i latència predictible.

Imatges: marketplace, imatges pròpies i galeries

Una imatge és la plantilla del disc de sistema operatiu des de la qual arrenca la VM.

Imatges del marketplace: publicades per Microsoft o per tercers. Inclouen des de sistemes operatius nets (Ubuntu, Debian, RHEL, Windows Server) fins a appliances amb programari preinstal·lat. Algunes porten cost de llicència addicional per hora a més del còmput: fixa't sempre en el preu abans de desplegar.
Imatges pròpies (personalitzades): creades a partir d'una VM que ja has configurat. Serveixen per al patró golden image: instal·les i endureixes un cop, desplegues cent vegades iguals.
Azure Compute Gallery: el servei per organitzar imatges pròpies amb versions, replicar-les a diverses regions i compartir-les entre subscripcions. És el que faràs servir quan les imatges deixin de ser una i passin a ser un catàleg.

Buscar imatges des de la CLI:

# Alies comodes que Azure mante (UbuntuLTS, Debian11, Win2022Datacenter...).
az vm image list --output table

# Cerca real al marketplace: totes les imatges d'Ubuntu Server 22.04
# publicades per Canonical i disponibles a West Europe.
az vm image list \
  --publisher Canonical \
  --location westeurope \
  --all \
  --query "[?contains(sku, '22_04')].{Publicador:publisher, Oferta:offer, SKU:sku, Versio:version}" \
  --output table

L'identificador complet d'una imatge té el format Publicador:Oferta:SKU:Versió, per exemple Canonical:ubuntu-24_04-lts:server:latest. Fer servir latest és còmode per a proves; en producció fixa una versió concreta perquè dos desplegaments del mateix script produeixin el mateix.

Crear la VM del motor de disponibilitat amb Azure CLI

Anem al gra. Creem la VM de desenvolupament del motor de disponibilitat, amb autenticació només per clau SSH (mai contrasenya), mida econòmica i les etiquetes obligatòries de Contoso.

Pas 1: generar el parell de claus SSH

# Genera un parell de claus ed25519 (mes curt i modern que RSA).
# -C afegeix un comentari que ajuda a identificar la clau despres.
ssh-keygen -t ed25519 -f ~/.ssh/contoso_motor -C "[email protected]"

Això crea dos fitxers: ~/.ssh/contoso_motor (clau privada, no surt mai del teu equip) i ~/.ssh/contoso_motor.pub (clau pública, la que pugem a Azure). Si l'ordre demana una frase de pas, posa-la: protegeix la clau si et roben el portàtil.

Pas 2: crear la màquina virtual

#!/usr/bin/env bash
set -euo pipefail

# ---- Parametres (mateixa nomenclatura que el modul 1) ----
GRUP="rg-contoso-reservas-dev"
REGIO="westeurope"
VM="vm-motor-disponibilidad-dev"
IMATGE="Canonical:ubuntu-24_04-lts:server:latest"
MIDA="Standard_B1s"

# ---- Creacio de la VM ----
az vm create \
  --resource-group "${GRUP}" \
  --name "${VM}" \
  --image "${IMATGE}" \
  --size "${MIDA}" \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/contoso_motor.pub \
  --public-ip-sku Standard \
  --public-ip-address-allocation static \
  --os-disk-name "disco-so-${VM}" \
  --os-disk-size-gb 30 \
  --storage-sku StandardSSD_LRS \
  --nsg-rule SSH \
  --tags entorno=desarrollo \
         proyecto=contoso-reservas \
         centro-coste=CC-1042 \
         [email protected] \
         criticidad=baja \
  --output table

Què fa cada opció, una per una:

Opció	Efecte
`--image`	Imatge de partida, en format `Publicador:Oferta:SKU:Versió`
`--size`	Mida de VM (família B, 1 vCPU, 1 GB)
`--admin-username`	Usuari administrador que es crea al sistema
`--ssh-key-values`	Clau pública que s'instal·la a `~/.ssh/authorized_keys`. En indicar-la, Azure deshabilita l'accés per contrasenya
`--public-ip-sku Standard`	SKU Standard: tancada per defecte, compatible amb zones. La SKU Basic està retirada
`--public-ip-address-allocation static`	La IP no canvia en reiniciar. Recorda: es factura encara que la VM estigui apagada
`--os-disk-name`	Nom explícit del disc, per no acabar amb noms aleatoris
`--storage-sku StandardSSD_LRS`	Tipus de disc del sistema operatiu
`--nsg-rule SSH`	Crea un NSG amb una regla d'entrada per al port 22
`--tags`	Les etiquetes obligatòries de l'esquema de Contoso, en minúscules i sense accents

Si no indiques xarxa virtual, az vm create en crea una amb un nom derivat (vm-motor-disponibilidad-devVNET) i una subxarxa per defecte. Per al laboratori serveix; en producció no. A la lliçó 02-05 dissenyarem vnet-contoso-pro amb les seves subxarxes i hi connectarem les VM amb --vnet-name i --subnet.

Advertència de seguretat: --nsg-rule SSH obre el port 22 a tot internet (0.0.0.0/0). És acceptable durant deu minuts en un laboratori; no ho és en producció. A 02-05 veuràs com restringir-lo per IP d'origen i, encara millor, com fer servir Azure Bastion per no exposar SSH en absolut.

La sortida inclou la IP pública assignada. També la pots recuperar en qualsevol moment:

IP=$(az vm show \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev \
  --show-details \
  --query publicIps \
  --output tsv)
echo "IP publica: ${IP}"

--show-details (o -d) és el que fa que az vm show inclogui dades de xarxa; sense ell, la consulta torna buida. És una d'aquelles raresses de la CLI que convé memoritzar.

Connectar-s'hi per SSH i instal·lar el servei

# Connexio amb la clau privada corresponent.
ssh -i ~/.ssh/contoso_motor azureuser@"${IP}"

Ja dins de la VM, simulem el desplegament del motor de disponibilitat. El motor real és Java, així que instal·lem l'entorn d'execució i un servei HTTP mínim que respongui com ho faria el motor:

# --- Dins de la VM ---
sudo apt-get update
sudo apt-get install -y openjdk-21-jre-headless nginx

# Pagina de salut que imita la resposta del motor heretat.
echo '{"servei":"motor-disponibilitat","estat":"ok","versio":"heretat-3.4"}' \
  | sudo tee /var/www/html/salud.json

sudo systemctl enable --now nginx
curl -s http://localhost/salud.json

Des del teu equip, comprova que respon per internet. Abans cal obrir el port 80 al NSG, perquè només vam obrir el 22:

# Regla d'entrada per a HTTP al NSG que va crear az vm create.
az network nsg rule create \
  --resource-group rg-contoso-reservas-dev \
  --nsg-name "vm-motor-disponibilidad-devNSG" \
  --name permitir-http \
  --priority 320 \
  --protocol Tcp \
  --destination-port-ranges 80 \
  --access Allow \
  --direction Inbound \
  --output none

curl -s "http://${IP}/salud.json"

La prioritat (320) determina l'ordre d'avaluació: número més baix, s'avalua abans. A 02-05 veuràs les regles per defecte i les etiquetes de servei amb detall.

Configuració inicial automàtica: cloud-init i extensions

Instal·lar a mà funciona un cop. Per fer-ho cent vegades igual hi ha dos mecanismes.

cloud-init (Linux)

cloud-init és l'estàndard de la indústria per configurar una màquina Linux en el seu primer arrencada. Se li passa un fitxer YAML i Azure l'injecta.

#cloud-config
package_update: true
packages:
  - openjdk-21-jre-headless
  - nginx
write_files:
  - path: /var/www/html/salud.json
    content: '{"servei":"motor-disponibilitat","estat":"ok","versio":"heretat-3.4"}'
    permissions: '0644'
runcmd:
  - systemctl enable --now nginx

Desa'l com a init-motor.yaml i fes-lo servir en crear la VM:

az vm create \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev \
  --image Canonical:ubuntu-24_04-lts:server:latest \
  --size Standard_B1s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/contoso_motor.pub \
  --custom-data init-motor.yaml \
  --output none

Bloc a bloc: package_update refresca l'índex de paquets; packages instal·la; write_files crea fitxers amb permisos concrets; runcmd executa ordres al final. La primera línia #cloud-config és obligatòria i ha de ser exactament aquesta: sense ella, cloud-init ignora el fitxer. Pots verificar el resultat dins de la VM amb cloud-init status --wait i revisar /var/log/cloud-init-output.log quan alguna cosa no surti.

Extensions de VM

Les extensions són agents petits que Azure instal·la i executa dins de la VM després de l'arrencada, a través de l'agent d'Azure. A diferència de cloud-init, es poden aplicar a una VM ja existent i es gestionen des del pla de control.

Extensió	Per a què serveix
`customScript`	Executa un script arbitrari (el comodí)
`AzureMonitorLinuxAgent`	Envia mètriques i registres a Log Analytics (mòdul 7)
`AADSSHLoginForLinux`	Inici de sessió SSH amb identitat de Microsoft Entra ID (mòdul 4)
`NetworkWatcherAgentLinux`	Diagnòstics de xarxa (lliçó 02-05)

# Executar un script de configuracio en una VM ja creada.
az vm extension set \
  --resource-group rg-contoso-reservas-dev \
  --vm-name vm-motor-disponibilidad-dev \
  --name customScript \
  --publisher Microsoft.Azure.Extensions \
  --version 2.1 \
  --settings '{"commandToExecute":"echo motor-disponibilitat-desplegat > /var/www/html/estado.txt"}' \
  --output none

Criteri pràctic: cloud-init per a la configuració base immutable de la primera arrencada; extensions per a agents de plataforma i per actuar sobre màquines ja desplegades. Si acabes escrivint scripts llargs en qualsevol dels dos, la resposta real és una imatge pròpia o un contenidor.

Estats d'una VM i què es factura en cadascun

Aquest apartat és el que més diners estalvia de tota la lliçó.

Estat	Ordre	Es factura el còmput?	Es factura el disc?	Notes
En execució	`az vm start`	Sí	Sí	Estat normal
Aturada (parada des de dins del SO)	`sudo shutdown -h now`	Sí	Sí	El maquinari continua reservat
Aturada (desassignada)	`az vm deallocate`	No	Sí	Allibera l'amfitrió; es perd el disc temporal
Eliminada	`az vm delete`	No	Depèn	Els discos i la IP poden sobreviure

Llegeix-ho una altra vegada: apagar la VM des de dins del sistema operatiu NO deixa de facturar el còmput. Azure manté els recursos de l'amfitrió reservats per a tu. Només la desassignació allibera el maquinari i atura el càrrec per còmput.

# Aturar i desassignar: aixo si que atura el rellotge del comput.
az vm deallocate \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev

# Comprovar l'estat real de la VM.
az vm get-instance-view \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev \
  --query "instanceView.statuses[?starts_with(code,'PowerState')].displayStatus" \
  --output tsv

Conseqüències de desassignar que has de conèixer:

Es perd el contingut del disc temporal (/mnt).
Si la IP pública és dinàmica, s'allibera i en arrencar en rebràs una altra. Amb estàtica la conserves, però la pagues mentre existeixi.
La IP privada dinàmica també pot canviar en reassignar.

Contoso aplica això de manera sistemàtica: les VM de rg-contoso-reservas-dev es desassignen cada nit i els caps de setmana. Al mòdul 7 automatitzaràs aquesta aturada amb Azure Automation, i al mòdul 8 veuràs quant representa a la factura (típicament, més de la meitat de la despesa dels entorns que no són producció).

Instantànies i imatges: còpies i clons

Dos mecanismes que es confonen sovint:

Mecanisme	Què és	Ús típic
Instantània (snapshot)	Còpia puntual d'un disc concret	Punt de retorn abans d'un canvi arriscat
Imatge	Plantilla d'una VM completa (SO + discos de dades), normalment generalitzada	Crear moltes VM idèntiques

# 1. Instantania del disc de sistema operatiu abans d'actualitzar el motor.
DISC_ID=$(az vm show \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev \
  --query "storageProfile.osDisk.managedDisk.id" \
  --output tsv)

az snapshot create \
  --resource-group rg-contoso-reservas-dev \
  --name "snap-motor-$(date +%Y%m%d)" \
  --source "${DISC_ID}" \
  --tags entorno=desarrollo proyecto=contoso-reservas centro-coste=CC-1042 \
  --output table

Primer obtenim l'ID de recurs del disc (aquella cadena /subscriptions/.../disks/... que vas veure a 01-05) i després creem la instantània a partir d'ell. Una instantània ocupa i es factura; esborra-la quan ja no la necessitis.

Per a una imatge generalitzada de Linux, el procés complet és: sudo waagent -deprovision+user dins de la VM, després az vm deallocate, az vm generalize i az image create. Una VM generalitzada ja no es pot tornar a fer servir: només serveix com a origen d'imatge. No ho facis amb la màquina que necessites demà.

Per a còpies de seguretat de debò (amb política, retenció i recuperació granular) no es fan servir instantànies manuals, sinó Azure Backup, que veuràs a la lliçó 07-05.

Neteja en acabar

# Opcio A: esborrar nomes la VM i els seus recursos associats (--yes evita la confirmacio).
az vm delete \
  --resource-group rg-contoso-reservas-dev \
  --name vm-motor-disponibilidad-dev \
  --yes

# Comprovacio imprescindible: han quedat discos o IP orfes?
az disk list --resource-group rg-contoso-reservas-dev --output table
az network public-ip list --resource-group rg-contoso-reservas-dev --output table
az network nic list --resource-group rg-contoso-reservas-dev --output table

# Opcio B (laboratori): esborrar el grup sencer. Irreversible.
# az group delete --name rg-contoso-reservas-dev --yes --no-wait

az vm delete no esborra per defecte el disc de SO, la NIC ni la IP pública. En crear la VM pots demanar que s'esborrin amb ella:

az vm create ... \
  --os-disk-delete-option Delete \
  --nic-delete-option Delete \
  --data-disk-delete-option Delete

Recorda que el grup rg-contoso-reservas-pro té el bloqueig no-borrar-produccion (CanNotDelete) que vas posar a 01-05: qualsevol intent d'esborrat allà fallarà fins que el retiris. És exactament el que volem.

Errors Comuns i Consells

Creure que apagar la VM deixa de facturar. Només az vm deallocate atura el càrrec per còmput. Apagar des del sistema operatiu no.
Esborrar la VM i deixar discos i IP orfes. Es facturen per existir. Revisa sempre després d'esborrar, o fes servir les opcions --*-delete-option Delete.
Desar dades al disc temporal. /mnt es buida en desassignar o en migrar d'amfitrió. Allà només hi va el que és llencívol.
Sobredimensionar la VM «per si de cas». Redimensionar és un az vm resize de dos minuts amb un reinici. Comença petit.
Obrir SSH o RDP a tot internet. El port 22 obert rep intents d'accés automatitzats en minuts. Restringeix per IP d'origen o fes servir Azure Bastion (02-05).
Fer servir contrasenyes en lloc de claus SSH. Amb --ssh-key-values Azure deshabilita l'accés per contrasenya. No hi ha cap raó per fer el contrari.
Fer servir latest a la versió d'imatge en producció. Dos desplegaments idèntics poden donar màquines diferents. Fixa la versió.
Oblidar --show-details a az vm show. Sense ell no veuràs les IP i creuràs que la VM no té xarxa.
Consell de nomenclatura: anomena explícitament disc, NIC i IP (disco-so-…, nic-…, ip-…). Els noms automàtics amb sufixos aleatoris converteixen la neteja en arqueologia.
Consell de llicències: si migres Windows Server o SQL Server amb Software Assurance, mira Azure Hybrid Benefit (lliçó 08-03) abans de desplegar; l'estalvi pot superar el 40 %.

Exercicis

Exercici 1: triar mida i disc amb criteri

Per a cada cas de Contoso Airlines, proposa família, mida aproximada i tipus de disc de SO, i justifica l'elecció:

VM de proves on en Diego Salas valida cada versió del motor de disponibilitat; es fa servir dues hores al dia.
Motor de disponibilitat en producció durant la temporada alta: 4 vCPU i 16 GB estimats, latència important, requereix SLA d'instància única.
Procés nocturn que recalcula tarifes: dues hores de CPU al 100 %, poca memòria, sense persistència rellevant.
Servidor d'informes heretat que carrega en memòria un cub de 48 GB.

Exercici 2: desplegar el motor amb cloud-init i verificar l'estalvi

Escriu un init-motor.yaml que instal·li nginx, creï /var/www/html/salud.json amb {"servei":"motor-disponibilitat","estat":"ok"} i arrenqui el servei.
Crea vm-motor-disponibilidad-dev a rg-contoso-reservas-dev amb Standard_B1s, disc Standard SSD de 30 GB, clau SSH i les quatre etiquetes obligatòries.
Obre el port 80 al NSG i comprova la resposta des del teu equip.
Desassigna la VM i demostra amb una ordre que el seu estat és deallocated.

Exercici 3: auditoria de despesa oculta

Escriu les ordres d'Azure CLI que responguin a aquestes preguntes a la subscripció de desenvolupament:

Quines VM hi ha i en quin estat d'energia està cadascuna?
Hi ha discos sense connectar a cap VM i quants GB sumen?
Hi ha IP públiques sense associar?
Quines VM no tenen l'etiqueta propietario?

Solucions

Solució 1:

Cas	Proposta	Justificació
1. Proves dues hores al dia	`Standard_B2s` + Standard SSD	La sèrie B acumula crèdits mentre està ociosa; amb desassignació nocturna el cost és mínim. No necessita SLA
2. Producció del motor	`Standard_D4ds_v5` + Premium SSD	Ús general equilibrat 4 vCPU/16 GB; l'SLA d'instància única del 99,9 % exigeix discos Premium a tots els discos
3. Recàlcul nocturn	`Standard_F4s_v2` + Standard SSD	Família de còmput: més CPU per euro i poca memòria necessària. Desassignar en acabar
4. Informes amb cub de 48 GB	`Standard_E8ds_v5` (8 vCPU / 64 GB) + Premium SSD	Família de memòria: ≈8 GB per vCPU, amb marge sobre els 48 GB del cub

Solució 2:

#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/salud.json
    content: '{"servei":"motor-disponibilitat","estat":"ok"}'
    permissions: '0644'
runcmd:
  - systemctl enable --now nginx

#!/usr/bin/env bash
set -euo pipefail

GRUP="rg-contoso-reservas-dev"
VM="vm-motor-disponibilidad-dev"

# 2. Creacio de la VM amb cloud-init i etiquetes obligatories.
az vm create \
  --resource-group "${GRUP}" \
  --name "${VM}" \
  --image Canonical:ubuntu-24_04-lts:server:latest \
  --size Standard_B1s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/contoso_motor.pub \
  --custom-data init-motor.yaml \
  --os-disk-name "disco-so-${VM}" \
  --os-disk-size-gb 30 \
  --storage-sku StandardSSD_LRS \
  --nsg-rule SSH \
  --tags entorno=desarrollo proyecto=contoso-reservas \
         centro-coste=CC-1042 [email protected] \
  --output none

# 3. Obrir HTTP i provar.
az network nsg rule create \
  --resource-group "${GRUP}" \
  --nsg-name "${VM}NSG" \
  --name permitir-http --priority 320 \
  --protocol Tcp --destination-port-ranges 80 \
  --access Allow --direction Inbound --output none

IP=$(az vm show -g "${GRUP}" -n "${VM}" --show-details --query publicIps -o tsv)
curl -s "http://${IP}/salud.json"

# 4. Desassignar i comprovar l'estat.
az vm deallocate --resource-group "${GRUP}" --name "${VM}"
az vm get-instance-view -g "${GRUP}" -n "${VM}" \
  --query "instanceView.statuses[?starts_with(code,'PowerState')].code" -o tsv
# Sortida esperada: PowerState/deallocated

Solució 3:

# 1. VM i el seu estat d'energia (--show-details inclou powerState).
az vm list --show-details \
  --query "[].{VM:name, Grup:resourceGroup, Estat:powerState, Mida:hardwareProfile.vmSize}" \
  --output table

# 2. Discos sense connectar i la seva mida.
az disk list \
  --query "[?diskState=='Unattached'].{Disc:name, GB:diskSizeGb, Grup:resourceGroup}" \
  --output table

# 3. IP publiques sense associar a cap configuracio de xarxa.
az network public-ip list \
  --query "[?ipConfiguration==null].{IP:name, Adreca:ipAddress, Grup:resourceGroup}" \
  --output table

# 4. VM sense etiqueta propietario.
az vm list \
  --query "[?tags.propietario == \`null\`].{VM:name, Grup:resourceGroup}" \
  --output table

Els punts 2 i 3 són la font més habitual de despesa invisible: es facturen per existir, no per fer-se servir.

Conclusió

Ja saps desplegar còmput IaaS a Azure amb criteri. Has vist quan una VM és la resposta correcta —el motor de disponibilitat heretat de Contoso, que encara no es pot reescriure— i quan és simplement el camí còmode i car. Coneixes l'anatomia completa d'una VM i els recursos que arrossega: disc de SO, disc temporal volàtil, discos de dades, NIC, IP pública i NSG, cadascun amb el seu cicle de vida propi. Saps llegir la nomenclatura de mides (Standard_D4ds_v5) i triar família segons el perfil de càrrega, i comparar tipus de disc entenent que l'SLA d'instància única exigeix Premium SSD. Has creat una VM Linux amb claus SSH, l'has configurada amb cloud-init i extensions i —el més rendible de la lliçó— has interioritzat la diferència entre aturada i aturada (desassignada), juntament amb la neteja que evita discos i IP orfes.

Ara bé, aquesta VM té un problema de fons que cap mida no arregla: és una sola màquina. Si l'amfitrió falla, si hi ha manteniment de plataforma o si a l'abril s'obre la venda de la temporada d'estiu i arriben deu vegades més peticions de les habituals, no hi ha xarxa de seguretat. Una instància única no té SLA llevat que sigui amb discos Premium, i tot i així continua sent un únic punt de fallada.

A la lliçó següent, Escalat i alta disponibilitat del còmput, resolem exactament això: escalat vertical davant d'horitzontal i per què el núvol aposta pel segon, conjunts d'escalat de màquines virtuals amb regles automàtiques per mètrica i programades per al pic de venda de Contoso, zones i conjunts de disponibilitat amb els seus dominis d'error i actualització, i les quatre opcions de balanceig de càrrega d'Azure comparades. En acabar tindràs l'API de Disponibilitat servint darrere d'un balancejador amb dues instàncies en zones diferents.

Màquines virtuals d'Azure