Módulo
Os módulos são os blocos de construção dos Playbooks.
Existem módulos para, praticamente, qualquer tarefa e eles estão evoluindo rapidamente.
Aqui, há uma referência online deles:
Playbooks
São a base do gerenciamento de configuração e deployment de múltiplas máquinas.
Playbooks contém declarações, mas também, podem orquestrar passos de deploy de aplicativos, podem ativar/desativar serviços e garantir que a configuração de um servidor está de um modo específico.
Nesse tutorial, será mostrada uma visão mais prática e imediata dos playbooks. Para a teoria sobre eles, veja a documentação no site:
Então, algumas definições iniciais. Primeiro, como organizar os playbooks. O ideal é que os playbooks fique sob algum controle de versão - de preferência, o Git. Acostume-se a, sempre que alterar e testar um playbook, fazer o
git commit, adicionando um comentário relevante sobre a mudança, para consultas futuras.
Inicialmente, vamos começar com um playbook que configurará uma máquina base. Essa máquina poderá, depois, ser customizada para ser um servidor PostgreSQL ou Tomcat, através de outro playbook. Então, vamos ver como criar e aplicar essa configuração.
O primeiro passo, é criar a estrutura de diretórios:
Mude para o diretório de playbooks:
cd ~/manager/books/
Vamos chamar essa configuração de
Basica e criar a estrutura. Rode os seguintes comandos:
mkdir Basica
$ mkdir -p Basica/uploads
$ cd Basica
* Copie um arquivo
/etc/sudoers de um S.O. identico ao quê você vai instalar para o diretório
uploads.
O diretório
Basica/uploads, agora, deverá conter o arquivo
sudoers copiado.
Edite esse arquivo, com o editor de sua preferência (
vim uploads/sudoers) e adicione a seguinte linha no final do arquivo:
operador ALL=(ALL) NOPASSWD:ALL
Agora, vamos criar o playbook que vai enviar esse arquivo para o servidor, com as permissões corretas. Agora, edite o arquivo
Basica.yml e adicione o seguinte conteúdo:
---
- hosts: all
user: operador
sudo: yes
tasks:
 - name: Ativando o sudo sem senha
action: copy src=./uploads/sudoers dest=/etc/sudoers owner=root group=root mode=0440
- name: (A) Remove o sources.list original
action: shell rm -f /etc/apt/sources.list
- name: (B) Baixando o sources.list
action: get_url url=http://172.25.137.131/sources/sources12.04.list dest=/etc/apt/sources.list owner=root group=root mode=0644
- name: Atualizando o cache do apt
action: apt update_cache=yes
- name: Atualizando o sistema
action: apt upgrade=full
- name: Criando o locale pt_BR.UTF-8
action: shell locale-gen pt_BR.UTF-8
- name: Atualizando todos os locales
action: shell locale-gen
- name: Instala o DKMS
action: apt name=dkms state=latest
- name: Instalando o Build-essential
action: apt name=build-essential state=latest
- name: Mudando o scheduler de disco default para NOOP
action: lineinfile dest=/etc/default/grub regexp='^GRUB_CMDLINE_LINUX_DEFAULT=' line=GRUB_CMDLINE_LINUX_DEFAULT\=\"elevator\=noop\"
- name: Mudando o scheduler de disco para NOOP
action: lineinfile dest=/etc/default/grub regexp='^GRUB_CMDLINE_LINUX=' line=GRUB_CMDLINE_LINUX\=\"elevator\=noop\"
- name: Atualizando o Grub
action: shell sudo update-grub
- name: Limpa o cache do Apt
action: shell sudo apt-get clean all
- name: Reiniciando o servidor
action: command reboot
O playbook acima é, praticamente, autoexplicativo. O mais notável é que ele altera arquivos de configuração do sistema para a opção desejada (os módulos lineinfile).
Obs.: as ações (A) e (B) só são necessárias, se você usa um
sources.list customizado. Senão, retire-as do playbook.
Para executar esse playbook:
ansible-playbook --ask-sudo-pass Basica.yml
A razão da opção
--ask-sudo-pass é que, nesse momento, o S.O. ainda está pedindo senha para fazer
sudo su -. Ele executará um pouco e falhará, porque está esperando o prompt de
sudo. Mas na segunda vez, execute-o assim:
ansible-playbook Basica.yml
Depois do playbook ser executado, ele não mais pedirá senha para comandos administrativos.