Fins ara hem treballat sobretot amb conceptes i amb la consola web. En aquesta lliçó canviem de marxa: aprendrem l'eina amb què s'administra Google Cloud de debò en el dia a dia, la CLI de gcloud, i l'entorn que la fa accessible des de qualsevol navegador sense instal·lar res, Cloud Shell.

Dominar gcloud no consisteix a memoritzar comandes, sinó a entendre'n l'estructura, saber demanar-li ajuda i saber extreure exactament la dada que necessites. Amb això, qualsevol operació de qualsevol servei es torna deduïble. Veurem què és Cloud Shell i quins límits té, com instal·lar el CLI en local, l'anatomia d'una comanda i el sistema d'ajuda, els formats de sortida i els filtres, l'autenticació i els seus dos modes, les configuracions anomenades per alternar entre alpinashop-dev i alpinashop-prod, la resta d'eines del SDK, i el scripting bàsic que encadena comandes.

I tancarem el mòdul amb el primer desplegament real del curs: Dani publicarà a internet una pàgina de «pròximament» d'AlpinaShop, d'extrem a extrem, sense sortir del navegador.

1. Què és Cloud Shell
2. Instal·lació local del Google Cloud CLI
3. Cloud Shell davant de CLI local
4. Anatomia d'una comanda gcloud i sistema d'ajuda
5. Formats de sortida: --format
6. Filtres: --filter
7. Autenticació: gcloud init, auth login i application-default
8. Configuracions anomenades
9. Altres eines del SDK
10. Scripting bàsic amb gcloud
11. Primer desplegament real: la pàgina de «pròximament» d'AlpinaShop

Cloud Shell és una màquina virtual Linux gratuïta que s'obre dins del navegador des de la icona >_ de la consola. Està pensada perquè puguis administrar Google Cloud sense instal·lar res i sense configurar credencials.

Què porta ja instal·lat i configurat:

Característiques i límits que cal conèixer abans de confiar-hi:

La conseqüència pràctica del punt de la persistència és important: si instal·les alguna cosa amb apt install, desapareixerà a la sessió següent. Perquè sobrevisqui, o bé ho instal·les al teu $HOME, o bé ho automatitzes al fitxer ~/.customize_environment, que Cloud Shell executa en arrencar la màquina.

Dues funcions addicionals que farem servir:

• Cloud Shell Editor: s'obre amb el botó «Obrir editor» i dona un IDE al navegador, amb explorador de fitxers, terminal integrada i ressaltat de sintaxi. Molt còmode per escriure scripts o editar un Dockerfile sense sortir de la consola.
• Vista prèvia web: la icona amb forma d'ull permet obrir al navegador un servei que estiguis executant a Cloud Shell (per defecte al port 8080) mitjançant una URL temporal i autenticada. És el que permet provar l'aplicació Flask d'AlpinaShop sense desplegar-la.

Cloud Shell és excel·lent per aprendre i per a tasques puntuals, però per treballar-hi diàriament voldràs el CLI a la teva pròpia màquina, amb el teu editor, els teus fitxers i els teus scripts.

Linux (Debian/Ubuntu), mitjançant el repositori oficial:

macOS, amb Homebrew:

Windows: descarrega l'instal·lador GoogleCloudSDKInstaller.exe des de la documentació oficial i executa'l. En finalitzar ofereix llançar gcloud init. També funciona perfectament instal·lant la versió Linux dins de WSL2, que és l'opció preferida per molts desenvolupadors.

Gestió de components addicionals:

Un avís: si vas instal·lar el CLI mitjançant apt o Homebrew, gcloud components update pot estar deshabilitat, perquè el gestor de paquets s'encarrega de les actualitzacions. En aquest cas, actualitza amb apt upgrade o brew upgrade. A Cloud Shell, el CLI s'actualitza sol.

La recomanació per a aquest curs: fes servir Cloud Shell. Elimina tota la fricció d'instal·lació i garanteix que treballes amb la mateixa versió que es descriu aquí. Instal·la el CLI local quan comencis a desenvolupar de debò.

Totes les comandes de gcloud segueixen la mateixa estructura, i entendre-la és el que converteix la CLI en una cosa deduïble en lloc de memoritzable:

Exemples llegits segons aquesta estructura:

Els verbs són consistents entre serveis, i aquesta consistència és el que permet deduir comandes que no has vist mai:

Si saps que existeix gcloud compute instances list, pots deduir que existirà gcloud sql instances list i gcloud run services list. I encertes.

gcloud search-help és una eina infravalorada: cerca a tota l'ajuda del CLI i retorna les comandes rellevants ordenades per pertinença. Quan no sàpigues quina comanda fer servir, comença per aquí.

Algunes comandes només estan disponibles en fases preliminars i requereixen un prefix:

Regla pràctica: si una comanda «no existeix», prova amb beta i amb alpha abans de donar-la per impossible. I no facis servir comandes alpha a producció: la seva interfície pot canviar sense avís previ.

Per defecte, gcloud retorna una taula pensada per a humans. El flag --format permet canviar completament aquesta sortida, i és la clau per fer servir gcloud dins d'scripts.

Exemples aplicats:

Funcions útils dins de --format, que estalvien molt postprocessament:

La regla que convé gravar: table perquè ho llegeixis tu, value perquè ho llegeixi un script, json per processar-ho amb jq.

--filter redueix el conjunt de resultats al costat del servidor o del client segons la comanda, evitant haver de filtrar amb grep, que és fràgil.

Operadors disponibles:

Exemples aplicats a AlpinaShop:

Com descobrir per quins camps es pot filtrar: mira primer la sortida en JSON. Els noms de camp del JSON són exactament els que accepta --filter.

Aquest apartat resol una de les confusions més habituals entre qui comença.

És l'assistent de configuració inicial. Fa tres coses en una: t'autentica, et deixa triar projecte per defecte i et deixa triar regió i zona per defecte.

Fes-lo servir la primera vegada que configures el CLI en una màquina, o quan vulguis crear una configuració nova des de zero.

Són dues credencials diferents, per a dos consumidors diferents:

L'escenari clàssic que confon tothom: Dani executa gcloud storage ls i funciona, però el seu script de Python falla amb un error de credencials. La causa és que va fer gcloud auth login però no gcloud auth application-default login: la biblioteca client busca les ADC, no les credencials del CLI.

Per a processos automatitzats (un pipeline de CI/CD, una tasca programada) no es fan servir credencials d'usuari, sinó comptes de servei. I dins de Google Cloud, el correcte és no descarregar claus: una VM, un servei de Cloud Run o un pod de GKE obtenen credencials automàticament del compte de servei que tinguin associat.

Els comptes de servei, els seus rols i les alternatives segures a les claus descarregades (Workload Identity Federation) s'estudien a la lliçó 03-04.

Una configuració de gcloud és un conjunt de propietats: compte actiu, projecte, regió i zona per defecte. En pots tenir diverses amb nom i saltar entre elles amb una comanda, cosa que resol elegantment el problema d'alternar entre alpinashop-dev i alpinashop-prod.

Dues tècniques complementàries molt recomanables:

I un consell que evita accidents seriosos: afegeix el projecte actiu al teu prompt de bash. Veure a cada línia sobre quin projecte estàs treballant és la millor prevenció contra executar a producció una cosa pensada per a desenvolupament.

El Google Cloud CLI inclou diverses eines a més de gcloud:

Aquestes eines es faran servir a fons als seus mòduls corresponents: Cloud Storage a 02-02, GKE a 02-05 i BigQuery a 04-01. Aquí només deixem constància que existeixen i que s'instal·len juntes.

La combinació de --format=value(...) amb bash converteix gcloud en una eina d'automatització potent. El patró fonamental és sempre el mateix: llistar amb un filtre, extreure un valor net, iterar.

Bones pràctiques per a scripts de gcloud:

• Comença sempre amb set -e perquè l'script s'aturi tan bon punt una comanda falli, en lloc de continuar sobre un estat inconsistent.
• Indica el projecte explícitament amb --project en scripts importants, en lloc de dependre de la configuració activa. Un script que esborra recursos i confia en la configuració activa és un accident esperant a passar.
• Prova primer sense --quiet, per veure què et preguntarà i sobre quins recursos actuaria.
• Moltes comandes accepten --dry-run o tenen equivalents de només lectura: fes-los servir abans d'executar operacions destructives.

Arriba el moment de posar alguna cosa a internet. Dani publicarà una pàgina estàtica de «pròximament» mentre l'equip prepara la migració, fent servir Cloud Storage per allotjar-la. És un avançament deliberat del servei que s'estudia a fons a la lliçó 02-02: aquí el fem servir com a exercici integrador de tot l'après al mòdul, sense entrar en classes d'emmagatzematge, cicles de vida ni versionat.

Pas 1. Preparar l'entorn. Obre Cloud Shell i confirma on ets:

Pas 2. Crear la pàgina. Fes servir l'editor o directament el terminal:

El bloc cat > fitxer <<'HTML' ... HTML és un here-document: escriu al fitxer tot el que hi ha entre les dues marques. Posar la marca entre cometes simples evita que bash intenti interpretar $ o cometes dins del contingut.

Pas 3. Crear el bucket. Els noms de bucket són únics a tot Google Cloud, igual que els projectId, així que hi afegim un sufix per evitar col·lisions:

Desglossament de la comanda:

• gs:// és l'esquema d'URI de Cloud Storage.
• --location=europe-west1 fixa la regió. Recorda de la lliçó 01-05: la ubicació d'un bucket és immutable.
• --uniform-bucket-level-access desactiva les llistes de control d'accés per objecte i fa que tots els permisos es gestionin només amb IAM. És l'opció recomanada perquè simplifica enormement el raonament sobre qui pot veure què.

Pas 4. Pujar els fitxers:

Pas 5. Fer públic el contingut. Aquest pas concedeix lectura a qualsevol a internet. És exactament el que volem per a una pàgina pública, i exactament el que mai has de fer amb un bucket que contingui dades internes:

allUsers és un identificador especial d'IAM que significa «qualsevol, autenticat o no». El rol roles/storage.objectViewer concedeix només lectura d'objectes: no permet llistar la configuració del bucket ni escriure res.

Pas 6. Configurar el bucket com a lloc web i comprovar el resultat:

Si curl retorna l'HTML que vas escriure, acabes de publicar el teu primer contingut a Google Cloud: has creat un recurs a la regió correcta, n'has configurat els permisos i ho has verificat, tot des del navegador i sense instal·lar res.

Pas 7. Netejar. Fonamental: no deixis recursos encesos que no faràs servir.

El que no hem fet aquí, i es veurà més endavant: servir la pàgina sota el domini alpinashop.example amb certificat TLS (requereix un balancejador de càrrega, lliçó 03-07), accelerar-la amb Cloud CDN (03-03), triar classe d'emmagatzematge i regles de cicle de vida (02-02) i automatitzar el desplegament amb Cloud Build (06-01).

• Confondre gcloud auth login amb gcloud auth application-default login. El primer autentica el CLI; el segon, el teu codi. Si el teu script de Python falla amb error de credencials i gcloud funciona, és això.
• Instal·lar paquets a Cloud Shell i perdre'ls. Només $HOME persisteix. Fes servir ~/.customize_environment per al que necessitis a cada arrencada.
• Executar una comanda al projecte equivocat. Fes servir configuracions anomenades, posa el projecte al prompt i afegeix --project explícit als scripts perillosos.
• Filtrar amb grep en lloc de --filter. grep depèn del format de sortida, que pot canviar; --filter opera sobre els camps reals de l'objecte.
• Fer servir --quiet en teclejar a mà. Està pensat per a scripts desatesos. Interactivament, aquestes confirmacions són la teva última línia de defensa.
• Suposar que una comanda no existeix. Prova gcloud search-help, i prova els prefixos beta i alpha.
• Treballar amb un CLI desactualitzat. Molts errors estranys es resolen amb gcloud components update.
• Consell: aprèn --format=json per explorar. És la manera de descobrir quins camps té un recurs i, per tant, per quins camps pots filtrar i què pots extreure.
• Consell: desa les teves comandes en scripts des del principi. El que avui teclejes a mà, demà ho repetiràs; i al mòdul 6 ho convertiràs en un pipeline.
• Consell: fes servir l'enllaç «Línia de comandes equivalent» de la consola. Continua sent la manera més ràpida d'aprendre comandes noves.

Escriu les comandes gcloud que resolguin el següent. Executa-les al teu projecte per comprovar-les:

1. Mostrar tots els teus projectes en una taula amb només l'ID i el número de projecte.
2. Desar en una variable de bash anomenada NUM el número del projecte alpinashop-dev, sense capçaleres ni text addicional.
3. Llistar les APIs habilitades el nom de les quals contingui storage o sql, mostrant únicament el nom.
4. Llistar les zones de la regió europe-west1 mostrant nom i estat en format de taula.
5. Esbrinar, sense sortir del terminal, quina comanda de gcloud serveix per gestionar pressupostos de facturació.

Marta necessita treballar sobre dos projectes i vol evitar accidents.

1. Crea dues configuracions anomenades, alpinashop-dev i alpinashop-prod, cadascuna amb el seu projecte, la regió europe-west1 i la zona europe-west1-b.
2. Escriu la comanda per llistar les instàncies de producció sense canviar la configuració activa (dues maneres diferents d'aconseguir-ho).
3. Dani executa correctament gcloud storage ls però el seu script de Python falla amb DefaultCredentialsError. Explica'n la causa i dona la comanda que ho soluciona.
4. Proposa una mesura addicional que redueixi el risc d'executar per error una comanda destructiva a producció.

Reprodueix el desplegament de l'apartat 11 amb una variant: en lloc d'una pàgina fixa, la portada ha de mostrar la data en què es va generar i la regió on està allotjat el bucket.

1. Genera l'index.html incloent-hi la data actual i el nom de la regió.
2. Crea el bucket amb un nom únic, puja-hi el fitxer, fes-lo públic i configura'l com a lloc web.
3. Verifica amb curl que el contingut servit inclou la data.
4. Escriu un petit script que comprovi que el bucket existeix i mostri quants objectes conté.
5. Elimina tots els recursos creats.

Solució 1

El punt 5 retornarà, entre altres resultats, gcloud billing budgets, amb les seves accions create, list, describe, update i delete. És la manera correcta de descobrir comandes sense sortir del terminal.

Solució 2

La primera fa servir la configuració completa de producció (compte, projecte, regió); la segona només sobreescriu el projecte i conserva la resta de la configuració activa. Per a operacions de només lectura totes dues serveixen; si les configuracions fessin servir comptes diferents, la primera seria la correcta.

3. La causa és que gcloud auth login autentica el CLI, però les biblioteques client de Python busquen les Application Default Credentials, que són un fitxer diferent. La solució:

4. Diverses mesures vàlides, i l'ideal és combinar-les: mostrar el projecte actiu al prompt de bash (export PS1='[$(gcloud config get-value project)] \w\$ '); fer servir sempre --project explícit als scripts que esborren o modifiquen recursos; no concedir al compte de treball diari permisos d'esborrat a producció, aplicant el principi de mínim privilegi (lliçó 03-04); i fer servir navegadors o perfils diferents per a consola de desenvolupament i de producció.

Solució 3

Fixa't en una diferència respecte a l'exemple de l'apartat 11: aquí la marca del here-document no va entre cometes simples (<<HTML en lloc de <<'HTML'), precisament perquè volem que bash substitueixi $(date ...) i $REGION abans d'escriure el fitxer.

La comprovació fa servir describe redirigint la sortida a /dev/null i avaluant només el seu codi de sortida: si el bucket no existeix, la comanda falla i entra a la branca else. El patró gs://$BUCKET/** llista tots els objectes de manera recursiva, i wc -l els compta.

Amb aquesta lliçó tanquem el mòdul 1, i ho fem amb alguna cosa funcionant a internet. Hem après què és Cloud Shell, què porta preinstal·lat i quins són els seus límits reals —especialment que només persisteixen els 5 GB del teu $HOME—, a més del seu editor web i la vista prèvia. Hem vist com instal·lar el CLI a Linux, macOS i Windows, i quan compensa cada opció. Hem desmuntat l'anatomia d'una comanda gcloud en grup, subgrup, acció i flags, cosa que converteix la CLI en una cosa deduïble, i hem après a demanar-li ajuda amb --help i gcloud search-help. Hem dominat --format (amb table per llegir, value per a scripts i json per explorar) i --filter amb tots els seus operadors. Hem aclarit la diferència entre gcloud auth login i gcloud auth application-default login, i hem muntat configuracions anomenades per alternar amb seguretat entre alpinashop-dev i alpinashop-prod. Hem conegut gcloud storage, bq i kubectl, que ens acompanyaran en mòduls posteriors, i hem escrit els nostres primers scripts encadenant gcloud amb bash. I, sobretot, Dani ha publicat la pàgina de «pròximament» d'AlpinaShop des del navegador, ha comprovat que se serveix i ha netejat els recursos després.

Repassant el mòdul sencer: vam entendre què és el núvol i per què AlpinaShop el necessita, vam obrir el compte amb pressupostos de seguretat des del primer dia, vam aprendre a moure'ns per la consola, vam dissenyar la jerarquia de projectes i la facturació, vam triar europe-west1 com a regió i vam comprendre quina part de la seguretat és nostra, i ara sabem manejar les eines. Tenim el terreny preparat i sabem fer servir la maquinària.

Al mòdul 2, Serveis principals de GCP, comencem a construir de debò: crearem màquines virtuals amb Compute Engine, mourem els 60 GB d'imatges de producte al bucket alpinashop-catalogo de Cloud Storage, migrarem la base de dades tienda a la instància Cloud SQL alpinashop-pedidos, coneixerem App Engine i el clúster alpinashop-cluster a Google Kubernetes Engine, explorarem les bases de dades NoSQL i acabarem amb el criteri per triar el servei de còmput adequat en cada cas. La migració d'AlpinaShop deixa de ser un pla i comença a ser codi.