Ha llegado el momento de salir del que probablemente sea uno de los periodos de “lanzamiento suave” más largos, y dar a conocer más ampliamente la disponibilidad de las imágenes SLE-Micro en la nube pública. Me tomo la libertad de definir "lanzamiento suave" en este caso como
especialmente la última parte, por supuesto, no es muy agradable y pretendo ponerle fin. Consideremos estos temas uno a la vez.
Las imágenes SLE-Micro han estado disponibles en AWS EC2, Azure y GCE desde la versión SLE-Micro 5.1. La versión más reciente es SLE-Micro 5.3 y estamos trabajando en la versión 5.4 que se publicará en un futuro no muy lejano. La información de la imagen está en pinta y, por lo tanto, también se puede ver en https://pint.suse.com .
El ciclo de vida de las imágenes sigue el ciclo de vida de la imagen publicada y está en un calendario de lanzamiento continuo de 3 meses. El producto SLE-Micro tiene un ciclo de vida diferente al de otros productos SLE, por ejemplo, SUSE Linux Enterprise Server y SUSE Linux Enterprise Server para aplicaciones SAP . Como tal, las transiciones de escenario son diferentes y tenemos más de 1 imagen activa.
En la actualidad, SLE-Micro está disponible como una opción BYOS con una opción PAYG en el horizonte. Esto significa que necesitará un código de registro del Centro de atención al cliente de SUSE para recibir actualizaciones de SLE-Micro.
Bueno, con este blog el período de no hablar de las imágenes finalmente ha terminado. Por supuesto, esto podría haber sucedido hace algún tiempo, pero el problema con el tiempo es que es un recurso limitado y...
Aquí espero brindar suficiente orientación para que el uso de SLE-Micro en la nube pública no sea una lucha. En primer lugar, SLE-Micro es muy diferente a otros productos SLE. Está pensado como un host contenedor, es decir, una implementación más enfocada de un sistema operativo construido para un caso de uso particular. Como tales suposiciones subyacentes son diferentes para la implementación de la distribución que para la distribución de uso general de SUSE Linux Enterprise Server. Al igual que con nuestras otras imágenes para otros productos, nuestro objetivo es modificar la distribución subyacente lo menos posible para el uso en los diversos marcos de la nube. Este objetivo responde a la idea de que los usuarios que utilizan SLE-Micro en su centro de datos o en otros dispositivos, como en el borde, encontrarán, en la medida de lo posible, el mismo comportamiento de la distribución en la nube.
Para obtener detalles sobre la administración de SLE-Micro, consulte la guía de administración .
Con esto como antecedente, comencemos destacando las diferencias para aquellos que pueden estar acostumbrados a usar imágenes SLES, SLES para SAP o SLE HPC en la nube. SLE-Micro tiene un sistema de archivos raíz de solo lectura que usa btrfs. El uso de btrfs permite actualizaciones transaccionales, lo que significa que las actualizaciones son atómicas, es decir, el sistema en ejecución no se modifica cuando se instalan nuevos paquetes o se actualizan los paquetes instalados. Más bien, se crea una nueva instantánea y las actualizaciones del sistema se instalan en la nueva instantánea. Las actualizaciones se activan al reiniciar.
Las actualizaciones transaccionales tienen una serie de características interesantes, como se destaca en la documentación. El requisito de reiniciar el sistema para cada actualización puede parecer un obstáculo a primera vista. Aquí es donde brilla la naturaleza especialmente diseñada de SLE-Micro. En un mundo en el que SLE-Micro se utiliza como host contenedor, el reinicio en realidad no es un problema. Los contenedores en el host se pueden mover razonablemente fácilmente a un host diferente, el host se reinicia y luego los contenedores se vuelven a mover. Por supuesto, en la nube, las actualizaciones -> evacuar -> reiniciar -> volver a llenar el ciclo es un enfoque que es algo contrario a la intuición. Iniciar una nueva instancia a partir de una nueva imagen -> integrar en el clúster -> eliminar la instancia anteriorEl ciclo elimina la actualización/actualización de un sistema en ejecución y puede parecer más "nativo de la nube". De todos modos, ambos enfoques tienen su mérito y la gente probablemente discutirá sobre los pros y los contras de cada enfoque en los años venideros.
Otra diferencia importante para quienes están acostumbrados a usar otras imágenes basadas en SLE es la inicialización de la instancia. Para SLE-Micro esto sucede con Ignition y Afterburn . Esto implica que agregar los datos de usuario de cloud-init existentes en el inicio de la instancia no tendrá ningún efecto. Además, el usuario inicial/predeterminado del sistema es diferente, en comparación con otras imágenes de productos SLE. En todos los CSP, el usuario es " suse ". La elección de un nombre de usuario coherente en todos los marcos de la nube se debió en parte a la idea de crear uniformidad para ayudar con la integración automática de instancias en clústeres en ejecución sin tener que realizar ajustes específicos del CSP (proveedor de servicios en la nube).
En la combinación Ignition/Afterburn de inicialización de instancias, la creación de usuarios es responsabilidad de Ignition. Mientras el encendido accede al servicio de metadatos de la instancia del proveedor de la nube, lo hace con el propósito de consumir los llamados datos de usuario . Ignition no analiza datos adicionales del servicio de metadatos, ya que Ignition no crea un usuario especificado en Azure a través de la consola web o la cli. Esta es también la razón por la que no se puede establecer una conexión ssh desde la consola web de GCE a una instancia de SLE-Micro de forma predeterminada.
Para crear usuarios adicionales, se debe pasar un archivo de configuración de encendido como datos de usuario a través del servicio de metadatos, por ejemplo
{n "encendido": { "versión": "3.1.0" },n "almacenamiento": {n "sistemas de archivos": [n {n "ruta": "/casa",n "dispositivo": "/dev/disco/por-etiqueta/ROOT",n "formato": "btrfs",n "wipeFilesystem": falso,n "opciones de montaje": [n "subvol=/@/casa"n ]n }n ]n },n "contraseña": {n "usuarios": [n {n "nombre": "foo",n "uido": 1100n }n ]n }n}
creará el usuario adicional llamado " foo " en la instancia. Esto solo creará el usuario, deberá especificar una clave ssh para iniciar sesión. Afterburn configurará la clave ssh utilizada para iniciar la instancia y que se pasa a través del servicio de metadatos de la instancia (IMDS) para el usuario " suse ". El motivo de esto es que la imagen inicia automáticamente el servicio systemd afterburn-sshkeys@suse y es este servicio, que forma parte de Afterburn, el que transfiere la clave ssh de IMDS al directorio de inicio del usuario creado.
El usuario “ suse ” preconfigurado se configura a través del archivo de configuración de encendido /usr/lib/ignition/base.d/base.ign . El uso de este archivo lo activa un módulo dracut, /etc/dracut.conf.d/85-ign-usr-config.conf . El usuario “ suse ” también está configurado para tener acceso a sudo a través de /etc/sudoers.d/builtin . Lo que significa que una vez que accede a su instancia de SLE-Micro como el usuario " suse ", puede cambiar al usuario " raíz " a través del
sudo -i
dominio.
La configuración del usuario a través del encendido solo ocurre en el primer arranque. Para diferenciar el primer arranque de cualquier otro arranque, se escribe un archivo de marca, /boot/writable/firstboot_happened .
Es muy probable que nuestra configuración de usuario por defecto no coincida con lo que te gustaría ver. Tiene un par de opciones para hacer que la configuración del sistema se ajuste a sus gustos.
Existe una posibilidad razonable de que esté familiarizado con el comando useradd . Dicho esto, dado que SLE-Micro está basado en btrfs, y como dije, intentamos proporcionar el mismo comportamiento tanto como sea posible que en otros entornos. Por lo tanto, en las imágenes de la nube pública, el diseño del sistema de archivos es el mismo que se documenta en la Guía de implementación de SLE-Micro . Esto significa que el directorio /home está en un subvolumen y, como tal, el comando useradd debe usarse en consecuencia .
Linware Argentina ⯈useradd --btrfs-subvolume-home --create-home bar
por ejemplo para agregar la barra de usuario al sistema. El directorio /etc está montado como un overlayFS y se puede editar, como tal, si desea que el usuario recién agregado tenga acceso de raíz a través de sudo , debe realizar los cambios de configuración necesarios como lo haría en cualquier otro sistema SLE. Estos cambios surten efecto inmediatamente, es decir, no es necesario reiniciar.
También puedes deshacerte del usuario “ suse ”. Tenga cuidado de configurar otro usuario para que tenga acceso " sudo " o perderá su acceso para administrar el sistema.
También puede modificar el archivo de configuración de encendido predeterminado. Dado que el sistema de archivos raíz es de solo lectura, deberá realizar cambios utilizando el
shell de actualización transaccional
dominio. Esto creará una nueva instantánea que se montará en lectura y escritura y podrá realizar los cambios que considere oportunos. Una vez que salga del shell, el código de actualización transaccional configurará la instantánea creada como de solo lectura y la convertirá en la instantánea predeterminada para el siguiente arranque. Para que esos cambios se apliquen en el próximo reinicio, el archivo de configuración también debe integrarse en el initrd, ya que el encendido y la postcombustión se ejecutan desde el initrd. Para reconstruir la ejecución de initrd
initrd de actualización transaccional
. Si desea que el usuario recién creado tenga acceso a través de la clave ssh proporcionada por el marco, también debe asegurarse de que
systemctl start afterburn-sshkeys@$TU_NUEVO_NOMBRE DE USUARIO
se ejecuta para ingerir la clave shh de IMDS en la instancia para el usuario recién creado. Una vez que haya terminado con eso, puede reiniciar. Tenga en cuenta que cada vez que se utiliza el comando de actualización transaccional para modificar el sistema, es decir, a través de la actualización transaccional o shell de actualización transaccional, se crea una nueva instantánea. Para seguir modificando 1 instantánea, use la opción –continuar .
Al igual que con otras imágenes SLE, el volumen raíz se establece en el tamaño especificado por nuestros socios, es decir, 10 GB en AWS y GCE y 30 GB en Azure. El tamaño mínimo recomendado para el volumen raíz de SLE-Micro es de 12 GB. El tamaño que elija para el volumen raíz depende, por supuesto, de cuántos contenedores cree que tendrá en el sistema y qué tan grandes son esos contenedores. También cada vez que actualice el sistema, es decir , actualización transaccional, se creará una instantánea. Si bien las instantáneas btrfs son eficientes en cuanto al espacio, aún ocupan espacio. El volumen raíz crecerá automáticamente a medida que cambie el tamaño del disco subyacente, tal como lo hace con otras imágenes SLE. Esto significa que cuando note que se está quedando sin espacio en disco, siempre puede detener su instancia y hacer que el disco del sistema sea más grande, hasta el límite de los tamaños de disco individuales en cada marco de la nube.
En este momento, el tiempo de ejecución del contenedor en las imágenes de la nube pública es docker . Esto ayuda con la integración en los clústeres de kubernetes. Dicho esto, como ha sido bien publicitado, kubernetes ha eliminado el soporte de docker en sentido ascendente y, como tal, este cambio se está abriendo camino en los entornos administrados de kubernetes, AKS, EKS, GKE. Por lo tanto, en algún momento en el futuro esta configuración predeterminada cambiará y este blog se actualizará en consecuencia. dockerd se ejecuta de forma predeterminada y docker pull y docker run funcionarán de forma inmediata .
SLE-Micro también es compatible con podman y systemd-container si desea/necesita cambiar el tiempo de ejecución del contenedor utilizado en el host para que se adapte a su entorno. Ambos tiempos de ejecución están disponibles en los repositorios. Lo que me lleva al tema del registro. Puede usar el comando SUSEConnect para registrar su instancia con su código de registro de SUSE en el Centro de atención al cliente de SUSE (SCC) o puede usar registercloudguest , como se describe aquí , para usar la infraestructura de actualización de la nube pública operada por SUSE como un proxy para SCC.
También puede preguntarse si las instantáneas internas que guarda btrfs tienen alguna relación o interfieren con las instantáneas externas del disco que se pueden crear utilizando las herramientas del marco de la nube con fines de copia de seguridad o para crear nuevas imágenes. La respuesta es no. No hay relación con las instantáneas externas que se pueden crear a través de las herramientas del marco y la creación de imágenes funciona como se esperaba.
A medida que lea la documentación de SLE-Micro, también encontrará una opción de inicialización llamada Combustión. La combustión no está incluida en las imágenes de la nube pública. Si bien la función de " ejecutar cualquier cosa en un script " de combustión proporciona básicamente una flexibilidad ilimitada, la combustión no tiene la capacidad de leer desde IMDS. Como tal, para configurar su instancia con combustión, sería necesario crear un disco separado en el marco, configurarlo para cumplir con la estructura de directorio necesaria y luego crear una instancia con este disco de configuración adjunto. Si se necesita el uso de la combustión para la integración en su entorno, puede crear sus propias imágenes utilizando barriles y recetas de barriles.. El proyecto keg-recipes contiene la descripción de la imagen que SUSE utiliza para crear las imágenes que publicamos. Agregar el paquete de combustión para crear una descripción de imagen personalizada debería ser razonablemente sencillo.
Otro tema que encontrará en la documentación es el registro del sistema. Para las instancias en la nube, no necesita usar el comando de actualización transaccional para registrar el sistema. Como se mencionó anteriormente , SUSEConnect o registercloudguest son las herramientas que desea utilizar. Puede utilizar el comando de actualización transaccional, pero siempre lo conectará con el Centro de atención al cliente de SUSE (SCC). No todas las imágenes tienen disponible el comando registercloudguest , ya que es una función que se agregó recientemente.
Y con esto, el "secreto" está fuera de la bolsa y espero que resaltar las diferencias con otras imágenes SLE sea útil cuando desee implementar aplicaciones basadas en contenedores en SLE-Micro en la nube pública.
