Tot recurs que creïs a Google Cloud viu dins d'un projecte, i tot projecte ocupa un lloc en una jerarquia. Aquesta estructura no és burocràcia administrativa: determina qui pot fer què, qui paga què, quines quotes s'apliquen, quines polítiques s'hereten i quins recursos es poden veure entre si. Dissenyar-la bé al principi costa una tarda; redissenyar-la dos anys després costa un trimestre.

En aquesta lliçó construïm l'estructura d'AlpinaShop a Google Cloud. Veurem la jerarquia completa Organització → Carpetes → Projectes → Recursos, què és exactament un projecte i per què el projectId és immutable i global, en quin sentit el projecte és una frontera de facturació, quotes, permisos i xarxa, com funcionen els comptes de facturació i qui els pot vincular, com es reparteix la despesa amb etiquetes, com s'exporta la facturació a BigQuery i com es llegeixen els informes i es configuren pressupostos. Acabarem amb les bones pràctiques d'estructura i un exemple pràctic complet amb gcloud.

1. La jerarquia de recursos de Google Cloud
2. La jerarquia d'AlpinaShop
3. Què és exactament un projecte: ID, número i nom
4. El projecte com a frontera
5. Comptes de facturació
6. Etiquetes per repartir la despesa
7. Informes, exportació a BigQuery i pressupostos
8. Herència de polítiques a la jerarquia
9. Bones pràctiques d'estructura de projectes
10. Exemple pràctic complet amb gcloud

Google Cloud organitza tot en un arbre de quatre nivells:

Cada nivell pot portar polítiques d'IAM i polítiques d'organització, i aquestes polítiques s'hereten cap avall. Aquest és el motiu real que existeixi la jerarquia: aplicar una regla una vegada i que cobreixi tot el que hi ha a sota.

Algunes precisions que eviten confusions:

• Sense organització no hi ha carpetes. Si et vas registrar amb un compte personal (lliçó 01-02), els teus projectes estan solts i no pots crear carpetes. Aquesta és una de les raons principals per fer servir Cloud Identity en una empresa.
• L'organització es crea sola. No la crees tu: apareix automàticament la primera vegada que un usuari del domini verificat crea un projecte.
• Els recursos no pengen de les carpetes, només els projectes. Una VM és sempre dins d'un projecte, mai directament en una carpeta.

Marta dissenya aquesta estructura per a AlpinaShop, deliberadament senzilla: per a una empresa de 40 persones, una jerarquia de tres carpetes i quatre projectes és més que suficient. Les estructures complexes són per a organitzacions amb desenes d'equips.

Per què aquesta estructura i no una altra:

• produccion i desarrollo separades permeten aplicar polítiques diferents a cada món. A producció es prohibiran les IP públiques i s'exigiran registres d'auditoria; a desenvolupament es permetrà més llibertat i s'hi posaran pressupostos baixos.
• compartido allotja el que serveix a tots dos entorns: el pipeline de CI/CD i el magatzem analític. Separar l'analítica en el seu propi projecte evita que les consultes de Lucía consumeixin quotes de producció i facilita donar-li permisos amplis allà sense donar-los-hi a la botiga.
• Un projecte per entorn, no un projecte amb recursos «de dev» i «de prod» barrejats. És la regla més important de totes.

En aquest mòdul treballarem només amb alpinashop-dev. La resta de projectes s'aniran creant quan els mòduls corresponents els necessitin.

Un projecte té tres identificadors diferents i confondre'ls genera errors difícils de diagnosticar.

Detalls del projectId que cal interioritzar:

• És únic a tot Google Cloud, no només a la teva organització. Si un altre client del món ja fa servir tienda, tu no pots. Per això els IDs corporatius solen portar prefix d'empresa.
• No es pot canviar mai. Ni reanomenant, ni per suport. L'única sortida és crear un altre projecte i migrar-hi els recursos, que en molts casos vol dir recrear-los.
• Regles de format: entre 6 i 30 caràcters, minúscules, números i guions, ha de començar per lletra i no pot acabar en guió.
• Quan esborres un projecte, el seu ID no s'allibera immediatament (i a la pràctica és millor assumir que no s'allibera mai per a ús propi).

Del projectNumber convé saber que apareix als comptes de servei predeterminats, amb formes com [email protected] o [email protected]. Quan vegis un número llarg en un correu de compte de servei, és el número del teu projecte.

El flag --format="table(...)" selecciona quins camps mostrar i els presenta en columnes. Sense ell, gcloud retornaria una taula per defecte amb menys informació. A la lliçó 01-06 veurem a fons --format i --filter.

Aquesta és la idea central de la lliçó: el projecte és simultàniament quatre fronteres diferents, i per això decidir què va en quin projecte és una decisió d'arquitectura.

D'aquestes quatre, la de xarxa és la que més sorprèn qui ve d'un entorn tradicional. Dues VMs en projectes diferents no comparteixen xarxa privada llevat que ho configuris explícitament mitjançant VPC compartida o peering, temes de les lliçons 03-01 i 07-03. Això és un avantatge d'aïllament, no un obstacle.

I una conseqüència útil que s'aprofita contínuament: esborrar un projecte esborra tot el que conté. És la manera més fiable de netejar un entorn de proves i de garantir que no queda res generant despesa.

Aquest marge de 30 dies és una xarxa de seguretat important: un esborrat accidental és recuperable, sempre que es detecti a temps.

Un compte de facturació defineix qui paga, amb quin mètode de pagament i a quines dades fiscals s'emet la factura. És un objecte que viu fora de la jerarquia de projectes: no penja d'una carpeta ni d'un projecte, sinó que s'hi associa.

La relació és N a 1: molts projectes poden apuntar a un mateix compte de facturació, però cada projecte en té com a màxim un.

Vincular un projecte a un compte de facturació exigeix permisos als dos costats, i això és una separació de responsabilitats deliberada:

A AlpinaShop, Marta té billing.admin, el responsable financer té billing.viewer per consultar la despesa sense poder tocar res, i Dani té billing.user sobre el compte per poder vincular projectes de proves ell mateix. El detall de com funcionen els rols d'IAM s'estudia a la lliçó 03-04.

unlink és una eina contundent i molt útil: és el «tall d'emergència» quan un projecte es dispara en cost. Atura el consum de serveis facturables gairebé de manera immediata, encara que també pot provocar la pèrdua de dades en serveis que no toleren quedar-se sense facturació. Fes-lo servir amb coneixement de causa.

Les etiquetes (labels) són parells clau-valor que es poden aplicar a projectes i a la majoria de recursos. El seu superpoder és que apareixen als informes de facturació i a l'exportació a BigQuery, cosa que permet respondre preguntes com «quant ens va costar l'entorn de desenvolupament el mes passat?» o «què gasta l'equip de dades?».

Regles de format:

• Clau i valor en minúscules, amb números, guions i guions baixos.
• Màxim 63 caràcters cadascun; fins a 64 etiquetes per recurs.
• La clau no pot estar buida; el valor sí.

Un esquema d'etiquetatge raonable per a AlpinaShop:

Consells sobre etiquetatge, apresos per la via dolorosa en molts equips:

• Defineix l'esquema abans de començar a crear recursos. Etiquetar 300 recursos a posteriori és un projecte en si mateix.
• Sigues estricte amb els valors. dev, desarrollo i Desarrollo són tres etiquetes diferents i trencaran els teus informes.
• No posis informació sensible a les etiquetes. Són visibles per a qualsevol amb permisos de lectura sobre el recurs.
• No confonguis labels amb tags. Google Cloud té a més unes tags (etiquetes amb governança) que serveixen per aplicar polítiques condicionalment, no per a facturació. Es veuen a la lliçó 07-07.

A la consola, Facturació → Informes ofereix una vista interactiva de la despesa amb filtres per projecte, servei, SKU, regió, etiquetes i període, i agrupació configurable. És on es responen la majoria de preguntes quotidianes.

Conceptes que apareixen en aquests informes i que convé distingir:

Un consell molt concret: quan la despesa no quadri, agrupa per SKU, no per servei. «Compute Engine: 210 €» no diu res; «Storage PD Capacity: 140 €» et diu que tens discos orfes.

Els informes de la consola són còmodes però limitats. Per a una anàlisi seriosa, Google permet exportar les dades de facturació a un dataset de BigQuery, on arriben amb detall diari per SKU, projecte, etiqueta i regió, i on es poden consultar amb SQL.

S'activa a Facturació → Exportació de facturació, triant el projecte i el dataset de destí. AlpinaShop l'enviarà al dataset alpinashop_analitica del projecte alpinashop-datos, perquè Lucía pugui creuar la despesa amb dades de negoci.

Dos advertiments:

• L'exportació no és retroactiva: només porta dades des del moment en què l'actives. És un altre motiu per configurar-la aviat encara que de moment no la facis servir.
• Les dades triguen unes quantes hores a aparèixer i es corregeixen durant el mes, així que no serveixen per a alertes en temps real.

L'anàlisi amb SQL d'aquestes dades correspon a la lliçó 04-01 (BigQuery) i el seu ús per optimitzar costos a la 07-05. Aquí n'hi ha prou d'activar-la.

Ja vam crear un pressupost bàsic a la lliçó 01-02. Ara podem aprofitar la jerarquia i les etiquetes per afinar-lo:

Punts a destacar de la comanda:

• --filter-labels limita el pressupost a la despesa dels recursos amb aquesta etiqueta, en lloc de a un projecte concret. És més flexible: si demà hi ha tres projectes de desenvolupament, el pressupost els cobreix tots sense tocar res.
• basis=forecasted-spend canvia la naturalesa de l'avís: en lloc d'avisar-te quan ja has gastat el 90 %, t'avisa quan la projecció de final de mes arriba a aquest percentatge. Dona dies de marge en lloc d'hores.
• Recorda de la lliçó 01-02: els pressupostos avisen, no bloquegen.

Segons la versió del SDK, aquest grup de comandes pot requerir el prefix alpha (gcloud alpha billing budgets ...). Comprova-ho amb gcloud billing budgets --help.

La jerarquia existeix, sobretot, perquè les polítiques s'apliquin una vegada i cobreixin tot el que hi ha a sota. Hi ha dos tipus de política i totes dues s'hereten:

Regles d'herència que cal entendre bé:

• Els permisos d'IAM s'acumulen cap avall i no es poden restar. Si concedeixes a algú el rol d'editor a nivell d'organització, ho serà a tots els projectes, i no li'l pots treure en un de concret mitjançant IAM. Per això concedir rols amplis en nivells alts és perillós.
• Les polítiques d'organització sí que restringeixen. Són l'eina correcta per prohibir coses, i per defecte una política definida en un node substitueix o es combina amb l'heretada segons la seva configuració.
• La regla pràctica: concedeix permisos al nivell més baix possible i restriccions al més alt possible.

Tots dos temes s'estudien a fons més endavant: IAM a la lliçó 03-04 i les polítiques d'organització i el govern a escala a la 07-07. El que necessites retenir ara és que el lloc on col·loques un projecte a la jerarquia determina què hereta, i per això moure un projecte entre carpetes canvia les seves polítiques efectives.

Sobre l'últim punt: hi ha una escola que defensa un projecte per microservei i entorn. Per a una organització gran amb equips autònoms pot tenir sentit; per a AlpinaShop seria una càrrega de manteniment desproporcionada. L'estructura ha de ser proporcional a la mida de l'equip. Quatre projectes per a 40 persones és raonable; quaranta no ho seria.

Marta muntarà l'estructura d'AlpinaShop des de Cloud Shell. Aquest bloc reuneix tot el que hem vist.

gcloud organizations list retorna les organitzacions sobre les quals tens permisos. Amb --format="value(ID)" n'extraiem només l'identificador numèric, sense capçaleres, per poder desar-lo en una variable. Si la sortida és buida, no tens organització (compte personal) i t'hauràs de saltar els passos de carpetes.

Aquí apareixen per primera vegada junts --filter i --format. --filter="displayName=desarrollo" redueix la llista a la carpeta que ens interessa, i --format="value(name)" n'extreu únicament l'identificador. És el patró de scripting que farem servir durant tot el curs.

Si el projecte ja existia de la lliçó 01-02 sense carpeta, es pot moure en lloc de recrear-lo:

El camp parent.type ha de mostrar folder i parent.id l'identificador de la carpeta de desenvolupament. billingEnabled ha de ser True: si és False, la vinculació no s'ha completat i pràcticament cap API funcionarà.

Amb això, AlpinaShop té una jerarquia real, un projecte correctament ubicat i etiquetat, facturació vinculada i una alarma econòmica activa.

• Triar malament el projectId. És immutable i global. Adopta la convenció empresa-carrega-entorn i aplica-la sense excepcions.
• Confondre projectId amb projectNumber. Quan una API o un missatge d'error en demani un de concret, dona-li aquell: no són intercanviables en tots els contextos.
• Barrejar desenvolupament i producció en un projecte. El dia que algú esborri per error la base de dades equivocada entendràs per què. A més impedeix separar quotes, permisos i cost.
• Concedir rols amplis a nivell d'organització o carpeta. Els permisos d'IAM s'hereten cap avall i no es poden restar en un nivell inferior.
• Etiquetar tard o de manera inconsistent. Un esquema definit des del principi i respectat val més que un de sofisticat aplicat a mitges.
• Activar l'exportació de facturació a BigQuery quan ja la necessites. No és retroactiva: els mesos anteriors estan perduts.
• Suposar que el pressupost talla la despesa. No ho fa. Continua sent un detector de fums.
• Consell: fes servir gcloud projects delete per netejar entorns de proves. És l'única manera fiable d'assegurar-te que no queda res facturant, i tens 30 dies de marge per penedir-te'n.
• Consell: no creïs més projectes dels que puguis governar. Cadascun arrossega permisos, xarxa, quotes i pressupost.

AlpinaShop creix i obre una filial a Portugal que operarà una botiga pròpia (alpinashop.pt) amb la seva pròpia base de dades, però compartirà el pipeline de CI/CD i el magatzem analític amb la matriu. A més, direcció exigeix poder veure d'un cop d'ull quant costa cada país per separat.

Dissenya la jerarquia resultant (carpetes i projectes), indica quines etiquetes hi afegiries i explica en quin nivell col·locaries la política que prohibeix crear VMs amb IP pública a producció i per què.

Respon raonadament:

1. Marta s'ha equivocat i ha creat el projecte amb l'ID alpinshop-dev (hi falta una a). Ho pot corregir? Quines opcions té?
2. Dani veu en un registre el correu [email protected]. Què és aquest número i com comprovaria a quin projecte pertany?
3. Marta vol que la despesa del projecte alpinashop-dev deixi de produir-se de manera immediata perquè un procés s'ha descontrolat. Quina comanda executa i quin risc assumeix?

Escriu un script de bash que creï un projecte anomenat alpinashop-pruebas amb aquestes característiques, comprovant a cada pas que l'operació ha tingut èxit:

• Ubicat a la carpeta desarrollo.
• Etiquetat amb entorno=pruebas, equipo=infraestructura i responsable=marta.
• Vinculat al compte de facturació.
• Amb un pressupost de 10 EUR i avisos al 50 %, 90 % (sobre previsió) i 100 %.

I afegeix al final la comanda que faries servir per eliminar per complet aquest entorn quan acabis les proves.

Solució 1

Una estructura raonable:

Etiquetes: a les ja existents (entorno, equipo, centro-coste) s'hi afegeix pais amb valors es i pt. Amb aquesta etiqueta, direcció obté el desglossament per país als informes de facturació sense necessitat de mirar la jerarquia, i es poden crear pressupostos per país amb --filter-labels=pais=pt.

La política que prohibeix IP públiques es col·loca a la carpeta produccion, no a cada projecte. Motius: es defineix una sola vegada, s'hereta automàticament per es i pt i per qualsevol país que s'hi afegeixi en el futur, i no afecta desenvolupament, on aquesta restricció entorpiria la feina. Col·locar-la a l'organització seria excessiu (trencaria desenvolupament) i col·locar-la a cada projecte seria fràgil (el proper projecte es crearia sense ella).

Solució 2

1. No ho pot corregir. El projectId és immutable. Les seves opcions són: (a) crear un projecte nou amb l'ID correcte i recrear o migrar els recursos, cosa barata si el projecte és acabat de crear i pràcticament buit; o (b) quedar-se amb l'ID erroni i corregir només el nom per mostrar, que sí que és editable amb gcloud projects update alpinashop-dev --name="...". Atès que el projecte és jove, el més sensat és recrear-lo i esborrar l'erroni.
2. És el projectNumber, l'identificador numèric del projecte, i aquesta adreça correspon al compte de servei predeterminat de Compute Engine d'aquest projecte. Per saber a quin projecte pertany:

   gcloud projects list --filter="projectNumber=482913057261" \\
     --format="value(projectId)"
   

3. Executa gcloud billing projects unlink alpinashop-dev. En desvincular la facturació, els serveis de pagament deixen de funcionar gairebé immediatament i la despesa s'atura. El risc és que alguns serveis no toleren quedar-se sense facturació i poden perdre dades o recursos: instàncies aturades, tasques cancel·lades, i en certs casos eliminació de recursos si la situació es prolonga. És una mesura d'emergència, no una manera de «pausar» un projecte. Una alternativa menys agressiva és identificar i aturar el recurs concret que s'ha descontrolat.

Solució 3

Per eliminar per complet l'entorn en acabar:

Aquesta única comanda elimina el projecte i tots els seus recursos, garantint que no queda res generant despesa. El projecte roman 30 dies en estat DELETE_REQUESTED i es pot recuperar en aquest termini amb gcloud projects undelete alpinashop-pruebas.

Aquesta lliçó ha establert l'esquelet sobre el qual es recolzarà tota la resta. Hem recorregut la jerarquia Organització → Carpetes → Projectes → Recursos i l'hem aplicada a AlpinaShop amb les carpetes produccion, desarrollo i compartido; hem distingit els tres identificadors d'un projecte i hem gravat que el projectId és immutable i únic a tot Google Cloud; hem vist que el projecte és simultàniament frontera de facturació, quotes, permisos i xarxa, i que esborrar-lo és la manera més fiable de netejar un entorn; hem entès els comptes de facturació, la seva relació N a 1 amb els projectes, qui els pot vincular i què significa unlink com a tall d'emergència; hem definit un esquema d'etiquetes per repartir la despesa per entorn, equip i centre de cost; hem activat l'exportació a BigQuery cap a alpinashop_analitica i hem afinat els pressupostos amb avisos sobre previsió; i hem repassat com s'hereta cada tipus de política i quina estructura de projectes és proporcional a una empresa de 40 persones.

Ja sabem qui és amo de què i qui paga. Falta l'altra coordenada: on viuen els recursos. A la lliçó següent, Regions, zones i model de responsabilitat compartida, veurem la geografia de Google Cloud —multiregió, regió i zona—, què significa que un servei sigui zonal, regional o global, com funciona la xarxa troncal privada de Google, quins criteris porten AlpinaShop a decidir entre europe-west1 i europe-southwest1 (latència, preu, serveis disponibles i residència de la dada sota el RGPD), què protegeix realment desplegar en diverses zones, i com es reparteix la responsabilitat de seguretat entre Google i tu segons el tipus de servei.