«¡La corrección ya está hecha!» …¿y el despliegue?
Tres meses después de entrar en la empresa, cuando mi periodo de prueba estaba por terminar, recibí por primera vez una tarea real de trabajo. Era una modificación muy simple, pero aun así me sentía medio nervioso y medio emocionado mientras corregía el código y terminaba las pruebas perfectamente en mi propio ordenador, en localhost.
«¡Jefe, todas las pruebas en local han pasado!»
El jefe asintió y me indicó que lo desplegara. «Buen trabajo. Entonces haz commit en GitLab, un repositorio de código como GitHub, y despliega en el servidor de producción.»
¿Despliegue? Me puse a rebuscar a toda prisa el documento de traspaso que había recibido durante la incorporación. Estaba lleno de términos que no entendía.
Primero subí el código como me dijeron. Ahora solo faltaba el último paso: conectarme al servidor de producción. De hecho, empecé a levantarme de la silla. Como en los dramas, pensaba que tenía que entrar en una sala de servidores helada, un IDC, y teclear directamente en un teclado conectado al servidor.
Mi mentor me vio y se echó a reír. «¿Adónde vas? Quédate sentado y entra por SSH.»
Mi primer encuentro con una pantalla negra
Abrí un programa llamado SSH(Secure Shell), introduje la dirección IP y la contraseña que me había dado mi mentor y pulsé Enter. Si hubiera sido Windows, me habría recibido un escritorio colorido. Pero en mi monitor solo apareció un cursor parpadeando sobre un fondo totalmente negro.
ubuntu@ip-172-31-0-1:~$ _
No había iconos para hacer clic con el ratón, ni tampoco un menú contextual para crear una carpeta nueva. Presioné teclas sin pensar por el pánico, luego escribí ls, y de pronto apareció una lista de archivos en texto plano.
«Ah, así que esto es esa CLI(Command Line Interface) de la que tanto había oído hablar.»
Pero el verdadero miedo llegó cuando intenté ejecutar un archivo. Lanzé el script update que aparecía en el manual, y lo que en Windows habría sido un simple doble clic se convirtió aquí en un mensaje de error en rojo.
Permission denied (permiso denegado)
Era mi propio servidor y aun así no podía ejecutarlo. ¿Por qué Linux era tan poco amable?
El encargado del almacén de un centro logístico digital
Volvamos a nuestra metáfora del ‘centro logístico digital’. Si mi portátil con Windows es una oficina privada y cómoda, entonces un servidor Linux es un gran almacén construido solo para procesar logística. Dentro de ese almacén hay decenas de miles de cajas, es decir, archivos.
Si el encargado tuviera que ir caminando a revisar cada caja una por una, GUI, y abrir cada puerta con una llave, clic a clic, el trabajo sería demasiado lento. Por eso Linux usa un walkie-talkie llamado comandos.
«¡Muestra la lista completa de cajas de la zona 1!» (ls) «¡Mueve la caja 3 a la zona 5!» (mv) «¡Ejecuta esta caja!» (./start.sh)
No es incómodo porque no haya ratón. Los gráficos se quitaron a propósito porque, una vez que te acostumbras, puedes controlar miles de archivos cien veces más rápido que con un ratón.
[Code Verification] La ley absoluta de los permisos
Lo que más tortura a quien empieza con Linux es precisamente el problema de los permisos. En Windows, pulsar una vez ‘Ejecutar como administrador’ resuelve casi todo. Linux, en cambio, comprueba estrictamente para cada archivo quién puede hacer qué.
Para sobrevivir, hay que saber leer ese idioma alienígena que aparece con ls -l en la terminal.
$ ls -l myscript.sh
-rwxr-xr-- 1 owner group 1024 Jan 1 12:00 myscript.sh
Análisis: lo importante es el -rwxr-xr-- del principio. Excluyendo el primer -, que indica archivo, hay que leerlo en bloques de tres.
¿Un script tuyo no se ejecuta? Nueve de cada diez veces, le falta permiso de ejecución, x. En ese momento, los principiantes suelen frustrarse y lanzar el hechizo prohibido chmod 777.
# Lo que nunca debes hacer
$ chmod 777 myscript.sh
777 significa: «Que yo, tú y hasta el perro que pasa por la calle podáis modificar y ejecutar este archivo.» Es lo mismo que dejar la puerta de seguridad totalmente abierta. En trabajo real, eso es absolutamente inaceptable. Hay que acostumbrarse a conceder solo los permisos mínimos necesarios, como chmod +x.
chmod 777 es cómodo, pero también se lo pone fácil a los atacantes.Consejo práctico: superar el miedo a la terminal
Al entrar en la empresa, mi mentor me dijo que usara PuTTY como herramienta de conexión al servidor. Pero buscando por Internet encontré una herramienta mejor llamada MobaXterm. En cuanto te conectas por SSH, muestra a la izquierda una lista de archivos mediante SFTP, casi como el explorador de archivos de mi propio ordenador.
Gracias a eso, aunque no conociera los comandos de terminal, podía abrir archivos con doble clic, editarlos y guardarlos. Pero si uno depende solo de ese tipo de atajos, nunca llega a hacerse amigo de Linux de verdad. En una incidencia urgente, no tienes tiempo para esperar a que se abra una herramienta con GUI.
Para cerrar: quien domina el entorno
Salir del invernadero llamado Windows y adaptarse a la naturaleza salvaje llamada Linux es doloroso. Pero una vez superas ese dolor, consigues un nivel de control imposible de alcanzar con un ratón.
Linux ya no es territorio desconocido. Pero sigue quedando un problema fundamental. ¿Y si en mi portátil, es decir, en mi entorno de desarrollo, tengo Java 17 instalado, pero en el servidor Linux, es decir, en el entorno de despliegue, hay Java 8? ¿O si existe una librería en Linux que no existe en mi Windows?
La excusa de «Pero en mi ordenador funciona» nace de las diferencias de sistema operativo y de versiones de librerías. ¿No habría forma de eliminar por completo esa brecha de entorno? ¿No podría congelar mi entorno del portátil tal cual y llevármelo al servidor?
Existe una tecnología que convirtió esa idea aparentemente absurda en realidad. La próxima vez hablaremos de Docker, la tecnología que fue más allá de la virtualización y desencadenó la revolución de los contenedores.