A la lliçó anterior vas crear un grup de recursos i un compte d'emmagatzematge fent clics, i van quedar preguntes a l'aire: què és realment un grup de recursos? Per què esborrar-lo elimina tot el que conté? Per què les etiquetes no s'hereten? I com pot ser que el portal, la línia d'ordres i una plantilla facin exactament el mateix?

La resposta a totes és la mateixa: Azure Resource Manager (ARM), el pla de control d'Azure. Entendre ARM és el que separa qui "sap fer servir el portal" de qui entén Azure. Aquesta lliçó és la més important del mòdul des del punt de vista conceptual, i les seves conseqüències pràctiques —organització, governança, cost, protecció de producció— t'acompanyaran fins a l'últim mòdul.

1. Què és Azure Resource Manager
2. La jerarquia completa d'Azure
3. Proveïdors de recursos i el seu registre
4. L'ID de recurs i com llegir-lo
5. Criteris reals per agrupar recursos
6. Bloquejos de recurs: protegir producció
7. Moure recursos entre grups i subscripcions
8. Etiquetes: per a què serveixen de debò
9. L'esquema d'etiquetatge de Contoso Airlines
10. Plantilles ARM i Bicep com a concepte
11. Límits i quotes de subscripció
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Azure Resource Manager és el servei de gestió d'Azure: l'única porta per on passen totes les operacions de creació, modificació, lectura i eliminació de recursos. No és una eina que facis servir directament; és l'API que hi ha darrere de totes les eines.

Conseqüències pràctiques d'aquest disseny, totes comprovables:

• Coherència total. El que pots fer pel portal ho pots fer per CLI, i a l'inrevés. Si alguna cosa apareix en una eina i no en una altra, sol ser qüestió de versió, no de capacitat.
• Un sol punt de seguretat. Els permisos RBAC (mòdul 4) i les polítiques (mòdul 4) s'apliquen a ARM, així que valen per a totes les eines per igual. No pots "esquivar" una política fent servir la CLI.
• Auditoria unificada. El registre d'activitat que vas veure a la lliçó anterior recull les operacions vinguin d'on vinguin.
• Desplegaments declaratius. ARM accepta plantilles que descriuen l'estat desitjat, resol l'ordre de creació i paral·lelitza el que pot.
• Operacions idempotents. Enviar dues vegades el mateix estat desitjat no crea dos recursos: convergeix al mateix resultat. Aquesta propietat és la base de la infraestructura com a codi.

Un matís que evita confusions futures: ARM governa el pla de control (crear un compte d'emmagatzematge, canviar-ne el nivell). El pla de dades (pujar un blob, executar una consulta SQL) l'atén cada servei amb el seu propi extrem i els seus propis permisos. Dos plans, dos models d'accés.

Quatre nivells, de major a menor abast. Cadascun té un propòsit diferent i és on s'apliquen determinades coses.

Regles de ferro que cal memoritzar:

1. Tot recurs pertany exactament a un grup de recursos, i aquest exactament a una subscripció.
2. Els permisos i les polítiques s'hereten cap avall. Un permís concedit a la subscripció s'aplica a tots els seus grups i recursos.
3. Les etiquetes NO s'hereten. Hi insisteixo perquè és contraintuïtiu justament pel punt anterior. Ho veurem a l'apartat 8.
4. Un grup de recursos pot contenir recursos de regions diferents. La seva pròpia regió només diu on es desen les metadades del grup.
5. Esborrar un grup de recursos esborra tot el seu contingut, sense excepció i sense paperera.

Sobre els grups d'administració: Contoso encara no els necessita amb dues subscripcions, però són l'eina correcta tan bon punt n'hi hagi diverses. Permeten, per exemple, aplicar una política de "només es pot desplegar en regions europees" a tot el que pengi del grup Producción, sense repetir-la subscripció a subscripció. Es desenvolupen a la lliçó 04-06 (Azure Policy).

Un proveïdor de recursos (resource provider) és el component d'ARM que sap crear i gestionar una família de recursos. El seu nom té la forma Microsoft.<Familia>:

Cada proveïdor ha d'estar registrat a la subscripció per poder-lo fer servir. El portal registra automàticament el proveïdor quan crees el primer recurs d'aquella família, per això normalment ni te n'adones. Però quan despleguis per CLI o amb una plantilla, un proveïdor sense registrar produeix un error críptic del tipus "The subscription is not registered to use namespace 'Microsoft.X'".

Els proveïdors també determinen quines versions d'API hi ha disponibles i en quines regions existeix cada tipus de recurs:

Cada recurs d'Azure té un identificador únic i global. Apareix als registres, als missatges d'error, a les plantilles i a qualsevol automatització, així que cal saber llegir-lo d'un cop d'ull.

Desglossament per segments:

Els recursos fills imbriquen el patró. Una base de dades dins d'un servidor SQL:

I alguns recursos viuen directament a la subscripció, sense grup (per exemple, una assignació de política a nivell de subscripció):

Obtenir l'ID d'un recurs des de la CLI:

La pregunta que tothom fa: "quants grups de recursos creo i què poso a cadascun?". La resposta professional no és "un per projecte" i prou.

Posa al mateix grup allò que neix i mor junt. Si esborraràs l'aplicació de reserves, vols que desaparegui també la xarxa virtual corporativa? No. Doncs no van al mateix grup.

• "Tot junt": un únic grup amb 300 recursos. Impossible de donar permisos amb criteri, impossible d'esborrar res amb seguretat.
• "Un per recurs": 300 grups amb un recurs cadascun. Tota la sobrecàrrega de gestió i cap dels avantatges.
• "Per tipus de recurs": un grup per a totes les VM, un altre per a totes les bases de dades. Sona ordenat i és un desastre: res no comparteix cicle de vida i no pots esborrar un projecte sense anar peça a peça.

Els tres últims s'aniran poblant als mòduls 2, 4 i 7. Fixa't que la xarxa està separada: és exactament el tipus de recurs compartit i durador que no ha de morir amb una aplicació.

Un bloqueig (lock) impedeix operacions destructives fins i tot a qui té permisos de propietari. És la xarxa de seguretat contra l'error humà, no contra l'atac.

Es poden aplicar a subscripció, grup de recursos o recurs individual, i s'hereten cap avall: un bloqueig al grup protegeix tots els seus recursos.

Des del portal: recurs o grup → Bloquejos → Afegeix.

ReadOnly és més agressiu del que sembla i provoca sorpreses:

• Un ReadOnly sobre un grup amb un compte d'emmagatzematge impedeix llistar les claus d'accés, perquè aquesta operació és tècnicament una escriptura (listKeys). Aplicacions que funcionaven deixen de funcionar.
• Un ReadOnly sobre una màquina virtual impedeix iniciar-la o aturar-la.
• Els bloquejos afecten el pla de control, no el de dades: amb CanNotDelete sobre un compte d'emmagatzematge, ningú no pot esborrar el compte, però qualsevol amb permisos de dades sí que pot esborrar els blobs de dins. Per a això existeixen altres proteccions (retenció, eliminació temporal), que es veuen al mòdul 2.

Pràctica recomanada a Contoso: CanNotDelete a tots els grups de producció i als recursos amb estat (bases de dades, comptes d'emmagatzematge, Key Vault). ReadOnly només en casos molt justificats i amb proves prèvies.

Els recursos es poden moure, però amb regles. És una operació habitual quan reorganitzes o quan un projecte passa de desenvolupament a producció.

• No tots els recursos es poden moure. Hi ha una llista oficial per tipus de recurs; comprova-ho sempre abans. Exemples habituals de restricció: passarel·les de VPN, algunes configuracions de xarxa i certs recursos amb dependències regionals.
• Moure no canvia la regió. Un recurs a West Europe continua a West Europe encara que el moguis a un grup la regió del qual sigui una altra. Per "moure'l de regió" cal recrear-lo o replicar-lo.
• Durant el moviment, el grup d'origen i el de destinació queden bloquejats per a escriptura fins que acabi.
• Cal moure els recursos dependents junts. Una VM necessita anar amb la seva interfície de xarxa, els seus discos i la seva IP pública.
• Els identificadors canvien, perquè l'ID inclou el grup. Qualsevol script, alerta o assignació de política que apunti a l'ID antic deixarà de funcionar.
• Les assignacions de permisos i les polítiques no viatgen amb el recurs: s'apliquen les del nou àmbit. Revisa l'accés després de moure.
• Moure entre subscripcions exigeix a més que totes dues siguin al mateix inquilí de Microsoft Entra ID i que els proveïdors estiguin registrats a la de destinació.

Consell pràctic: en un moviment important, valida primer:

Una etiqueta (tag) és un parell nom-valor que s'adjunta a una subscripció, un grup de recursos o un recurs. Cada recurs admet fins a 50 etiquetes.

Les etiquetes semblen un adorn fins que l'empresa té 400 recursos. Llavors es converteixen en l'única manera de respondre a preguntes crítiques:

És a dir: cost, propietat i compliment. Sense etiquetes, la conversa del mòdul 8 amb la Nuria Peña ("per què gastem 4.000 € aquest mes?") és impossible de mantenir, perquè Cost Management et sabrà dir que gastes en màquines virtuals, però no de qui són.

Les etiquetes no s'hereten. Una etiqueta posada en un grup de recursos no apareix als recursos que conté. És el parany número u d'Azure per a qui ve del portal, perquè tota la resta (permisos, polítiques, bloquejos) sí que s'hereta.

Per què importa tant? Perquè els informes de cost s'agreguen per l'etiqueta del recurs que genera el càrrec. Si vas etiquetar només el grup, els teus informes per centro-coste sortiran buits.

Les tres solucions reals:

1. Etiquetar en la creació, sempre, a la pestanya Etiquetes o amb el paràmetre --tags. És la disciplina bàsica.
2. Azure Policy amb efecte Modify: una política que afegeix automàticament al recurs l'etiqueta heretada del grup. És la solució professional i es veu a la lliçó 04-06.
3. Infraestructura com a codi: les etiquetes van escrites a la plantilla i s'apliquen soles a cada desplegament (lliçó 05-06).

Altres detalls operatius:

• Els noms d'etiqueta no distingeixen majúscules de minúscules per a les operacions, però els valors sí que les conserven tal com les escrius. Tria un format i respecta'l: produccion i Produccion es comptaran com a valors diferents als informes.
• No posis secrets a les etiquetes: són visibles per a qualsevol amb permís de lectura.
• Alguns tipus de recurs no admeten etiquetes; són minoria, però existeixen.

Sortida típica de l'última ordre:

I al portal: recurs o grup → secció Etiquetes → afegir parells nom/valor → Aplica. Per etiquetar molts recursos alhora, fes servir Tots els recursos, marca les caselles i prem Assigna etiquetes.

La Marta Ríos publica aquest esquema com a norma interna. És obligatori a tots els recursos i el farem servir durant tot el curs.

Regles de l'esquema:

1. Tots els valors en minúscules i sense accents, perquè els informes agrupin bé.
2. propietario és sempre una persona, no un departament: els departaments no responen al telèfon.
3. Els recursos sense les quatre etiquetes obligatòries es marquen com a no conformes i apareixeran a l'informe de compliment quan implantem Azure Policy (lliçó 04-06).

Aplicat als recursos que ja coneixes:

Ja saps que ARM accepta descripcions declaratives de l'estat desitjat. Aquestes descripcions són les plantilles ARM (JSON) i Bicep (un llenguatge més llegible que es compila a JSON). Aquí només el concepte: el desenvolupament complet és a la lliçó 05-06.

Una plantilla ARM en JSON, reduïda al mínim:

El mateix en Bicep, molt més llegible:

Tres idees per quedar-se:

• És declaratiu: descrius el resultat, no els passos. ARM calcula què cal crear, modificar o deixar igual.
• És idempotent: desplegar cinc vegades deixa el mateix resultat que desplegar-ne una.
• És versionable: la plantilla viu a Git, es revisa en una pull request i es desplega des d'una canalització (mòdul 5).

Truc d'aprenentatge que ja vas veure al portal: en qualsevol recurs, secció Automatització → Exporta la plantilla, obtens el JSON del recurs existent. És la millor manera d'aprendre la sintaxi a partir d'una cosa que ja funciona.

Azure no és infinit. Cada subscripció té límits (alguns fixos, altres ampliables obrint una sol·licitud de suport). Assabentar-se d'un límit enmig d'un desplegament urgent és una experiència desagradable i evitable.

Les xifres exactes canvien; consulta sempre "Subscripció d'Azure i límits, quotes i restriccions del servei" a la documentació oficial.

La quota que més problemes dona als principiants és la de nuclis de VM per regió i família: un compte gratuït nou pot tenir marge per a molt poques màquines, i l'error en desplegar ("Operation could not be completed as it results in exceeding approved quota") desconcerta perquè sembla una errada del desplegament i no ho és.

Consultar la teva quota real:

Per ampliar la quota: portal → Subscripcions → la teva subscripció → Ús + quotes → Sol·licita un augment. Se sol resoldre en minuts o hores.

• Crear un grup de recursos "calaix de sastre". Si no saps per què un recurs és allà, està mal ubicat. Agrupa per cicle de vida.
• Creure que les etiquetes s'hereten. No s'hereten. Etiqueta cada recurs en la creació o automatitza-ho amb Azure Policy.
• Etiquetar amb valors inconsistents. Produccion, produccion, PRO i prod són quatre valors diferents als informes de cost, i l'informe queda inservible. Fixa el vocabulari i respecta'l.
• Posar ReadOnly alegrement. Pot trencar aplicacions en impedir operacions que semblen de lectura però són d'escriptura (com llistar claus). Prova-ho primer a desenvolupament.
• Confiar en CanNotDelete per protegir dades. Protegeix el recurs, no el seu contingut. Els blobs de dins es poden esborrar igualment.
• Moure recursos sense comprovar la llista de compatibles ni avisar que els ID canviaran. Revisa després les alertes, els scripts i els permisos.
• Ignorar el registre de proveïdors en automatitzar en una subscripció nova. Registra els proveïdors al principi de l'script.
• Descobrir la quota de nuclis enmig d'un desplegament. Consulta-la abans amb az vm list-usage.
• Consell de cost: els grups de recursos, les etiquetes i els bloquejos són gratuïts. Fes-los servir sense por: són la infraestructura de governança més barata que existeix i la que més diners estalvia a mitjà termini.

Contoso Airlines llançarà a més un programa de fidelització ("Contoso Millas"), amb el seu propi web, la seva base de dades i el seu centre de cost CC-2077, propietat d'en Diego Salas. Compartirà la xarxa virtual corporativa i el Key Vault existents.

1. Proposa els grups de recursos necessaris i què conté cadascun.
2. Justifica per què la xarxa virtual no ha d'estar al grup del projecte.
3. Escriu el conjunt d'etiquetes obligatòries per al grup de producció de Contoso Millas.

1. Descompon aquest ID en les seves cinc parts i indica què és cadascuna:

2. Construeix l'ID que tindria una subxarxa anomenada snet-web dins d'aquesta mateixa xarxa virtual.
3. Escriu l'ordre de la CLI que retorna només l'ID del compte d'emmagatzematge sttarjetascontosopro del grup rg-contoso-reservas-pro.

1. Escriu les ordres per crear el grup rg-contoso-reservas-pro a West Europe amb les quatre etiquetes obligatòries i aplicar-hi un bloqueig CanNotDelete.
2. Escriu l'ordre que llista tots els recursos de la subscripció etiquetats amb proyecto=contoso-reservas.
3. La Marta intenta esborrar el grup des del portal i falla. Explica què passa i què ha de fer per aconseguir-ho legítimament.
4. En Diego posa ReadOnly sobre el grup de desenvolupament i, l'endemà, l'aplicació de proves deixa d'arrencar perquè no pot llegir les claus del compte d'emmagatzematge. Explica per què.

Solució 1:

1. Grups proposats:

2. La xarxa virtual té un cicle de vida diferent: sobreviu als projectes i la comparteixen diverses aplicacions. Si visqués dins del grup del projecte, en retirar Contoso Millas s'esborraria la xarxa de tothom, i a més caldria donar als desenvolupadors permisos sobre un recurs d'infraestructura que no han d'administrar.

3. Etiquetes del grup de producció de Millas:

Solució 2:

1. Descomposició:

2. ID de la subxarxa (recurs fill, s'hi imbrica tipus/nom):

3. Ordre:

Solució 3:

1. Creació i bloqueig:

2. Llistat per etiqueta:

3. El bloqueig CanNotDelete impedeix l'eliminació encara que la Marta en sigui propietària. Per esborrar-lo legítimament ha d'eliminar primer el bloqueig (az lock delete o portal → Bloquejos), cosa que exigeix permís sobre Microsoft.Authorization/locks, i després esborrar el grup. Aquest pas extra, deliberadament incòmode, és exactament el punt: obliga a una decisió conscient.

4. Perquè ReadOnly bloqueja qualsevol operació d'escriptura al pla de control, i obtenir les claus d'un compte d'emmagatzematge s'implementa com l'acció listKeys, que ARM classifica com a escriptura. L'aplicació no pot recuperar les claus i falla en arrencar. Solució: retirar el ReadOnly (fer servir CanNotDelete en el seu lloc) i, millor encara, deixar de fer servir claus i passar a identitats administrades (lliçó 04-02).

Azure Resource Manager és el pla de control únic d'Azure: portal, CLI, PowerShell, SDK i plantilles parlen amb la mateixa API, i per això els permisos, les polítiques i l'auditoria són coherents vinguis d'on vinguis. S'hi recolza la jerarquia grup d'administració → subscripció → grup de recursos → recurs, on els permisos i les polítiques s'hereten cap avall... i les etiquetes no.

Has après a llegir un ID de recurs, a registrar proveïdors, a agrupar recursos per cicle de vida i entorn (evitant el "tot junt" i l'"un per tipus"), a protegir producció amb bloquejos —coneixent els paranys de ReadOnly i els límits de CanNotDelete—, a moure recursos sabent que els ID canvien i que els permisos no viatgen, i a dissenyar un esquema d'etiquetatge seriós: el de Contoso Airlines, amb entorno, proyecto, centro-coste i propietario com a obligatòries. També has vist de què van les plantilles ARM i Bicep, i on són els límits i quotes que convé mirar abans i no després.

Has notat que en aquesta lliçó els exemples ja eren, gairebé tots, ordres. No és casualitat: governar desenes de recursos amb etiquetes i bloquejos a força de clics no escala. A l'última lliçó del mòdul, Azure CLI, PowerShell i Cloud Shell, aprendràs a manejar Azure des de la línia d'ordres i escriuràs el teu primer script complet, parametritzat i idempotent, que crea tota la base de Contoso Airlines i sap netejar-se després.