Seguro que te ha pasado. Estás ahí, frente a la consola de Google Cloud, con tu flamante máquina virtual (VM) de Linux recién creada, y de repente te das cuenta de que necesitas subir ese archivo de configuración de tres gigas o, peor aún, ese script de Python que juraste que funcionaba en local pero que ahora tienes que probar en la nube. Te quedas mirando la pantalla negra de la terminal y piensas: «¿Y ahora cómo meto yo esto ahí dentro?». No te preocupes, que a todos nos ha pasado alguna vez, incluso a los que llevamos años peleándonos con servidores en centros de datos que, a veces, parecen más laberintos que otra cosa.
La verdad es que mover archivos a una VM de Linux en Compute Engine no es física cuántica, pero tiene su aquel. Dependiendo de si usas Windows, macOS o si eres de los que no sueltan su distribución de Linux ni para ir a comprar el pan, el camino puede variar un poco. Además, influye mucho si lo que quieres es subir un «hola_mundo.txt» o si estás intentando migrar una base de datos entera de un cliente que tiene prisa. Vamos a ver cómo se hace esto sin perder los nervios y, sobre todo, sin comprometer la seguridad de tu infraestructura, que luego vienen los sustos con las facturas o los accesos no deseados.
Si me preguntas a mí, esta es mi opción favorita cuando no tengo ganas de pelearme con llaves SSH o configuraciones de red extrañas. Imagina que Cloud Storage es como un almacén gigante, un trastero digital donde dejas las cosas y luego vas con tu VM y las recoges. Es limpio, es eficiente y, lo mejor de todo, es muy difícil de romper. En España, muchas empresas tecnológicas que están migrando sus servicios a la nube utilizan este método porque permite separar el almacenamiento de la computación, algo que arquitectónicamente es muy sano.
Para que nos entendamos, el proceso es sencillo: subes el archivo a un «bucket» (un cubo, para los amigos) de Cloud Storage y luego, desde dentro de la VM, lo descargas. Vaya, que es como dejarle las llaves del coche a un colega en un buzón de seguridad.
¿Cómo se hace esto en la práctica?
Primero, necesitas tener instalado el Google Cloud CLI en tu ordenador local. Si no lo tienes, ya estás tardando, porque es la navaja suiza de cualquier desarrollador que se precie. Una vez lo tienes, subir un archivo es tan simple como ejecutar esto en tu terminal:
# Subiendo el archivo al bucket
# Ojo, cambia 'mi-archivo.tar.gz' por el tuyo y 'mi-bucket-famoso' por el nombre de tu bucket
gsutil cp mi-archivo.tar.gz gs://mi-bucket-famoso/Una vez que el archivo está en la nube, te conectas a tu VM por SSH y haces la operación inversa. Lo bueno de las VMs de Google Cloud es que suelen venir con el SDK preinstalado, así que solo tienes que teclear:
# Descargando el archivo dentro de la VM
# Aquí es donde ocurre la magia
gsutil cp gs://mi-bucket-famoso/mi-archivo.tar.gz .La ventaja de este método es que no importa el tamaño del archivo. Si estás en Cartagena y tienes una conexión de fibra decente, subirás los datos a los servidores de Google (que por cierto, tienen región en Madrid, lo cual ayuda mucho con la latencia) y luego la VM, que está conectada a la red interna de Google a velocidades de vértigo, bajará el archivo en un abrir y cerrar de ojos. Es, con diferencia, la forma más robusta de trabajar.
La potencia del comando gcloud compute scp
Ahora bien, si eres de los que prefieren el contacto directo y no quieres pasar por un intermediario como Cloud Storage, el comando gcloud compute scp es tu mejor amigo. Es como el scp de toda la vida de Linux, pero vitaminado y con esteroides, porque se encarga de gestionar las llaves SSH por ti. Esto es una bendición, porque si mal no recuerdo, la mitad de los problemas de conexión a servidores suelen ser por culpa de una llave pública mal puesta o un permiso de archivo 600 que se nos olvidó configurar.
Imagina que tienes un archivo llamado configuracion_servidor.yaml en tu carpeta de descargas y lo quieres enviar al directorio /home/usuario de tu VM. El comando sería algo así:
# Enviando archivos directamente a la VM
# No te olvides de poner el nombre de la instancia y la zona
gcloud compute scp ~/Downloads/configuracion_servidor.yaml nombre-de-tu-vm:~/ --zone=europe-southwest1-aFíjate en el detalle de la zona: europe-southwest1-a. Esa es la región de Madrid. Siempre que puedas, intenta que tus recursos estén cerca de casa, no solo por la velocidad, sino por cumplir con las normativas de datos y, por qué no decirlo, por apoyar la infraestructura local.
Si lo que quieres es traerte un archivo de la VM a tu ordenador (porque has generado un log de errores que parece El Quijote de largo y quieres leerlo cómodamente en tu editor de texto favorito), solo tienes que invertir el orden de los factores:
# Trayendo un archivo de la VM al local
gcloud compute scp nombre-de-tu-vm:~/logs/error.log ./logs-locales/ --zone=europe-southwest1-aUn pequeño truco: si necesitas subir una carpeta entera, añade el flag --recursive. Pero ten cuidado, que si la carpeta tiene miles de archivos pequeños (como una carpeta node_modules, ese agujero negro de la informática), puede tardar una eternidad. En esos casos, mejor comprime todo en un .zip o .tar.gz antes de mandarlo.
SSH desde el navegador: El salvavidas de última hora
A veces estás en un ordenador que no es el tuyo. Quizás estás en la biblioteca de la UPCT en Cartagena, o en un coworking y no tienes instalado el gcloud CLI. No pasa nada. Google tiene una opción que parece magia negra: el SSH desde el navegador.
Entras en la consola de Google Cloud, vas a la sección de Compute Engine, y al lado de tu VM verás un botón que dice «SSH». Al darle, se abre una ventana de terminal en tu navegador. Pero lo que mucha gente no sabe es que esa ventana tiene un menú de configuración (el icono del engranaje arriba a la derecha) que te permite «Subir archivo» o «Descargar archivo».
La verdad es que para archivos pequeños es una maravilla. Es rápido, no requiere configurar nada y funciona en cualquier sitio. Eso sí, no intentes subir un backup de 500MB por aquí porque lo más probable es que la pestaña del navegador se canse de vivir y se cierre antes de terminar. Es una herramienta de emergencia, muy útil, pero con sus limitaciones.
Para los clásicos: WinSCP y FileZilla en Windows
No todo el mundo se siente cómodo con la terminal, y eso está bien. Hay gente que prefiere ver sus archivos, arrastrarlos y soltarlos. Si usas Windows, lo más probable es que conozcas WinSCP o FileZilla. Estos programas usan el protocolo SFTP (Secure File Transfer Protocol), que básicamente es SSH pero con una cara bonita.
Para usar esto con Google Cloud, la cosa se complica un pelín porque tienes que generar tus propias llaves SSH y subirlas a la consola de Google. No es que sea difícil, pero es un poco más tedioso. Tienes que usar una herramienta llamada PuTTYgen para crear un par de llaves (pública y privada). La pública la pegas en la sección de metadatos de tu proyecto en Google Cloud, y la privada la configuras en WinSCP.
Una vez configurado, es como usar el explorador de archivos de Windows. A la izquierda tienes tu ordenador, a la derecha la VM de Linux. Arrastras, sueltas y listo. Es muy visual y para gestionar estructuras de carpetas complejas viene de perlas. Además, te permite editar archivos directamente: haces doble clic, se abre en tu Notepad++ o VS Code, guardas, y el programa lo sube automáticamente. Para retocar configuraciones sobre la marcha es una gozada.
¿Y qué pasa con los permisos? (El dolor de cabeza habitual)
Aquí es donde la mayoría de la gente tropieza. Subes el archivo con éxito, te sientes un hacker de película, intentas ejecutarlo y… Permission denied. ¡Vaya por Dios!
Cuando subes un archivo a través de SCP o Cloud Storage, el archivo suele pertenecer al usuario con el que te has conectado. Si luego ese archivo tiene que ser leído por un servidor web como Nginx o Apache, o ejecutado por un sistema de base de datos, lo más probable es que tengas que cambiar los permisos o el propietario.
Para que nos entendamos, si subes un script y quieres que se pueda ejecutar, tendrás que hacer un:
chmod +x mi-script.shO si necesitas que el servidor web pueda leer una carpeta que acabas de subir:
sudo chown -R www-data:www-data /var/www/mi-sitio-webEs un paso extra que a veces se nos olvida y nos hace perder media hora buscando por qué la web da un error 403. La informática tiene estas cosas, pequeños detalles que te mantienen humilde.
Casos de uso reales: De Cartagena al mundo
Para darle un poco de contexto a todo esto, pensemos en una empresa de Cartagena que se dedica a la monitorización de cultivos mediante sensores IoT. Tienen cientos de sensores enviando datos a una VM en la nube. De vez en cuando, necesitan actualizar el algoritmo de procesamiento de datos que corre en esa VM.
El desarrollador, que probablemente esté tomándose un café cerca de la Plaza del Ayuntamiento, no va a subir el código archivo por archivo. Lo más normal es que use un sistema de control de versiones como Git. Pero, ¿y si tiene que subir un modelo de Inteligencia Artificial ya entrenado que pesa varios gigas? Ahí es donde entra gsutil o gcloud compute scp.
Otro ejemplo: imagina que estás configurando un nodo de una red de blockchain o un servidor de juegos para jugar con los amigos al Minecraft. Necesitas subir los archivos del mundo o la configuración del nodo. En estos casos, la velocidad de subida es clave, y usar las herramientas nativas de Google te asegura que no vas a estar toda la tarde esperando a que la barrita de progreso llegue al 100%.
Seguridad: No dejes la puerta abierta
Al final del día, lo más importante no es cómo subes los archivos, sino que lo hagas de forma segura. Nunca, y repito, NUNCA, abras el puerto 21 para usar FTP tradicional. El FTP es más viejo que el hilo negro y envía tus contraseñas en texto plano por la red. Cualquier persona con un poco de conocimiento y malas intenciones podría interceptar tus credenciales.
Usa siempre protocolos cifrados como SFTP o las herramientas de Google Cloud que ya van sobre canales seguros. Además, si usas llaves SSH, ponles una contraseña (passphrase). Sí, es un poco pesado escribirla cada vez, pero es la diferencia entre que un robo de tu portátil sea un contratiempo o una catástrofe total para tu empresa.
También es buena idea usar el principio de «mínimo privilegio». Si solo necesitas subir archivos a un bucket de Cloud Storage, crea una cuenta de servicio que solo tenga permisos de escritura en ese bucket específico, no le des permisos de administrador de todo el proyecto. Es como darle a alguien la llave del buzón pero no la de la casa.
Resumiendo las opciones
Para que no te líes, aquí tienes una pequeña guía rápida de cuándo usar qué:
- ¿Archivos enormes o muchos archivos? Usa Cloud Storage (
gsutil). Es lo más fiable y rápido. - ¿Un par de archivos rápido desde tu terminal? Usa
gcloud compute scp. Es directo y sin complicaciones de llaves. - ¿Estás en un ordenador ajeno o tienes prisa? Usa el SSH desde el navegador. Es el botón de pánico perfecto.
- ¿Prefieres ver las carpetas y arrastrar archivos? Configura WinSCP o FileZilla con tus llaves SSH.
- ¿Automatización? Si vas a subir archivos de forma recurrente, lo mejor es integrar
gsutilen tus scripts de CI/CD.
La verdad es que, una vez que le coges el truco, transferir archivos a Linux se vuelve algo mecánico. Es como conducir; al principio estás pendiente de los pedales y las marchas, pero luego simplemente vas a donde quieres ir. En el mundo de la nube, estas herramientas son tus pedales.
Y ojo, que aunque aquí hayamos hablado de Google Cloud, muchos de estos conceptos se aplican igual si usas AWS, Azure o un servidor que tengas debajo de la mesa (aunque esto último ya no se lleve tanto). Al final, Linux es Linux, y los protocolos son los mismos.
Espero que esta guía te sirva para que la próxima vez que te encuentres ante esa terminal negra, no sientas ese vacío en el estómago. Ya ves que hay opciones para todos los gustos, desde la terminal más pura hasta la interfaz gráfica más amigable. Al final del día, lo que importa es que ese archivo llegue a su destino y que tu proyecto siga adelante, ya estés en Cartagena, en Madrid o en la Conchinchina. ¡A darle caña a esas VMs!
Deja una respuesta