Phenquestions
1. Que hace?
¿Alguna vez se preguntó cómo los proveedores de VPS configuran sus VM, agregan sus claves SSH, crean usuarios e instalan paquetes cada vez que enciende una nueva VM en la 'nube'?? Bueno, la respuesta para la mayoría de los proveedores es cloud-init. La mayoría de sistemas operativos y distribuciones envían imágenes de disco virtual con sus respectivos sistemas operativos instalados en la imagen. La instalación es mínima y puede servir como plantilla para el sistema de archivos raíz del sistema operativo. Los encargados del mantenimiento del sistema operativo también tienen la amabilidad de proporcionar la imagen del disco virtual para todos los formatos, desde imágenes de disco sin procesar hasta qcow2 e incluso vmdk, vdi y vhd.
La imagen también tiene un paquete adicional preinstalado y es cloud-init. El trabajo de cloud-init es inicializar la máquina virtual (normalmente dentro de un servicio de alojamiento en la nube como DigitalOcean, AWS o Azure) hable con el proveedor de alojamiento fuente de datos y obtenga la información de configuración que luego utiliza para configurar la VM.
La información de configuración puede incluir datos del usuario como claves SSH, nombre de host de la instancia, usuarios y contraseñas junto con cualquier otro comando arbitrario que el usuario quiera ejecutar.
2. El problema con Cloud-Init
Cloud-init es una gran herramienta si es un usuario de la nube, si está poniendo en marcha máquinas virtuales o contenedores y su proveedor de nube tiene la amabilidad de pedirle una configuración de nube, es genial! Con un archivo de configuración en la nube, también conocido como sus datos de usuario, puede agregar usuarios, ejecutar comandos arbitrarios, instalar paquetes justo cuando se crea la máquina virtual. El proceso se puede repetir una y otra vez sin que se tecleen una y otra vez los tediosos comandos. Pronto tendrá una flota de máquinas virtuales, todas con una configuración idéntica.
Sin embargo, si profundizas un poco más y ves cómo se hace la salchicha, comenzarás a cuestionar algunos de los aspectos de cloud-init. Por ejemplo, de forma predeterminada, la fuente de datos es como un punto final REST, y estos están esencialmente codificados en el paquete cloud-init. Claro, puede configurar una fuente de datos usted mismo, pero el proceso es desagradable y requiere mucho tiempo. La documentación para hacer esto es casi inexistente.
La documentación oficial no es más que un manual de usuario para usuarios finales que dependen de servicios en la nube preexistentes. No le dice cómo puede configurar su propia fuente de datos de inicio en la nube, en caso de que sea un próximo proveedor. Incluso la documentación del usuario final es deficiente, y recomendaría a las personas que usen el excelente tutorial de DigitalOcean en su lugar.
Para empeorar las cosas, los usuarios con laboratorios de virtualización en el hogar y un pequeño inicio de VPS tienen dificultades para beneficiarse de esas imágenes ligeras en la nube. Realmente no puede iniciar una máquina virtual a partir de esas plantillas sin una fuente de datos de inicio en la nube o algún hacker que sea difícil de automatizar y escalar. En otras palabras, ni siquiera puede optar por ignorar cloud-init a menos que desee crear sus propias plantillas.
De una manera clásica de systemd, se está liberando de sus roles predefinidos y comienza a meterse con las redes y otras partes del sistema operativo, lo que desanima a los usuarios. Se incluye en Ubuntu 18.04 servidor ISO que no tiene absolutamente ningún sentido (al menos no para mí).
3. Solución alternativa para laboratorios domésticos
Dejando a un lado todas las críticas, todavía tengo que lidiar con cloud-init en mi uso diario. Tengo una instalación mínima de Debian 9 en hardware x86_64, que utilizo como hipervisor KVM. Tenía muchas ganas de usar las imágenes de disco qcow2 que envían Ubuntu y CentOS. Estas imágenes de disco tienen el sistema operativo preinstalado en ellas, y para usarlas simplemente necesita:
- Cópielos como la imagen del disco duro virtual de su VM.
- Cambie el tamaño virtual del sistema de archivos raíz al tamaño deseado (se recomienda al menos 10 GB). Esto no aumentará el tamaño físico de su máquina virtual, pero la imagen del disco puede crecer con el tiempo a medida que la máquina virtual le agrega más datos.
- Configure las máquinas virtuales usando cloud-init. El requisito mínimo es establecer la contraseña del usuario raíz o las claves SSH, pero puede hacer prácticamente todo lo que cloud-init es capaz.
Se siguen los siguientes pasos:
- Descargue la imagen en la nube de su sistema operativo favorito y guárdela en el directorio / var / lib / libvirt / boot:
$ curl -O https: // imágenes en la nube.ubuntu.com / xenial / current / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / images
- Cree un disco duro virtual vacío del tamaño deseado y expanda la imagen qcow2 descargada en él. Me gusta almacenar los discos duros de la máquina virtual en el directorio / var / lib / libvirt / images /, puede elegir un directorio diferente. Elija lo que elija, ejecute los siguientes comandos en el mismo directorio:
tamaño de disco virtual de 8GB
$ virt-resize --expand / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2
- Crear archivos de inicio en la nube. Estos son archivos de datos de usuario y metadatos:
id-instancia: myVM
nombre de host local: myVM
$ vim datos de usuario
# cloud-config
usuarios:
- nombre: root
chpasswd:
lista: |
root: myPassword
expirar: falso
El único usuario que tengo aquí es el usuario root. Si no menciona a ningún usuario, entonces el usuario predeterminado con nombre ubuntu se crea. El nombre de usuario predeterminado difiere de un sistema operativo a otro, por lo que recomiendo especificar un usuario, incluso si es solo raíz. La siguiente parte del archivo de datos de usuario le dice a cloud-init que configure la contraseña para todos los usuarios a los que desea asignar una contraseña. Nuevamente, solo estoy configurando la contraseña solo para el usuario root, y es mi contraseña. Asegúrese de que no haya espacio entre los dos puntos y la cadena de contraseña.
Mejor aún, puede usar claves SSH en lugar de tener contraseñas codificadas por ahí.
$ vim datos de usuario# cloud-config
usuarios:
- nombre: root
ssh_pwauth: verdadero
ssh_authorized_keys:
- ssh-rsa
- Incruste los archivos de datos de usuario y metadatos en una iso.
Asegúrese de que el archivo cidata-myVM.iso se encuentra en / var / lib / libvirt / images /
- Vaya al directorio / var / lib / libvirt / images e inicialice la máquina virtual con el comando virt-install: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
--disco myVM.qcow2, formato = qcow2, bus = virtio --disk myVM-cidata.iso, dispositivo = cdrom
--puente de red = virbr0, modelo = virtio --os-type = linux
--os-variant = ubuntu16.04 --noautoconsolaAhora puede intentar iniciar sesión en la máquina virtual usando el comando virsh console myVM y usando el nombre de usuario root y su contraseña correspondiente para iniciar sesión. Para salir de la consola, simplemente escriba Ctrl +]
Conclusión
Las imágenes en la nube que envían la mayoría de los proveedores son realmente eficientes en términos de utilización de recursos y también se sienten realmente rápidas y receptivas. El hecho de que tengamos que lidiar con la configuración incómoda de inicio en la nube como punto de partida solo dificulta la adopción por parte de la comunidad de KVM y tecnologías relacionadas.
La comunidad puede aprender mucho de la forma en que Docker crea y envía sus imágenes. Son realmente fáciles de administrar tanto como contenedores en ejecución y plantillas que son fáciles de distribuir y usar.z
