gutocarvalho.net

cotidiano simples, vida feliz

mantenha suas configurações nos trilhos

By

Manutenção Manual

1. Vivendo a rotina das configurações manuais

Esse tipo de administração tem em suas principais características tarefas que executamos de forma repetida, veja, estamos sempre executando tarefas para configurar novos hosts, criar usuários, modificar contas de usuários, gerenciar aplicações, serviços e daemons, e como fazemos isto várias vezes por dia,  sem um controle mais refinado ou revisão destas mudanças, sejam para atender uma demanda, sejam para corrigir um problema, a chance de cometermos erros são evidentes.

A maioria das organizações e empresas de TI trabalha com a administração de configurações através de procedimentos manuais, em alguns casos encontramos o uso de scripts personalizados (shellscripts), em outros casos encontramos o uso de imagens pré-configuradas de sistemas operacionais (ISOS), práticas que podemos observar com certa facilidade em muitos lugares.

A administração manual até funciona em pequenos ambientes, com uma equipe reduzida, mas quando nosso ambiente começa a crescer, quando começamos a trabalhar com equipes multidisciplinares, estes procedimentos tendem a não funcionar muito bem, criando uma sobrecarga em sua equipe.

A medida que o  ambiente começa a crescer, você vai perceber que fica mais difícil administrá-lo de forma manual, os scripts começam a crescer e se tornar complexos, instáveis e manté-los se torna bem cansativo, as imagens de sistemas operaconais já não são suficientes pois são necessárias vários tipos diferentes de imagens – distros diferentes – e as configurações destas precisam mudar com frequência para atender as novas demandas, projetos e necessidades.

Em alguma momento sua equipe de sysadmins vai perceber que as técnicas que antes os ajudavam e agilizavam a resolução de demandas  não funcionam mais a medida que novos servidores são criados.

Podemos dizer que a administração manual não escala, e além de não escalar gera uma grande sobrecarregam em cima de alguns ou de todos os membros d esua equipe, isto tende a aumentar o custo necessário para manter seu ambiente,  afinal sobrecarga significa hora extra de noite, madrugada, finais de semana e feriados, com isto você será forçado a ampliar sua equipe de sysadmins para dar conta das tarefas – tentando cumprir as metas.

Observe que quando uma metodologia ou técnica de administração de configuração não é escalável, você começa a perceber algumas coisas, dentre elas:

  • Você percebe que fica mais difícil encontrar problemas em seu parque;
  • Você percebe que não é tão simples assim manter os sistemas funcionando de forma orquestrada;
  • Você percebe que é quase impossível manter todos os seus sistemas operacionais padronizados;
  • Você percebe que sua produtividade diminui a medida que o ambiente cresce;
  • Você percebe que sua capacidade de responder a incidentes e resolver problemas já não é mais a mesma;

Se você já está percebendo tudo isto, você tem um problema. Talvez seja uma boa hora para pensar em mudanças, mas mudar não é fácil, você precisa estar disposto a mudar. Se estiver disposto, certamente duas perguntas vão surgir na superfície de sua mente, são elas:

  • Quais seriam estas mudanças?
  • Quais as técnicas, metodologias ou tecnologias que podem me ajudar?

Este post vai lhe dar uma ajuda para encontrar as respostas para estas duas perguntas, mas para entender a solução, primeiro precisamos entender de forma clara os problemas que vem com a administração manual, acompanhe o desenvolvimento da questão padronização logo abaixo.

1.1 Padronização de ambientes

Para entender melhor e aprofundar a questão da padronização que menciono acima, vamos abordar alguns exemplos. Aqui vou focar em ambiente linux, e neste caso, não ter um parque padronizado significa que você não tem como garantir que as configurações fundamentais estão devidamente ajustadas em todos os servidores, tais como:

  • Configurações de DNS, rota e hosts em todos as VMs e PMs;
  • Configurações referentes a usuários e privilégios (passwd/group/shadow/sudo);
  • Configuração padrão de repositórios (yum/apt);
  • Configuração para (auto)update de pacotes;
  • Conjunto de pacotes de monitoramento;
  • Conjunto de pacotes do sysadmin (htop,ccze,less,mtr,traceroute,nmap,vim,iptraf,iperf,etc…);
  • Configurações de editores padrão do sistema (VIM/NANO/EMACS);
  • Configurações de variáveis e de ambientes de usuários (.bashrc, .bash_profile);
  • Configurações de variáveis e de ambientes – global (profile, bashrc);
  • Configurações de DATA/HORA (NTPd/NTPDATE);
  • Configurações de MTA Local e Aliases (envio de mensagens de erros para algum lugar);
  • Configurações de rotinas no CRON;
  • Configurações de LOGROTATE;
  • Configurações de SYSLOG/RSYSLOG;
  • Tuning de Kernel (sysctl);
  • Hardening do OS;

Algumas coisas não parecem tão sérias, mas vamos entender o que elas podem afetar:

  • Se sua data/hora estão erradas, isto pode gerar uma parada de alguns sistemas ou mesmo arruinar uma tentativa de auditoria nos logs de um servidor.
  • Um DNS errado pode afetar o funcionamento de um sistema e dos serviços que dependem da resolução de DNS;
  • Um repositório mal configurado pode instalar pacotes não homologados, isto pode afetar aplicações rodando;
  • Um logrotate mal configurado pode fazer seu disco encher rapidamente e causar um incidente parando seus sistemas e serviços;

E por ai vai, veja que a falta de um ambiente padronizado pode ser uma grande dor de cabeça para sua equipe, e normalmente por negligência ou sobrecarga, é comum ter servidores padronizados e outros não.

1.2 Contas de usuários

Talvez um dos problema mais básicos que afligem sysadmins que administram grandes parques seja a gestão de contas nestes servidores. Imagine que você tenha um parque com 450 Servidores, agora vamos supor que no início a semana sua equipe recebe um novo administrador de sistemas.

Pense no trabalho que você vai ter para criar o usuário do novo colaborador em todos os servidores do parque, para isto você precisa fazer o seguinte:

  1. Acessar um servidor
  2. Se tornar root
  3. Criar o usuário
  4. Setar senha temporária
  5. Setar privilégios no SUDO

São necessários 2250 ações para criar o usuário em 450 servidores.

Se você gastar 3 minutos por servidor isso dá um total de 1350 minutos ou 22,5 horas de trabalho repetitivo.

E o novo sysadmin precisará acessar 450 servidores para trocar sua senha.

Isto é com certeza muito trabalho, e não acontece desta forma, o mais comum é criar o usuário do novo colaborador sob demanda, conforme os problemas e as necessidades que vão surgindo.

Outra coisa muito comum que encontramos em ambientes como este são contas de colaboradores que já saíram da empresa há muito tempo, estas contas além de existirem estão ativas – normalmente, algo que é um grave risco de segurança. Normalmente estas contas ainda existem pois da mesma forma que é difícil criar, é igualmente difícil e trabalhoso removê-las mesmo se formos usar um clusterssh ou programa similar.

A parte da troca de senhas cai no mesmo problema, as vezes as senhas dos syadmins são aquelas temporárias como “mudar123”, e uma troca de senha em 450 máquina é virtualmente inviável e desmotiva qualquer iniciativa ou voluntário para fazê-lo.

É claro que pode podemos configurar autenticação LDAP para os servidores LINUX, mas ainda assim você vai ter que configurar PAM/NSSWITCH/NSSLDAP em todos os 450 servidores. Mesmo que você tenha previsto esta configuração na IMAGEM padrão do servidor LINUX, se por ventura alguma configuração do LDAP muda, você terá cerca de 450 servidores para corrigir uma configuração de LDAP, sendo que as vezes só precisamos ajustar uma única linha.

E mesmo que usemos autenticação LDAP, caso este saia do ar, será sempre necessário ter um usuário coringa – local – para fazer a administração, nestes casos se for preciso trocar a senha deste usuário coringa, você passará pela mesma dor de cabeça.

Veja que é inviável e cansativo administrar contas de usuários desta forma.

1.3 Configuração dos Serviços

Outro processo comum é a configuração de serviços sejam eles LDAP, SAMBA, HTTP, MYSQL, PGSQL, FTP, SMTP, IMAP, POP, dentre outros.

Se pedirmos para 2 sysadmins instalarem qualquer um destes serviços, teremos procedimentos diferentes e será extramente difícil entender e rastrear como a demanda foi atendida, quais foram os pacotes instalados, quais foram as dependências, quais foram os arquivos criados, alterados, modificados, se há alguma rotina no cron, se há script no init, se o script está configurado em algum runlevel, se está tudo pronto para rodar em produção de forma segura.

E se formos replicar a instalação e configuração do serviço, teremos de copiar arquivos – normalmente fazendo um SCP/RSYNC – e isto vai nos gerar um terceiro – distinto – processo de instalação e configuração do mesmo serviço.

Veja que não há como garantir um padrão trabalhando deste jeito.

Logo podemos entender que configurar serviços desta forma resulta em:

  • Dificuldade para identificar como o serviço foi instalado;
  • Dificuldade para avaliar quais arquivos foram criados, modificado ou alterados;
  • Dificuldade para replicar a configuração para outra máquina;
  • Falta de padronização nas configurações do mesmo serviço em servidores diferentes em nosso parque;
  • Falta de documentação do processo de instalação e configuração do serviço;

Acredito que ninguém que ter este tipo de resultado. Agora vamos complicar um pouco mais, imagine que a equipe de monitoramento iniciou um projeto que visa substituir a ferramenta atual de monitoramento – NAGIOS, logo este projeto prevê a instalação do agente Zabbix em todos os 450 servidores do seu parque , sem  esquecer de remover o agente NAGIOS e as suas configurações.

O processo de instalação consiste em:

  1. Acessar o servidor
  2. Adicionar um repositório YUM Zabbix Local
  3. Atualizar indices do YUM
  4. Instalar o pacote zabbix-agent
  5. Remover o arquivo /etc/zabbix/zabbix_agent.conf
  6. Editar o arquivo /etc/zabbix/zabbix_agentd.conf
  7. Modificar o conteúdo do arquivo /etc/zabbix/zabbix_agentd.conf
  8. Reiniciar o processo zabbix-agent
  9. Remover o pacote nagios
  10. Remover os traços de arquivos de configuração do nagios no sistema

São 4500 ações que devem ser executadas em 450 servidores, levando em conta que você gaste 5 minutos por servidor, serão 2250 minutos ou 37.5 horas de trabalho repetitivo para terminar esta demanda.

Veja que você vai dedicar 37,5 horas de um sysadmin para uma tarefa repetitiva e cansativa, algo que inclusive poderá desmotivar o profissional que pode vir a querer sair da equipe antes da próxima demanda deste tipo.

Dá para perceber que é inviável – e até insano – implantar novas soluções em um parque grande desta forma.

Mas não é só isso, vamos avaliar também o quesito documentação.

1.4 Documentação das configurações

Esse aqui é o calcanhar de Aquiles de muitas organizações de TI. Eu mesmo já encontrei parques imensos com quase nada documentado, podemos chamar isto de ambiente caótico. No caso de estar trabalhando em ambiente deste tipo, você vai ter que  estudar o serviço, os arquivos de configuração e mapear todo o ambiente afim de entender como tudo funciona, só assim poderá planejar e executar algum tipo de manutenção, e de início já sabemos que isto vai levar muito tempo.

Antes de mais nada vale lembrar que não existe implantação de projeto sem documentação, quem faz isso não sabe o que é um projeto e nem sabe o que está fazendo, mas isto eu deixo para falarmos em outro post.

Em resumo, é muito raro encontrar um sysadmin ou mesmo gestores de sysadmins que gostem ou que consigam compreender a importância de elaborar uma boa documentação, algo que reflita as configurações de seus sistemas ou serviços, os processos e procedimentos envolvidos em todo o ambiente produtivo. Sem documentação a qualidade do que é entregue e a qualidade do serviço que produziu esta entrega é sempre muito ruim, tenha certeza.

Sem documentação é muito difícil efetuar manutenção em um ambiente, sistema ou serviço, mas não se aflija, vamos ver logo mais mais que a Gestão de Configurações nos ajuda em alguns aspectos relacionados a documentação.

1.5 Entendendo e aceitando realidade

Podemos entender que se o ambiente é pequeno, se temos por exemplo 10 máquinas, é possível fazer o processo de configuração manualmente, mas se temos um parque com 450 máquinas, este processo de configuração, manutenção e documentação fica completamente inviável, com isto o que normalmente vamos encontrar é o caos completo e absoluto no parque de servidores.

Para fugir destes cenários caóticos, temos que buscar soluções ágeis e inteligentes para automatizar e centralizar a configuração de sistemas e serviços, além de adotar processos e documentar os procedimentos de instalação e configuração de forma objetiva.

Saiba que a gerência de configurações propõe soluções para estes problemas.

Colocando suas configurações no trilho

2. Entendendo a Gerência de Configurações

A gerência de configuração oferece um conjunto de recursos que visa garantir a integridade das configurações de nossos sistemas, serviços e infraestrutura envolvida, fazendo isto de forma ágil e automatizada.

Precisamos entender que a gerência de configuração é crítica para ambientes que estão crescendo ou que sejam de natureza complexa e heterogenia, é através dela que podemos trabalhar provisionamento, gerência de mudanças, gerência de configurações, deploy, documentação e muitas outras questões.

Hoje – na prática – conseguimos identificar que a maioria dos incidentes em um ambiente ocorrem pela falta de processos e procedimentos bem definidos, ou seja falha humana.

As vezes um sysadmin instala um pacote onde não devia ou mesmo remove um pacote que é dependência de outro, e por isso um terceiro pacote é removido parando por exemplo uma aplicação WEB – servidores linux.

Esse exemplo acima aconteceu em um dos clientes que presto consultoria há poucos dias, o cliente ainda não utilizava nenhuma ferramenta de gerência de configuração, portanto houve um incidente que afetou a produtividade e o SLA de várias equipes que dependiam do sistema de controle de tickets – o qual foi afetado pela remoção de pacotes –  para gerenciar suas demandas.

Se este cliente utilizasse alguma ferramenta de gerência de configurações, o pacote removido seria instalado novamente e os arquivos de configuração modificados seriam corrigidos voltando a versão correta, fazendo com que o ambiente voltasse a funcionar.

Temos certamente algumas vantagens ao trabalharmos com gerência de configuração, são elas:

  • Padronização do seu parque;
  • Distribuição centralizada das configurações;
  • Controle das configurações em seus servidores;
  • Rastreamento das mudanças em seus servidores;
  • Documentação instantânea a partir da construção das configurações;
  • Maior segurança e controle das aplicações em produção;
  • Facilidades para distribuir novas configurações para todo o parque de forma rápida;
  • Acelerar a criação de novos servidores;
  • Acelerar a configuração de novos serviços;

2.1 Ferramentas de Gerência de Configuração

Existem hoje diversas ferramentas open-source que podem nos ajudar a implantar gerência de configuração em nosso ambiente LINUX/UNIX.

Dentre as mais conhecidas temos:

  • Puppet
  • Chef
  • CFEngine
  • SpaceWalk (Redhat)

Abaixo vocês vão encontrar um link para uma wiki que faz algumas comparações entre as principais ferramentas open-source que fazem gerência de configurações.

Comparison of open source configuration management software

2.2 Puppet

No próximo POST vou falar do Puppet, ferramenta que conheci através dos Srs. @dcsobral e @coredump quando trabalhamos juntos em um projeto em Brasília.

Vou falar especificamente do Puppet pois foi ele que eu estudei, aprendi a usar e até falei sobre em algumas palestras em parceria com o @dcsobral no CONSEGI e FLISOL em 2011.

O objetivo não será comparar com outras ferramentas, eu pretendo apresentar o puppet, sua estrutura, arquitetura, funcionamento e recursos, chegando a demonstrar a instalação e implantação da ferramenta com classes e módulos básicos.

Os tutoriais ficarão na WIKI e comentários no Blog.

3. Indo além da gerência de configurações

Mas é claro que a gerência de configuração sozinha não resolve todos os seus problemas, eu recomendo que sejam criados processos bem definidos para orientar as ações da equipe nas manutenções em seu parque, recomendo que seja adotada uma ferramenta de gestão de demandas/tickets (OTRS ou REDMINE), pois isso facilita a abertura, acompanhamento e gerência de demandas, possibilitando ao final de um ciclo (semanal/mensal/bimestral) métricas que podem ser avaliadas para que você busque melhorá-las a cada ciclo. E o mais importante na minha opinião, adoção de uma ferramenta wiki (recomendo o DOKUWIKI ou REDMINE) para estender a documentação, registrar os processos, procedimentos, ambientes e tudo mais o que for necessário, de forma ágil e rápida, necessitando apenas de um navegador, deixando tudo centralizado.

Agora é só aguardar os posts do Puppet, já estão no Forno.

[s]
GutoCarvalho