Hasta ahora hemos trabajado sobre todo con conceptos y con la consola web. En esta lección cambiamos de marcha: aprenderemos la herramienta con la que se administra Google Cloud de verdad en el día a día, la CLI de gcloud, y el entorno que la hace accesible desde cualquier navegador sin instalar nada, Cloud Shell.

Dominar gcloud no consiste en memorizar comandos, sino en entender su estructura, saber pedirle ayuda y saber extraer exactamente el dato que necesitas. Con eso, cualquier operación de cualquier servicio se vuelve deducible. Veremos qué es Cloud Shell y qué límites tiene, cómo instalar el CLI en local, la anatomía de un comando y el sistema de ayuda, los formatos de salida y los filtros, la autenticación y sus dos modos, las configuraciones nombradas para alternar entre alpinashop-dev y alpinashop-prod, las demás herramientas del SDK, y el scripting básico que encadena comandos.

Y cerraremos el módulo con el primer despliegue real del curso: Dani va a publicar en internet una página de "próximamente" de AlpinaShop, de extremo a extremo, sin salir del navegador.

1. Qué es Cloud Shell
2. Instalación local del Google Cloud CLI
3. Cloud Shell frente a CLI local
4. Anatomía de un comando gcloud y sistema de ayuda
5. Formatos de salida: --format
6. Filtros: --filter
7. Autenticación: gcloud init, auth login y application-default
8. Configuraciones nombradas
9. Otras herramientas del SDK
10. Scripting básico con gcloud
11. Primer despliegue real: la página de "próximamente" de AlpinaShop

Cloud Shell es una máquina virtual Linux gratuita que se abre dentro del navegador desde el icono >_ de la consola. Está pensada para que puedas administrar Google Cloud sin instalar nada y sin configurar credenciales.

Qué trae ya instalado y configurado:

Características y límites que hay que conocer antes de confiar en ella:

La consecuencia práctica del punto de la persistencia es importante: si instalas algo con apt install, desaparecerá en la siguiente sesión. Para que sobreviva, o lo instalas en tu $HOME, o lo automatizas en el fichero ~/.customize_environment, que Cloud Shell ejecuta al arrancar la máquina.

Dos funciones adicionales que usaremos:

• Cloud Shell Editor: se abre con el botón "Abrir editor" y da un IDE en el navegador, con explorador de ficheros, terminal integrada y resaltado de sintaxis. Muy cómodo para escribir scripts o editar un Dockerfile sin salir de la consola.
• Vista previa web: el icono con forma de ojo permite abrir en el navegador un servicio que estés ejecutando en Cloud Shell (por defecto en el puerto 8080) mediante una URL temporal y autenticada. Es lo que permite probar la aplicación Flask de AlpinaShop sin desplegarla.

Cloud Shell es excelente para aprender y para tareas puntuales, pero para trabajar a diario querrás el CLI en tu propia máquina, con tu editor, tus ficheros y tus scripts.

Linux (Debian/Ubuntu), mediante el repositorio oficial:

macOS, con Homebrew:

Windows: descarga el instalador GoogleCloudSDKInstaller.exe desde la documentación oficial y ejecútalo. Al finalizar ofrece lanzar gcloud init. También funciona perfectamente instalando la versión Linux dentro de WSL2, que es la opción preferida por muchos desarrolladores.

Gestión de componentes adicionales:

Un aviso: si instalaste el CLI mediante apt o Homebrew, gcloud components update puede estar deshabilitado, porque el gestor de paquetes se encarga de las actualizaciones. En ese caso, actualiza con apt upgrade o brew upgrade. En Cloud Shell, el CLI se actualiza solo.

La recomendación para este curso: usa Cloud Shell. Elimina toda la fricción de instalación y garantiza que trabajas con la misma versión que se describe aquí. Instala el CLI local cuando empieces a desarrollar de verdad.

Todos los comandos de gcloud siguen la misma estructura, y entenderla es lo que convierte la CLI en algo deducible en lugar de memorizable:

Ejemplos leídos según esta estructura:

Los verbos son consistentes entre servicios, y esa consistencia es lo que permite deducir comandos que nunca has visto:

Si sabes que existe gcloud compute instances list, puedes deducir que existirá gcloud sql instances list y gcloud run services list. Y aciertas.

gcloud search-help es una herramienta infravalorada: busca en toda la ayuda del CLI y devuelve los comandos relevantes ordenados por pertinencia. Cuando no sepas qué comando usar, empieza por ahí.

Algunos comandos solo están disponibles en fases preliminares y requieren un prefijo:

Regla práctica: si un comando "no existe", prueba con beta y con alpha antes de darlo por imposible. Y no uses comandos alpha en producción: su interfaz puede cambiar sin previo aviso.

Por defecto, gcloud devuelve una tabla pensada para humanos. El flag --format permite cambiar completamente esa salida, y es la clave para usar gcloud dentro de scripts.

Ejemplos aplicados:

Funciones útiles dentro de --format, que ahorran mucho postprocesado:

La regla que conviene grabar: table para leer tú, value para que lo lea un script, json para procesarlo con jq.

--filter reduce el conjunto de resultados en el lado del servidor o del cliente según el comando, evitando tener que filtrar con grep, que es frágil.

Operadores disponibles:

Ejemplos aplicados a AlpinaShop:

Cómo descubrir por qué campos se puede filtrar: mira primero la salida en JSON. Los nombres de campo del JSON son exactamente los que acepta --filter.

Este apartado resuelve una de las confusiones más habituales entre quienes empiezan.

Es el asistente de configuración inicial. Hace tres cosas en una: te autentica, te deja elegir proyecto por defecto y te deja elegir región y zona por defecto.

Úsalo la primera vez que configuras el CLI en una máquina, o cuando quieras crear una configuración nueva desde cero.

Son dos credenciales distintas, para dos consumidores distintos:

El escenario clásico que confunde a todo el mundo: Dani ejecuta gcloud storage ls y funciona, pero su script de Python falla con un error de credenciales. La causa es que hizo gcloud auth login pero no gcloud auth application-default login: la biblioteca cliente busca las ADC, no las credenciales del CLI.

Para procesos automatizados (un pipeline de CI/CD, una tarea programada) no se usan credenciales de usuario, sino cuentas de servicio. Y dentro de Google Cloud, lo correcto es no descargar claves: una VM, un servicio de Cloud Run o un pod de GKE obtienen credenciales automáticamente de la cuenta de servicio que tengan asociada.

Las cuentas de servicio, sus roles y las alternativas seguras a las claves descargadas (Workload Identity Federation) se estudian en la lección 03-04.

Una configuración de gcloud es un conjunto de propiedades: cuenta activa, proyecto, región y zona por defecto. Puedes tener varias con nombre y saltar entre ellas con un comando, lo que resuelve elegantemente el problema de alternar entre alpinashop-dev y alpinashop-prod.

Dos técnicas complementarias muy recomendables:

Y un consejo que evita accidentes serios: añade el proyecto activo a tu prompt de bash. Ver en cada línea sobre qué proyecto estás trabajando es la mejor prevención contra ejecutar en producción algo pensado para desarrollo.

El Google Cloud CLI incluye varias herramientas además de gcloud:

Estas herramientas se usarán a fondo en sus módulos correspondientes: Cloud Storage en 02-02, GKE en 02-05 y BigQuery en 04-01. Aquí solo dejamos constancia de que existen y de que se instalan juntas.

La combinación de --format=value(...) con bash convierte gcloud en una herramienta de automatización potente. El patrón fundamental es siempre el mismo: listar con un filtro, extraer un valor limpio, iterar.

Buenas prácticas para scripts de gcloud:

• Empieza siempre con set -e para que el script se detenga en cuanto un comando falle, en lugar de seguir sobre un estado inconsistente.
• Indica el proyecto explícitamente con --project en scripts importantes, en lugar de depender de la configuración activa. Un script que borra recursos y confía en la configuración activa es un accidente esperando a ocurrir.
• Prueba primero sin --quiet, para ver qué te va a preguntar y sobre qué recursos actuaría.
• Muchos comandos aceptan --dry-run o tienen equivalentes de solo lectura: úsalos antes de ejecutar operaciones destructivas.

Llega el momento de poner algo en internet. Dani va a publicar una página estática de "próximamente" mientras el equipo prepara la migración, usando Cloud Storage para alojarla. Es un anticipo deliberado del servicio que se estudia a fondo en la lección 02-02: aquí lo usamos como ejercicio integrador de todo lo aprendido en el módulo, sin entrar en clases de almacenamiento, ciclos de vida ni versionado.

Paso 1. Preparar el entorno. Abre Cloud Shell y confirma dónde estás:

Paso 2. Crear la página. Usa el editor o directamente el terminal:

El bloque cat > fichero <<'HTML' ... HTML es un here-document: escribe en el fichero todo lo que hay entre las dos marcas. Poner la marca entre comillas simples evita que bash intente interpretar $ o comillas dentro del contenido.

Paso 3. Crear el bucket. Los nombres de bucket son únicos en todo Google Cloud, igual que los projectId, así que añadimos un sufijo para evitar colisiones:

Desglose del comando:

• gs:// es el esquema de URI de Cloud Storage.
• --location=europe-west1 fija la región. Recuerda de la lección 01-05: la ubicación de un bucket es inmutable.
• --uniform-bucket-level-access desactiva las listas de control de acceso por objeto y hace que todos los permisos se gestionen solo con IAM. Es la opción recomendada porque simplifica enormemente el razonamiento sobre quién puede ver qué.

Paso 4. Subir los ficheros:

Paso 5. Hacer público el contenido. Este paso concede lectura a cualquiera en internet. Es exactamente lo que queremos para una página pública, y exactamente lo que nunca debes hacer con un bucket que contenga datos internos:

allUsers es un identificador especial de IAM que significa "cualquiera, autenticado o no". El rol roles/storage.objectViewer concede solo lectura de objetos: no permite listar la configuración del bucket ni escribir nada.

Paso 6. Configurar el bucket como sitio web y comprobar el resultado:

Si curl devuelve el HTML que escribiste, acabas de publicar tu primer contenido en Google Cloud: has creado un recurso en la región correcta, has configurado sus permisos y lo has verificado, todo desde el navegador y sin instalar nada.

Paso 7. Limpiar. Fundamental: no dejes recursos encendidos que no vas a usar.

Lo que no hemos hecho aquí, y se verá más adelante: servir la página bajo el dominio alpinashop.example con certificado TLS (requiere un balanceador de carga, lección 03-07), acelerarla con Cloud CDN (03-03), elegir clase de almacenamiento y reglas de ciclo de vida (02-02) y automatizar el despliegue con Cloud Build (06-01).

• Confundir gcloud auth login con gcloud auth application-default login. El primero autentica el CLI; el segundo, tu código. Si tu script de Python falla con error de credenciales y gcloud funciona, es esto.
• Instalar paquetes en Cloud Shell y perderlos. Solo $HOME persiste. Usa ~/.customize_environment para lo que necesites en cada arranque.
• Ejecutar un comando en el proyecto equivocado. Usa configuraciones nombradas, pon el proyecto en el prompt y añade --project explícito en los scripts peligrosos.
• Filtrar con grep en lugar de --filter. grep depende del formato de salida, que puede cambiar; --filter opera sobre los campos reales del objeto.
• Usar --quiet al teclear a mano. Está pensado para scripts desatendidos. Interactivamente, esas confirmaciones son tu última línea de defensa.
• Suponer que un comando no existe. Prueba gcloud search-help, y prueba los prefijos beta y alpha.
• Trabajar con un CLI desactualizado. Muchos errores extraños se resuelven con gcloud components update.
• Consejo: aprende --format=json para explorar. Es la forma de descubrir qué campos tiene un recurso y, por tanto, por qué campos puedes filtrar y qué puedes extraer.
• Consejo: guarda tus comandos en scripts desde el principio. Lo que hoy tecleas a mano, mañana lo repetirás; y en el módulo 6 lo convertirás en un pipeline.
• Consejo: usa el enlace "Línea de comandos equivalente" de la consola. Sigue siendo la forma más rápida de aprender comandos nuevos.

Escribe los comandos gcloud que resuelvan lo siguiente. Ejecútalos en tu proyecto para comprobarlos:

1. Mostrar todos tus proyectos en una tabla con solo el ID y el número de proyecto.
2. Guardar en una variable de bash llamada NUM el número del proyecto alpinashop-dev, sin cabeceras ni texto adicional.
3. Listar las APIs habilitadas cuyo nombre contenga storage o sql, mostrando únicamente el nombre.
4. Listar las zonas de la región europe-west1 mostrando nombre y estado en formato tabla.
5. Averiguar, sin salir del terminal, qué comando de gcloud sirve para gestionar presupuestos de facturación.

Marta necesita trabajar sobre dos proyectos y quiere evitar accidentes.

1. Crea dos configuraciones nombradas, alpinashop-dev y alpinashop-prod, cada una con su proyecto, la región europe-west1 y la zona europe-west1-b.
2. Escribe el comando para listar las instancias de producción sin cambiar la configuración activa (dos formas distintas de conseguirlo).
3. Dani ejecuta correctamente gcloud storage ls pero su script de Python falla con DefaultCredentialsError. Explica la causa y da el comando que lo soluciona.
4. Propón una medida adicional que reduzca el riesgo de ejecutar por error un comando destructivo en producción.

Reproduce el despliegue del apartado 11 con una variante: en lugar de una página fija, la portada debe mostrar la fecha en que se generó y la región donde está alojado el bucket.

1. Genera el index.html incluyendo la fecha actual y el nombre de la región.
2. Crea el bucket con un nombre único, súbelo, hazlo público y configúralo como sitio web.
3. Verifica con curl que el contenido servido incluye la fecha.
4. Escribe un pequeño script que compruebe que el bucket existe y muestre cuántos objetos contiene.
5. Elimina todos los recursos creados.

Solución 1

El punto 5 devolverá, entre otros resultados, gcloud billing budgets, con sus acciones create, list, describe, update y delete. Es la forma correcta de descubrir comandos sin salir del terminal.

Solución 2

La primera usa la configuración completa de producción (cuenta, proyecto, región); la segunda solo sobrescribe el proyecto y conserva el resto de la configuración activa. Para operaciones de solo lectura ambas sirven; si las configuraciones usaran cuentas distintas, la primera sería la correcta.

3. La causa es que gcloud auth login autentica el CLI, pero las bibliotecas cliente de Python buscan las Application Default Credentials, que son un fichero distinto. La solución:

4. Varias medidas válidas, y lo ideal es combinarlas: mostrar el proyecto activo en el prompt de bash (export PS1='[$(gcloud config get-value project)] \w\$ '); usar siempre --project explícito en los scripts que borran o modifican recursos; no conceder a la cuenta de trabajo diario permisos de borrado en producción, aplicando el principio de mínimo privilegio (lección 03-04); y usar navegadores o perfiles distintos para consola de desarrollo y de producción.

Solución 3

Fíjate en una diferencia respecto al ejemplo del apartado 11: aquí la marca del here-document no va entre comillas simples (<<HTML en lugar de <<'HTML'), precisamente porque queremos que bash sustituya $(date ...) y $REGION antes de escribir el fichero.

La comprobación usa describe redirigiendo la salida a /dev/null y evaluando solo su código de salida: si el bucket no existe, el comando falla y entra en la rama else. El patrón gs://$BUCKET/** lista todos los objetos de forma recursiva, y wc -l los cuenta.

Con esta lección cerramos el módulo 1, y lo hacemos con algo funcionando en internet. Hemos aprendido qué es Cloud Shell, qué trae preinstalado y cuáles son sus límites reales —especialmente que solo persisten los 5 GB de tu $HOME—, además de su editor web y la vista previa. Hemos visto cómo instalar el CLI en Linux, macOS y Windows, y cuándo compensa cada opción. Hemos desmontado la anatomía de un comando gcloud en grupo, subgrupo, acción y flags, lo que convierte la CLI en algo deducible, y hemos aprendido a pedirle ayuda con --help y gcloud search-help. Hemos dominado --format (con table para leer, value para scripts y json para explorar) y --filter con todos sus operadores. Hemos aclarado la diferencia entre gcloud auth login y gcloud auth application-default login, y hemos montado configuraciones nombradas para alternar con seguridad entre alpinashop-dev y alpinashop-prod. Hemos conocido gcloud storage, bq y kubectl, que nos acompañarán en módulos posteriores, y hemos escrito nuestros primeros scripts encadenando gcloud con bash. Y, sobre todo, Dani ha publicado la página de "próximamente" de AlpinaShop desde el navegador, ha comprobado que se sirve y ha limpiado los recursos después.

Repasando el módulo entero: entendimos qué es la nube y por qué AlpinaShop la necesita, abrimos la cuenta con presupuestos de seguridad desde el primer día, aprendimos a movernos por la consola, diseñamos la jerarquía de proyectos y la facturación, elegimos europe-west1 como región y comprendimos qué parte de la seguridad es nuestra, y ahora sabemos manejar las herramientas. Tenemos el terreno preparado y sabemos usar la maquinaria.

En el módulo 2, Servicios principales de GCP, empezamos a construir de verdad: crearemos máquinas virtuales con Compute Engine, moveremos los 60 GB de imágenes de producto al bucket alpinashop-catalogo de Cloud Storage, migraremos la base de datos tienda a la instancia Cloud SQL alpinashop-pedidos, conoceremos App Engine y el clúster alpinashop-cluster en Google Kubernetes Engine, exploraremos las bases de datos NoSQL y terminaremos con el criterio para elegir el servicio de cómputo adecuado en cada caso. La migración de AlpinaShop deja de ser un plan y empieza a ser código.