ANSIBLE (Ferramenta de Automação)

WhatsApp-Image-2017-12-29-at-11.57.41-AM.jpeg

Após uma pesquisa detalhada sobre sistemas de automação, o ANSIBLE se mostrou como uma ferramenta muito util no quesito facilidade de uso.

O Ansible se comunica com as máquinas através do protocolo SSH, dispensando portanto a instalação de clients ou agents nas maquinas clientes ou nos hosts alvos.

Uma vez que o servidor ja esta devidamente instalado e configurado, os clientes devem possuir como requisito mínimo o ssh e o phyton instalados somente.

Os hosts poderão entao ser definidos diretamente no arquivo hosts dentro de /etc/ansible/hosts ou diretamente na linha de comando.

Exemplo da estrutura do /etc/ansible/hosts:

192.168.0.1

[webservers]
foo.example.com
bar.example.com

Podendo ser executado diretamente atrevés do terminal http://rundeck.orgpor linha de comandos, para tarefas mais simples como verificar o status de um serviço, bem como, param tarefas mais complexas, utilizando a sintaxe YAML (YAML Ain't Markup Language) em arquivos de configurações denominados PLAYBOOKS.

Exemplo de tarefa por linha de comando: ansible webservers -m ping

Exemplo da construção de um playbook: este exemplo ele altera as configurações do apache, reinicia o serviço, garante que ele está em execução e que seu serviço seja chamado após o boot do sistema

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest
  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running (and enable it at boot)
    service: name=httpd state=started enabled=yes
  handlers:
    - name: restart apache
      service: name=httpd state=restarted

Sua estrutura pode então ser dividida da seguinte forma:

Playbook - Playbooks são a forma pelo qual o Ansible consegue configurar uma política ou passos de um processo de configuração. São feitos para serem fáceis de ler e podem realizar desde deploys de máquinas remotas até delegar ações com diferentes hosts através da interação com servers de monitoramento.

  • Play - Um Playbook pode contar várias plays que nada mais são que uma espécie de introdução para as tasks. Isso é, uma play contém várias tasks e define as propriedades que serão utilizadas para as mesmas. Isso é, nome de hosts, permissões de acesso, portas http. As configurações para as tasks são definidas aqui.
  • Task - As tasks são onde o trabalho vai ser efetivamente realizado. Elas contém as definições do que será instalado ou qual arquivo será copiado para o servidor que está sendo configurado, por exemplo. As tasks contém modules, que efetivamente vão realizar o trabalho de automatização
  • Play - Um Playbook pode contar várias plays que nada mais são que uma espécie de introdução para as tasks. Isso é, uma play contém várias tasks e define as propriedades que serão utilizadas para as mesmas. Isso é, nome de hosts, permissões de acesso, portas http. As configurações para as tasks são definidas aqui.
  • Task - As tasks são onde o trabalho vai ser efetivamente realizado. Elas contém as definições do que será instalado ou qual arquivo será copiado para o servidor que está sendo configurado, por exemplo. As tasks contém modules, que efetivamente vão realizar o trabalho de automatização.
  • Module - As tasks são o local onde o trabalho ocorrerá, mas quem efetivamente o realiza são os modules. São parecidos com os resources do Chef, onde você pode definir diversas atividades, como iniciar um serviço, alterar aquivos com base em um template e outra infinidade de coisas. Por exemplo, há modulos responsáveis por instalar pacotes (apt), adicionar um repositório via ppa (apt_repository), entre outros.
  • Handler - São opcionais, sendo estruturas que são ativadas por tasks e são executadas quando são notificadas por uma task. Por exemplo, após a instalação e configuração de um serviço, talvez seja interessante que você reinicie o mesmo. Essa é uma das ocasiões em que o uso de um handler é aconselhado.
  • Module - As tasks são o local onde o trabalho ocorrerá, mas quem efetivamente o realiza são os modules. São parecidos com os resources do Chef, onde você pode definir diversas atividades, como iniciar um serviço, alterar aquivos com base em um template e outra infinidade de coisas. Por exemplo, há modulos responsáveis por instalar pacotes (apt), adicionar um repositório via ppa (apt_repository), entre outros.

    Uma característica interessante dos handlers, que é fortemente ligada ao princípio da idempotência, é que, caso mais de uma task notifique a execução de um handler, este só será executado uma vez ao fim do bloco de tasks. (https://pt.wikiversity.org/wiki/Ferramenta_de_automatiza%C3%A7%C3%A3o_Ansible).

 

Comparativo com outras ferramentas:

https://stackshare.io/stackups/ansible-vs-chef-vs-puppet-vs-salt

https://stackshare.io/stackups/ansible-vs-chef-vs-puppet-vs-salt

 O Ansible também conta com um dashbord (Enterprise) chamado Ansible Tower, que é uma API para o ansible desenvolvida pela RedHat porém é pago, e seu uso free se limita a um trial.

Captura-de-tela-de-2017-12-29-13-14-09.png

Ansible Tower Pricing

Alem do Ansible Tower, o ansible pode ser integrado com diversas ferramentas como o FOREMAN (https://www.theforeman.org) e o RUNDECK (http://rundeck.org).

 

 

 

https://www.ansible.com/

http://docs.ansible.com/ansible/latest/playbooks_intro.html

https://docs.ansible.com/

https://serversforhackers.com/c/an-ansible-tutorial

http://rundeck.org

https://puppet.com/

https://www.chef.io/

 

Voltar ao topo