Como um departamento de TI deve escolher uma distribuição Linux padrão?

Há muita opinião da comunidade sobre quais distribuições Linux são apropriadas para ambientes de servidor de produção e que não são, no entanto, muito desse sentimento parece religioso e raramente apresenta evidências de apoio.

Supondo que estivéssemos tentando selecionar uma distribuição Linux para padronizar (porque temos interesse em manter nossos ambientes o mais homogêneos possível), quais critérios são importantes e como você determina se as diferentes distribuições atendem a esses critérios?

Atualmente, trabalho em um ambiente que usa o Linux há mais de uma década. Todo mundo no escritório usa distribuições diferentes em seus desktops e nos servidores. Como tal, as opções de distribuição tendem a girar em torno de várias coisas em nenhuma ordem específica:

1. História - Obviamente, sistemas como RedHat e Debian já existem há muito tempo. Como tal, o ditado "se não está quebrado, não conserte" pode ser usado para isso. A atualização se torna mais fácil se o software for bem suportado em uma distribuição.
2. Familiaridade - Semelhante à História, porém todos temos nossos favoritos. Eu cortei meus dentes no Debian e migrei para o Ubuntu (uma decisão difícil na época, porque tenho a tendência de me comprometer com uma comunidade). Por outro lado, é uma dor ter que se lembrar de como fazer as coisas em uma dúzia de distribuições diferentes (para não mencionar as construídas por arranhões).
3. Suporte - Migrei para o Ubuntu principalmente porque apreciei o que eles estavam fazendo no que diz respeito a oferecer suporte pago. Esse era um ponto de venda se um cliente tivesse alguma preocupação em executar um sistema a longo prazo. Semelhante à abordagem do RedHat (mas o RPM estava acontecendo na época). Também temos vários servidores RedHat por esse motivo.
4. Dependências - Alguns softwares são mais fáceis de usar em algumas distros simplesmente porque os pacotes dependentes são mais facilmente obtidos ou montáveis. Como exemplo disso seria oVirt no RedHat. Não há pacotes para alguns softwares em algumas distros. E você poderia compilá-lo, mas por que você faria se o pacote estivesse ali em outra distribuição?
5. Granularidade - Distros como o Gentoo oferecem controle mais refinado sobre versão e granularidade de troca de software. Outras distribuições têm "fixação" de várias formas, mas isso ainda não é tão controlável ou confiável.
6. Vinculação - Embora seja possível compilar a partir do código-fonte na maioria das distribuições, algumas são melhores do que outras. Isso pode ter efeito, por exemplo, se o seu projeto corrigir as bibliotecas existentes para funcionalidade estendida.
7. Beleza - Algumas distribuições são mais bonitas . Todo geek sabe que é apenas fofo (e você provavelmente poderia fazer isso como um aplicativo da web hoje em dia), mas alguns clientes ficam impressionados com isso, e todos nós sabemos disso.
8. Estabilidade - Algumas distros transmitem versões "estáveis" de software, em oposição a "testing", "experimental" etc. etc. Isso pode significar muito se você souber que a versão em que está construindo acabará por chegar a um consenso sobre estabilidade. Você pode desenvolver "experimental" sabendo que, quando o projeto terminar, ele alcançará "estável" e será bom confiar nele.
9. Gerenciamento de pacotes - Se você estiver desenvolvendo algo diariamente, e ele vai chegar a milhares de máquinas em uma ocorrência, provavelmente você desejará algo que facilite a construção, manutenção e rastreamento de pacotes nesses sistemas.
10. Consistência - Este é mais um argumento para a mesma distribuição. Menos erros são cometidos (e menos erros de segurança) quando as pessoas podem se concentrar em uma distribuição, em oposição a várias.
11. Agenda de liberação previsível - Se você quiser ter certeza de que seu software permanece suportado, as atualizações planejadas oferecem um certo tipo de estabilidade.
12. Segurança - Algumas distros têm equipes de segurança ativas cuja tarefa é responder imediatamente a riscos de segurança genuínos em qualquer pacote aprovado.

Essas são apenas algumas coisas que surgem da minha cabeça em relação às razões pelas quais cada sistema foi escolhido. Não vejo nenhuma luz orientadora ou preferência de uma distribuição sobre outra nesta decisão. Diversidade e escolha podem ser ótimas e oferecer algumas opções realmente boas para iniciar um projeto rapidamente, mas também é o laço que pode pendurá-lo. Lembre-se de pensar antes do que você precisará. Planeje quais são as necessidades do sistema e quando ele será atualizado ou desativado. Não assuma que você sempre será quem o manterá.

Vou compartilhar minhas experiências trabalhando como tecnólogo em algumas áreas diferentes ...

(Cuidado: esta é uma história sobre a Red Hat e como eu cresci profissionalmente com ela)

Comecei a trabalhar com o Linux profissionalmente em 2000-2002. Isso ocorreu durante a ampla adoção do Red Hat e do Red Hat Professional Editions (6.x, 7.x, 8.0) . Eles estavam disponíveis para download gratuito, além de conjuntos embalados em caixa. Eles poderiam ser facilmente encontrados em lojas de informática.

Para mim, isso teve o benefício de envolver usuários amadores e domésticos com o mesmo produto que estava começando a surgir na empresa. Meu trabalho naquele momento foi transferir sistemas de servidores de clientes dos Unices comerciais (HP-UX, AIX e SCO) para a plataforma Red Hat.

A economia de custos foi substancial! A substituição de servidores HP9000 PA-RISC de US $ 100.000 + por servidores Intel Compaq ProLiant de US $ 40.000 foi uma vitória absoluta em custo e desempenho.

Então, por que a Red Hat?

A Red Hat foi a primeira desse mercado, obtendo suporte crítico a negócios, fornecedores e hardware. Ver grandes fornecedores de aplicativos usarem a Red Hat como plataforma de destino selou o acordo. Usuários de hobby como eu foram capazes de transferir as habilidades aprimoradas em casa para nossos ambientes de trabalho com facilidade. A comunidade estava crescendo. Pilhas de Slashdot , Freshmeat e LAMP são dominadas! Foi um bom momento para o Linux.

Nesse ponto, eu era responsável pelo desenvolvimento e avaliação das distribuições Linux como uma plataforma para uma solução de software ERP proprietária. Eu fiquei com o Red Hat. De vez em quando, eu tentava outra distribuição ( Mandrake , SuSE , Debian , Gentoo ), mas encontrava problemas com empacotamento, suporte de hardware (servidores ou periféricos), comunidade (tamanho da) comunidade ou algum outro negócio.

Um exemplo: eu estava usando o hardware Compaq / HP ProLiant equipado com placas PCI-X de expansão Digi Serial e software de fax de produção Esker VSIfax . Os dois últimos só tinham suporte de driver para os sistemas operacionais Red Hat. Em alguns casos, o software foi entregue apenas em formato binário ou RPM, impedindo o uso fácil em outras variantes do Linux.

Momento importante no mundo da tecnologia da informação
Ninguém quer ser aquele que recomenda a solução ou o projeto perdedor que, eventualmente, fica órfão, para que você fique com escolhas seguras. Eu estava gerenciando uma pilha de tecnologia que precisava funcionar de maneira confiável e ter várias camadas de suporte. Escolher uma distribuição diferente naquele momento teria justificado. fui. irresponsável.

A lua de mel da Red Hat terminou para mim em 2003 com a descontinuação das edições profissionais do software. O Red Hat Enterprise Linux foi o substituto e veio com um pouco de bagagem ... Custo (modelo caro baseado em assinatura), acessibilidade (encolhendo a base de usuários e a comunidade) e confusão geral sobre o futuro ...

Comecei a procurar alternativas, reavaliando o Gentoo, Debian e SuSE. Não consegui o suporte certo para todos os componentes da nossa pilha de tecnologia. Fui forçado a permanecer no ecossistema da Red Hat ... Devido à grande mudança de custo associada ao Red Hat Enterprise Linux, acabei executando um Red Hat 8.0 altamente modificado nos últimos anos de seu fim de vida. Não foi até os clones do RHEL amadurecerem ( Whitebox Linux e, mais tarde, CentOS ) que eu preparei uma mudança real do meu padrão.

A principal vantagem dos derivados da Red Hat era e é a compatibilidade binária com as versões RHEL pagas. É ainda possível realizar conversões no local entre RHEL e CentOS e vice-versa. Continuei trabalhando com sistemas do tipo RHEL até fazer a próxima carreira ...

Mais tarde, me encontrei no setor de negociação financeira de alta frequência , onde era responsável pela engenharia de P&D e Linux para sistemas críticos de negociação automatizada. A ênfase neste mundo foi a velocidade , por meio de testes e ajustes cuidadosos. Mais uma vez, o suporte ao hardware foi fundamental. Eu teria placas de rede específicas , hardware especializado, hardware de servidor ou bibliotecas de aplicativos que foram certificadas apenas para sistemas RHEL ou do tipo RHEL. Mesmo nos casos em que as coisas poderiam ser compiladas para outras variantes do Linux, o fator comunidade surgiu. Quando eu estava no ponto em que precisava pesquisar um problema, muitas vezes havia um problema que podia ser atribuído a notas ou comentários nos relatórios do Red Hat Bugzilla ou, às vezes, eu simplesmente enviava um patch ou solicitava a próxima versão .

Quando comecei a me aprofundar nas redes de baixa latência e no ajuste do kernel, comecei a dissecar os kernels RHEL padrão e os kernel do RHEL MRG Realtime . Percebi quanto trabalho havia nos lançamentos ... Mais de 200 patches para um kernel do vanilla kernel.org. Leia os comentários e envie notas. Você pode ter pequenas coisas como sysctlparâmetros expostos ou padrões mais saudáveis ​​aplicados. A Red Hat paga às pessoas para corrigir, testar e corrigir esses problemas. Eu não vi o mesmo compromisso de outras distribuições Linux ... Acrescente o fato de que a plataforma corporativa tem garantia de segurança real, correção de bugs e suporte de backport por anos .

Por fim, mudei-me para outra empresa financeira que era quase toda Gentoo no servidor e desktop ... Foi um desastre para mim. Vindo do mundo Red Hat e CentOS, encontrei vários problemas de estabilidade e gerenciamento com a configuração do Gentoo. O controle de versão foi o maior problema, mas o encolhimento do suporte da comunidade e a falta de testes reais também foram preocupações. Comecei a introduzir o RHEL no ambiente porque alguns de nossos softwares de terceiros exigiam isso ...

Mas havia um problema ... Meus desenvolvedores estavam acostumados ao Gentoo e tinham caminhos de atualizações relativamente fáceis para bibliotecas principais e versões de aplicativos. Eles não podiam se ajustar a ter as principais versões fixas nas quais o Red Hat Enterprise Linux padroniza. O processo de desenvolvimento e liberação foi atormentado por perguntas sobre por que o GLIBC 2.7 não pôde ser enxertado no RHEL 5.x ou por que uma determinada versão do compilador ou da biblioteca não estava disponível. Quando informados de que as atualizações entre as principais versões do RHEL / CentOS exigiam essencialmente reconstruções completas , eles perderam muita confiança na solução.

Nesse ponto, percebi que a Red Hat estava se movendo muito devagar para os desenvolvedores que queriam estar na vanguarda / na vanguarda. O RHEL 6.x foi uma atualização muito necessária e bem-vinda, mas esse tema se tornou mais evidente quando comecei a entrevistar startups e empresas que aderiram aos princípios do DevOps .

Hoje ...
Um número crescente de desenvolvedores e usuários de Linux vem de ambientes Linux não Red Hat, não SuSE e não corporativos.

• Eles estão usando Ubuntu ou Debian ...
• Eles não precisavam lidar com hardware antigo ou com o suporte de grandes fornecedores.
• Eles estão escrevendo seus próprios aplicativos desde o início (autossustentados).
• A virtualização e a computação em nuvem abstraem a camada de hardware; portanto, as preocupações com drivers de controladores RAID, periféricos PCI-X ou agentes de gerenciamento distribuídos por binários não estão no radar.
• Esses usuários desejam as ferramentas e a terra do usuário às quais estão acostumados.

Portanto, há um conflito ... Esses usuários não entendem por que eles seriam restritos às versões de aplicativos ou bibliotecas. Os administradores da velha escola ainda estão se adaptando ao novo paradigma . Argumentos que parecem estar enraizados na religião são realmente apenas funções de como as pessoas desenvolveram suas respectivas habilidades.

Hoje vi um anúncio de emprego para uma posição de engenheiro do DevOps Linux muito antiga que dizia:

Deve ser especialista em distribuições Linux baseadas no Debian (Ubuntu e variantes são aceitáveis . Red Hat aceitável , mas não preferido)

Então, acho que funciona nos dois sentidos ... Afastei-me das oportunidades de emprego porque os servidores de 800 CentOS que eu gerenciava estavam programados para serem convertidos no Ubuntu. Claro, Linux é Linux ... mas eu não achava que seria tão eficaz quanto eu poderia ... Eu me atrapalhei com as instalações do Debian e desejei que uma distribuição baseada em RPM estivesse em uso. Eu tive discussões acaloradas sobre os méritos de várias plataformas (geralmente colocando o Gentoo no final da lista).

Então, o que é certo para o SEU ambiente? Depende. Estive em empresas nas quais os engenheiros de sistemas conduzem decisões, bem como em organizações onde os desenvolvedores são os principais. Eu acho que o melhor arranjo é quando os desenvolvedores e as pessoas que suportam os sistemas concordam com a plataforma. Mas fora disso, pense em suporte de longo prazo, usabilidade, comunidade e o que acomoda sua pilha de aplicativos da maneira mais apropriada.

Um desenvolvedor talentoso deve poder trabalhar em um ambiente semelhante ao RHEL ou ao Debian. E bem, as plataformas de desenvolvimento devem refletir o ambiente de produção. Você vai de lá ...