Agile DevOps: Automação de infraestrutura

Trate a infraestrutura como código com Chef ou Puppet

Quantas vezes você aplicou manualmente as mesmas etapas ao criar uma infraestrutura, ou contou com outra equipe para configurar um ambiente para você? E se todas essas ações fossem colocadas em um script e uma versão como o restante do sistema de software? Nesta parte do artigo Agile DevOps , o especialista em DevOps Paul Duvall mostra como o Chef e o Puppet permitem automatizar o fornecimento da infraestrutura. Ele cobre os fundamentos de cada uma dessas ferramentas — junto com suas similaridades, casos de uso e diferenças, — além de fornecer uma demonstração em vídeo da criação de scripts com o Puppet.

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall é o CTO da Stelligent. Um palestrante de destaque em muitas importantes conferências de software, ele trabalhou em praticamente todas as funções em projetos de software: desenvolvedor, gerente de projetos, arquiteto e testador. Ele é o principal autor de Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007) e Ganhador do 2008 Jolt Award. Ele também é autor de Startup@Cloud e DevOps in the Cloud LiveLessons (Pearson Education, junho de 2012). Ele contribuiu para vários outros livros também. Paul é autor da série de 20 artigos Automation for the people no developerWorks. Sua paixão é levar software de alta qualidade aos usuários de forma mais rápida e com maior frequência por meio da nuvem e de entrega contínua. Leia seu blog em Stelligent.com.



01/Out/2012

Sobre esta série

Os desenvolvedores podem aprender muito com o pessoal de operações, e o pessoal de operações pode aprender muito com os desenvolvedores. Esta série de artigos é dedicada a explorar os usuos práticos de aplicar uma mentalidade de aplicativo ao desenvolvimento, e vice-versa — e de considerar produtos de software como entidades holísticas que podem ser entregues com maior agilidade e frequência que nunca.

Automação de infraestrutura é o processo de criar scripts de ambientes — da instalação de um sistema operacional até a instalação e configuração de serviços em instâncias, a configuração de como as instâncias e softwares comunicam-se entre si, e muito mais. Criando scripts para ambientes, é possível aplicar a mesma configuração a um único nó ou a milhares.

A automação de infraestrutura também atende por outros nomes: gerenciamento de configuração, gerenciamento de TI, fornecimento, infraestruturas em script, gerenciamento de configuração do sistema e muitos outros termos que se sobrepõem. O sentido é o mesmo: sua infraestrutura e sua configuração estão sendo descritas como um ou um conjunto de scripts para que os ambientes possam ser replicados de maneira muito menos propensa a erros. As operações de automação de infraestrutura trazem agilidade para desenvolvimento e operações, porque qualquer membro autorizado da equipe pode modificar os scripts enquanto aplicam boas práticas de desenvolvimento— , como teste e versão automatizados— à sua infraestrutura.

Na última década, várias ferramentas comerciais e de software livre surgiram para dar suporte à automação da infraestrutura. As ferramentas de software livre incluem Bcfg2, CFEngine, Chef e Puppet. Elas podem ser usadas na nuvem e em ambientes virtuais e físicos. Neste artigo, o foco será nas ferramentas de automação de infraestrutura de software livre mais populares: Chef e Puppet. Embora você não vá aprender os detalhes de cada ferramenta, obterá um entendimento das similaridades e diferenças entre elas, junto com alguns exemplos representativos. Para obter um exemplo mais detalhado da configuração e do uso de uma ferramenta de automação de infraestrutura, este artigo fornece um vídeo acompanhante que mostra como executar o Puppet em um ambiente de nuvem.

Abordagens tradicionais

Nem todas as equipes estão aplicando ferramentas de automação de infraestrutura — junto com suas práticas e padrões— , então o que estão fazendo? Abordagens tradicionais — que não podem ser escaladas — incluem configurar ambientes manualmente ou gravar e executar combinações de scripts que devem ser realizados por um humano. Isso leva a processos propensos a erro que aumentam os tempos de ciclo, evitando que equipes liberem software regularmente.

Chef e Puppet ambos usam uma domain-specific language (DSL) Ruby para criar scripts de ambientes. O Chef é expressado como uma DSL Ruby interno , e usuários do Puppet usam principalmente sua DSL externa— também gravada em Ruby. Essas ferramentas tendem a ser usadas com mais frequência em automação de sistema Linux® , mas têm suporte para Windows também. O Puppet tem uma base de usuários maior que o Chef, e oferece mais suporte para sistemas operacionais mais antigos e desatualizados. Com o Puppet, é possível definir dependências de outras tarefas. Ambas as ferramentas são idempotentes— , o que significa que você obtém o mesmo resultado com a mesma configuração, não importa quantas vezes você as execute.

Chef

O Chef está disponível desde 2009. Ele foi influenciado pelo Puppet e pelo CFEngine. O Chef oferece suporte para várias plataformas, incluindo Ubuntu, Debian, RHEL/CentOS, Fedora, Mac OS X, Windows 7 e Windows Server. Ele muitas vezes é descrito como mais fácil de usar — especialmente por desenvolvedores de Ruby, porque tudo no Chef é definido como um script Ruby e segue um modelo com o qual os desenvolvedores estão acostumados a trabalhar. O Chef tem uma base de usuários entusiasmados, e a comunidade do Chef está crescendo rapidamente enquanto desenvolve livros de receitas para outros usarem.

Como funciona

Participe

Uma comunidade de transformação Agile fornece notícias, discussões e treinamento para ajudar você e sua organização a desenvolver uma base sobre princípios de desenvolvimento agile.

No Chef, três componentes centrais interagem entre si— Chef server, nodes e a Chef workstation. O Chef executa cookbooks, que consistem em recipes que realizam etapas automatizadas— chamadas ações— em nós, como por exemplo instalar e configurar software ou adicionar arquivos. O servidor Chef contém dados de configuração para gerenciar vários nós. Os arquivos e recursos de configuração armazenados no servidor Chef são puxados por nós quando solicitados. Exemplos de resources incluem arquivo, pacote, cron e executar.

Os usuários interagem com o servidor Chef usando a interface de linha de comando do Chef, chamada Knife. Os nós podem ter uma ou mais funções (roles). Uma função define attributes (configurações específicas do nó) e receitas para um nó pode aplicá-las através de vários nós. As receitas podem executar outras receitas. As receitas em um nó, chamadas de lista de execução, são executadas na ordem em que estão listadas. Uma estação de trabalho Chef é uma instância com um repositório Chef local e Knife instalados nela.

A Tabela 1 descreve os principais componentes do Chef:

Tabela 1. Componentes do Chef
ComponenteDescrição
AttributesDescrevem os dados do nó, como um endereço IP e o nome de host.
Chef ClientRealiza trabalho em nome de um nó. Um único Chef client pode executar receitas para vários nós.
Chef SoloPermite que você execute os livros de receita Chef na ausência de um servidor Chef.
Cookbooks Contêm todos os recursos necessários para automatizar sua infraestrutura e podem ser compartilhados com outros usuários do Chef. Os cookbooks normalmente consistem em várias receitas.
Data bagsContém dados globalmente disponíveis usados por nós e funções.
KnifeUsado por administradores do sistema para carregar alterações de configuração para o Servidor Chef. O Knife é usado para comunicação entre os nós via SSH.
Management consoleA interface da web do servidor Chef para gerenciar nós, funções, livros de receitas, pacotes de dados e clientes de API.
Hosts que executam o cliente Chef. Os principais recursos de um nó, do ponto de vista do Chef, são seus atributos e lista de execução. Os nós são o componente ao qual receitas e funções são aplicadas.
OhaiDetecta dados sobre seu sistema operacional. Pode ser usado de maneira independente, mas seu objetivo principal é fornecer dados do nó ao Chef.
RecipeA configuração fundamental no Chef. Recipes contêm coleções de recursos que são executados na ordem definida para configurar os nós.
Repository (Chef repository)O lugar em que são hospedados os cookbooks, roles, configuration files e outros artefatos para gerenciar sistemas com o Chef.
ResourceUma abstração de várias plataformas de algo que você está configurando em um nó. Por exemplo, usuários e pacotes podem ser configurados de maneira diferente em plataformas de sistemas operacionais diferentes. O Chef elimina a complexidade de fazer isso para o usuário.
RoleUm mecanismo de agrupar recursos similares em nós similares.
Server (Chef server)Repositório centralizado da configuração do seu servidor.

Exemplos

A Listagem 1 demonstra o uso do recurso service dentro da receita que é parte de um livro de receitas Tomcat. É possível ver que se podem usar ferramentas como o Chef para realizar configuração específica da plataforma e gerenciar a configuração do servidor.

Listagem 1. Receitas do Chef
service "tomcat" do
  service_name "tomcat6"
  case node["platform"]
  when "centos","redhat","fedora"
    supports :restart => true, :status => true
  when "debian","ubuntu"
    supports :restart => true, :reload => true, :status => true
  end
  action [:enable, :start]
end

A Listagem 2 define os atributos para o livro de receitas Tomcat. Neste exemplo, estou definindo algumas portas externas para o servidor Tomcat disponibilizar. Outros tipos de atributos que se podem ver incluem valores para diretórios, opções, usuários e outras configurações.

Listagem 2. Atributos Chef
default["tomcat"]["port"] = 8080
default["tomcat"]["ssl_port"] = 8443
default["tomcat"]["ajp_port"] = 8009

O Chef estende a linguagem Ruby — em comparação a uma DSL externa — para fornecer um modelo para aplicar configuração a muitos nós de uma só vez. O Chef usa um modelo interpretativo sem gerenciamento de dependência explícito, assim, pessoas com uma experiência focada em desenvolvimento tendem a gravitar para o Chef, quando estão realizando o script dos seus ambientes.


O Puppet

O Puppet é usado desde 2005. Muitas organizações, incluindo Google, Twitter, Oracle e Rackspace, usam-no para gerenciar suas infraestruturas. O Puppet, que tende a exigir uma curva de aprendizado mais acentuada que o Chef, oferece suporte a uma variedade de ambientes Windows e *nix. O Puppet tem uma comunidade de usuários grande e ativa. Ele é usado em milhares de organizações com instalações executando dezenas de milhares de instâncias.

Como funciona

O Puppet usa o conceito de servidor principal — chamado de Puppet master— que centraliza a configuração entre nodes e agrupa-os com base em tipo. Por exemplo, se você tivesse um conjunto de servidores da web que estivessem todos executando Tomcat com um WAR Jenkins, iria agrupá-los no Puppet principal. O Puppet agent executa como um daemon em sistemas. Isso permite implementar mudanças de infraestrutura em vários nós simultaneamente. Funciona da mesma maneira que um gerenciador de implementação, mas, em vez de implementar aplicativos, implementa mudanças de infraestrutura.

O Puppet inclui uma ferramenta chamada facter. O facter contém metadados sobre o sistema e pode ser usado para filtragem entre servidores. Por exemplo, é possível usar o facter para determinar o nome do host do nó.MCollective é uma ferramenta de implementação que integra-se com o Puppet. É possível usar o MCollective para implementar mudanças de infraestrutura através de nós.

A Tabela 2 lista os principais componentes Puppet:

Tabela 2. Principais componentes do Puppet
ComponenteDescrição
AgenteUm processo daemon executando em um nó que coleta informações sobre o nó e envia essas informações ao Puppet principal.
CatalogCompilação de fatos que especificam como configurar o nó.
FactsDados sobre um nó, enviados pelo nó para o Puppet master.
ManifestDescreve recursos e as dependências entre eles.
MóduloManifestos relacionados a grupos (em um diretório). Por exemplo, um module pode definir como um banco de dados como o MySQL é instalado, configurado e executado.
Um host gerenciado pelo Puppet principal. Os nós são definidos como classes, mas contêm o nome do host ou nome completo do domínio.
Puppet masterO servidor que gerencia todos os nós do Puppet.
RecursosPor exemplo, o pacote, arquivo ou serviço.

Exemplos

No exemplo na Listagem 3, um manifesto do Puppet descreve os pacotes a instalar em um nó. O Puppet determina a melhor abordagem e a melhor ordem de execução para instalar esses pacotes.

Listagem 3. Manifesto do Puppet para instalação de pacote
class system {
  package { "rubygems": ensure => "installed" }

  package { "make": ensure => "installed" }
  package { "gcc": ensure => "installed" }
  package { "gcc-c++": ensure => "installed" }
  package { "ruby-devel": ensure => "installed" }
  package { "libcurl-devel": ensure => "installed" }
  package { "zlib-devel": ensure => "installed" }
  package { "openssl-devel": ensure => "installed" }
  package { "libxml2-devel": ensure => "installed" }
  package { "libxslt-devel": ensure => "installed" }
}

O snippet do manifesto do Puppet na Listagem 4 mostra exemplos de diferentes tipos de recurso — pacote e serviço — que podem ser usados no script de uma infraestrutura:

Listagem 4. Manifesto do Puppet para httpd
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Puppet utiliza um modelo declarativo com gerenciamento de dependência explícito. Por isso, ele tende a ser uma das primeiras considerações de ferramenta pelos engenheiros que tem uma experiência mais de administração de sistemas e estão buscando criar um script dos seus ambientes.


Infraestrutura como código

Neste artigo, você aprendeu — por meio de exemplos — que a sua infraestrutura não precisa mais ser um esforço manual unicamente aplicado a nós individuais. Automatizando sua infraestrutura, é possível ampliar e reduzir sem qualquer esforço adicional. Porque sua infraestrutura é modelada em scripts, é possível criar uma versão e então testá-la como o código do aplicativo.

No próximo artigo, você aprenderá padrões e técnicas para criar ambientes efêmeros (ou temporários) — ambientes que são criados e destruídos em 24 horas e adotam a mentalidade de abundância (ou seja, ausência de escassez) que vem com o Agile DevOps.

Recursos

Aprender

Obter produtos e tecnologias

  • Chef: vários "sabores" do Chef estão disponíveis.
  • O Puppet: faça o download do Puppet Enterprise.
  • IBM Tivoli Provisioning Manager: Tivoli Provisioning Manager habilita uma infraestrutura dinâmica automatizando o gerenciamento de servidores físicos, servidores virtuais, software, armazenamento e redes.
  • IBM Tivoli® System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms fornece alta disponibilidade e automação para aplicativos corporativos e serviços de TI.
  • Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.

Discutir

  • Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora os blogs, fóruns, grupos e wikis orientados ao desenvolvedor.
  • A comunidade de transformação Agile fornece notícias, discussões e treinamento para ajudar você e sua organização a desenvolver uma base sobre princípios de desenvolvimento agile.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java
ArticleID=838433
ArticleTitle=Agile DevOps: Automação de infraestrutura
publish-date=10012012