Programming & Development

Automation & Scripting (PowerShell, Bash)

Intermediate 6 modules • 16 hours •49 € VAT included

Curso orientado a automatizar tareas reales de sistemas usando Bash y PowerShell con enfoque operativo: pipeline, parametros, salida, logs, codigos de retorno, robustez e idempotencia.

Automatizar no es "pasar comandos a un fichero". Es convertir una tarea repetitiva, propensa a errores o costosa en una ejecucion controlada, repetible y observable. Bash y PowerShell resuelven problemas parecidos en entornos distintos, pero con modelos muy diferentes: texto en pipeline frente a objetos, ergonomia Unix frente a ecosistema Windows y .NET.

The first module is free. Request information about full-course access.

Please note: the course material (modules, exam, glossary and labs) is written in Spanish. Only the site interface is available in English. A good reading level of Spanish is required.

On sale soon. The first module is free: sign up and start.

hola@itlabcert.com

Request received. We will reply to your email within 48 working hours. No need to send it again.

For myself For my company or team

I have read and accept the privacy policy. We will only use your data to reply to you.

hola@itlabcert.com

Modulo 01. Mentalidad de automatizacion y tipos de tareas

Objetivo del modulo

Aprender a decidir que tareas conviene automatizar, con que alcance y bajo que controles para no convertir un problema manual pequeno en un problema automatico mucho mayor.

Resultados esperados

Identificar tareas repetitivas, manuales o propensas a error.
Diferenciar automatizacion puntual, recurrente e integrada.
Entender idempotencia, seguridad y observabilidad en scripts.
Aplicar criterio antes de escribir codigo.

Desarrollo teorico

Automatizar no es simplemente ahorrar tiempo. Una automatizacion bien elegida reduce errores, acelera operaciones y libera capacidad humana para tareas de mayor valor. Una automatizacion mal elegida replica el error manual a gran velocidad o anade riesgo sobre sistemas sensibles. Por eso el primer paso no es elegir Bash o PowerShell, sino clasificar la tarea.

Clasificacion de tareas candidatas. Las tareas candidatas claras para automatizacion son las que cumplen varias de estas caracteristicas:

Repetitivas: Se ejecutan con frecuencia (diaria, semanal, ante eventos).
Pasos estables: El procedimiento no cambia significativamente entre ejecuciones.
Datos estructurados: La entrada y salida son predecibles y parseables.
Resultado verificable: Se puede confirmar exito o fallo de forma objetiva.
Bajo riesgo de daño irreversible: O se puede mitigar con simulacion y confirmacion.

Menos apropiadas para automatizacion inmediata son las tareas altamente ambiguas, con decisiones humanas complejas que requieren juicio contextual, o con impacto destructivo si falla una suposicion no validada.

Ejemplos concretos por categoria:

BUENAS CANDIDATAS:
- Renombrar cientos de archivos segun patron
- Consultar estado de servicios en N servidores
- Validar configuraciones contra una baseline
- Desplegar un paquete en entornos de test
- Recoger inventario de software instalado
- Limpiar logs antiguos segun politica de retencion

CANDIDATAS CON PRECAUCION:
- Reiniciar servicios en produccion
- Modificar configuraciones de red
- Crear/eliminar cuentas de usuario
- Aplicar parches en servidores criticos

MALAS CANDIDATAS (sin mas contexto):
- Diagnosticar incidentes no tipificados
- Aprobar cambios que requieren juicio de negocio
- Tareas que cambian completamente cada vez

Los tres niveles de automatizacion.

Script ad-hoc: Se escribe para resolver una necesidad puntual. Se ejecuta una vez (o pocas) y puede no mantenerse. Es el primer nivel y el mas fragil. Ejemplo: un script Bash para migrar ficheros de un directorio a otro durante una migracion.
Automatizacion recurrente: Script o tarea programada que se ejecuta periodicamente. Requiere mas robustez: validacion de entradas, manejo de errores, logging, idempotencia. Ejemplo: un cron job que limpia logs mayores de 30 dias.
Automatizacion integrada: Forma parte de un flujo mayor (pipeline CI/CD, orquestador, runbook de incidentes). Requiere contratos claros de entrada/salida, observabilidad, versionado y testing. Ejemplo: un script que forma parte del deploy automatizado en un pipeline.

Idempotencia. Un script idempotente produce el mismo resultado si se ejecuta una vez o multiples veces. Esto es critico para automatizacion recurrente. Si un script crea un directorio sin verificar si existe, falla en la segunda ejecucion. Si un script anade una linea a un fichero sin comprobar si ya esta, duplica contenido.

# NO idempotente: falla si el directorio ya existe
mkdir /opt/app/logs

# Idempotente: crea solo si no existe
mkdir -p /opt/app/logs

# NO idempotente: anade duplicados
Add-Content -Path config.txt -Value "MaxRetries=3"

# Idempotente: solo anade si no existe
$contenido = Get-Content config.txt
if ($contenido -notcontains "MaxRetries=3") {
    Add-Content -Path config.txt -Value "MaxRetries=3"
}

Dry run y simulacion. Antes de ejecutar una accion destructiva o masiva, un script bien disenado ofrece un modo de simulacion que muestra lo que haria sin hacerlo:

#!/usr/bin/env bash
set -euo pipefail

DRY_RUN="${DRY_RUN:-true}"

eliminar_logs_antiguos() {
    local directorio="$1"
    local dias="$2"

    find "$directorio" -name "*.log" -mtime +"$dias" -print |
    while IFS= read -r archivo; do
        if [[ "$DRY_RUN" == "true" ]]; then
            echo "[DRY RUN] Eliminaria: $archivo"
        else
            rm "$archivo"
            echo "[OK] Eliminado: $archivo"
        fi
    done
}

eliminar_logs_antiguos "/var/log/app" 30

Observabilidad. Todo script operativo debe dejar rastro de lo que hizo. Eso significa: logging a fichero o a stdout/stderr con timestamps, codigos de salida correctos (0 = exito, distinto de 0 = fallo), y opcionalmente metricas o notificaciones. Un script que ejecuta acciones silenciosamente es imposible de auditar y de diagnosticar cuando falla.

Control de errores. Los scripts robustos anticipan fallos y los manejan de forma explicita:

# Si falla la conexion, notificar y salir
if ! ping -c1 -W3 "$servidor" >/dev/null 2>&1; then
    echo "ERROR: $servidor no alcanzable" >&2
    exit 1
fi

try {
    $resultado = Invoke-Command -ComputerName $servidor -ScriptBlock { Get-Service }
} catch {
    Write-Error "No se pudo conectar a $servidor: $_"
    exit 1
}

Matriz de decision. Antes de automatizar, responde estas preguntas:

Pregunta	Si la respuesta es NO...
Se repite al menos semanalmente?	Quiza no vale la pena automatizar
Los pasos son estables?	El script se rompera pronto
Se puede verificar el resultado?	No sabras si funciono
El impacto de un fallo es manejable?	Necesitas dry run y confirmacion
Tienes datos de entrada fiables?	El script fallara por datos, no por logica

Contenido ampliado

Concepto	Definicion	Ejemplo
Idempotencia	Mismo resultado si se repite	`mkdir -p`, check before create
Dry run	Simulacion sin ejecucion real	`DRY_RUN=true ./script.sh`
Observabilidad	Registro de lo ejecutado	Logging con timestamps
Codigo de salida	Indicador de exito o fallo	`exit 0` vs `exit 1`
Script ad-hoc	Solucion puntual	Migracion unica de datos
Automatizacion integrada	Parte de un flujo mayor	Step en pipeline CI/CD

Puntos clave

No toda tarea repetitiva merece automatizacion inmediata; hay que evaluar riesgo y estabilidad.
El riesgo operativo importa tanto como el ahorro de tiempo.
Una automatizacion segura necesita validacion, simulacion y control de errores.
Repetibilidad e idempotencia son atributos centrales de un script maduro.
Los tres niveles (ad-hoc, recurrente, integrado) tienen requisitos de robustez diferentes.
La observabilidad no es opcional: un script silencioso es un script peligroso.

Checklist operativa

Definir entrada, salida y criterios de exito antes de escribir codigo.
Evaluar impacto si el script falla o se repite accidentalmente.
Decidir si hace falta modo dry run o simulacion.
Implementar logging con timestamps y codigos de salida correctos.
Validar parametros de entrada al inicio del script.
Documentar prerequisitos y dependencias del script.

Errores frecuentes

Automatizar sin entender del todo el proceso manual subyacente.
No validar parametros de entrada y asumir datos perfectos.
Hacer scripts destructivos sin confirmacion ni simulacion previa.
Confundir velocidad con calidad operativa.
No dejar registro (logging) de lo ejecutado.
Crear scripts ad-hoc y tratarlos como automatizacion permanente sin refactorizar.

Practica sugerida

Selecciona tres tareas reales de tu dia a dia y clasificalas en una tabla con columnas: tarea, frecuencia, estabilidad de pasos, riesgo si falla, nivel de automatizacion recomendado (ad-hoc / recurrente / integrado). Para la tarea mas adecuada, escribe el pseudocodigo de un script que incluya validacion de entrada, dry run, ejecucion, logging y codigo de salida.

Preguntas de autoevaluacion

Que caracteristicas hacen a una tarea buena candidata para automatizacion.
Por que la idempotencia cambia la confianza en un script recurrente.
Cuando conviene implementar dry run y que valor aporta.
Que diferencia hay entre un script ad-hoc y una automatizacion integrada.
Por que un script que ejecuta acciones sin logging es un riesgo operativo.

Cierre

La mejor automatizacion empieza antes del codigo: entendiendo el proceso, evaluando el riesgo y definiendo la evidencia que confirmara que el resultado es correcto. Solo entonces tiene sentido elegir la herramienta y escribir la primera linea.

Usar Bash para encadenar comandos, trabajar con variables, condicionales y bucles, y automatizar tareas comunes en entornos Unix/Linux.

What you will learn

Escribir scripts Bash simples y ejecutables.
Usar variables, argumentos y expansion de shell.
Aplicar `if`, `case`, `for` y `while`.
Entender el pipeline textual y los codigos de salida.

Module contents

Desarrollo teorico
Contenido ampliado
Puntos clave
Checklist operativa
Errores frecuentes
Practica sugerida
Preguntas de autoevaluacion
Cierre