¿Cómo debe un departamento de TI elegir una distribución estándar de Linux?

Existe una gran sensación de comunidad acerca de qué distribuciones de Linux son apropiadas para entornos de servidores de producción y cuáles no lo son, sin embargo, muchas de estas sensaciones parecen basadas en la religión y rara vez se presentan con evidencia de apoyo.

Suponiendo que estábamos tratando de seleccionar una distribución de Linux para estandarizar (porque tenemos interés en mantener nuestros entornos lo más homogéneos posible), ¿qué criterios son importantes y cómo hace determinaciones sobre qué tan bien las distribuciones diferentes cumplen esos criterios?

Actualmente trabajo en un entorno que ha usado Linux durante más de una década. Todos en la oficina usan diferentes distribuciones en sus escritorios, así como en los servidores. Como tal, las opciones de distribución tienden a girar en torno a varias cosas sin un orden particular:

1. Historia : obviamente, los sistemas como RedHat y Debian han existido durante mucho tiempo. Como tal, se puede usar el dicho "si no está roto, no lo arregles". La actualización se vuelve más fácil si el software es compatible con una distribución.
2. Familiaridad : similar a la historia, sin embargo, todos tenemos nuestros favoritos. Me corté los dientes en Debian y migré a Ubuntu (una decisión difícil en ese momento porque tiendo a comprometerme con una comunidad). Por el contrario, es doloroso tener que recordar cómo hacer las cosas en una docena de distribuciones diferentes (sin mencionar las que están hechas desde cero).
3. Soporte : migré a Ubuntu principalmente porque aprecié lo que estaban haciendo en cuanto a ofrecer soporte pagado. Ese era un punto de venta si alguna vez un cliente tenía una preocupación por ejecutar un sistema a largo plazo. Similar al enfoque de RedHat (pero el infierno de RPM estaba sucediendo en ese momento). Tenemos una serie de servidores RedHat por este motivo también.
4. Dependencias : algunos softwares son más fáciles de usar en algunas distribuciones simplemente porque los paquetes dependientes son más fáciles de obtener o construir. Como ejemplo de esto sería oVirt en RedHat. No hay paquetes para algunos softwares en algunas distribuciones. Y podría compilarlo, pero ¿por qué lo haría si el paquete estuviera allí en otra distribución?
5. Granularidad : las distribuciones como Gentoo ofrecen un control más preciso sobre el control de versiones y la granularidad de cambio de software. Otras distribuciones tienen "fijación" en varias formas, pero todavía no es tan controlable o confiable.
6. Enlace : aunque es posible compilar desde la fuente en la mayoría de las distribuciones, algunas distribuciones son mejores que otras. Esto puede tener un efecto, por ejemplo, si su proyecto parchea las bibliotecas existentes para una funcionalidad extendida.
7. Bondad : algunas distribuciones son más atractivas. Todos los geek saben que es solo una pelusa (y probablemente podría salirse con la suya como una aplicación web en estos días), pero algunos clientes están impresionados por estas cosas, y todos lo sabemos.
8. Estabilidad : algunas distribuciones transmiten versiones "estables" de software en lugar de "pruebas", "experimentales", etc. Esto puede significar mucho si sabe que la versión sobre la que está construyendo finalmente alcanzará un consenso sobre la estabilidad. Puede desarrollarse en "experimental" sabiendo que para cuando su proyecto esté terminado, habrá alcanzado "estable" y será bueno confiar en él.
9. Administración de paquetes : si está desarrollando algo a diario y va a llegar a miles de máquinas de una sola vez, entonces probablemente desee algo que facilite la construcción, el mantenimiento y el seguimiento de paquetes en esos sistemas.
10. Consistencia : este es más un argumento para la misma distribución. Se cometen menos errores (y menos errores de seguridad) cuando las personas pueden centrarse en una distribución en lugar de en varias.
11. Programa de lanzamiento predecible : si desea asegurarse de que su software siga siendo compatible, las actualizaciones planificadas ofrecen un cierto tipo de estabilidad.
12. Seguridad : algunas distribuciones tienen equipos de seguridad activos cuyo trabajo es responder de inmediato a los riesgos de seguridad genuinos en cualquier paquete aprobado.

Esas son solo algunas de las cosas que se me ocurren con respecto a las razones por las que se eligió cada sistema. No veo ninguna luz guía o preferencia de una distribución sobre otra en esta decisión. La diversidad y la elección pueden ser excelentes y ofrecerle algunas opciones realmente buenas para comenzar un proyecto rápidamente, pero también es la soga que puede colgarlo. Asegúrese de pensar antes de lo que va a necesitar. Planifique cuáles son las necesidades del sistema y cuándo se va a actualizar o retirar el sistema. No asumas que siempre serás tú quien lo mantenga.

Compartiré mis experiencias trabajando como tecnólogo en diferentes campos ...

(Precaución: esta es una historia sobre Red Hat y cómo crecí profesionalmente con ella)

Comencé a trabajar con Linux profesionalmente en 2000-2002. Esto fue durante la amplia adopción de Red Hat y Red Hat Professional Editions (6.x, 7.x, 8.0) . Estos estaban disponibles para descarga gratuita, así como conjuntos empaquetados en caja. Podrían encontrarse fácilmente en tiendas de informática.

Para mí, esto tenía el beneficio de involucrar a los aficionados y usuarios domésticos con el mismo producto que comenzaba a surgir en la empresa. Mi trabajo en este momento era trasladar los sistemas de servidor de los clientes de Unices comerciales (HP-UX, AIX y SCO) a la plataforma Red Hat.

¡El ahorro de costos fue sustancial! Reemplazar los servidores PA-RISC HP9000 + $ 100k + con los servidores Intel ProLiant de Compaq de $ 40k fue una ganancia absoluta en costo y rendimiento.

Entonces, ¿por qué Red Hat?

Red Hat fue el primero en este mercado, obteniendo soporte crítico de negocios, proveedores y hardware. Al ver que los grandes proveedores de aplicaciones usan Red Hat como plataforma objetivo se cerró el trato. Los usuarios aficionados como yo pudimos transferir las habilidades perfeccionadas en casa a nuestros entornos de trabajo con facilidad. La comunidad estaba creciendo. ¡Las pilas Slashdot , Freshmeat y LAMP gobernaron! Fue un buen momento para Linux.

En este punto, era responsable del desarrollo y evaluación de las distribuciones de Linux como plataforma para una solución de software ERP patentada. Me quedé con Red Hat. De vez en cuando, intentaba otra distribución ( Mandrake , SuSE , Debian , Gentoo ), pero encontraba problemas con el empaquetado, el soporte de hardware (servidores o periféricos), la comunidad (tamaño de la) o algún otro factor decisivo.

Un ejemplo: estaba usando hardware Compaq / HP ProLiant equipado con tarjetas de expansión PCI-X Digi Serial y software de fax de producción Esker VSIfax . Los dos últimos solo tenían soporte de controladores para los sistemas operativos Red Hat. En algunos casos, el software solo se entregó en formato binario o RPM, lo que impide su fácil uso en otras variantes de Linux.

El ímpetu es importante en el mundo de la tecnología de la información
Nadie quiere ser uno que recomiende la solución o el proyecto perdedor que eventualmente queda huérfano, por lo que debe elegir opciones seguras. Estaba administrando una pila de tecnología que necesitaba funcionar de manera confiable y tener varias capas de soporte. Elegir una distribución diferente en ese punto tendría justo. estado. irresponsable.

La luna de miel de Red Hat terminó para mí en 2003 con la interrupción de las ediciones profesionales del software. Red Hat Enterprise Linux fue el reemplazo y vino con bastante equipaje ... Costo (modelo costoso basado en suscripción), accesibilidad (reducción de la base de usuarios y la comunidad) y confusión general sobre el futuro ...

Comencé a buscar alternativas, reevaluando Gentoo, Debian y SuSE. No pude obtener el soporte adecuado en todos los componentes de nuestra pila de tecnología. Me vi obligado a seguir con el ecosistema de Red Hat ... Debido al enorme cambio de costos asociado con Red Hat Enterprise Linux, terminé ejecutando un Red Hat 8.0 altamente modificado durante años después de su fin de vida. No fue hasta que los clones de RHEL maduraron ( Whitebox Linux , y más tarde, CentOS ) que preparé un cambio real lejos de mi estándar.

La principal ventaja de los derivados de Red Hat fue y es la compatibilidad binaria con las versiones RHEL pagas. Incluso es posible realizar conversiones en el lugar entre RHEL y CentOS, y viceversa. Continué trabajando con sistemas similares a RHEL hasta que hice el siguiente movimiento profesional ...

Más tarde me encontré en la industria de comercio financiero de alta frecuencia , donde fui responsable de la ingeniería de I + D y Linux para sistemas críticos de comercio automatizado. El énfasis en este mundo era la velocidad , mediante pruebas y ajustes cuidadosos. Nuevamente, el soporte de hardware fue clave. Tendría tarjetas de red específicas , hardware especializado, hardware de servidor o bibliotecas de aplicaciones que solo fueron certificadas para RHEL o sistemas similares a RHEL. Incluso en los casos en que las cosas podrían compilarse para otras variantes de Linux, surgió el factor de la comunidad. Cuando estaba en el punto en que necesitaba investigar un problema, a menudo era un problema que podía rastrearse en notas o comentarios en los informes de Red Hat Bugzilla, o, a veces, simplemente enviaba un parche o una solicitud para el próximo lanzamiento .

Cuando comencé a profundizar en las redes de baja latencia y el ajuste del kernel, comencé a diseccionar los kernels RHEL y los kernels RHEL MRG Realtime . Me di cuenta de cuánto trabajo en las versiones ... más de 200 parches para un kernel vanilla kernel.org. Lea los comentarios y las notas de compromiso. Puede tener cosas pequeñas como sysctlparámetros expuestos o aplicar valores predeterminados más sanos. Red Hat le paga a la gente para parchear, probar y solucionar estos problemas. No vi el mismo compromiso de otras distribuciones de Linux ... Agregue el hecho de que la plataforma empresarial tiene garantizada seguridad real, corrección de errores y soporte de backport durante años .

Así que finalmente me mudé a otra firma financiera que era casi todo Gentoo en el servidor y el escritorio ... Fue un desastre para mí. Viniendo del mundo de Red Hat y CentOS, encontré numerosos problemas de estabilidad y administración con la configuración de Gentoo. El control de versiones era el mayor problema, pero la disminución del apoyo de la comunidad y la falta de pruebas reales también eran preocupaciones. Comencé a introducir RHEL en el entorno porque algunos de nuestros software de terceros lo requerían ...

Pero había un problema ... Mis desarrolladores estaban acostumbrados a Gentoo y tenían rutas de actualizaciones relativamente fáciles para bibliotecas centrales y versiones de aplicaciones. No pudieron ajustarse a tener las versiones principales fijas que Red Hat Enterprise Linux estandariza. El proceso de desarrollo y lanzamiento estuvo plagado de preguntas sobre por qué GLIBC 2.7 no pudo ser injertado en RHEL 5.xo por qué cierto compilador o versión de biblioteca no estaba disponible. Cuando se les dijo que las actualizaciones entre las principales versiones de RHEL / CentOS esencialmente requerían reconstrucciones completas , perdieron mucha confianza en la solución.

En este punto, me di cuenta de que Red Hat se movía demasiado lento para los desarrolladores que querían estar a la vanguardia. RHEL 6.x fue una actualización muy necesaria y bienvenida, pero este tema se hizo más evidente una vez que comencé a entrevistar a nuevas empresas y empresas que se suscribieron a los principios de DevOps .

Hoy ...
Un número creciente de desarrolladores y usuarios de Linux provienen de entornos Linux que no son Red Hat, SuSE ni Enterprise.

• Están usando Ubuntu o Debian ...
• No tenían que lidiar con el hardware de la vieja escuela o el soporte de grandes proveedores.
• Están escribiendo sus propias aplicaciones desde cero (autosuficientes).
• La virtualización y la computación en la nube abstraen la capa de hardware, por lo que las preocupaciones sobre los controladores de controlador RAID originales, los periféricos PCI-X o los agentes de administración distribuidos en binario ni siquiera están en el radar.
• Estos usuarios quieren las herramientas y la tierra de usuarios a la que están acostumbrados.

Entonces hay un conflicto ... Estos usuarios no entienden por qué estarían restringidos en las versiones de la aplicación o la biblioteca. Los administradores de la vieja escuela todavía se están adaptando al nuevo paradigma . Los argumentos que parecen estar enraizados en la religión son realmente funciones de cómo las personas desarrollaron sus respectivos conjuntos de habilidades.

Hoy vi un anuncio de trabajo para un puesto de ingeniero de DevOps Linux muy antiguo que decía:

Debe ser hábil a experto en distribuciones de Linux basadas en Debian (Ubuntu y variantes están bien. Red Hat es aceptable , pero no preferido)

Así que supongo que funciona en ambos sentidos ... Me alejé de las oportunidades de trabajo porque los 800 servidores CentOS que administraría estaban programados para convertirse a Ubuntu. Claro, Linux es Linux ... pero no sentí que sería tan efectivo como podría ser ... Me equivoqué con las instalaciones de Debian y deseé que se utilizara una distribución basada en RPM. He tenido los acalorados argumentos sobre los méritos de varias plataformas (generalmente colocando a Gentoo al final de la lista).

Entonces, ¿qué es lo correcto para SU entorno? Depende. He estado en empresas donde los ingenieros de sistemas manejan decisiones, así como en organizaciones donde los desarrolladores son los reyes. Creo que el mejor arreglo es cuando los desarrolladores y las personas que respaldan los sistemas acuerdan la plataforma. Pero aparte de eso, piense en el soporte a largo plazo, la usabilidad, la comunidad y lo que acomoda su pila de aplicaciones de la manera más adecuada.

Un desarrollador talentoso debería poder trabajar en un entorno similar a RHEL o Debian. Y bueno, las plataformas de desarrollo deberían reflejar el entorno de producción. Vas desde allí ...