Algunas personas dicen que las distribuciones de Linux ya no importan con los contenedores. Los enfoques alternativos, como los contenedores distroless y scratch, parecen estar de moda. Parece que estamos considerando y tomando decisiones tecnológicas basadas más en el sentido de la moda y la gratificación emocional inmediata que pensando en los efectos secundarios de nuestras elecciones. Deberíamos hacernos preguntas como:¿Cómo afectarán estas opciones al mantenimiento dentro de seis meses? ¿Cuáles son las compensaciones de ingeniería? ¿Cómo afecta este cambio de paradigma a nuestros sistemas de compilación a escala?
Es frustrante de ver. Si olvidamos que la ingeniería es un juego de suma cero con ventajas y desventajas medibles, con costos y beneficios de diferentes enfoques, nos perjudicamos a nosotros mismos, perjudicamos a nuestros empleadores y perjudicamos a nuestros colegas que eventualmente mantendrán nuestro codificar un flaco favor. Finalmente, les hacemos un flaco favor a todos los mantenedores (¡salve a los mantenedores!) al no apreciar el trabajo que hacen.
Comprender el problema
Para comprender el problema, debemos investigar por qué comenzamos a usar distribuciones de Linux en primer lugar. Agruparía las razones en dos grupos principales:núcleos y otros paquetes. En realidad, compilar núcleos es bastante fácil. Slackware y Gentoo (todavía tengo un punto débil en mi corazón) nos enseñaron eso.
Por otro lado, la gran cantidad de software de desarrollo y tiempo de ejecución que debe empaquetarse para un sistema Linux utilizable puede ser abrumador. Además, la única forma en que puede asegurarse de que millones de permutaciones de paquetes se puedan instalar y trabajar juntos es usando el viejo paradigma:compílelo y envíelo como una cosa (es decir, una distribución de Linux). Entonces, ¿por qué las distribuciones de Linux compilan kernels y todos los paquetes juntos? Simple:para asegurarse de que las cosas funcionen juntas.
Primero, hablemos de los núcleos. El núcleo es especial. Arrancar un sistema Linux sin un núcleo compilado es un desafío. Es el núcleo de un sistema operativo Linux y es lo primero en lo que confiamos cuando arranca un sistema. Los núcleos tienen muchas opciones de configuración diferentes cuando se compilan que pueden tener un efecto tremendo en cómo se ejecutan el hardware y el software en uno. Un problema secundario en este cubo es que el software del sistema, como compiladores, bibliotecas C e intérpretes, debe ajustarse para las opciones que incorporó al kernel. Gentoo nos enseñó esto de una manera visceral, lo que convirtió a todos en un mantenedor de distribución en miniatura.
Vergonzosamente (porque he trabajado con contenedores durante los últimos cinco años), debo admitir que he compilado kernels recientemente. Tuve que hacer que KVM anidado funcionara en RHEL 7 para poder ejecutar OpenShift en máquinas virtuales OpenStack, en una máquina virtual KVM en mi computadora portátil, así como nuestro kit de desarrollo de contenedores (CDK). #justsayin Basta con decir que encendí RHEL7 en un kernel 4.X completamente nuevo en ese momento. Como cualquier buen administrador de sistemas, estaba un poco preocupado porque me perdí algunas opciones de configuración y parches importantes. Y, por supuesto, tenía echaba de menos algunas cosas. El modo de suspensión dejó de funcionar correctamente, mi estación de acoplamiento dejó de funcionar correctamente y hubo muchos otros errores pequeños y aleatorios. Pero funcionó lo suficientemente bien para una demostración en vivo de OpenShift en OpenStack, en una sola máquina virtual KVM en mi computadora portátil. Vamos, eso es un poco divertido, ¿verdad? Pero estoy divagando...
Ahora, hablemos de todos los otros paquetes. Si bien el kernel y el software del sistema asociado pueden ser complicados de compilar, el problema mucho más grande desde la perspectiva de la carga de trabajo es compilar miles y miles de paquetes para brindarnos un sistema Linux utilizable. Cada paquete requiere experiencia en la materia. Algunas piezas de software requieren ejecutar solo tres comandos:./configure , hacer y realizar la instalación . Otros requieren mucha experiencia en la materia, desde agregar usuarios y configurar valores predeterminados específicos en etc. para ejecutar scripts posteriores a la instalación y agregar archivos de unidad systemd. El conjunto de habilidades necesarias para las miles de piezas diferentes de software que puede usar es abrumador para cualquier persona. Pero, si desea un sistema utilizable con la capacidad de probar un nuevo software cuando lo desee, debe aprender a compilar e instalar el nuevo software antes de que pueda comenzar a aprender a usarlo. Eso es Linux sin una distribución de Linux. Ese es el problema de ingeniería que está aceptando cuando renuncia a una distribución de Linux.
El punto es que tiene que construir todo junto para asegurarse de que funcione junto con un nivel razonable de confiabilidad, y se necesita mucho conocimiento para construir una cohorte utilizable de paquetes. Este es más conocimiento del que cualquier desarrollador o administrador de sistemas podrá aprender y retener razonablemente. Todos los problemas que describí se aplican a su host de contenedor (software del sistema y kernel) y la imagen del contenedor (software del sistema y todos los demás paquetes); observe la superposición; también hay compiladores, bibliotecas C, intérpretes y JVM en la imagen del contenedor.
La solución
Ya lo sabes, pero las distribuciones de Linux son la solución. Deje de leer y envíe su mantenedor de paquetes más cercano (nuevamente, ¡salve a los mantenedores!) Una tarjeta electrónica (espera, ¿acabo de revelar mi edad?). Hablando en serio, esta gente hace un montón de trabajo, y es realmente subestimado. Kubernetes, Istio, Prometheus y Knative:te estoy mirando. También se acerca su momento, cuando estará en modo de mantenimiento, sobreutilizado y subestimado. Volveré a escribir este mismo artículo, probablemente sobre Kubernetes, dentro de siete a diez años.
Primeros principios con compilaciones de contenedores
Existen ventajas y desventajas entre construir desde cero y construir a partir de imágenes base.
Crear desde imágenes base
Construir a partir de imágenes base tiene la ventaja de que la mayoría de las operaciones de construcción no son más que la instalación o actualización de un paquete. Se basa en una tonelada de trabajo realizado por los mantenedores de paquetes en una distribución de Linux. También tiene la ventaja de que un evento de aplicación de parches dentro de seis meses, o incluso dentro de 10 años (con RHEL), es un evento de administrador de operaciones/sistemas (actualización de yum), no un evento de desarrollador (que requiere revisar el código para averiguar por qué algunos el argumento de la función ya no funciona).
Hagamos doble clic en eso un poco. El código de la aplicación se basa en muchas bibliotecas que van desde bibliotecas JSON munging hasta mapeadores relacionales de objetos. A diferencia del kernel de Linux y Glibc, estos tipos de bibliotecas cambian con muy poca consideración para romper la compatibilidad de API. Eso significa que dentro de tres años, su evento de aplicación de parches probablemente se convierta en un evento de cambio de código, no en un evento de actualización de yum. Entendido, déjenlo entender. Desarrolladores, recibirán un aviso a las 2 a. m. si el equipo de seguridad no puede encontrar un hack de firewall para bloquear el exploit.
Construir a partir de una imagen base no es perfecto; hay desventajas, como el tamaño de todas las dependencias que se arrastran. Esto casi siempre hará que las imágenes de su contenedor sean más grandes que construir desde cero. Otra desventaja es que no siempre tendrá acceso al último código ascendente. Esto puede ser frustrante para los desarrolladores, especialmente cuando solo quiere obtener algo, pero no tan frustrante como que lo llamen para ver una biblioteca en la que no ha pensado en tres años que los mantenedores ascendentes han estado cambiando todo el tiempo. .
Si eres un desarrollador web y me miras con desdén, tengo una palabra para ti:DevOps. Eso significa que llevas un localizador, amigo mío.
Construir desde cero
Las construcciones Scratch tienen la ventaja de ser realmente pequeñas. Cuando no confía en una distribución de Linux en el contenedor, tiene mucho control, lo que significa que puede personalizar todo según sus necesidades. Este es el mejor modelo de su clase y es válido en ciertos casos de uso. Otra ventaja es que tienes acceso a los últimos paquetes. No tiene que esperar a que una distribución de Linux actualice nada. Usted tiene el control, por lo que elige cuándo pasar el trabajo de ingeniería para incorporar nuevo software.
Recuerde, hay un costo para controlar todo. A menudo, la actualización a nuevas bibliotecas con nuevas funciones arrastra cambios de API no deseados, lo que significa corregir las incompatibilidades en el código (en otras palabras, eliminar errores). Afeitar yaks a las 2 AM cuando la aplicación no funciona no es divertido. Afortunadamente, con los contenedores, puede retroceder y afeitarse los yaks al siguiente día hábil, pero aún consumirá su tiempo para brindar un nuevo valor al negocio, nuevas características a sus aplicaciones. Bienvenido a la vida de un administrador de sistemas.
Bien, dicho esto, hay veces que construir desde cero tiene sentido. Reconozco completamente que los programas Golang compilados estáticamente y los programas C son dos candidatos decentes para construcciones scratch/distroless. Con este tipo de programas, cada compilación de contenedor es un evento de compilación. Todavía tiene que preocuparse por la ruptura de la API dentro de tres años, pero si es una tienda de Golang, debe tener el conjunto de habilidades para arreglar las cosas con el tiempo.
Conclusión
Básicamente, las distribuciones de Linux hacen mucho trabajo para ahorrarle tiempo, en un sistema Linux normal o con contenedores. El conocimiento que tienen los mantenedores es tremendo y se aprovecha mucho sin ser realmente apreciado. La adopción de contenedores ha empeorado aún más el problema porque se abstrae aún más.
Con hosts de contenedores, una distribución de Linux le ofrece acceso a un amplio ecosistema de hardware, que va desde pequeños sistemas ARM hasta cajas gigantes de 128 CPU x86 y máquinas virtuales de proveedores de la nube. Ofrecen motores de contenedores en funcionamiento y tiempos de ejecución de contenedores listos para usar, por lo que puede encender sus contenedores y dejar que otra persona se preocupe por hacer que las cosas funcionen.
Para imágenes de contenedores, las distribuciones de Linux le ofrecen fácil acceso a una tonelada de software para sus proyectos. Incluso cuando construyas desde cero, es probable que veas cómo un mantenedor de paquetes construyó y envió cosas (un buen artista es un buen ladrón), así que no subestimes este trabajo.
Entonces, gracias a todos los mantenedores de Fedora, RHEL (Frantisek, eres mi héroe), Debian, Gentoo y todas las demás distribuciones de Linux. Aprecio el trabajo que haces, a pesar de que soy un "chico de contenedores".