Por que Chef?
Ser um administrador de sistema oscila entre o tedioso e o eletrizante. A parte eletrizante é relativa a ajustar um sistema que seja incrível e sólido como uma rocha. A chata é repetir isso 10 ou mesmo 100 vezes. Além disso, ao longo de sua carreira, você configurará certos aplicativos repetidamente. Você sabe quais: sendmail, apache, samba etc. Tem havido muitas tentativas de construir um framework, uma abstração, para automatizar o processo de configurar essas e outras ferramentas conhecidas.
Há um desses frameworks que finalmente funciona, o Chef. Há muitas razões para usar o Chef, mas a principal é: vocês, administradores de sistemas, que são espertos demais para passar o resto de suas vidas reinventando a roda.
Deixe-me dizer um pouco mais sobre como o Chef é bacana, e depois mostrarei brevemente alguns tópicos técnicos e farei esclarecimentos sobre alguns mitos do Chef.
Cinco principais razões para usar o Chef
- Escrever um monte de documentação cansa. O Chef reduz drasticamente a quantidade de documentação que você tem que escrever.
- O Bash não escala. Sério.
- É tecnicamente incrível.
- O Chef cresce com você.
- Você pode parar com a reinvenção da roda.
Falemos agora de como ele é incrível em maiores detalhes.
Escreva menos documentação
Menos documentação? É brincadeira? Não, de verdade. Se você é como eu, tem mania de anotar todo o seu histórico do Bash. Se não é, você não se preocupa de qualquer forma. Com o Chef, sua infraestrutura é literalmente código, em vez de uma coleção de artefatos únicos. Arquivos README de alto nível e poucos comentários de código bem colocados são suficientes. Veja esta receita de uma configuração básica de sendmail.
Configuração básica de sendmail com Chef:
package 'sendmail' do<br> action :install<br>end<br><br>service 'sendmail' do<br> action [ :enable,:start ]<br>end<br><br>template "/etc/mail/sendmail.cf" do<br> source "sendmail.cf.erb"<br> notifies :restart,"service[sendmail]"<br> variables({ :relay_host => node['smtp_relay_host'] })<br>end<br><br>template "/etc/mail/relay-domains" do<br> source "relay-domains"<br> notifies :restart,"service[sendmail]"<br>end
O Bash não escala
O Bash é uma coisa bacana, mas como todas ferramentas UNIX, é fundamentalmente limitado pelo design. O Bash não tem um mecanismo de reutilização de código mais poderoso do que as funções. Usa um único namespace global. Essas e outras limitações dificultaram para nós, administradores de sistema, reusar e generalizar nossos scripts shell em diferentes distribuições e abandonar diferentes versões de *nix. Finalmente, é bastante difícil escrever scripts shell que sejam idempotentes, ou seja, tenham o mesmo efeito, mesmo que rodem uma ou 100 vezes. Isso é particularmente verdadeiro ao manipular arquivos de configuração. Vamos dar uma olhada em como configurar /etc/sudoers com o Chef.
# /etc/sudoers<br>#<br># Generated by Chef for <%= node[:fqdn] %><br><br>Defaults !lecture,tty_tickets,!fqdn<br><br># User privilege specification<br>root ALL=(ALL) ALL<br><br><% @sudoers_users.each do |user| -%><br><%= user %> ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL<br><% end -%><br><br># Members of the sysadmin group may gain root privileges%<br>sysadmin ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL<br><br><% @sudoers_groups.each do |group| -%><br># Members of the group '<%= group %>' may gain root privileges<br>%<%= group %> ALL=(ALL) <%= "NOPASSWD:" if @passwordless %>ALL<br><% end -%>
Todas as variáveis nesse template são passadas nesta receita. Se você pensa que pode replicar esse template usando sed, por favor, insira como comentário, de forma que possamos comparar resultados.
Finalmente, mas não menos importante, o Bash pode ser tão ilegível e confuso como o mais obscuro código perl. Com o Chef, você tem um DSL intuitivo de alto nível para descrever sua configuração. Lembra o que eu disse a respeito de menos documentação ser necessária?
Qualidade técnica
NoSQL FTW
Uma das qualidades que muitas ferramentas *nix compartilham é armazenar suas configurações em arquivos de texto, e não em formatos binários ou em um banco de dados. O Chef armazena as configurações do seu sistema em texto e em banco de dados. Ele consegue isso usando um banco de dados orientado a documentos, o CouchDB. Isso faz com que a configuração seja ”buscável” e tenha melhor performance. Um dos meus aborrecimentos com o nagios é que tenho que reiniciá-lo todas as vezes em que mudo um serviço ou host. Não há reinicializações irritantes com o Chef. Cada mudança de configuração que você fizer tem efeito imediato. Além disso, você pode usar seu editor de texto favorito e a linha de comando para fazer mudanças na configuração. Finalmente, o uso de um banco de dados significa que o Chef é facilmente acessado através de um GUI. Nós, administradores de sistema, frequentemente olhamos o GUI como muletas para a multidão Windows. A interface de usuário web do Chef é ótima para visualização de sua própria infraestrutura, o que é difícil de fazer olhando para um simples texto.
Conhecimento é metade da batalha
O Chef usa o Ohai para coletar dados a respeito do seu sistema. Suas receitas podem acessar esses atributos e tomar decisões baseadas neles. Por exemplo, você pode determinar qual versão do Red Hat você está usando simplesmente olhando o valor do node[‘platform_version’]. Você não tem que utilizar cat | grep | awk para descobrir qual versão está sendo usada.
O Ohai faz os cookbooks serem mais dinâmicos e capazes de suportar diferentes distribuições. Como veremos mais tarde, essa é uma das razões por que há tantos cookbooks disponíveis.
Search
O Search é uma característica no Chef Server que permite a você fazer uma consulta sobre a configuração de todos os outros servidores e de databags globalmente definidas. Isso permite a você fazer coisas como configurar clusters nos quais um membro precisa saber não apenas sobre sua própria configuração, mas também sobre as configurações dos outros membros do cluster.
Exemplo de uso do search com data bags. Para a receita completa vá aqui.
sysadmin_group = Array.new<br><br>search(:users, 'groups:sysadmin') do |u|<br> sysadmin_group << u['id']<br> <br> home_dir = "/home/#{u['id']}"<br><br> user u['id'] do<br> uid u['uid']<br> gid u['gid']<br> shell u['shell']<br> comment u['comment']<br> supports :manage_home => true<br> home home_dir<br> notifies :create, "ruby_block[reset group list]", :immediately<br> end<br><br>end
Knife
O Knife é uma das ferramentas de linha de comando realmente bacanas. É seu mecanismo primário para interagir com o chef-server. O Knife compartilha muitas características de uso com o git. Se você gosta do git, vai gostar do knife.
shef
O shef trabalha do seu jeito, de forma interativa. A maior parte de nós, administradores de sistema, somos autodidatas, e aprendemos melhor fazendo. Dispare o shef e você poderá brincar com atributos e criar receitas imediatamente. Pode também conectá-lo a seu servidor e fazer download dos cookbooks.
O Chef cresce com você
O Chef usa Ruby puro como sua linguagem de configuração, não amarrado ao Ruby, ou outra linguagem customizada de configuração. Você só precisa aprender um pouco de ruby para se iniciar no Chef. Uma vez ultrapassado o básico do Chef, você poderá aprofundar-se no Ruby. Alguns de nós podemos resmungar contra o Ruby ao compará-lo com Perl/Python/TCL/<escreve alguma linguagem aqui>. Bem, o Ruby pode empalidecer um pouco diante do Python, mas mesmo assim é uma linguagem poderosa, com características plenas.
Assim como no Perl, há um monte de magia negra dentro do Ruby. Ele não pode ser usado descuidadamente, ou vai te morder. Ao contrário do Python, com o Ruby não é difícil fazer a coisa errada.
Você pode parar de reinventar a roda
Até aparecer o Chef, os administradores de sistema não dispunham de um modo realmente modular para fazer a abstração e o compartilhamento das configurações do sistema. Por favo,r pare de ler e vá em http://community.opscode.com/cookbooks.
Mais tarde, você deve dar uma olhada na codificação em https://github.com/opscode/cookbooks. Você descobrirá que alguns administradores de sistema vira-casaca estão contando nossos segredos. Chegou a hora de você fazer o mesmo. Na verdade, você pode jogar fora uma grande parte de seus scripts shell e substituí-los por cookbooks do Chef. Você descobrirá que muitas receitas existentes servem aos seus propósitos e que você pode facilmente adicionar receitas novas a cookbooks existentes para suas necessidades que não foram satisfeitas.
Recentemente, substituí 500 linhas de script shell por 7 cookbooks, 5 deles reaproveitados do community.opscode.com e 2 novos, escritos a partir do zero. No processo de substituição do script shell, eu na verdade escrevi 4 cookbooks que involuntariamente duplicaram a funcionalidade dos cookbooks existentes.
O aparecimento do cloud computing, tanto público, como o EC2, ou internamente, com o openstack, significa que os administradores de sistema terão que lidar com pelo menos 10 vezes mais sistemas. Teremos que ser 10 vezes mais produtivos. Teremos que mudar de “gerenciamento de servidores” para “gerenciamento de configurações”. O Chef é uma das ferramentas-chave para conseguir isso.
Uma advertência ao Big Fat Chef
O Chef faz com que bons administradores de sistema sejam mais produtivos. Não transforma administradores de sistema juniores em experts. Na verdade, os torna mais perigosos. Como ouvi no IRC um dia: “O Chef é para os administradores de sistema o que o C++ é para a engenharia de software”. Muito verdadeiro. Você pode automatizar configurações do sistema com cookbooks direto da prateleira, mas terá que entender o que eles fazem exatamente e testá-los com muito rigor.
Mitos a respeito do Chef
Há alguns mitos a respeito do Chef que precisam ser detonados. O maior é o que diz que você tem que ser um programador profissional para usar o Chef.
Isso não é verdadeiro por algumas razões, incluindo a suposição de que administradores de sistema já não são programadores. Escrever scripts shell complexos é programação. Criar regras de reescrita no Apache é quase programação. Além do mais, o Chef não requer que você seja um especialista em Ruby para começar, da mesma forma que você não tem que ser um Hacker Bash para usar a linha de comando.
Escutei boatos aqui e ali que o Chef é “inseguro”, porque as receitas são executadas no chef-client, e não no chef-server. Meu argumento é que o Chef é mais seguro por causa disso. Se as receitas fossem executadas no chef-server, haveria o risco de que uma única receita maligna modificasse outras receitas de forma a fazer de sua network inteira uma botnet. Isso transformaria seu chef-server em um ponto de falha único, e faria dele um poderoso vetor de ataque.
Finalmente, alguns argumentam que o Chef não é bom porque todo servidor para ser configurado deve ser único e feito a mão. Se você acredita nisso, talvez você deva ir para as artes performáticas virtuais e deixar o negócio de tornar a Internet incrível.
Conclusão
O Chef é uma ferramenta verdadeiramente poderosa que todo administrador de sistemas sério deve considerar. Ele oferece imensos benefícios pessoais e profissionais.
?
Texto original disponível em http://devopsanywhere.blogspot.com/2011/10/why-chef.html
é administrador de sistemas Linux e atualmente trabalha na Europa.
