[{"data":1,"prerenderedAt":152},["ShallowReactive",2],{"seo-verification":3,"blog-opentofu-gestione-su-flota-de-vps-con-infrastructure-as-code-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-opentofu-gestione-su-flota-de-vps-con-infrastructure-as-code-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":98,"ctaBody":99,"ctaButton":100,"ctaUrl":101,"relatedPosts":102},297,"opentofu-gestione-su-flota-de-vps-con-infrastructure-as-code",{"fr":12,"en":13,"ar":14,"es":10},"opentofu-terraform-vps-automatiser-infrastructure","opentofu-manage-your-vps-fleet-with-infrastructure-as-code","opentofu-إدارة-أسطول-vps-الخاص-بك-بالبنية-التحتية-كبيانات","OpenTofu: gestione su flota de VPS con Infrastructure as Code","OpenTofu, el fork CNCF de Terraform, permite describir su flota de VPS en HCL y aprovisionarla con un solo comando. Guía práctica para agencias y desarrolladores.",10,0,false,"2026-08-23T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},2,"Automatización","automatisation","bg-brand-action\u002F10 text-brand-action",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fopentofu-terraform-vps-automatiser-infrastructure-poster.svg","Usted gestiona diez VPS, luego veinte, y cada nuevo servidor exige la misma lista de comprobación manual: pedido, red, Docker, reverse proxy, certificado. Un paso olvidado en el orden y la entrega se cae. OpenTofu, el fork open source de Terraform alojado bajo la CNCF, invierte esta lógica: usted describe el estado objetivo de su infraestructura en HCL, ejecuta `tofu apply` y la herramienta calcula el delta entre lo que existe y lo que debe existir. Esta guía cubre el aprovisionamiento de VPS —la creación, la actualización y la destrucción de servidores— como complemento de la configuración de sistema que Ansible ya gestiona.",[34,38,49,52,77,81,84,87,95],{"type":35,"title":36,"body":37},"h2","Por qué OpenTofu en lugar de seguir con SSH manual","Hasta cinco o seis clientes, la gestión manual aguanta: usted recuerda qué se ejecuta dónde y la lista de puesta en servicio se sabe de memoria. Más allá, la memoria se convierte en un riesgo operativo. Un VPS aprovisionado a mano no tiene un estado legible: usted no sabe, sin conectarse, si el firewall está configurado, si Docker tiene la versión esperada o si ese servidor sigue formando parte de la rotación.\n\nOpenTofu resuelve un problema distinto al de Ansible. Ansible gestiona la *configuración* de un servidor que ya existe: lo que se ejecuta en él, los archivos presentes, los servicios arrancados. OpenTofu gestiona el *ciclo de vida* del servidor mismo: creación, actualización de atributos, destrucción. Mantiene un archivo de estado (`terraform.tfstate`) que sabe exactamente qué está aprovisionado y qué ya no lo está. Ambas herramientas son complementarias: OpenTofu aprovisiona, Ansible configura.\n\nEn agosto de 2023, HashiCorp cambió la licencia de Terraform de MPL-2.0 a BUSL-1.1, una licencia no libre que prohíbe ciertos usos comerciales. La comunidad respondió creando OpenTofu, un fork compatible con el HCL de las versiones anteriores a Terraform 1.6, hoy alojado bajo la CNCF (Cloud Native Computing Foundation) y la Linux Foundation. El comando es `tofu`, no `terraform`, pero los archivos `.tf` y la lógica son idénticos.",{"type":39,"title":40,"items":41},"ul","Lo que gana con un estado declarativo",[42,43,44,45,46,47,48],"**Inventario fiable** — el archivo `terraform.tfstate` dice exactamente qué servidores existen, con qué IP y qué atributos, sin tener que conectarse a cada uno.","**Reproducibilidad** — un nuevo cliente o un nuevo proyecto recibe el mismo VPS configurado de la misma forma, desde el mismo archivo `.tf` versionado en Git.","**Destrucción limpia** — `tofu destroy` retira los recursos en el orden correcto, sin dejar servidores huérfanos que se siguen facturando.","**Diff legible** — `tofu plan` muestra exactamente lo que se creará, modificará o destruirá antes de actuar, como un `git diff` de su infraestructura.","**Complementariedad con Ansible** — OpenTofu crea el VPS y coloca los metadatos (clave SSH, nombre, red); Ansible toma el relevo para desplegar Docker, Nginx y sus aplicaciones.","**Versionable y auditable** — su infraestructura se convierte en un repositorio Git con commits, revisiones de código y un historial de cambios.","**Licencia open source duradera** — OpenTofu está bajo MPL-2.0, sin restricción comercial, con una gobernanza comunitaria bajo la CNCF.",{"type":35,"title":50,"body":51},"Requisitos previos antes de empezar","Esta guía supone que dispone de un VPS con acceso root e IPv4 dedicada para ejecutar sus cargas de trabajo, y de un equipo de desarrollo (macOS, Linux o Windows con WSL2) desde el que lanza `tofu`. OpenTofu no se ejecuta en el VPS de destino: corre localmente y habla con la API del proveedor o con el daemon Docker del servidor.\n\nPara seguir los ejemplos necesita: OpenTofu instalado en local (consulte \u003Ca href=\"https:\u002F\u002Fopentofu.org\u002Fdocs\u002Fintro\u002Finstall\u002F\">opentofu.org\u002Fdocs\u002Fintro\u002Finstall\u003C\u002Fa>), un acceso API o credenciales SSH hacia el VPS de destino, y Git para versionar sus archivos `.tf`. No se requiere ninguna dependencia adicional — OpenTofu descarga él mismo los providers en el `tofu init`.\n\nPara pilotar Docker en un VPS remoto mediante OpenTofu, el daemon Docker del servidor debe escuchar en su socket Unix (por defecto) o en un puerto TCP seguro. El provider `kreuzwerker\u002Fdocker` se conecta a ese socket por SSH o TCP.",{"type":53,"title":54,"steps":55},"steps","Implementar OpenTofu en una flota de VPS",[56,59,62,65,68,71,74],{"title":57,"body":58},"Instalar OpenTofu en local","Diríjase a \u003Ca href=\"https:\u002F\u002Fopentofu.org\u002Fdocs\u002Fintro\u002Finstall\u002F\">opentofu.org\u002Fdocs\u002Fintro\u002Finstall\u003C\u002Fa> para las instrucciones según su OS. En macOS con Homebrew: `brew install opentofu`. En Debian\u002FUbuntu: el repositorio oficial de OpenTofu proporciona el paquete `opentofu`. Verifique la instalación con `tofu version` — el comando debe devolver la versión instalada.",{"title":60,"body":61},"Estructurar su proyecto Infrastructure as Code","Cree un directorio dedicado y cuatro archivos estándar.\n\n```hcl\n# main.tf — recursos principales\n# variables.tf — declaraciones de variables\n# outputs.tf — valores expuestos tras el apply\n# terraform.tfvars — valores concretos (añadir a gitignore si son secretos)\n```\n\nEsta estructura no es obligatoria para OpenTofu, pero es la convención ampliamente adoptada: `main.tf` contiene los recursos, `variables.tf` declara los tipos y valores por defecto, `outputs.tf` expone lo que Ansible u otra herramienta debe leer tras el aprovisionamiento (IP del servidor, nombre de host…), y `terraform.tfvars` contiene los valores concretos que no desea codificar de forma fija en `main.tf`.",{"title":63,"body":64},"Declarar el provider y generar una clave SSH","OpenTofu instala los providers necesarios en el `tofu init`. El provider `hashicorp\u002Ftls` genera un par de claves SSH en local, lo que evita gestionar claves manualmente.\n\n```hcl\nterraform {\n  required_providers {\n    tls = {\n      source  = \"hashicorp\u002Ftls\"\n      version = \"~> 4.0\"\n    }\n  }\n}\n\nresource \"tls_private_key\" \"vps_key\" {\n  algorithm = \"ED25519\"\n}\n\noutput \"private_key_pem\" {\n  value     = tls_private_key.vps_key.private_key_pem\n  sensitive = true\n}\n```\n\nLance `tofu init` para descargar el provider y luego `tofu apply` para generar la clave. Recupérela con `tofu output -raw private_key_pem > ~\u002F.ssh\u002Fvps_key && chmod 600 ~\u002F.ssh\u002Fvps_key`.",{"title":66,"body":67},"Aprovisionar el VPS con null y local-exec","Si su proveedor de VPS no tiene un provider OpenTofu oficial, el provider `hashicorp\u002Fnull` con un `local-exec` permite ejecutar un comando local (una llamada API con curl, un script shell) y modelar el recurso en el state.\n\n```hcl\nresource \"null_resource\" \"vps_provision\" {\n  triggers = {\n    server_name = var.server_name\n  }\n\n  provisioner \"local-exec\" {\n    command = \u003C\u003CEOT\n      curl -s -X POST https:\u002F\u002Fapi.votre-fournisseur.com\u002Fv1\u002Fservers \\\n        -H \"Authorization: Bearer ${var.api_token}\" \\\n        -d '{\"name\": \"${var.server_name}\", \"image\": \"ubuntu-22.04\"}'\n    EOT\n  }\n}\n```\n\nEste patrón es adecuado para una fase transitoria. Si su proveedor expone una API REST, basta con un script shell llamado en `local-exec` para crear el servidor y escribir su IP en un archivo que `outputs.tf` expondrá después.",{"title":69,"body":70},"Pilotar Docker en el VPS con el provider kreuzwerker","Una vez aprovisionado el VPS e instalado Docker (por Ansible, normalmente), el provider `kreuzwerker\u002Fdocker` le permite declarar contenedores, redes y volúmenes en OpenTofu.\n\n```hcl\nterraform {\n  required_providers {\n    docker = {\n      source  = \"kreuzwerker\u002Fdocker\"\n      version = \"~> 3.0\"\n    }\n  }\n}\n\nprovider \"docker\" {\n  host = \"ssh:\u002F\u002Froot@${var.server_ip}:22\"\n}\n\nresource \"docker_container\" \"app\" {\n  name  = \"mon-app\"\n  image = docker_image.app.image_id\n}\n\nresource \"docker_image\" \"app\" {\n  name = \"nginx:alpine\"\n}\n```\n\nEl provider se conecta al daemon Docker del VPS por SSH — ningún puerto TCP adicional que abrir. La versión estable del provider está disponible en el \u003Ca href=\"https:\u002F\u002Fregistry.terraform.io\u002Fproviders\u002Fkreuzwerker\u002Fdocker\u002Flatest\u002Fdocs\">Terraform Registry\u003C\u002Fa>.",{"title":72,"body":73},"Versionar el state para un equipo","En desarrollo en solitario, el state local (`terraform.tfstate`) basta. En equipo o en CI\u002FCD, dos desarrolladores que lanzan `tofu apply` a la vez corrompen el state. La solución es un backend remoto con bloqueo.\n\nOpenTofu soporta de forma nativa S3 (AWS, MinIO autoalojado) y el GitLab Managed Terraform State. Con un bucket MinIO en un VPS:\n\n```hcl\nterraform {\n  backend \"s3\" {\n    bucket                      = \"tofu-state\"\n    key                         = \"production\u002Fterraform.tfstate\"\n    region                      = \"eu-west-1\"\n    endpoint                    = \"https:\u002F\u002Fminio.votre-domaine.com\"\n    skip_credentials_validation = true\n    skip_metadata_api_check     = true\n    skip_region_validation      = true\n    force_path_style            = true\n  }\n}\n```\n\nEl bloqueo es automático: si hay un `tofu apply` en curso, un segundo se rechaza hasta que termine el primero.",{"title":75,"body":76},"Integrar OpenTofu en su pipeline CI\u002FCD","Un pipeline típico de Woodpecker CI o Forgejo Actions ejecuta `tofu plan` en cada pull request (para revisión humana del diff de infraestructura) y `tofu apply` al hacer merge en la rama principal.\n\n```yaml\nsteps:\n  - name: tofu-plan\n    image: ghcr.io\u002Fopentofu\u002Fopentofu:latest\n    commands:\n      - tofu init\n      - tofu plan -out=tfplan\n\n  - name: tofu-apply\n    image: ghcr.io\u002Fopentofu\u002Fopentofu:latest\n    commands:\n      - tofu apply tfplan\n    when:\n      branch: main\n      event: push\n```\n\nEl state remoto (paso anterior) es indispensable aquí: el runner de CI no tiene acceso al state local de su equipo.",{"type":78,"title":79,"body":80},"tip","Separe los workspaces por entorno","OpenTofu ofrece los `workspaces` para aislar varios estados en el mismo backend: `tofu workspace new staging` crea un espacio aislado y `tofu workspace select production` cambia a producción. Es más ligero que duplicar los directorios `.tf`. En la práctica, un workspace por cliente o por entorno (staging, prod) evita que un `tofu destroy` en staging afecte a producción. Nombre sus recursos con `${terraform.workspace}` para que sigan siendo distintos en el state.",{"type":35,"title":82,"body":83},"Ansible y OpenTofu: la frontera entre ambos","La pregunta surge a menudo: si Ansible ya hace el trabajo, ¿para qué añadir otra herramienta? La frontera es nítida una vez que se plantea con claridad.\n\nOpenTofu responde a «¿qué existe?»: crea el servidor, le asigna una IP, coloca una clave SSH, registra su estado. Si lo elimina de su archivo `.tf` y lanza `tofu apply`, el servidor desaparece — OpenTofu gobierna el ciclo de vida.\n\nAnsible responde a «¿en qué estado está lo que existe?»: instala Docker, configura Nginx, deja un archivo `.env`, reinicia un servicio. Si el servidor ya está ahí, Ansible hace con él lo que usted le pida — pero si no está, Ansible no puede crearlo.\n\nEl flujo natural para una agencia: OpenTofu aprovisiona el VPS y expone su IP como `output`, un playbook de Ansible consume ese `output` mediante un inventario dinámico, configura el servidor y despliega las aplicaciones. El artículo \u003Ca href=\"\u002Fblog\u002Fansible-automatiser-serveurs-vps\">Ansible: automatizar la configuración de sus servidores VPS\u003C\u002Fa> cubre la parte de configuración en detalle.",{"type":35,"title":85,"body":86},"Solución de problemas: los errores frecuentes","Tres situaciones se repiten con regularidad cuando se adopta OpenTofu en una flota existente.",{"type":39,"title":88,"items":89},"Errores comunes y su corrección",[90,91,92,93,94],"**`Error acquiring the state lock`** — un fallo durante un `apply` deja un archivo `.terraform.tfstate.lock.info` en el backend. OpenTofu se niega a continuar mientras exista el bloqueo. Tras comprobar que ningún otro `apply` está en curso, elimine el bloqueo con `tofu force-unlock \u003CLOCK_ID>` (el ID aparece en el mensaje de error). En un backend S3\u002FMinIO, el archivo es visible en el bucket.","**`tofu plan` muestra un `destroy + create` inesperado** — algunos atributos de un recurso fuerzan una recreación (`force new resource`) cuando cambian: el nombre del servidor, el tipo de imagen del OS, la región. Si modifica uno de esos atributos, OpenTofu no puede hacer una actualización en el sitio — destruye y vuelve a crear. Lea el plan con atención antes de aplicar y utilice `tofu plan -target=resource.name` para limitar el alcance.","**State perdido o desincronizado** — si el archivo de state se pierde y los servidores siguen existiendo, `tofu state list` enumera lo que OpenTofu cree aprovisionado, y `tofu import \u003Cresource.type.name> \u003Cid-externe>` importa un recurso existente en el state sin volver a crearlo. Es la herramienta de recuperación cuando la realidad y el state han divergido.","**Provider no encontrado tras `tofu init`** — compruebe que el `source` del provider es exacto (p. ej. `kreuzwerker\u002Fdocker` y no `docker\u002Fdocker`) y que tiene acceso a internet desde la máquina que lanza `tofu init`. En un entorno air-gapped, descargue los providers por adelantado y utilice `plugin_cache_dir`.","**`Error: No valid credential sources found`** — OpenTofu no encuentra las credenciales del provider. Compruebe las variables de entorno que espera el provider (a menudo `TF_VAR_api_token` o un archivo de credenciales específico) y que `terraform.tfvars` se lee correctamente (debe estar en el mismo directorio que `main.tf`).",{"type":35,"title":96,"body":97},"Su infraestructura se convierte en código versionado","OpenTofu no sustituye a SSH: hace que SSH sea excepcional. El flujo diario pasa a ser: modificar un archivo `.tf`, lanzar `tofu plan` para leer el diff, validar, lanzar `tofu apply`. Los servidores que ya no tiene que gestionar se destruyen con `tofu destroy` y desaparecen de la facturación.\n\nPara una agencia que supera la decena de clientes, es la palanca que hace pasar la gestión de infraestructura de un trabajo de memoria a un trabajo de código. Un VPS Cloud ServOrbit con acceso root, IPv4 dedicada y elección de OS es la unidad base que sus archivos `.tf` aprovisionan y destruyen a demanda. Su infraestructura se convierte en código versionado.","Un VPS Cloud listo para OpenTofu","Acceso root, IPv4 dedicada y elección de OS: un VPS Cloud ServOrbit es la unidad base que sus archivos `.tf` aprovisionan y destruyen a demanda.","Iniciar mi VPS Cloud","\u002Fsolutions\u002Fdeveloppeurs",[103,118,137],{"id":104,"slug":105,"slugs":106,"title":110,"excerpt":111,"readTime":17,"views":112,"isPinned":19,"publishedAt":113,"updatedAt":21,"category":114,"categories":115,"featuredImage":29,"bgImage":30,"posterImage":117,"relatedSolution":29},236,"automatizar-servidores-vps-con-ansible",{"fr":107,"en":108,"ar":109,"es":105},"ansible-automatiser-serveurs-vps","automating-vps-server-management-with-ansible","أتمتة-إدارة-خوادم-vps-باستخدام-ansible","Automatizar la gestión de servidores VPS con Ansible","Automatice la gestión de una flota de servidores VPS con Ansible: inventario, playbooks, roles y Vault para una infraestructura reproducible.",1,"2026-08-08T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[116],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fansible-automatiser-serveurs-vps-poster.svg",{"id":119,"slug":120,"slugs":121,"title":125,"excerpt":126,"readTime":127,"views":18,"isPinned":19,"publishedAt":128,"updatedAt":21,"category":129,"categories":134,"featuredImage":29,"bgImage":30,"posterImage":136,"relatedSolution":29},229,"checklist-docker-compose-en-produccion",{"fr":122,"en":123,"ar":124,"es":120},"docker-compose-production-checklist","docker-compose-in-production-10-point-checklist","docker-compose-في-الإنتاج-قائمة-التحقق-من-10-نقاط","Docker Compose en producción: checklist de 10 puntos","Checklist de Docker Compose en producción: 10 ajustes esenciales, gestión de secretos sin downtime, copias de volúmenes sin corrupción, CVE-2026-17106.",8,"2026-08-06T00:00:00+00:00",{"id":130,"name":131,"slug":132,"color":133,"icon":132},3,"Despliegue","deploiement","bg-success\u002F10 text-success",[135],{"id":130,"name":131,"slug":132,"color":133,"icon":132},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":138,"slug":139,"slugs":140,"title":144,"excerpt":145,"readTime":146,"views":112,"isPinned":19,"publishedAt":147,"updatedAt":21,"category":148,"categories":149,"featuredImage":29,"bgImage":30,"posterImage":151,"relatedSolution":29},212,"woodpecker-ci-forgejo-pipeline-cicd-vps",{"fr":141,"en":142,"ar":143,"es":139},"woodpecker-ci-pipeline-vps-forgejo","woodpecker-ci-and-forgejo-cicd-pipeline-on-a-vps","woodpecker-ci-وforgejo-خط-أنابيب-cicd-على-خادم-vps","Woodpecker CI y Forgejo: pipeline CI\u002FCD en un VPS","Despliega Woodpecker CI v3 con Forgejo en tu VPS: configuración Docker Compose, pipelines YAML, secretos, runners multi-arquitectura y depuración OAuth.",11,"2026-08-02T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[150],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fwoodpecker-ci-pipeline-vps-forgejo-poster.svg",1789665028864]