Agile DevOps

Automação de infraestrutura

Trate a infraestrutura como código com Chef ou Puppet

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

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.

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

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

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