Tema: provisioning
-
Archivos de respuesta de Windows (unattend.xml): fases de configuración y dónde los busca Setup
Un archivo de respuesta unattend.xml aporta ajustes a fases de configuración concretas de Windows Setup; windowsPE, generalize, specialize y oobeSystem son las que más intervienen en el aprovisionamiento. Setup lo localiza mediante un orden de búsqueda implícito fijo y lo guarda en caché en %WINDIR%\Panther, y Windows System Image Manager crea estos archivos y puede ocultar, pero no cifrar, las contraseñas de cuentas locales.
-
Comandos ad-hoc de Ansible y modo check para una primera ejecución segura sobre un conjunto de hosts
Un comando `ansible` ad-hoc ejecuta un módulo sobre uno o varios hosts sin necesidad de un playbook; combinado con `--check --diff` y un `--limit` acotado, permite a un agente ver qué efecto tendría un cambio en la flota antes de aplicarlo.
-
Generalizar una imagen de Windows con Sysprep: /generalize, /oobe, /shutdown y el límite de rearme
Sysprep /generalize elimina de una instalación de Windows la información propia del equipo, como el SID y los dispositivos configurados, para poder implementar la imagen en otros equipos. En Windows 8.1/Server 2012 y posteriores, Sysprep puede ejecutarse hasta 1001 veces por imagen (3 veces en Windows 7/Server 2008 R2), y los fallos de generalización dejan rastro en los registros Panther de System32\Sysprep.
-
Regenerar las claves de host SSH y el machine ID en un host Linux clonado
Un host Linux recién clonado necesita sus propias claves de host SSH y su propio machine ID antes de unirse a una flota; `ssh-keygen -A` y `systemd-machine-id-setup` pueden crearlos, pero en un clon que ya arrancó, un machine ID duplicado requiere escribir un valor nuevo y reiniciar. Comprobar duplicados en toda la flota es la única verificación real de que la clonación no copió los mismos identificadores en todas partes.
-
Preparar una imagen base (golden image) de Linux para clonar: claves de host, machine-id, logs y reglas de red
Una imagen de Linux pensada para clonarse muchas veces no debe contener un /etc/machine-id relleno (ni un /var/lib/dbus/machine-id obsoleto), claves de host SSH, configuración de red fijada a una MAC ni estado de cloud-init. De lo contrario, cada clon arranca con los mismos identificadores que los demás, y si se eliminan las claves de host sin un mecanismo para regenerarlas en el primer arranque, los clones quedan sin SSH.
-
Dar de baja un servidor de forma segura: eliminarlo de todos los sistemas que aún confían en él
Dar de baja un servidor no es solo apagarlo: el DNS, la monitorización, los trabajos de copia de seguridad, el registro de inventario y cualquier objeto de equipo del directorio siguen confiando en él o esperándolo mientras nadie lo elimine explícitamente, y el almacenamiento requiere un método de sanitización adecuado al tipo de medio antes de reutilizarlo o desecharlo.
-
Creación de imágenes de máquina con Packer: builders, provisioners, validate y build
HashiCorp Packer separa los builders de una plantilla (qué plataforma produce la imagen) de los provisioners (qué configura la máquina antes de capturarla). `packer init` instala los plugins necesarios, `packer validate` comprueba la sintaxis y la configuración de una plantilla antes de que `packer build` la ejecute, y marcar las variables como sensibles evita que las credenciales aparezcan en las plantillas y en los logs.
-
Debian preseed y Ubuntu autoinstall: dos formatos de instalación automatizada que no son intercambiables
El instalador de Debian se automatiza con un archivo preseed que responde las preguntas de debconf, mientras que Ubuntu Server (20.04+) y Desktop (23.04+) usan el formato YAML autoinstall de Subiquity, entregado como user-data de cloud-init o como autoinstall.yaml en el medio de instalación. Los dos formatos no son portables entre distribuciones y conviene validar ambos antes de usarlos en una instalación desatendida.
-
Agentes de aprovisionamiento de Windows en el primer arranque en la nube: EC2Launch v2, el agente de VM de Azure y cloudbase-init
AWS, Azure y la mayoría de las demás nubes incluyen en la imagen de Windows un pequeño agente que procesa los datos de usuario o los datos personalizados en el primer arranque. Los agentes habituales son EC2Launch v2, los agentes de aprovisionamiento y de VM de Windows de Azure (que guardan los datos personalizados en CustomData.bin pero no los ejecutan) y el proyecto de código abierto cloudbase-init. Cada uno registra en una ubicación distinta, que conviene revisar cuando el aprovisionamiento parece haber fallado sin avisar.
-
Lista de verificación posterior al aprovisionamiento antes de entregar un servidor
Que un servidor arranque no significa que esté listo para cargas de producción. Esta lista da a un agente un orden fijo de comprobaciones (hora, resolución de nombres, nivel de parches, monitorización, alta en copias de seguridad, acceso y análisis de línea base) que debe ejecutar antes de dar por terminado un host recién aprovisionado.
-
Gestión de configuración frente a image baking: dónde deciden la idempotencia y el drift
Las herramientas de gestión de configuración hacen converger un sistema en ejecución hacia un estado declarado en cada ejecución, mientras que el baking de una imagen de máquina fija ese estado una sola vez, en el momento de la compilación. La idempotencia hace seguro repetir el primer enfoque, y elegir entre baking y configuración en el arranque equivale a decidir dónde se permite que ocurra el drift.
-
Nombrar, etiquetar y registrar un servidor nuevo: metodología para nombres de host e inventario
Un servidor que se aprovisiona sin un nombre coherente, sin etiquetas de propietario y propósito y sin registro en un inventario queda, en la práctica, como infraestructura sin documentar en cuanto su creador deja el proyecto; esta metodología fija el nombre de host en Linux y Windows y define qué debe contener un registro mínimo de inventario.
-
Cómo manejar cloud-init en una instancia nueva de Debian o Ubuntu: user-data, status --wait y reejecuciones seguras
cloud-init aplica el user-data una sola vez en el primer arranque; `cloud-init status --wait` bloquea hasta que esa ejecución termina para que un script de aprovisionamiento no compita con ella, `cloud-init schema --system` detecta un archivo user-data incorrecto antes del siguiente arranque y `cloud-init clean` es la forma documentada de forzar una reejecución completa para pruebas.
Legible por máquina: JSON