Capítulo 1 · 1.9
cloud-init propio: configure su VPS automáticamente en el primer arranque
Con cloud-init puede añadir durante la instalación un archivo que su VPS ejecuta por sí mismo en el primer arranque. Así, su servidor instala de inmediato sus paquetes habituales, crea su propio usuario y ejecuta sus comandos. Resulta práctico si reinstala con frecuencia o si siempre quiere empezar con la misma base. No necesita ninguna API ni terminal para ello.
¿Dónde se introduce?
- Abra la pantalla del VPS a través de Mis productos.
- VPS nuevo: verá el bloque Instale su VPS (consulte Instalar su VPS: sistema operativo, contraseña y clave SSH). Reinstalación: elija la pestaña Avanzado y, en Reinstalación, haga clic en Reinstalar... (consulte Reinstalar o montar una ISO).
- Elija el sistema operativo e introduzca la contraseña de root y, si lo desea, su clave SSH, como siempre.
- Debajo de la clave SSH, haga clic en cloud-init propio. El campo se despliega.
- Pegue su archivo en el campo.
- Haga clic en el botón para instalar, por ejemplo Instalar Debian 13, o, en caso de reinstalación, en Borrar todo y reinstalar.
La contraseña de root o la clave SSH siguen siendo necesarias, también con un cloud-init propio. Con ellas siempre podrá acceder, también a través de la consola (consulte La consola: su VPS en el navegador).
¿Qué puede contener el archivo?
El campo admite user-data, el archivo que cloud-init lee en el primer arranque. La primera línea determina de qué se trata:
| Primera línea | ¿Qué es? |
|---|---|
#cloud-config | Ajustes en YAML: paquetes, usuarios, archivos, comandos. Es lo que utilizará normalmente. |
#!, por ejemplo #!/bin/bash | Un script. Se ejecuta una sola vez como root, al final del primer arranque. |
#cloud-boothook | Un script que se ejecuta muy pronto durante el arranque, de nuevo en cada arranque. Solo para usuarios avanzados. |
## template: jinja | Una plantilla con variables de cloud-init. En la línea siguiente figura entonces #cloud-config o #!. |
- Máximo 256 KB, y solo texto (UTF-8).
- En YAML se sangra con espacios, nunca con tabuladores.
- WebOké se encarga de la red (IPv4 e IPv6). No se utiliza una network-config propia, así que no incluya ajustes de red.
Un ejemplo
Este archivo actualiza todos los paquetes, instala htop y fail2ban, crea el usuario anna con su clave SSH y sudo, asigna al servidor un nombre propio y configura la zona horaria:
#cloud-config
hostname: web1
fqdn: web1.example.com
package_update: true
package_upgrade: true
packages:
- htop
- fail2ban
users:
- default
- name: anna
shell: /bin/bash
sudo: "ALL=(ALL) NOPASSWD:ALL"
ssh_authorized_keys:
- ssh-ed25519 AAAAC3Nza... anna@laptop
runcmd:
- timedatectl set-timezone Europe/Amsterdam
Sustituya la clave por su propia clave pública (consulte Crear una clave SSH en Windows, Mac y Linux). La línea - default mantiene el usuario predeterminado, de modo que la contraseña de root y la clave SSH del formulario siguen funcionando con normalidad. Tras el primer arranque, inicie sesión con ssh anna@203.0.113.10. En Desactivar el inicio de sesión con contraseña y como root y fail2ban contra los intentos de adivinar contraseñas puede leer cómo desactivar después el inicio de sesión como root y cómo configurar fail2ban.
Consejo: El ejemplo es para Debian y Ubuntu. En AlmaLinux y Rocky Linux, htop y fail2ban se encuentran en el repositorio adicional EPEL. Allí, omita packages y coloque bajo runcmd primero dnf install -y epel-release y después dnf install -y htop fail2ban.
¿Qué añade WebOké por su cuenta?
WebOké siempre incluye el nombre de host, la contraseña de root (solo como hash) y su clave SSH. Su archivo se combina con ello. Si usted mismo define users, password, chpasswd o ssh_authorized_keys, sus valores tienen prioridad sobre lo que añade WebOké.
Atención: Si usted mismo define ssh_authorized_keys o password en el nivel superior de su archivo, estos sustituyen la clave y la contraseña del formulario. En ese caso, incluya usted mismo la clave con la que desea iniciar sesión; de lo contrario, solo podrá acceder a través de la consola.
¿Ha funcionado?
cloud-init se ejecuta una sola vez, en el primer arranque tras la instalación. A veces tarda unos minutos más que la propia instalación, sobre todo si se instalan paquetes. Inicie sesión y compruébelo:
anna@web1:~$ cloud-init status --long
anna@web1:~$ sudo tail -n 30 /var/log/cloud-init-output.log
anna@web1:~$ sudo cloud-init schema --system
cloud-init status --longmuestrastatus: donecuando todo ha terminado,runningsi todavía está en curso yerrorsi algo ha fallado, junto con el error. Concloud-init status --waitespera hasta que termine.- En
/var/log/cloud-init-output.logencontrará la salida de sus paquetes, comandos y scripts. Hay más detalles en/var/log/cloud-init.log. cloud-init schema --systemcomprueba si su archivo contiene errores. Si el YAML no es correcto, cloud-init omite las partes que no entiende, sin que la instalación falle.
¿Algo ha salido mal? Corríjalo manualmente en el servidor, o modifique su archivo y reinstale. Tenga en cuenta que la reinstalación borra todo lo que hay en su VPS.
Conviene saber
- Funciona con todos los sistemas operativos de la lista: Ubuntu 24.04 y 26.04, Debian 12 y 13, AlmaLinux 9 y 10 y Rocky Linux 9 y 10.
- Su archivo se transmite cifrado y no se guarda en el historial de tareas de su VPS. Aun así, no incluya contraseñas ni otros secretos que no necesite.
- Todas las posibilidades figuran en la documentación de cloud-init en docs.cloud-init.io.
Atención: El contenido de su cloud-init es responsabilidad suya. El servicio de soporte no revisa su archivo ni ayuda a redactarlo o mejorarlo.
