La consola de Google Cloud es la puerta de entrada visual a la plataforma: un panel web desde el que se puede crear, inspeccionar y borrar cualquier recurso, revisar el gasto, leer registros y abrir un terminal. Conocerla bien acelera enormemente el aprendizaje, porque permite explorar servicios sin memorizar comandos y porque cada pantalla de la consola te muestra el comando gcloud o el REST equivalente, lo que la convierte en la mejor herramienta para aprender la CLI.

En esta lección recorremos la consola de arriba abajo: la barra superior y el selector de proyecto, el menú de navegación y cómo fijar favoritos, el buscador de recursos, el panel de inicio y sus tarjetas, dónde se consultan el estado y las cuotas del proyecto, y la sección de APIs y servicios. Presentaremos también Cloud Shell y su editor integrado (solo de vista: su uso a fondo es la lección 01-06) y compararemos las tres formas de trabajar con Google Cloud para saber cuándo usar cada una. Cerraremos con un recorrido práctico en el que Marta deja el proyecto alpinashop-dev preparado para todo el curso.

1. Anatomía de la consola: barra superior y selector de proyecto
2. El menú de navegación y los servicios fijados
3. El buscador de recursos
4. El panel de inicio y sus tarjetas
5. Estado del proyecto, cuotas y límites
6. APIs y servicios
7. Cloud Shell y el editor, en un vistazo
8. Tres formas de trabajar con GCP
9. Recorrido práctico: Marta prepara alpinashop-dev

La consola vive en console.cloud.google.com. La barra superior está siempre presente y contiene, de izquierda a derecha:

Es, con diferencia, el elemento con el que más cuidado hay que tener: todo lo que ves y todo lo que creas ocurre en el proyecto seleccionado. Un porcentaje considerable de los incidentes de principiante ("borré la base de datos equivocada", "no encuentro la VM que acabo de crear") se reduce a haber tenido el proyecto equivocado seleccionado.

Al pulsarlo se abre un diálogo con dos pestañas, Recientes y Todos, este último mostrando la jerarquía de organización y carpetas. Cada proyecto aparece con su nombre y su ID. Puedes marcar proyectos con una estrella para tenerlos siempre arriba.

Consejos prácticos:

• Fíjate siempre en el projectId, no en el nombre. Los nombres se repiten; los IDs no.
• El projectId activo aparece también en el propio selector, así que basta un vistazo antes de cualquier acción destructiva.
• La URL de la consola incluye el proyecto: console.cloud.google.com/compute/instances?project=alpinashop-dev. Puedes guardar marcadores directos a un servicio de un proyecto concreto, algo muy cómodo cuando alternas entre alpinashop-dev y alpinashop-prod.
• Cuando llegue el momento de tener producción, considera cambiar el tema visual o usar ventanas de navegador distintas para cada entorno. Es un truco simple que previene errores serios.

El menú lateral organiza los servicios por categorías: Compute, Storage, Databases, Networking, Operations, Big Data, AI and Machine Learning, Security, etc. Son las mismas familias que vimos en la lección 01-01.

Con doscientos servicios, navegar el menú entero es inviable a diario. Por eso existe la opción de fijar (pin) servicios: al pasar el ratón sobre un servicio aparece un icono de chincheta que lo lleva a la sección superior del menú, siempre visible y accesible en un clic.

Los servicios fijados:

• Se guardan por usuario, no por proyecto: acompañan a Marta cuando cambia entre alpinashop-dev y alpinashop-prod.
• Se pueden reordenar arrastrando.
• Son la mejor herramienta para reducir la fatiga de navegación en las primeras semanas.

El menú también puede anclarse abierto con el icono de la chincheta en su cabecera, de modo que la consola quede en dos columnas y el menú deje de ser un desplegable. En pantallas anchas es cómodo; en portátiles pequeños roba espacio útil.

La barra de búsqueda de la consola no busca solo en la documentación: busca recursos reales de tu proyecto. Escribiendo alpinashop-catalogo te llevará directamente al bucket; escribiendo Cloud SQL te llevará al servicio.

Qué encuentra:

• Recursos: instancias, buckets, bases de datos, cuentas de servicio, reglas de firewall...
• Servicios y páginas de la consola: útil cuando no recuerdas en qué categoría del menú vive algo.
• Documentación: artículos oficiales.
• Acciones: en muchos casos ofrece directamente "Crear instancia" o similar.

Detalles útiles:

• El atajo de teclado es la barra /, como en GitHub.
• La búsqueda de recursos utiliza Cloud Asset Inventory por debajo. Eso significa dos cosas: puede tardar unos minutos en indexar recursos recién creados, y solo muestra aquello sobre lo que tienes permisos de lectura.
• Es la vía más rápida para encontrar un recurso cuando no recuerdas en qué proyecto lo creaste, siempre que la búsqueda tenga el ámbito adecuado.

El panel de inicio (Dashboard) es la pantalla que ves al entrar en un proyecto. Está compuesto por tarjetas que puedes añadir, quitar y reorganizar con el botón "Personalizar".

Tarjetas más útiles en un proyecto joven como alpinashop-dev:

La tarjeta de Estado de la plataforma merece una mención: enlaza con el panel público de estado de Google Cloud (status.cloud.google.com), donde se publican las incidencias por servicio y región. Es el primer sitio que hay que mirar cuando algo deja de funcionar sin que hayas tocado nada.

Google Cloud impone cuotas a casi todos los recursos: número de CPUs por región, direcciones IP externas, peticiones por minuto a una API, tamaño de determinados objetos. Existen por dos razones: proteger la infraestructura compartida frente a usos abusivos y protegerte a ti de un error que dispare el gasto.

Se consultan en IAM y administración → Cuotas y límites del sistema. Ahí puedes filtrar por servicio, ver el límite, el uso actual y el porcentaje consumido, y solicitar un aumento cuando el límite sea insuficiente.

Cosas que conviene saber antes de encontrártelas:

• Las cuentas nuevas tienen cuotas bajas. Es normal que una cuenta recién creada solo permita un puñado de CPUs por región. Si al llegar al módulo 2 no puedes crear la VM que quieres, probablemente sea esto y no un error tuyo.
• Las cuotas son por proyecto y muchas veces por región. Tener margen en europe-west1 no significa tenerlo en europe-southwest1.
• Las solicitudes de aumento no son instantáneas. Suelen resolverse en horas o algún día. Si planificas un despliegue grande, pídelas con antelación.
• Una cuota agotada se manifiesta como un error de creación, con un mensaje que menciona explícitamente Quota exceeded. Leer el mensaje completo ahorra mucho tiempo.

La sección APIs y servicios es el centro de control de qué puede hacer el proyecto. Se divide en:

• APIs y servicios habilitados: la lista de lo activo, con gráficas de tráfico, errores y latencia por API. Es un buen lugar para detectar que algo está llamando mucho más de lo esperado.
• Biblioteca: el catálogo completo de APIs disponibles, con buscador. Desde aquí se activan.
• Credenciales: claves de API, IDs de cliente OAuth y cuentas de servicio asociadas.
• Pantalla de consentimiento OAuth: necesaria cuando tu aplicación pide datos de usuarios de Google.

Recuerda de la lección anterior que las APIs vienen desactivadas por defecto en cada proyecto nuevo y que activarlas no cuesta dinero, pero usarlas sí. La lista de APIs habilitadas funciona además como documentación implícita: mirándola sabes qué usa realmente el proyecto.

Un detalle práctico muy útil: cuando la consola te impide hacer algo porque falta una API, ofrece un botón de activación en el propio flujo. No hace falta que vayas a buscarla a la biblioteca.

En muchas pantallas de creación de recursos, junto al botón "Crear", hay dos enlaces discretos: "Línea de comandos equivalente" y "REST equivalente". Al pulsarlos, la consola te muestra exactamente el comando gcloud o la petición HTTP que ejecutaría con las opciones que has rellenado en el formulario.

Es, sin exagerar, la mejor herramienta de aprendizaje de la plataforma:

1. Configuras el recurso visualmente, con las descripciones de cada campo a la vista.
2. Pides el comando equivalente.
3. Lo copias, lo entiendes y lo guardas en un script.

Así se pasa de la consola a la automatización sin memorizar nada.

El icono >_ de la barra superior abre Cloud Shell: una máquina virtual Linux efímera, gratuita, que se abre como panel en la parte inferior del navegador. Viene con el Google Cloud CLI, Python, Java, Go, Node.js, Docker, kubectl, git y terraform ya instalados, y ya autenticada con tu usuario, de modo que puedes ejecutar comandos gcloud sin configurar nada.

Junto a ella, el botón Abrir editor lanza Cloud Shell Editor, un editor de código basado en la misma tecnología que Visual Studio Code, con explorador de ficheros, terminal integrada y resaltado de sintaxis. Permite editar ficheros de tu directorio personal de Cloud Shell sin salir del navegador.

Y un tercer elemento: la vista previa web, un icono con forma de ojo que permite abrir en el navegador un servicio que estés ejecutando dentro de Cloud Shell (por ejemplo, la aplicación Flask de AlpinaShop en el puerto 8080) a través de una URL temporal y autenticada.

Con esto es suficiente por ahora: el funcionamiento detallado de Cloud Shell, sus límites, la persistencia de tu $HOME y la anatomía de los comandos gcloud son el tema completo de la lección 01-06, con la que cerraremos el módulo.

Todo lo que se puede hacer en Google Cloud se puede hacer de tres maneras, y las tres acaban llamando a la misma API REST por debajo. Elegir bien ahorra mucho tiempo.

Cuándo usar cada una, en la práctica:

• Consola: aprender un servicio nuevo, explorar, mirar gráficas y facturación, diagnosticar un incidente, hacer algo una sola vez. Y siempre que quieras el comando equivalente para llevártelo a un script.
• gcloud: administración diaria, tareas repetitivas, scripts de despliegue, operaciones sobre muchos recursos a la vez. Es el punto dulce para un administrador.
• Bibliotecas cliente (Python, Java, Go, Node.js...): cuando es tu aplicación la que necesita hablar con Google Cloud. Dani las usará en la app Flask de AlpinaShop para subir imágenes a Cloud Storage o publicar mensajes en el topic pedidos-nuevos. Nunca invoques gcloud desde código de producción: usa la biblioteca cliente.
• API REST directa: cuando no hay biblioteca para tu lenguaje o necesitas un control muy fino.

Y una cuarta vía que conviene mencionar aunque llegue más adelante: infraestructura como código con Terraform (lección 06-07). Cuando la infraestructura deja de ser un experimento y pasa a ser un activo, no se describe con comandos sueltos sino con ficheros versionados en Git. La progresión natural de un equipo es consola → gcloud → Terraform.

El diagrama explica algo importante: no hay funcionalidades exclusivas de la consola. Si algo se puede hacer visualmente, existe una API que lo hace, y por tanto se puede automatizar.

Marta va a dejar el proyecto listo para trabajar durante todo el curso. Sigue estos pasos tú también:

Paso 1. Verificar el proyecto activo. Abre la consola y comprueba en el selector superior que pone alpinashop-dev. Si no, cámbialo. Anota el projectId y el projectNumber que aparecen en la tarjeta "Información del proyecto" del panel de inicio: los necesitaremos en la próxima lección.

Paso 2. Fijar los servicios del curso. Abre el menú de navegación y fija con la chincheta estos servicios, que son los que más usaremos:

Paso 3. Personalizar el panel de inicio. Pulsa "Personalizar" y deja visibles al menos: Información del proyecto, Facturación, Recursos y Estado de la plataforma.

Paso 4. Comprobar las cuotas de partida. Ve a IAM y administración → Cuotas, filtra por el servicio Compute Engine API y localiza la cuota de CPUs en la región europe-west1. Anota el valor: te dirá cuántas máquinas podrás crear en el módulo 2.

Paso 5. Revisar las APIs habilitadas. En APIs y servicios → Habilitados, comprueba que están activas las que activamos en la lección anterior. Fíjate en la gráfica de tráfico: en un proyecto recién creado debería estar prácticamente plana.

Paso 6. Abrir Cloud Shell. Pulsa el icono >_, espera a que se aprovisione la máquina y ejecuta:

El primer comando lee tu configuración local de gcloud y muestra la cuenta autenticada y el proyecto por defecto. El segundo consulta la API de Resource Manager y devuelve los datos del proyecto, formateados como tabla con solo tres columnas gracias a --format. Si ambos devuelven lo esperado, tu entorno está correctamente preparado.

Paso 7. Guardar marcadores. Crea marcadores en el navegador para las páginas que más visitarás, con el proyecto ya incluido en la URL:

• https://console.cloud.google.com/home/dashboard?project=alpinashop-dev
• https://console.cloud.google.com/billing
• https://console.cloud.google.com/apis/dashboard?project=alpinashop-dev

• Trabajar con el proyecto equivocado seleccionado. El error más frecuente y el que más daño hace. Mira el selector antes de cualquier acción destructiva y usa ventanas o perfiles de navegador distintos para desarrollo y producción.
• Confundir "no lo veo" con "no existe". Si un recurso no aparece, casi siempre es porque estás en otro proyecto, en otra región o porque te faltan permisos de lectura. La consola oculta lo que no puedes ver en lugar de avisarte.
• Buscar un recurso recién creado y no encontrarlo. El buscador se apoya en Cloud Asset Inventory y tarda unos minutos en indexar. Ve por el menú del servicio.
• Ignorar el enlace "Línea de comandos equivalente". Es la forma más rápida de aprender gcloud y de convertir un clic en algo repetible.
• No revisar las cuotas hasta que fallan. Un despliegue que falla por Quota exceeded con la solicitud de aumento pendiente puede costarte un día entero.
• Estar autenticado con dos cuentas de Google a la vez. Es fuente constante de confusión: la consola puede abrirse con la cuenta personal. Usa perfiles de navegador separados.
• Consejo: cuando algo falle, mira primero status.cloud.google.com. Perder una hora depurando una incidencia de Google es un clásico evitable.
• Consejo: fija pocos servicios. Fijar veinte es como no fijar ninguno. Empieza con los cinco o seis que uses de verdad.

Para cada tarea, indica si la abordarías desde la consola, con gcloud o con una biblioteca cliente, y justifica la elección en una frase:

1. Dani necesita que la aplicación Flask de AlpinaShop suba la foto de un producto al bucket alpinashop-catalogo cada vez que un empleado da de alta un artículo.
2. Marta quiere ver la evolución del gasto del último trimestre desglosada por servicio.
3. Hay que aplicar la misma etiqueta entorno=desarrollo a 40 recursos existentes.
4. Marta está estudiando Cloud SQL por primera vez y quiere entender qué opciones existen al crear una instancia.
5. Un proceso nocturno debe crear un snapshot de un disco todos los días a las 3:00.

Realiza en tu propia cuenta el recorrido del apartado 9 y responde:

1. ¿Cuál es el projectNumber de tu proyecto y en qué se diferencia del projectId?
2. ¿Cuántas CPUs te permite tu cuota actual en la región europe-west1?
3. Localiza en la consola una pantalla de creación de recurso que ofrezca el enlace "Línea de comandos equivalente" y anota el comando que genera sin llegar a crear el recurso.

Marta recibe un mensaje de Dani: "He creado una máquina virtual esta mañana y ahora no aparece por ningún lado. ¿La has borrado?".

Enumera al menos cuatro causas posibles, ordenadas de más probable a menos, y di cómo comprobarías cada una desde la consola.

Solución 1

1. Biblioteca cliente (la de Cloud Storage para Python). Es la propia aplicación la que necesita hablar con Google Cloud; invocar gcloud desde código de producción sería frágil e inseguro.
2. Consola, sección de Facturación → Informes. Es una tarea de visualización y exploración, exactamente donde la interfaz gráfica gana.
3. gcloud, combinando un listado con --format=value(...) y un bucle en bash. Hacerlo a mano en la consola cuarenta veces es lento y propenso a errores.
4. Consola. Al explorar un servicio nuevo, el formulario con descripciones de cada campo enseña más rápido que la documentación de la CLI. Después, el enlace "Línea de comandos equivalente" te da el comando ya montado.
5. gcloud dentro de una tarea programada (o, mejor aún, una política de snapshots gestionada). Es una operación repetitiva y desatendida: debe estar en un script versionado, no en la memoria de nadie.

Solución 2

1. El projectNumber es un identificador numérico asignado automáticamente por Google, mientras que el projectId es la cadena legible que elegiste al crear el proyecto (alpinashop-dev). Ambos son inmutables y únicos globalmente; algunas APIs y algunos formatos internos usan el número en lugar del ID. Se estudian en detalle en la lección 01-04.
2. Depende de tu cuenta. En cuentas nuevas es habitual encontrar límites bajos (del orden de unas pocas decenas de CPUs, y a veces menos durante el periodo de prueba). Lo importante del ejercicio es saber dónde se consulta: IAM y administración → Cuotas, filtrando por Compute Engine API y por región.
3. Por ejemplo, en Compute Engine → Crear instancia, tras rellenar el formulario, el enlace "Línea de comandos equivalente" genera un gcloud compute instances create ... con todos los flags correspondientes a las opciones marcadas. Puedes copiarlo y cerrar el formulario sin crear nada.

Solución 3

Causas ordenadas por probabilidad:

1. Proyecto equivocado. Dani puede estar mirando alpinashop-prod cuando la creó en alpinashop-dev, o al revés. Comprobación: revisar el selector de proyecto y buscar la VM por su nombre en el buscador global.
2. Región o zona equivocada. La lista de instancias de Compute Engine puede tener un filtro de zona activo. Comprobación: quitar los filtros de la lista de instancias, que por defecto muestra todas las zonas.
3. Cuenta de Google equivocada. Dani puede haber creado la VM con su cuenta personal y estar mirando ahora con la corporativa, o al revés. Comprobación: mirar el avatar de la barra superior.
4. Permisos insuficientes. Si alguien ha ajustado los roles, Dani podría no tener permiso de lectura sobre Compute Engine y la consola simplemente no le mostraría la instancia. Comprobación: revisar sus roles en IAM y administración.
5. La VM sí fue borrada o detenida. Comprobación definitiva: Cloud Logging, filtrando por la actividad de administración del proyecto, muestra quién ejecutó qué operación y cuándo. Es la fuente de verdad, y la veremos en la lección 06-06.

Ya sabemos movernos. En esta lección hemos recorrido la barra superior y hemos identificado el selector de proyecto como el control más crítico de la consola; hemos aprendido a fijar servicios favoritos en el menú de navegación para reducir la fatiga de navegación; hemos visto que el buscador indexa recursos reales a través de Cloud Asset Inventory; hemos personalizado el panel de inicio con las tarjetas de proyecto, facturación, recursos y estado de la plataforma; hemos localizado dónde se consultan las cuotas y hemos entendido que las cuentas nuevas parten con límites bajos; hemos revisado la sección de APIs y servicios y descubierto el enlace "Línea de comandos equivalente", probablemente la mejor herramienta de aprendizaje de toda la plataforma. También hemos visto de pasada Cloud Shell, su editor y la vista previa web, y hemos comparado las tres formas de trabajar con GCP para saber cuándo conviene cada una. Marta ha dejado alpinashop-dev con sus servicios fijados y su panel preparado.

Hasta aquí hemos tratado el proyecto como una caja donde caben cosas. En la próxima lección, Proyectos, jerarquía de recursos y facturación, abriremos esa caja: veremos la jerarquía completa Organización → Carpetas → Proyectos → Recursos aplicada a AlpinaShop con carpetas produccion y desarrollo, la diferencia exacta entre projectId, projectNumber y nombre, por qué el proyecto es la frontera de facturación, cuotas, permisos y red, cómo funcionan las cuentas de facturación y las etiquetas para repartir el gasto, y cómo la jerarquía hereda las políticas. Es la lección que evita que dentro de un año la nube de AlpinaShop sea un montón de proyectos sin orden.