{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images","title":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","description":"Guía práctica de infraestructura inmutable, armando golden images con Packer, automatizando pipelines de AMI, implementando deployments blue-green, eliminando configuration drift, y la historia honesta de migrar un sistema de producción desde servers mutables.","language":"es","datePublished":"2025-12-21","dateModified":null,"contentFormat":"text/markdown","content":"DevOps\n\n# Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables\n\n2025-12-214 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/immutable-infrastructure-packer-golden-images>)\n\n## El Principio Central\n\nInfraestructura inmutable significa que los servers nunca se modifican después del deployment. El workflow es:\n\n```\nCambio de Código → Construir Nueva Imagen → Deployar Nuevas Instancias → Destruir Instancias Viejas\n```\n\nNo:\n\n```\nCambio de Código → SSH al server → apt-get install → rezar\n```\n\n## Construcción de Golden Images con [Packer](<https://www.packer.io/>)\n\n```hcl\n# packer/app-server.pkr.hcl\nvariable \"app_version\" { type = string }\nvariable \"git_sha\" { type = string }\n\nsource \"amazon-ebs\" \"app_server\" {\n ami_name = \"app-server-${var.app_version}-${formatdate(\"YYYYMMDD-hhmm\", timestamp())}\"\n instance_type = \"t3.medium\"\n region = \"us-east-1\"\n\n source_ami_filter {\n filters = {\n name = \"ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-arm64-server-*\"\n root-device-type = \"ebs\"\n virtualization-type = \"hvm\"\n }\n owners = [\"099720109477\"]\n most_recent = true\n }\n\n ssh_username = \"ubuntu\"\n\n tags = {\n Name = \"app-server-${var.app_version}\"\n GitSHA = var.git_sha\n BuildTime = timestamp()\n }\n}\n\nbuild {\n sources = [\"source.amazon-ebs.app_server\"]\n\n provisioner \"shell\" {\n inline = [\n \"sudo apt-get update -y\",\n \"sudo apt-get upgrade -y\",\n \"sudo apt-get install -y curl unzip jq\",\n \"curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -\",\n \"sudo apt-get install -y nodejs\",\n ]\n }\n\n provisioner \"file\" {\n source = \"../dist/\"\n destination = \"/tmp/app/\"\n }\n\n provisioner \"shell\" {\n inline = [\n \"sudo mkdir -p /opt/app\",\n \"sudo cp -r /tmp/app/* /opt/app/\",\n \"cd /opt/app && sudo npm ci --production\",\n \"sudo systemctl daemon-reload\",\n \"sudo systemctl enable app.service\",\n ]\n }\n}\n```\n\n## El Pipeline de AMI\n\n```yaml\n# .github/workflows/ami-pipeline.yml\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - run: npm ci && npm run build\n - run: npm test\n - name: Build AMI\n id: build\n run: |\n AMI_ID=$(packer build -machine-readable \\\n -var \"app_version=${{ github.ref_name }}\" \\\n -var \"git_sha=${{ github.sha }}\" \\\n packer/app-server.pkr.hcl | \\\n grep 'artifact,0,id' | cut -d: -f2)\n echo \"ami_id=$AMI_ID\" >> $GITHUB_OUTPUT\n - name: Validate AMI\n run: |\n INSTANCE_ID=$(aws ec2 run-instances \\\n --image-id ${{ steps.build.outputs.ami_id }} \\\n --instance-type t3.small \\\n --query 'Instances[0].InstanceId' --output text)\n aws ec2 wait instance-status-ok --instance-ids $INSTANCE_ID\n IP=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \\\n --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)\n curl -f http://$IP:3000/health || exit 1\n aws ec2 terminate-instances --instance-ids $INSTANCE_ID\n```\n\n## Deployments Blue-Green\n\n```bash\n#!/bin/bash\nNEW_AMI=$1\nCURRENT_ENV=$(get_active_environment)\nTARGET_ENV=$([[ \"$CURRENT_ENV\" == \"blue\" ]] && echo \"green\" || echo \"blue\")\n\n# 1. Lanzar nuevas instancias en el environment target\nupdate_asg_ami \"$TARGET_ENV\" \"$NEW_AMI\"\nwait_for_healthy \"$TARGET_ENV\" 120\n\n# 2. Canary: mandar 10% del tráfico\nset_traffic_weights \"$CURRENT_ENV\" 90 \"$TARGET_ENV\" 10\nsleep 300\n\n# 3. Verificar error rates\nERROR_RATE=$(get_error_rate \"$TARGET_ENV\" \"5m\")\nif (( $(echo \"$ERROR_RATE > 0.01\" | bc -l) )); then\n echo \"Error rate muy alto ($ERROR_RATE), haciendo rollback\"\n set_traffic_weights \"$CURRENT_ENV\" 100 \"$TARGET_ENV\" 0\n exit 1\nfi\n\n# 4. Shift a 50/50\nset_traffic_weights \"$CURRENT_ENV\" 50 \"$TARGET_ENV\" 50\nsleep 300\n\n# 5. Cutover completo\nset_traffic_weights \"$CURRENT_ENV\" 0 \"$TARGET_ENV\" 100\n```\n\n## La Historia de la Migración\n\nMigrar de mutable a inmutable nos tomó tres meses. Las partes más difíciles:\n\n**1. Descubrir todos los cambios manuales.** Corrimos ` debsums ` y ` find / -newer /var/log/installer ` en cada server de producción. Encontramos 23 paquetes instalados manualmente, 8 archivos de config modificados, 3 cron jobs agregados a mano, y un script Python que alguien había escrito directamente en un server de producción que era crítico para el pipeline de facturación.\n\n**2. Configuración de la aplicación.** La app leía config de archivos locales editados a mano. Movimos todo a variables de ambiente inyectadas vía user data del EC2 y [AWS](<https://aws.com/>) Systems Manager Parameter Store.\n\n**3. Manejo de logs.** Servers que se destruyen pierden sus logs. Configuramos el agente de CloudWatch Logs en la golden image para shippear logs antes de que el server muera.\n\n**4. Hábitos del equipo.** El cambio más difícil fue cultural. Los ingenieros tuvieron que dejar de pensar \"voy a hacer SSH y arreglarlo\" y empezar a pensar \"voy a arreglar el template y reconstruir.\" Literalmente deshabilitamos el acceso SSH a instancias de producción para forzar el cambio.\n\n## Para Cerrar\n\nLa infraestructura inmutable no es sobre herramientas, Packer es solo el mecanismo. Es sobre una disciplina: los servers son ganado, no mascotas. Nacen de una imagen, sirven requests, y son reemplazados. Sin parches, sin hotfixes, sin \"voy a cambiar esta cosita nomás.\"\n\nLa migración fue dolorosa. Tres meses de arqueología en servers que venían acumulando cambios por más de un año. Pero el resultado vale la pena: cada deployment es un estado conocido-bueno, cada rollback es instantáneo (solo apuntar a la AMI anterior), y el configuration drift es imposible por diseño.\n\nLa mejor infraestructura es la que no te sorprende.\n\n## Preguntas frecuentes\n\n### ¿Qué es infraestructura inmutable y cómo difiere del manejo tradicional de servers?\n\nEn infraestructura inmutable, los servers nunca se modifican después del deployment. En vez de hacer SSH para parchear, actualizar o configurar un server corriendo, construís una nueva imagen con los cambios, deployás instancias frescas desde esa imagen, y destruís las viejas. Esto elimina el configuration drift, el estado donde servers que deberían ser idénticos divergieron por cambios ad-hoc.\n\n### ¿Es práctica la infraestructura inmutable para bases de datos y servicios stateful?\n\nPara la capa de compute, absolutamente. Para servicios stateful como bases de datos, el enfoque se modifica, se utiliza imágenes inmutables para el engine de la base de datos y la configuración, pero el volumen de datos es persistente y se monta por separado. RDS y servicios de bases de datos gestionados esencialmente ya hacen esto.\n\n### ¿Cómo manejás parches de emergencia con infraestructura inmutable?\n\nDe la misma manera que deployments regulares, solo más rápido. Tu pipeline de AMI debería ser suficientemente rápido (bajo 10 minutos) para que construir una nueva imagen para un parche de emergencia sea viable.\n\n## Tips\n\n1. **LuchoTip:** Nunca hagas SSH a una instancia de producción para arreglar algo. Si se necesita arreglarlo, arreglá el template de Packer y reconstruí la imagen. El momento en que parcheás un server corriendo, creaste un copo de nieve que causará problemas en el próximo deployment.\n2. **LuchoTip:** Construir tus AMIs en un pipeline de CI, no en la laptop de alguien. Taggeá cada AMI con el SHA del commit de git que la produjo, ` git_sha = abc123 `. Cuando algo se rompe, es posible rastrear cualquier instancia corriendo hasta el código exacto que la construyó.\n3. **LuchoTip:** Mantener tu build de golden image bajo 8 minutos. Cualquier cosa más larga y tu equipo va a empezar a buscar atajos. Yo pre-bakeo una imagen base semanalmente (parches de OS, runtime) y superpongo la aplicación encima, el build específico de app tarda 90 segundos.\n4. **LuchoTip:** Los deployments blue-green necesitan tiempo de bake. No hagas cutover inmediatamente, ejecutar ambos environments por al menos 15 minutos monitoreando error rates. Una vez hice rollout de un memory leak que no apareció hasta 12 minutos después del deployment.\n\n- infraestructura-inmutable\n- packer\n- golden-images\n- ami\n- blue-green-deployments\n- configuration-drift\n- devops\n- infrastructure-as-code\n- deployment\n- automatizacion\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#title"},{"level":2,"text":"El Principio Central","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#el-principio-central"},{"level":2,"text":"Construcción de Golden Images con Packer","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#construccin-de-golden-images-con-packer"},{"level":2,"text":"El Pipeline de AMI","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#el-pipeline-de-ami"},{"level":2,"text":"Deployments Blue-Green","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#deployments-blue-green"},{"level":2,"text":"La Historia de la Migración","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#la-historia-de-la-migracin"},{"level":2,"text":"Para Cerrar","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#para-cerrar"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#questions"},{"level":3,"text":"¿Qué es infraestructura inmutable y cómo difiere del manejo tradicional de servers?","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-1"},{"level":3,"text":"¿Es práctica la infraestructura inmutable para bases de datos y servicios stateful?","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-2"},{"level":3,"text":"¿Cómo manejás parches de emergencia con infraestructura inmutable?","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#article-tips"}],"sections":[{"heading":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","level":1,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images","content":"DevOps"},{"heading":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","level":1,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#title","content":"2025-12-214 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/immutable-infrastructure-packer-golden-images>)"},{"heading":"El Principio Central","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#el-principio-central","content":"Infraestructura inmutable significa que los servers nunca se modifican después del deployment. El workflow es:\n\n```\nCambio de Código → Construir Nueva Imagen → Deployar Nuevas Instancias → Destruir Instancias Viejas\n```\n\nNo:\n\n```\nCambio de Código → SSH al server → apt-get install → rezar\n```"},{"heading":"Construcción de Golden Images con Packer","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#construccin-de-golden-images-con-packer","content":"```hcl\n# packer/app-server.pkr.hcl\nvariable \"app_version\" { type = string }\nvariable \"git_sha\" { type = string }\n\nsource \"amazon-ebs\" \"app_server\" {\n ami_name = \"app-server-${var.app_version}-${formatdate(\"YYYYMMDD-hhmm\", timestamp())}\"\n instance_type = \"t3.medium\"\n region = \"us-east-1\"\n\n source_ami_filter {\n filters = {\n name = \"ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-arm64-server-*\"\n root-device-type = \"ebs\"\n virtualization-type = \"hvm\"\n }\n owners = [\"099720109477\"]\n most_recent = true\n }\n\n ssh_username = \"ubuntu\"\n\n tags = {\n Name = \"app-server-${var.app_version}\"\n GitSHA = var.git_sha\n BuildTime = timestamp()\n }\n}\n\nbuild {\n sources = [\"source.amazon-ebs.app_server\"]\n\n provisioner \"shell\" {\n inline = [\n \"sudo apt-get update -y\",\n \"sudo apt-get upgrade -y\",\n \"sudo apt-get install -y curl unzip jq\",\n \"curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -\",\n \"sudo apt-get install -y nodejs\",\n ]\n }\n\n provisioner \"file\" {\n source = \"../dist/\"\n destination = \"/tmp/app/\"\n }\n\n provisioner \"shell\" {\n inline = [\n \"sudo mkdir -p /opt/app\",\n \"sudo cp -r /tmp/app/* /opt/app/\",\n \"cd /opt/app && sudo npm ci --production\",\n \"sudo systemctl daemon-reload\",\n \"sudo systemctl enable app.service\",\n ]\n }\n}\n```"},{"heading":"El Pipeline de AMI","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#el-pipeline-de-ami","content":"```yaml\n# .github/workflows/ami-pipeline.yml\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - run: npm ci && npm run build\n - run: npm test\n - name: Build AMI\n id: build\n run: |\n AMI_ID=$(packer build -machine-readable \\\n -var \"app_version=${{ github.ref_name }}\" \\\n -var \"git_sha=${{ github.sha }}\" \\\n packer/app-server.pkr.hcl | \\\n grep 'artifact,0,id' | cut -d: -f2)\n echo \"ami_id=$AMI_ID\" >> $GITHUB_OUTPUT\n - name: Validate AMI\n run: |\n INSTANCE_ID=$(aws ec2 run-instances \\\n --image-id ${{ steps.build.outputs.ami_id }} \\\n --instance-type t3.small \\\n --query 'Instances[0].InstanceId' --output text)\n aws ec2 wait instance-status-ok --instance-ids $INSTANCE_ID\n IP=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \\\n --query 'Reservations[0].Instances[0].PublicIpAddress' --output text)\n curl -f http://$IP:3000/health || exit 1\n aws ec2 terminate-instances --instance-ids $INSTANCE_ID\n```"},{"heading":"Deployments Blue-Green","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#deployments-blue-green","content":"```bash\n#!/bin/bash\nNEW_AMI=$1\nCURRENT_ENV=$(get_active_environment)\nTARGET_ENV=$([[ \"$CURRENT_ENV\" == \"blue\" ]] && echo \"green\" || echo \"blue\")\n\n# 1. Lanzar nuevas instancias en el environment target\nupdate_asg_ami \"$TARGET_ENV\" \"$NEW_AMI\"\nwait_for_healthy \"$TARGET_ENV\" 120\n\n# 2. Canary: mandar 10% del tráfico\nset_traffic_weights \"$CURRENT_ENV\" 90 \"$TARGET_ENV\" 10\nsleep 300\n\n# 3. Verificar error rates\nERROR_RATE=$(get_error_rate \"$TARGET_ENV\" \"5m\")\nif (( $(echo \"$ERROR_RATE > 0.01\" | bc -l) )); then\n echo \"Error rate muy alto ($ERROR_RATE), haciendo rollback\"\n set_traffic_weights \"$CURRENT_ENV\" 100 \"$TARGET_ENV\" 0\n exit 1\nfi\n\n# 4. Shift a 50/50\nset_traffic_weights \"$CURRENT_ENV\" 50 \"$TARGET_ENV\" 50\nsleep 300\n\n# 5. Cutover completo\nset_traffic_weights \"$CURRENT_ENV\" 0 \"$TARGET_ENV\" 100\n```"},{"heading":"La Historia de la Migración","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#la-historia-de-la-migracin","content":"Migrar de mutable a inmutable nos tomó tres meses. Las partes más difíciles:\n\n**1. Descubrir todos los cambios manuales.** Corrimos ` debsums ` y ` find / -newer /var/log/installer ` en cada server de producción. Encontramos 23 paquetes instalados manualmente, 8 archivos de config modificados, 3 cron jobs agregados a mano, y un script Python que alguien había escrito directamente en un server de producción que era crítico para el pipeline de facturación.\n\n**2. Configuración de la aplicación.** La app leía config de archivos locales editados a mano. Movimos todo a variables de ambiente inyectadas vía user data del EC2 y [AWS](<https://aws.com/>) Systems Manager Parameter Store.\n\n**3. Manejo de logs.** Servers que se destruyen pierden sus logs. Configuramos el agente de CloudWatch Logs en la golden image para shippear logs antes de que el server muera.\n\n**4. Hábitos del equipo.** El cambio más difícil fue cultural. Los ingenieros tuvieron que dejar de pensar \"voy a hacer SSH y arreglarlo\" y empezar a pensar \"voy a arreglar el template y reconstruir.\" Literalmente deshabilitamos el acceso SSH a instancias de producción para forzar el cambio."},{"heading":"Para Cerrar","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#para-cerrar","content":"La infraestructura inmutable no es sobre herramientas, Packer es solo el mecanismo. Es sobre una disciplina: los servers son ganado, no mascotas. Nacen de una imagen, sirven requests, y son reemplazados. Sin parches, sin hotfixes, sin \"voy a cambiar esta cosita nomás.\"\n\nLa migración fue dolorosa. Tres meses de arqueología en servers que venían acumulando cambios por más de un año. Pero el resultado vale la pena: cada deployment es un estado conocido-bueno, cada rollback es instantáneo (solo apuntar a la AMI anterior), y el configuration drift es imposible por diseño.\n\nLa mejor infraestructura es la que no te sorprende."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#questions","content":""},{"heading":"¿Qué es infraestructura inmutable y cómo difiere del manejo tradicional de servers?","level":3,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-1","content":"En infraestructura inmutable, los servers nunca se modifican después del deployment. En vez de hacer SSH para parchear, actualizar o configurar un server corriendo, construís una nueva imagen con los cambios, deployás instancias frescas desde esa imagen, y destruís las viejas. Esto elimina el configuration drift, el estado donde servers que deberían ser idénticos divergieron por cambios ad-hoc."},{"heading":"¿Es práctica la infraestructura inmutable para bases de datos y servicios stateful?","level":3,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-2","content":"Para la capa de compute, absolutamente. Para servicios stateful como bases de datos, el enfoque se modifica, se utiliza imágenes inmutables para el engine de la base de datos y la configuración, pero el volumen de datos es persistente y se monta por separado. RDS y servicios de bases de datos gestionados esencialmente ya hacen esto."},{"heading":"¿Cómo manejás parches de emergencia con infraestructura inmutable?","level":3,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#question-3","content":"De la misma manera que deployments regulares, solo más rápido. Tu pipeline de AMI debería ser suficientemente rápido (bajo 10 minutos) para que construir una nueva imagen para un parche de emergencia sea viable."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#article-tips","content":"1. **LuchoTip:** Nunca hagas SSH a una instancia de producción para arreglar algo. Si se necesita arreglarlo, arreglá el template de Packer y reconstruí la imagen. El momento en que parcheás un server corriendo, creaste un copo de nieve que causará problemas en el próximo deployment.\n2. **LuchoTip:** Construir tus AMIs en un pipeline de CI, no en la laptop de alguien. Taggeá cada AMI con el SHA del commit de git que la produjo, ` git_sha = abc123 `. Cuando algo se rompe, es posible rastrear cualquier instancia corriendo hasta el código exacto que la construyó.\n3. **LuchoTip:** Mantener tu build de golden image bajo 8 minutos. Cualquier cosa más larga y tu equipo va a empezar a buscar atajos. Yo pre-bakeo una imagen base semanalmente (parches de OS, runtime) y superpongo la aplicación encima, el build específico de app tarda 90 segundos.\n4. **LuchoTip:** Los deployments blue-green necesitan tiempo de bake. No hagas cutover inmediatamente, ejecutar ambos environments por al menos 15 minutos monitoreando error rates. Una vez hice rollout de un memory leak que no apareció hasta 12 minutos después del deployment.\n\n- infraestructura-inmutable\n- packer\n- golden-images\n- ami\n- blue-green-deployments\n- configuration-drift\n- devops\n- infrastructure-as-code\n- deployment\n- automatizacion\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/immutable-infrastructure-packer-golden-images"},{"text":"Packer","url":"https://www.packer.io/"},{"text":"AWS","url":"https://aws.com/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images"},"headline":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","description":"Guía práctica de infraestructura inmutable, armando golden images con Packer, automatizando pipelines de AMI, implementando deployments blue-green, eliminando configuration drift, y la historia honesta de migrar un sistema de producción desde servers mutables.","datePublished":"2025-12-21","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://statics.lucioduran.com/images/lucioduran-social-card.jpg","url":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"DevOps","keywords":"infraestructura-inmutable, packer, golden-images, ami, blue-green-deployments, configuration-drift, devops, infrastructure-as-code, deployment, automatizacion","wordCount":702,"timeRequired":"PT4M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/immutable-infrastructure-packer-golden-images"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Infraestructura Inmutable: Golden Images con Packer, Pipelines de AMI, Deployments Blue-Green y la Migración Real desde Servers Mutables","item":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Qué es infraestructura inmutable y cómo difiere del manejo tradicional de servers?","acceptedAnswer":{"@type":"Answer","text":"En infraestructura inmutable, los servers nunca se modifican después del deployment. En vez de hacer SSH para parchear, actualizar o configurar un server corriendo, construís una nueva imagen con los cambios, deployás instancias frescas desde esa imagen, y destruís las viejas. Esto elimina el configuration drift, el estado donde servers que deberían ser idénticos divergieron por cambios ad-hoc."}},{"@type":"Question","name":"¿Es práctica la infraestructura inmutable para bases de datos y servicios stateful?","acceptedAnswer":{"@type":"Answer","text":"Para la capa de compute, absolutamente. Para servicios stateful como bases de datos, el enfoque se modifica, se utiliza imágenes inmutables para el engine de la base de datos y la configuración, pero el volumen de datos es persistente y se monta por separado. RDS y servicios de bases de datos gestionados esencialmente ya hacen esto."}},{"@type":"Question","name":"¿Cómo manejás parches de emergencia con infraestructura inmutable?","acceptedAnswer":{"@type":"Answer","text":"De la misma manera que deployments regulares, solo más rápido. Tu pipeline de AMI debería ser suficientemente rápido (bajo 10 minutos) para que construir una nueva imagen para un parche de emergencia sea viable."}}]}]}],"contentHash":"1b9988d6075a2e4cb53629e098bb3bb529bdc6208967548c30051c8d08bea769","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/immutable-infrastructure-packer-golden-images","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":55326,"contentBytes":8241}}