Idempotencia en Azure CLI: tu primer script Bash para crear recursos sin duplicados

Por qué te conviene leer esto hasta el final

Imaginate este escenario: son las 11 p. m., tu pipeline rompió por un test inestable y tenés que relanzarlo. Le das clic a Run confiado… ¡y Azure devuelve “ResourceAlreadyExists”! Ahora hay dos Storage Accounts, el despliegue volvió a fallar y mañana tu jefe te pregunta por qué subió la factura.

La solución es dominar la idempotencia: un script que puedas ejecutar todas las veces que quieras y que siempre deje la nube en el mismo estado. En este post vas a:

1. Instalar y configurar la CLI (si aún no la tenés).

2. Escribir un script de 14 líneas que pregunta antes de crear.

3. Probar dos ejecuciones seguidas para ver la idempotencia en acción.

4. Limpiar los recursos y evitar gastos innecesarios.

5. Entender cómo escalar esto a CI/CD y a Infra-as-Code.

1. Entorno: Git Bash + Azure CLI en Windows

1.1 Git Bash

Si tenés Git for Windows, ya disponés de Git Bash. Buscá en el menú Inicio o hacé clic derecho en cualquier carpeta y elegí Git Bash Here.

1.2 Azure CLI

Abrí PowerShell (o la misma Git Bash) y corré:

Tip: WinGet descarga la versión oficial, se actualiza sola con Windows Update y no rompe nada.

Verificá que quedó bien:

Deberías ver algo como:

Si estás en macOS o WSL, reemplazá WinGet por Homebrew o el script apt que provee Microsoft. Pero como el tema es Git Bash en Windows, seguimos con este entorno.

2. Autenticación (una sola vez)

Abrí Git Bash y escribí:

1. Se abre el navegador y la página de Microsoft.

2. Ingresás tu usuario y doble factor (MFA).

3. Volvés a la consola. Asegurate de que estás en la suscripción correcta:

Listo, tu token dura una hora en memoria; la CLI renovará silenciosamente si hacés más comandos en la sesión.

3. Qué significa idempotencia (un minuto de teoría)

• Definición corta: Si ejecutás la misma operación varias veces seguidas, el resultado final no cambia después de la primera.

• Ejemplo cotidiano: pulsar el interruptor de luz en “ON” cuando la luz ya está encendida.

• Por qué importa en DevOps

  • Retry sin miedo: tu pipeline puede relanzarse y converger al mismo estado.

  • Costos controlados: cero recursos duplicados.

  • Temas legales‐financieros: menos sorpresas en auditorías.

4. Escribí el script paso a paso

4.1 Creá el archivo

Pegá este contenido con comentarios para que entiendas cada línea:

Guardá (Ctrl+O, Enter) y salí (Ctrl+X).

4.2 Permití la ejecución

5. Ejecutalo dos veces y observá

5.1 Primera pasada

No re‐creó nada, misión cumplida.

 Validá si querés

Solo figura un RG y una cuenta de almacenamiento.

6. Limpiá recursos de prueba

Azure borra el grupo en segundo plano; vos seguís con tu vida.

7. Cómo llevarlo al siguiente nivel

1. Variables dinámicas
   Convertí RG y SA en algo como "rg-$GITHUB_RUN_ID" para aislar cada ejecución de CI.

2. Etiquetas y políticas
   Agregá --tags Owner=DevTeam Env=Test en los comandos de creación y aplicá reglas de caducidad automática.

3. Infraestructura como código
   Este patrón es la base mental para entender Bicep o Terraform.
   Conocé el comando, su idempotencia y luego dejá que el motor plan+apply haga magia.

8. Resumen ejecutivo

• Instalaste Azure CLI con WinGet.

• Logueaste tu cuenta y seleccionaste la suscripción.

• Escribiste un script Bash de 14 líneas con az group create, az group wait y un condicional if ! az storage account show.

• Probaste la idempotencia ejecutándolo dos veces: la primera creó, la segunda respetó el estado.

• Eliminaste recursos de demo para evitar costos.

9. Próximos pasos

• Subí este script a tu repo y ponelo como paso en GitHub Actions.

• Probá crear otro recurso (por ejemplo un App Service) con la misma lógica de “exists ?” antes de “create”.

• Contame en los comentarios que dudas tienes.