fundamentos · temario
1.4tema 4 de 4

Entorno Linux

Shell, permisos, procesos, SSH, variables de entorno y Docker básico.

Linux es el sistema operativo de los servidores donde corren los modelos de IA, los clusters de GPU y los contenedores de producción. No importa que desarrolles en macOS o Windows: el deploy siempre termina en Linux. Dominar la shell no es opcional; es el lenguaje de comunicación con la infraestructura.

La shell (bash o zsh) es un REPL que interpreta comandos y scripts. Los comandos se pueden encadenar con pipes (|): la salida de un comando se convierte en la entrada del siguiente. Esto permite construir pipelines de procesamiento complejos con herramientas pequeñas y simples. La filosofía Unix: cada herramienta hace una cosa y la hace bien.

El sistema de permisos de Linux se basa en tres niveles (owner, group, others) y tres bits (read, write, execute). En formato octal, 755 significa rwxr-xr-x: el propietario puede leer/escribir/ejecutar, el grupo y otros solo pueden leer/ejecutar. Los scripts de entrenamiento deben ser ejecutables (chmod +x) y los archivos de configuración con credenciales deben ser privados (chmod 600).

SSH (Secure Shell) permite conectarse a servidores remotos de forma segura. La autenticación por clave pública/privada es más segura que contraseñas: generas un par de claves con ssh-keygen, copias la clave pública al servidor con ssh-copy-id, y nunca necesitas escribir una contraseña. En CI/CD, las claves SSH se guardan como secrets.

Las variables de entorno son el mecanismo estándar para configurar aplicaciones sin hardcodear valores en el código. Una API key nunca va en el código fuente; va en una variable de entorno cargada desde un archivo .env (excluido de git) o desde el sistema de secrets del servidor. En Python se accede con os.environ.get('KEY') o la librería python-dotenv.

Docker permite empaquetar una aplicación con todas sus dependencias en una imagen reproducible. La imagen describe el entorno exacto (OS, librerías, configuración) y el contenedor es una instancia en ejecución de esa imagen. En IA, esto garantiza que el entorno de entrenamiento y el de producción son idénticos, eliminando el clásico 'en mi máquina funciona'.

structure.txt
# Navegación y archivos
pwd                          # directorio actual
ls -la                       # listar con permisos y ocultos
cd /path/to/dir
mkdir -p src/data/raw        # crear directorios anidados
cp -r source/ dest/          # copiar directorio recursivo
rm -rf build/                # borrar directorio (cuidado)

# Permisos
chmod 755 train.sh           # rwxr-xr-x
chmod 600 .env               # rw------- (solo propietario)
chown user:group file.py

# Pipes y redirección
cat data.csv | grep 'error' | wc -l
python train.py > train.log 2>&1
tail -f train.log            # seguir log en tiempo real

# Procesos
ps aux | grep python
kill -9 <pid>
nohup python train.py &      # ejecutar en background
jobs                         # listar jobs actuales

# SSH
ssh-keygen -t ed25519 -C 'user@email.com'
ssh-copy-id user@server.com
ssh user@server.com
scp model.pkl user@server:/data/models/

# Variables de entorno
export API_KEY='abc123'      # temporal, solo esta sesión
echo $API_KEY
source .env                  # cargar desde archivo

# Docker básico
docker build -t my-model:latest .
docker run --gpus all -v $(pwd)/data:/data my-model:latest
docker ps                    # contenedores en ejecución
docker logs <container-id>
docker exec -it <id> bash    # shell dentro del contenedor

Debugging lab

Detecta y corrige el error en el código.

0/5 tests passing0%
  1. 1.4.5.1

    chmod 777 .env

  2. 1.4.5.2

    docker run my-model -v /data:/data

  3. 1.4.5.3

    ssh-keygen -t rsa ssh user@server # password prompt aparece

  4. 1.4.5.4

    export DATABASE_URL=postgres://user:pass@host/db echo DATABASE_URL

  5. 1.4.5.5

    python train.py > train.log