Você que tem ambientes grandes e complexos, ambiente com muitas maquinas hoje é até um pecado não automatizar ambiente.

Com o advento de Nuvem e virtualização cada vez mais teremos mais servidores e serviços separados com elasticidade.

O Ansible veio para automatizar ambiente e facilitar as tarefas chatas de atualização ou instalação de patchs e muito mais.

Eu não vou mostrar como instalar o Ansible pois é uma tarefa relativamente facil

yum install ansible ou apt-get e blá blá blá o google mostra o caminho a você que se interessar.

Introdução

Ansible é um sistema de gerenciamento de configuração fácil que pode ser usada para automatizar e organizar suas tarefas de configuração do sistema para uma grande rede de computadores. Enquanto alguns outros sistemas de gerenciamento de configuração exigem muitos pacotes diferentes para ser instalado nos sistemas de servidor e cliente, com Ansible, você só precisa instalar um componente do servidor e ter acesso SSH para as máquinas clientes.

Neste guia, vamos discutir playbooks ansible, que são forma de criar scripts automatizados para configurar computadores clientes do Ansible.

Vamos supor que você tem um servidor Ansible configurado e alguns clientes.

No nosso guia, o servidor é um Ubuntu 12.04 máquina, e os clientes que vão ser configuração também são Ubuntu 12.04 máquinas, para facilidade de explicação.

Quais são Playbooks ansible?

Playbooks ansible são uma forma de enviar comandos para computadores remotos via script através do SSH. Em vez de usar comandos Ansible individualmente para configurar remotamente os computadores a partir da linha de comando, você pode configurar ambientes complexos inteiros por meio de um script para um ou mais sistemas.

Playbooks ansible estão escritos no formato de serialização de dados YAML. Se você não sabe o que é um formato de dados, pense nisso como uma maneira de traduzir uma estrutura de dados (listas, matrizes, dicionários, etc) em um formato que pode ser facilmente armazenado no disco. O arquivo pode então ser utilizada para criar a estrutura em um momento posterior. JSON é um outro formato  de dados popular, mas YAML é muito mais fácil de ler.

Cada cartilha contém uma ou mais peças, que mapeiam hosts para uma determinada função. Ansible faz isso através de tarefas, que são basicamente as chamadas em módulos.

Explorando um Playbook Básico

Veja o comando.

--- - hosts: droplets tasks: - name: Installs nginx web server apt: pkg=nginx 
state=installed update_cache=true notify: - start nginx handlers: 
- name: start nginx service: name=nginx state=started 

Vamos em seções para que possamos entender como esses arquivos são construídos e que cada peça significa.

O arquivo começa com:

 --- 

Este é um requisito para YAML para interpretar o arquivo como um documento adequado. YAML permite que vários “documentos” em um arquivo, cada um separado por --- , mas Ansible só quer um por arquivo, de modo que este só deve estar presente na parte superior do arquivo.

YAML é muito sensível ao espaço em branco, e usa isso para agrupar diferentes peças de informação em conjunto. Você deve usar apenas espaços e não tabs e você deve usar espaçamento consistente para o arquivo a ser lido corretamente. Itens no mesmo nível de recuo são considerados elementos irmãos.

Os itens que comecem com um - são considerados itens da lista. Os itens que têm o formato de key: value operar como hashes ou dicionários. Isso é muito bonito tudo o que há para YAML básica.

Documentos YAML, basicamente, definir uma estrutura de árvore hierárquica com os que contêm elementos mais à esquerda.

Na segunda linha, temos o seguinte:

 --- - hosts: droplets 

Este é um item de lista no YAML como aprendemos acima, mas uma vez que é no mais à esquerda do nível, é também uma “peça” Ansible. Peças são basicamente grupos de tarefas que são executadas em um determinado conjunto de hosts, que lhes permitam cumprir a função que deseja atribuir a eles. Cada jogo deve especificar um host ou grupo de exércitos, como fazemos aqui.

Em seguida, temos um conjunto de tarefas:

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - start nginx 

No nível superior, temos “tarefas:” no mesmo nível “hosts:”. Este contém uma lista (porque começa com um “-“), que contém pares chave-valor.

O primeiro, “nome”, é mais do que uma descrição do que um nome. Você pode chamar isso de qualquer coisa que você gostaria.

A próxima chave é “apto”. Esta é uma referência a um módulo Ansible, assim como quando usamos o comando ansible e digitar algo como:

 ansible -m apt -a 'whatever' all 

Este módulo permite especificar um pacote e o estado que ele deve estar em, que é “instalado” no nosso caso. O update-cache=true parte diz a nossa máquina remota para atualizar seu cache de pacotes (apt-get update) antes de instalar o software.

O item “notificar” contém uma lista com um item, o que é chamado de “começar nginx”. Este não é um comando interno Ansible, é uma referência a um manipulador, que pode executar determinadas funções quando é chamado a partir de uma tarefa. Vamos definir o “start nginx” manipulador abaixo.

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - 
start nginx handlers: - name: start nginx service: name=nginx state=started 

A seção “manipuladores” existe ao mesmo nível que os “hosts” e “tarefas”. Manipuladores são como tarefas, mas eles só correr quando lhes foi dito por uma tarefa que ocorreram alterações no sistema do cliente.

Por exemplo, temos um manipulador aqui que inicia o serviço Nginx após o pacote é instalado. O manipulador não é chamado a menos que o “Instal servidor web nginx” resultados da tarefa em mudanças no sistema, o que significa que o pacote teve de ser instalado e já não estava lá.

Nós podemos salvar este em um arquivo chamado algo como “nginx.yml”.

Só por algum contexto, se você fosse escrever esse mesmo arquivo em JSON, que poderia ser algo como isto:

 [ { "hosts": "droplets", "tasks": [ { "name": "Installs nginx web server", 
"apt": "pkg=nginx state=installed update_cache=true", "notify": [ "start nginx" ] } ], 
"handlers": [ { "name": "start nginx", "service": "name=nginx state=started" } ] } ] 

Como você pode ver, YAML é muito mais compacto e maioria das pessoas diria mais legal.

Executando um Ansible Playbook

Depois de ter um guia estratégico construído, você pode chamá-lo facilmente usando este formato:

 playbook.yml ansible-playbook

Por exemplo, se queríamos para instalar e iniciar o Nginx em todos os nossos servidores, poderíamos emitir este comando:

 ansible-playbook nginx.yml 

No entanto, se nós gostaríamos de filtrar a lista , aplicar-se apenas a um desses hospedeiros, podemos adicionar um sinalizador para especificar um subconjunto dos arquivos:

 ansible-playbook -l host_subset playbook.yml

Então, se nós só quesermos instalar e executar o Nginx em um servidor, por exemplo “host3”, que poderia digitar o seguinte:

 ansible-playbook -l host3 nginx.yml 

Adicionando recursos ao Playbook

Agora a nossa cartilha tem esta aparência:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

É simples e funciona, em vários hosts ou em um só.

Podemos começar a expandir a funcionalidade através da adição de tarefas.

Adicionar um padrão Index Arquivo

Podemos dizer-lhe para transferir um arquivo do nosso servidor Ansible no host, adicionando algumas linhas como este abaixo:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644

  handlers:
    - name: start nginx
      service: name=nginx state=started

Podemos, então, fazer um diretório chamado static_files em nosso diretório atual e coloque um arquivo index.html dentro.

 mkdir static_files nano static_files/index.html 

Dentro desse arquivo, vamos apenas criar uma estrutura básica html:

 <html> <head> <title>This is a sample page</title> </head> <body> 
<h1>Here is a heading!</h1> <p>Here is a regular paragraph. Wow!</p> 
</body> </html> 

Salve e feche o arquivo.

Agora, quando executar novamenter o playbook, Ansible irá verificar cada tarefa. Vai ver que Nginx já está instalado no host, por isso vai deixá-lo ser. Ele vai ver a nova seção tarefa e substituir o arquivo index.html padrão com o do nosso servidor.

Resultados

Quando instalar e configurar os serviços manualmente, é quase sempre necessário saber se suas ações foram bem-sucedidas ou não. Podemos cozinhar essa funcionalidade em nossos playbooks usando “registrar”.

Para cada tarefa, que pode, opcionalmente, registrar seu resultado (sucesso ou falha) em uma variável que podemos verificar mais tarde.

Ao utilizar esta funcionalidade, também temos de dizer Ansible para ignorar erros para essa tarefa, já que normalmente ele aborta a execução cartilha para aquela máquina se qualquer problema acontece.

Assim, se quiser verificar se uma tarefa falhou ou não para decidir sobre os passos subsequentes, podemos usar a funcionalidade de registo.

Por exemplo, poderíamos dizer o nosso guia estratégico para carregar um index.php  se ele existir. Se essa tarefa falhar, poderíamos em vez de tentar carregar um index.html. Vamos verificar a condição de falha na outra tarefa, porque nós só queremos fazer o upload do arquivo HTML se o arquivo PHP falhar:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.php for host
      copy: src=static_files/index.php dest=/usr/share/nginx/www/ mode=0644
      register: php
      ignore_errors: True

    - name: Remove index.html for host
      command: rm /usr/share/nginx/www/index.html
      when: php|success

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644
      when: php|failed

  handlers:
    - name: start nginx
      service: name=nginx state=started

 

Esta nova versão tenta carregar um arquivo de índice PHP para o local indicado. Ela regista com sucesso da operação em uma variável chamada “PHP”.

Se esta operação foi bem sucedida, a tarefa ira remover o arquivo index.html é executado em seguida.

Se a operação falhar, o arquivo index.html é carregado em vez disso.

Conclusão

Agora, você deve ter um bom controle sobre como automatizar tarefas complexas usando Ansible.

Este é um exemplo básico de como você pode começar a construir a sua biblioteca de configuração.

Combinando definições de host e do grupo como nós aprendemos sobre este tutorial, e com variáveis disponíveis para preencher as informações, podemos começar a montar sistemas complexos que interagem uns com os outros. Em um artigo futuro, vamos discutir como implementar variáveis em nossos playbooks e criar funções para ajudar a gerenciar tarefas complexas.

Como ainda falamos de nuvem o Ansible em ambiente IaaS publico ou não é ideal.

Teste no Azure e Amazon e não precisa falar que ambiente Onpremisses, todos funcionaram.

Tem um demo sensacional no site oficial:

https://www.ansible.com/

Veja um howto facil.

Se você quer seguir para um caminho de DEVOPS o Ansible é a porta de entrada.

Espero ter ajudado.

Abraços