O Chef Sugar fornece métodos DSL em diversas áreas, tais como computação em nuvem (ex., cloud, ec2) ou plataforma (ex., ubuntu, centos). Existem discussões em andamento para incluir métodos auxiliares. No seu artigo, Seth mostra um exemplo que contrasta uma receita que faz uso do Chef Sugar com outra que não. Essa receita:
include_recipe 'cookbook::_windows_setup' if platform_family?('windows')
include_recipe 'cookbook::_ec2_setup' if node['ec2'] || node['eucalyptus']
package 'foo' do
action :nothing
end.run_action(:install)
execute 'untar package' do
if node['kernel']['machine'] == 'x86_64'
command 'ARCH_FLAGS=x64 make'
else
command 'ARCH_FLAGS=i386 make'
end
not_if do
::File.exists?('/bin/tool') &&
::File.executable?('/bin/tool') &&
shell_out!('/bin/tool --version').stdout.strip == node['tool']['version']
end
end
credentials = Chef::EncryptedDataBagItem.load('accounts', 'passwords')
pode ser transformada na seguinte receita:
include_recipe 'cookbook::_windows_setup' if windows?
include_recipe 'cookbook::_ec2_setup' if ec2? || eucalyptus?
compile_time do
package 'apache2'
end
execute 'untar package' do
if _64_bit?
command 'ARCH_FLAGS=x64 make'
else
command 'ARCH_FLAGS=i386 make'
end
not_if { installed_at_version?('/bin/tool', node['tool']['version']) }
end
credentials = encrypted_data_bag_item('accounts', 'passwords')
O Chef Sugar foi escrito intencionalmente para ser acessado de dentro de uma receita, mas também como uma biblioteca do Chef, o conceito que permite a inclusão de um código Ruby em um cookbook. A única diferença significante é que quando usado como uma biblioteca, os métodos do Chef Sugar recebem um objeto node como parâmetro:
# cookbook/libraries/default.rb
def only_on_windows(&block)
yield if Chef::Sugar::PlatformFamily.windows?(@node)
end
InfoQ.com: O açúcar sintático é visto as vezes como algo supérfluo e menos importante. Uma vez que você criou um projeto chamado Chef Sugar, você claramente não pensa que esse é sempre o caso. Quando você acha que um pouco de açúcar sintático é bom e quando é demais?
Vargo: Eu acho que açúcar sintático é uma das principais razões do Ruby (e Rails) ter se tornado um sucesso entre os desenvolvedores. Por exemplo, ActiveSupport é um açúcar para a classe Integer que permite chamar métodos como 5.days.ago. Açúcar sintático é inacreditavelmente usado para reduzir a complexidade e a repetição. Muitos cookbooks compartilham idiomas ou padrões comuns - como verificar se o pedaço de um software está instalado em uma versão em particular. Quando eu vejo esse tipo de padrão aparecendo, eu sei que é hora de aplicar um pouco de açúcar.
Por outro lado, eu não buscava, e não busco, ativamente áreas para "açucarar". Eu acho que isso é um equívoco feito com frequência. Na minha opinião, o açúcar foi muito longe quando existem mais que dois ramos de lógica ou componentes. Por exemplo, alguém pode facilmente escrever um açúcar sintático que encapsula um grupo de lógica e recursos, mas isso serve melhor como uma biblioteca ou LWRP. Açúcares devem ser facilmente testáveis e manuteníveis, e desenvolvedores iniciantes devem ser capazes de dissecar o método que define o açúcar sintático.
InfoQ.com: Você acredita que, em geral, esse tipo de funcionalidade deve estar disponível no núcleo da aplicação ou é melhor tê-las como extensões? Por que?
Vargo: Eu acredito fortemente no padrão de arquitetura plugável. Eu poderia facilmente ter incluído Chef Suger no núcleo do Chef, mas tomei a decisão consciente de mantê-lo isolado. Assim como um desenvolvedor não deve ser obrigado a usar o ActiveSupport, um desenvolvedor Chef não deve ser obrigado a usar Chef Sugar.
Do ponto de vista de manutenibilidade, tendo o Chef Sugar como uma gem separada me permite trabalhar e iterar de forma independente do ciclo de versionamento do Chef. O Ruby mesmo está usando esse formato plugável, migrando classes principais do para gems com mantenedores individuais. Rubinius 2.0 é inteiro composto de gems. Assim como existem vantagens em ter um sistema distribuído ao invés de uma aplicação monolítica, essas vantagens estão presentes quando usando um componente plugável ao invés de construir o componente no núcleo do framework. Esse padrão também está presente em ferramentas como Vagrant Knife (a interface de linha de comando do Chef) ou RubyGems.
Existe, porém, um meio termo no qual o componente plugável é empacotado junto de uma versão específica do núcleo (como uma dependência), mas continua a existir fora do framework como um recurso isolado. Os usuário podem atualizá-los para a última versão a qualquer momento ou esperar para atualizar o pacote inteiro. Ruby 2.0 segue esse padrão. Tente desinstalar o bigdecimal e você receberá o seguinte erro:
ERROR: While executing gem ... (Gem::InstallError)
gem "bigdecimal" cannot be uninstalled because it is a default gemMas os desenvolvedores podem optar por atualizar o pacote para a última versão a qualquer hora.
Um último ponto a considerar, e que é sempre esquecido, está relacionado às implicações de licenciamento. No caso do Chef Sugar, assim como o Chef, usa a licença Apache 2.0, então isso não é um problema. Mas em certos casos não é possível incluir algum componente no núcleo do aplicativo porque ele poderia impedir de revender, patentear (devido à restrição imposta por algumas licenças), etc.
InfoQ.com: Existe alguma outra parte do Chef que pode ser beneficiar dos métodos adicionais do Chef Sugar?
Vargo: Como eu disse antes, eu não procuro partes para "açucarar". Quando a primeira versão do Chef Sugar foi lançada, havia uma imensa popularidade. Dentro de 20 minutos, um membro da comunidade a disponibilizou no FreeBSD. O projeto viveu então por dois meses sem qualquer manutenção (ele simplesmente funcionava). Há alguns meses atrás alguém adicionou o suporte no Cloudstack.
Eu tenho a tendência de me orgulhar pelo rápido reconhecimento e fazer os merges solicitados, então eu sempre encorajo as pessoas a submetê-los. Eu também não tenho medo de dizer não quando um patch avança além dos objetivos do projeto. Se um membro da comunidade vê algo que pode ser "açucarado", eu fico contente em dar uma olhada.
InfoQ.com: Quais são as partes mais importantes no Chef que podem ser beneficiar de um maior envolvimento da comunidade?
Vargo: Todas as mudanças relacionadas ao Chef são controladas no Sistema de Gerenciamento de Mudanças do Chef. A maioria das solicitações estão ordenadas por prioridade. Para novos membros, as solicitações marcadas como "trivial" ou "menor" envolvem pequenas mudanças e são uma boa forma de mergulhar no núcleo do Chef. E, por último, nunca subestime o poder das correções tipográficas ou gramaticais. Como o Chef está cada vez mais aumentando a sua popularidade, usuários de língua não inglesa também devem ser capazes de ler a documentação.
Adicionalmente, há um projeto aberto no GitHub para as RFCs do Chef. Elas são propostas da comunidade para funcionalidades alto nível ou mudanças no roadmap. As solicitações de mudança de código (pull request) naquele repositório se beneficiam significativamente do envolvimento da comunidade (mesmo que seja algo extremamente pequeno).
Além do projeto central do Chef, foi anunciado no Chef Community Summit, em Novembro, algumas importantes mudanças no Projeto de Livro de Receitas (receitas da comunidade que o Chef mantém). O Chef está em um processo de compartilhar as responsabilidades das receitas com os membros da comunidade.