Ansible - Guia Rápido
Ansible é um mecanismo de TI simples de código aberto que automatiza a implantação de aplicativos, orquestração intra-serviço, provisionamento em nuvem e muitas outras ferramentas de TI.
O Ansible é fácil de implantar porque não usa nenhum agente ou infraestrutura de segurança personalizada.
Ansible usa um manual para descrever trabalhos de automação e um manual usa uma linguagem muito simples, ou seja, YAML(É uma linguagem de serialização de dados legível por humanos e é comumente usada para arquivos de configuração, mas pode ser usada em muitos aplicativos onde os dados estão sendo armazenados) que é muito fácil para humanos entender, ler e escrever. Portanto, a vantagem é que até mesmo os caras do suporte de infraestrutura de TI podem ler e entender o manual e depurar se necessário (YAML - está em uma forma legível por humanos).
O Ansible foi projetado para implantação em várias camadas. O Ansible não gerencia um sistema de cada vez, ele modela a infraestrutura de TI, descrevendo todos os seus sistemas estão inter-relacionados. O Ansible é completamente sem agente, o que significa que o Ansible funciona conectando seus nós por meio de ssh (por padrão). Mas se você quiser outro método de conexão como o Kerberos, o Ansible oferece essa opção para você.
Depois de se conectar aos seus nós, o Ansible envia pequenos programas chamados “Módulos Ansible”. O Ansible executa esses módulos em seus nós e os remove quando concluído. O Ansible gerencia seu inventário em arquivos de texto simples (esses são os arquivos hosts). O Ansible usa o arquivo de hosts onde é possível agrupar os hosts e controlar as ações em um grupo específico nos manuais.
Arquivo de Hosts de Amostra
Este é o conteúdo do arquivo hosts -
#File name: hosts
#Description: Inventory file for your application. Defines machine type abc
node to deploy specific artifacts
# Defines machine type def node to upload
metadata.
[abc-node]
#server1 ansible_host = <target machine for DU deployment> ansible_user = <Ansible
user> ansible_connection = ssh
server1 ansible_host = <your host name> ansible_user = <your unix user>
ansible_connection = ssh
[def-node]
#server2 ansible_host = <target machine for artifact upload>
ansible_user = <Ansible user> ansible_connection = ssh
server2 ansible_host = <host> ansible_user = <user> ansible_connection = sshO que é Gerenciamento de Configuração
O gerenciamento de configuração em termos de Ansible significa que ele mantém a configuração do desempenho do produto, mantendo um registro e atualizando informações detalhadas que descrevem o hardware e o software de uma empresa.
Essas informações normalmente incluem as versões e atualizações exatas que foram aplicadas aos pacotes de software instalados e os locais e endereços de rede dos dispositivos de hardware. Por exemplo, se você deseja instalar a nova versão doWebLogic/WebSphere servidor em todas as máquinas presentes em sua empresa, não é viável para você ir e atualizar manualmente cada máquina.
Você pode instalar o WebLogic / WebSphere de uma só vez em todas as suas máquinas com os manuais e inventário da Ansible escritos da maneira mais simples. Tudo que você precisa fazer é listar os endereços IP de seus nós no inventário e escrever um manual para instalar o WebLogic / WebSphere. Execute o manual de sua máquina de controle e ele será instalado em todos os seus nós.
Como funciona o Ansible?
A imagem abaixo mostra o funcionamento da Ansible.
Ansible works conectando-se aos seus nós e enviando pequenos programas, chamados de "Ansible módulos "para eles. Ansibleem seguida, executa esses módulos (por padrão por SSH) e os remove quando concluído. Sua biblioteca de módulos pode residir em qualquer máquina e não são necessários servidores, daemons ou bancos de dados.
O nó de gerenciamento na imagem acima é o nó de controle (nó de gerenciamento) que controla toda a execução do manual. É o nó a partir do qual você está executando a instalação. O arquivo de inventário fornece a lista de hosts onde os módulos Ansible precisam ser executados e o nó de gerenciamento faz uma conexão SSH e executa os pequenos módulos na máquina de hosts e instala o produto / software.
Beauty do Ansible é que ele remove os módulos uma vez instalados de forma tão eficaz que se conecta à máquina host, executa as instruções e, se for instalado com sucesso, remove o código que foi copiado na máquina host que foi executada.
Neste capítulo, aprenderemos sobre a configuração do ambiente de Ansible.
Processo de Instalação
Principalmente, existem dois tipos de máquinas quando falamos sobre implantação -
Control machine - Máquina de onde podemos gerenciar outras máquinas.
Remote machine - Máquinas que são manuseadas / controladas por máquina de controle.
Pode haver várias máquinas remotas que são controladas por uma máquina de controle. Portanto, para gerenciar máquinas remotas, temos que instalar o Ansible na máquina de controle.
Requisitos da máquina de controle
O Ansible pode ser executado em qualquer máquina com Python 2 (versões 2.6 ou 2.7) ou Python 3 (versões 3.5 e superiores) instalado.
Note - O Windows não suporta máquina de controle.
Por padrão, o Ansible usa ssh para gerenciar máquina remota.
O Ansible não adiciona nenhum banco de dados. Não requer nenhum daemons para iniciar ou mantê-lo funcionando. Ao gerenciar máquinas remotas, Ansibledoes notdeixe qualquer software instalado ou em execução neles. Portanto, não há dúvida de como atualizá-lo ao mudar para uma nova versão.
O Ansible pode ser instalado na máquina de controle que possui os requisitos mencionados acima de diferentes maneiras. Você pode instalar a versão mais recente por meio de Apt, yum, pkg, pip, OpenCSW, pacman, etc.
Instalação através de Apt em Máquina Ubuntu
Para instalar o Ansible, você deve configurar o PPA em sua máquina. Para isso, você deve executar a seguinte linha de código -
$ sudo apt-get update $ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible $ sudo apt-get update
$ sudo apt-get install ansibleDepois de executar a linha de código acima, você está pronto para gerenciar máquinas remotas por meio do Ansible. Basta executar o Ansible – version para verificar a versão e apenas para verificar se o Ansible foi instalado corretamente ou não.
O Ansible usa a sintaxe YAML para expressar os manuais do Ansible. Este capítulo fornece uma visão geral do YAML. Ansible usa YAML porque é muito fácil para humanos entender, ler e escrever quando comparado a outros formatos de dados como XML e JSON.
Cada YAML arquivo opcionalmente começa com “---” e termina com “...”.
Compreendendo YAML
Nesta seção, aprenderemos as diferentes maneiras em que os dados YAML são representados.
par de valor-chave
YAML usa um par de valores-chave simples para representar os dados. O dicionário é representado no par chave: valor.
Note - Deve haver espaço entre: e valor.
Exemplo: um registro do aluno
--- #Optional YAML start syntax
james:
name: james john
rollNo: 34
div: B
sex: male
… #Optional YAML end syntaxAbreviação
Você também pode usar abreviações para representar dicionários.
Exemplo
James: {name: james john, rollNo: 34, div: B, sex: male}Lista Representante
Também podemos representar a Lista em YAML. Cada elemento (membro) da lista deve ser escrito em uma nova linha com o mesmo recuo começando com “-“ (- e espaço).
Exemplo
---
countries:
- America
- China
- Canada
- Iceland
…Abreviação
Você também pode usar abreviações para representar listas.
Exemplo
Countries: [‘America’, ‘China’, ‘Canada’, ‘Iceland’]Listar dentro de dicionários
Podemos usar lista dentro de dicionários, ou seja, o valor da chave é lista.
Exemplo
---
james:
name: james john
rollNo: 34
div: B
sex: male
likes:
- maths
- physics
- english
…Lista de Dicionários
Também podemos fazer lista de dicionários.
Exemplo
---
- james:
name: james john
rollNo: 34
div: B
sex: male
likes:
- maths
- physics
- english
- robert:
name: robert richardson
rollNo: 53
div: B
sex: male
likes:
- biology
- chemistry
…YAML usa “|” para incluir novas linhas ao mostrar várias linhas e “>” para suprimir novas linhas ao mostrar várias linhas. Devido a isso, podemos ler e editar linhas grandes. Em ambos os casos, a intentação será ignorada.
Nós também podemos representar BooleanValores (verdadeiro / falso) em YAML. Ondeboolean os valores podem não fazer distinção entre maiúsculas e minúsculas.
Exemplo
---
- james:
name: james john
rollNo: 34
div: B
sex: male
likes:
- maths
- physics
- english
result:
maths: 87
chemistry: 45
biology: 56
physics: 70
english: 80
passed: TRUE
messageIncludeNewLines: |
Congratulation!!
You passed with 79%
messageExcludeNewLines: >
Congratulation!!
You passed with 79%Algumas palavras comuns relacionadas a Ansible.
Service/Server - Um processo na máquina que fornece o serviço.
Machine - Um servidor físico, vm (máquina virtual) ou um contêiner.
Target machine - Uma máquina que estamos prestes a configurar com o Ansible.
Task - Uma ação (execute isto, exclua aquilo) etc gerenciado por Ansible.
Playbook - O arquivo yml onde os comandos Ansible são escritos e yml é executado em uma máquina.
Os comandos ad hoc são comandos que podem ser executados individualmente para executar funções rápidas. Esses comandos não precisam ser executados posteriormente.
Por exemplo, você deve reiniciar todos os servidores da empresa. Para isso, você executará os comandos Adhoc de '/usr/bin/ansible'.
Esses comandos ad-hoc não são usados para gerenciamento de configuração e implantação, porque esses comandos são de uso único.
ansible-playbook é usado para gerenciamento de configuração e implantação.
Paralelismo e comandos Shell
Reinicialize o servidor da empresa em 12 garfos paralelos de cada vez. Para isso, precisamos configurar o SSHagent para conexão.
$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsaPara executar a reinicialização de todos os servidores da sua empresa em um grupo, 'abc', em 12 bifurcações paralelas -
$ Ansible abc -a "/sbin/reboot" -f 12Por padrão, o Ansible executará os comandos Ad-hoc acima da conta do usuário atual. Se você quiser mudar este comportamento, você terá que passar o nome de usuário nos comandos Ad-hoc da seguinte forma -
$ Ansible abc -a "/sbin/reboot" -f 12 -u usernameTransferência de arquivo
Você pode usar os comandos Ad-hoc para fazer SCP (Secure Copy Protocol) muitos arquivos em paralelo em várias máquinas.
Transferindo arquivo para muitos servidores / máquinas
$ Ansible abc -m copy -a "src = /etc/yum.conf dest = /tmp/yum.conf"Criando novo diretório
$ Ansible abc -m file -a "dest = /path/user1/new mode = 777 owner = user1 group = user1 state = directory"Excluindo diretórios e arquivos inteiros
$ Ansible abc -m file -a "dest = /path/user1/new state = absent"Gerenciando Pacotes
Os comandos Ad-hoc estão disponíveis para yum e apt. A seguir estão alguns comandos Ad-hoc usando yum.
O comando a seguir verifica se o pacote yum está instalado ou não, mas não o atualiza.
$ Ansible abc -m yum -a "name = demo-tomcat-1 state = present"O comando a seguir verifica se o pacote não está instalado.
$ Ansible abc -m yum -a "name = demo-tomcat-1 state = absent"O comando a seguir verifica se a versão mais recente do pacote está instalada.
$ Ansible abc -m yum -a "name = demo-tomcat-1 state = latest"Coletando fatos
Os fatos podem ser usados para implementar declarações condicionais no manual. Você pode encontrar informações ad hoc de todos os seus fatos por meio do seguinte comando Ad-hoc -
$ Ansible all -m setupNeste capítulo, aprenderemos sobre Playbooks em Ansible.
Playbooks são os arquivos onde o código Ansible é escrito. Os manuais são escritos no formato YAML. YAML significa Yet Another Markup Language.Playbookssão um dos principais recursos do Ansible e dizem a Ansible o que executar. Eles são como uma lista de tarefas para Ansible que contém uma lista de tarefas.
Os manuais contêm as etapas que o usuário deseja executar em uma máquina específica. Os manuais são executados sequencialmente. Os manuais são os blocos de construção para todos os casos de uso do Ansible.
Estrutura do manual
Cada manual é uma agregação de uma ou mais peças nele. Playbooks são estruturados usando Plays. Pode haver mais de uma peça dentro de um manual.
A função de uma peça é mapear um conjunto de instruções definidas contra um determinado host.
YAML é uma linguagem estritamente tipada; portanto, cuidado extra deve ser tomado ao gravar os arquivos YAML. Existem diferentes editores YAML, mas preferimos usar um editor simples como o notepad ++. Basta abrir o notepad ++ e copiar e colar o yaml abaixo e alterar o idioma para YAML (Idioma → YAML).
Um YAML começa com --- (3 hífens)
Crie um manual
Vamos começar escrevendo um arquivo YAML de amostra. Percorreremos cada seção escrita em um arquivo yaml.
---
name: install and configure DB
hosts: testServer
become: yes
vars:
oracle_db_port_value : 1521
tasks:
-name: Install the Oracle DB
yum: <code to install the DB>
-name: Ensure the installed service is enabled and running
service:
name: <your service name>O exemplo acima é um exemplo de manual, onde tentamos cobrir a sintaxe básica de um manual. Salve o conteúdo acima em um arquivo comotest.yml. Uma sintaxe YAML precisa seguir o recuo correto e é preciso ter um pouco de cuidado ao escrever a sintaxe.
As Diferentes Tags YAML
Vamos agora examinar as diferentes tags YAML. As diferentes tags são descritas abaixo -
nome
Esta tag especifica o nome do manual do Ansible. Como no que este manual estará fazendo. Qualquer nome lógico pode ser dado ao manual.
hospedeiros
Esta tag especifica as listas de hosts ou grupo de hosts contra os quais queremos executar a tarefa. O campo / tag hosts é obrigatório. Diz ao Ansible em quais hosts executar as tarefas listadas. As tarefas podem ser executadas na mesma máquina ou em uma máquina remota. Pode-se executar as tarefas em várias máquinas e, portanto, a tag hosts também pode ter um grupo de entradas de hosts.
vars
Tag Vars permite que você defina as variáveis que você pode usar em seu manual. O uso é semelhante a variáveis em qualquer linguagem de programação.
tarefas
Todos os manuais devem conter tarefas ou uma lista de tarefas a serem executadas. Tarefas são uma lista de ações que precisam ser executadas. Um campo de tarefas contém o nome da tarefa. Isso funciona como um texto de ajuda para o usuário. Não é obrigatório, mas prova ser útil na depuração do manual. Cada tarefa é vinculada internamente a um trecho de código denominado módulo. Um módulo que deve ser executado e os argumentos necessários para o módulo que você deseja executar.
As funções fornecem uma estrutura para coleções totalmente independentes ou interdependentes de variáveis, tarefas, arquivos, modelos e módulos.
No Ansible, a função é o mecanismo principal para dividir um manual em vários arquivos. Isso simplifica a escritacomplex playbooks, e isso os torna mais fáceis de reutilizar. A quebra do manual permite que você divida logicamente o manual em componentes reutilizáveis.
Cada função é basicamente limitada a uma funcionalidade específica ou saída desejada, com todas as etapas necessárias para fornecer esse resultado dentro da própria função ou em outras funções listadas como dependências.
As funções não são manuais. As funções são pequenas funcionalidades que podem ser usadas independentemente, mas devem ser usadas nos manuais. Não há como executar uma função diretamente. As funções não têm configuração explícita para qual host a função será aplicada.
Os manuais de nível superior são a ponte que mantém os hosts de seu arquivo de inventário para as funções que devem ser aplicadas a esses hosts.
Criação de uma nova função
A estrutura de diretório para funções é essencial para criar uma nova função.
Estrutura da Função
As funções têm um layout estruturado no sistema de arquivos. A estrutura padrão pode ser alterada, mas por enquanto vamos nos limitar aos padrões.
Cada função é uma árvore de diretório em si. O nome da função é o nome do diretório dentro do diretório / roles.
$ ansible-galaxy -hUso
ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...Opções
-h, --help - Mostre esta mensagem de ajuda e saia.
-v, --verbose - Modo detalhado (-vvv para mais, -vvvv para habilitar a depuração de conexão)
--version - Mostra o número da versão do programa e sai.
Criação de um diretório de funções
O comando acima criou os diretórios de funções.
$ ansible-galaxy init vivekrole
ERROR! The API server (https://galaxy.ansible.com/api/) is not responding, please try again later.
$ ansible-galaxy init --force --offline vivekrole - vivekrole was created successfully $ tree vivekrole/
vivekrole/
├── defaults
│ └── main.yml
├── files ├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md ├── tasks
│ └── main.yml
├── templates ├── tests │ ├── inventory
│ └── test.yml
└── vars
└── main.yml
8 directories, 8 filesNem todos os diretórios serão usados no exemplo e mostraremos o uso de alguns deles no exemplo.
Utilizando funções no manual
Este é o código do manual que escrevemos para fins de demonstração. Este código pertence ao playbook vivek_orchestrate.yml. Definimos os hosts:tomcat-node e chamou as duas funções - install-tomcat e start-tomcat.
A declaração do problema é que temos uma guerra que precisamos implantar em uma máquina via Ansible.
---
- hosts: tomcat-node
roles:
- {role: install-tomcat}
- {role: start-tomcat}Conteúdo de nossa estrutura de diretório de onde executamos o manual.
$ ls
ansible.cfg hosts roles vivek_orchestrate.retry vivek_orchestrate.yml
Existe um diretório de tarefas em cada diretório e contém um main.yml. O conteúdo main.yml de install-tomcat é -
---
#Install vivek artifacts
-
block:
- name: Install Tomcat artifacts
action: >
yum name = "demo-tomcat-1" state = present
register: Output
always:
- debug:
msg:
- "Install Tomcat artifacts task ended with message: {{Output}}"
- "Installed Tomcat artifacts - {{Output.changed}}"O conteúdo de main.yml do tomcat inicial é -
#Start Tomcat
-
block:
- name: Start Tomcat
command: <path of tomcat>/bin/startup.sh"
register: output
become: true
always:
- debug:
msg:
- "Start Tomcat task ended with message: {{output}}"
- "Tomcat started - {{output.changed}}"A vantagem de dividir a cartilha em funções é que qualquer pessoa que quiser usar o recurso Instalar tomcat pode chamar a função Instalar Tomcat.
Quebrando um manual em um papel
Se não for pelas funções, o conteúdo do main.yml da respectiva função pode ser copiado no manual ymlArquivo. Mas para ter modularidade, os papéis foram criados.
Qualquer entidade lógica que pode ser reutilizada como uma função reutilizável, essa entidade pode ser movida para a função. O exemplo disso é mostrado acima
Execute o comando para executar o manual.
-vvv option for verbose output – verbose output
$ cd vivek-playbook/Este é o comando para executar o manual
$ sudo ansible-playbook -i hosts vivek_orchestrate.yml –vvv
-----------------------------------------------------------------
-----------------------------------------------------------------------Resultado
A saída gerada é como visto na tela -
Usando /users/demo/vivek-playbook/ansible.cfg como arquivo de configuração.
PLAYBOOK: vivek_orchestrate.yml *********************************************************
***********************************************************
1 plays in vivek_orchestrate.yml
PLAY [tomcat-node] **********************************************************************
******** *************************************************
TASK [Gathering Facts] *************************************************
****************************** *********************************************
Tuesday 21 November 2017 13:02:05 +0530 (0:00:00.056) 0:00:00.056 ******
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/system/setup.py
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo
/root/.ansible/tmp/ansible-tmp-1511249525.88-259535494116870 `" &&
echo ansible-tmp-1511249525.88-259535494116870="`
echo /root/.ansible/tmp/ansibletmp-1511249525.88-259535494116870 `" ) && sleep 0'
<localhost> PUT /tmp/tmpPEPrkd TO
/root/.ansible/tmp/ansible-tmp-1511249525.88259535494116870/setup.py
<localhost> EXEC /bin/sh -c 'chmod u+x
/root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/
/root/.ansible/tmp/ansible-tmp-1511249525.88259535494116870/setup.py && sleep 0'
<localhost> EXEC /bin/sh -c '/usr/bin/python
/root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/setup.py; rm -rf
"/root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/" > /dev/null 2>&1 && sleep 0'
ok: [server1]
META: ran handlers
TASK [install-tomcat : Install Tomcat artifacts] ***********************************
***************************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:5
Tuesday 21 November 2017 13:02:07 +0530 (0:00:01.515) 0:00:01.572 ******
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/packaging/os/yum.py
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo
/root/.ansible/tmp/ansible-tmp-1511249527.34-40247177825302 `" && echo
ansibletmp-1511249527.34-40247177825302="` echo
/root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302 `" ) && sleep 0'
<localhost> PUT /tmp/tmpu83chg TO
/root/.ansible/tmp/ansible-tmp-1511249527.3440247177825302/yum.py
<localhost> EXEC /bin/sh -c 'chmod u+x
/root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/
/root/.ansible/tmp/ansible-tmp-1511249527.3440247177825302/yum.py && sleep 0'
<localhost> EXEC /bin/sh -c '/usr/bin/python
/root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/yum.py; rm -rf
"/root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/" > /dev/null 2>
&1 && sleep 0'
changed: [server1] => {
"changed": true,
"invocation": {
"module_args": {
"conf_file": null,
"disable_gpg_check": false,
"disablerepo": null,
"enablerepo": null,
"exclude": null,
"install_repoquery": true,
"installroot": "/",
"list": null,
"name": ["demo-tomcat-1"],
"skip_broken": false,
"state": "present",
"update_cache": false,
"validate_certs": true
}
},
"msg": "",
"rc": 0,
"results": [
"Loaded plugins: product-id,
search-disabled-repos,
subscriptionmanager\nThis system is not registered to Red Hat Subscription Management.
You can use subscription-manager to register.\nResolving Dependencies\n-->
Running transaction check\n--->
Package demo-tomcat-1.noarch 0:SNAPSHOT-1 will be installed\n--> Finished Dependency
Resolution\n\nDependencies Resolved\n
\n================================================================================\n
Package Arch Version Repository
Size\n==================================================================\nInstalling:\n
demo-tomcat-1 noarch SNAPSHOT-1 demo-repo1 7.1 M\n\nTransaction
Summary\n==================================================================\nInstall 1
Package\n\nTotal download size: 7.1 M\nInstalled size: 7.9 M\nDownloading
packages:\nRunning transaction
check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n Installing :
demotomcat-1-SNAPSHOT-1.noarch 1/1 \n Verifying :
demo-tomcat-1-SNAPSHOT-1.noarch 1/1 \n\nInstalled:\n
demo-tomcat-1.noarch 0:SNAPSHOT-1 \n\nComplete!\n"
]
}
TASK [install-tomcat : debug] **********************************************************
***************************************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:11
Tuesday 21 November 2017 13:02:13 +0530 (0:00:06.757) 0:00:08.329 ******
ok: [server1] => {
"changed": false,
"msg": [
"Install Tomcat artifacts task ended with message: {
u'msg': u'', u'changed': True, u'results':
[u'Loaded plugins: product-id,
search-disabledrepos,
subscription-manager\\nThis system is not registered to Red Hat Subscription Management.
You can use subscription-manager to register.\\nResolving Dependencies\\n-->
Running transaction check\\n--->
Package demo-tomcat-1.noarch 0:SNAPSHOT-1 will be installed\\n-->
Finished Dependency Resolution\\n
\\nDependencies
Resolved\\n\\n==================================================================\\n
Package Arch Version Repository
Size\\n========================================================================
=====\\nInstalling:\\n demo-tomcat-1 noarch SNAPSHOT-1 demo-repo1 7.1 M\\n\\nTransaction
Summary\\n=========================================================\\nInstall 1
Package\\n\\nTotal download size: 7.1 M\\nInstalled size: 7.9 M\\nDownloading
packages:\\nRunning
transaction check\\nRunning transaction test\\nTransaction test succeeded\\nRunning
transaction\\n
Installing : demo-tomcat-1-SNAPSHOT-1.noarch 1/1 \\n Verifying :
demo-tomcat-1-SNAPSHOT-1.noarch
1/1 \\n\\nInstalled:\\n demo-tomcat-1.noarch 0:SNAPSHOT-1 \\n\\nComplete!\\n'], u'rc': 0
}",
"Installed Tomcat artifacts - True"
]
}
TASK [install-tomcat : Clean DEMO environment] ****************************************
************************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:19
Tuesday 21 November 2017 13:02:13 +0530 (0:00:00.057) 0:00:08.387 ******
[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or
{% %}. Found: {{installationOutput.changed}}
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/files/file.py
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo
/root/.ansible/tmp/ansible-tmp-1511249534.13-128345805983963 `" && echo
ansible-tmp-1511249534.13-128345805983963="` echo
/root/.ansible/tmp/ansibletmp-1511249534.13-128345805983963 `" ) && sleep 0'
<localhost> PUT /tmp/tmp0aXel7 TO
/root/.ansible/tmp/ansible-tmp-1511249534.13128345805983963/file.py
<localhost> EXEC /bin/sh -c 'chmod u+x
/root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/
/root/.ansible/tmp/ansible-tmp-1511249534.13128345805983963/file.py && sleep 0'
<localhost> EXEC /bin/sh -c '/usr/bin/python
/root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/file.py; rm -rf
"/root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/" > /dev/null 2>&1
&& sleep 0'
changed: [server1] => {
"changed": true,
"diff": {
"after": {
"path": "/users/demo/DEMO",
"state": "absent"
},
"before": {
"path": "/users/demo/DEMO",
"state": "directory"
}
},
"invocation": {
"module_args": {
"attributes": null,
"backup": null,
"content": null,
"delimiter": null,
"diff_peek": null,
"directory_mode": null,
"follow": false,
"force": false,
"group": null,
"mode": null,
"original_basename": null,
"owner": null,
"path": "/users/demo/DEMO",
"recurse": false,
"regexp": null,
"remote_src": null,
"selevel": null,
"serole": null,
"setype": null,
"seuser": null,
"src": null,
"state": "absent",
"unsafe_writes": null,
"validate": null
}
},
"path": "/users/demo/DEMO",
"state": "absent"
}
TASK [install-tomcat : debug] ********************************************************
*************************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:29
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.257) 0:00:08.645 ******
ok: [server1] => {
"changed": false,
"msg": [
"Clean DEMO environment task ended with message:{u'diff': {u'after': {u'path':
u'/users/demo/DEMO', u'state': u'absent'},
u'before': {u'path': u'/users/demo/DEMO', u'state': u'directory'}}, u'state': u'absent',
u'changed': True, u'path': u'/users/demo/DEMO'}",
"check value :True"
]
}
TASK [install-tomcat : Copy Tomcat to user home] *************************************
********************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:37
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.055) 0:00:08.701 ******
[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or
{% %}. Found: {{installationOutput.changed}}
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/commands/command.py
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo
/root/.ansible/tmp/ansible-tmp-1511249534.43-41077200718443 `" && echo
ansibletmp-1511249534.43-41077200718443="` echo
/root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443 `" ) && sleep 0'
<localhost> PUT /tmp/tmp25deWs TO
/root/.ansible/tmp/ansible-tmp-1511249534.4341077200718443/command.py
<localhost> EXEC /bin/sh -c 'chmod u+x
/root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443/
/root/.ansible/tmp/ansible-tmp-1511249534.4341077200718443/command.py && sleep 0'
<localhost> EXEC /bin/sh -c '/usr/bin/python
/root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443/command.py; rm -rf
"/root/.ansible/tmp/ansibletmp-1511249534.43-41077200718443/" > /dev/null 2>&1
&& sleep 0'
changed: [server1] => {
"changed": true,
"cmd": [
"cp",
"-r",
"/opt/ansible/tomcat/demo",
"/users/demo/DEMO/"
],
"delta": "0:00:00.017923",
"end": "2017-11-21 13:02:14.547633",
"invocation": {
"module_args": {
"_raw_params": "cp -r /opt/ansible/tomcat/demo /users/demo/DEMO/",
"_uses_shell": false,
"chdir": null,
"creates": null,
"executable": null,
"removes": null,
"warn": true
}
},
"rc": 0,
"start": "2017-11-21 13:02:14.529710",
"stderr": "",
"stderr_lines": [],
"stdout": "",
"stdout_lines": []
}
TASK [install-tomcat : debug] ********************************************************
**********************************************************
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:47
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.260) 0:00:08.961 ******
ok: [server1] => {
"changed": false,
"msg": "Copy Tomcat to user home task ended with message {
'stderr_lines': [], u'changed': True, u'end': u'2017-11-21 13:02:14.547633', u'stdout':
u'', u'cmd': [u'cp', u'-r', u'/opt/ansible/tomcat/demo', u'/users/demo/DEMO/'], u'rc': 0,
u'start': u'2017-11-21 13:02:14.529710', u'stderr': u'', u'delta': u'0:00:00.017923',
'stdout_lines': []}"
}
TASK [start-tomcat : Start Tomcat] **************************************************
**********************************************************
task path: /users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:5
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.044) 0:00:09.006 ******
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/commands/command.py
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo
/root/.ansible/tmp/ansible-tmp-1511249534.63-46501211251197 `" && echo
ansibletmp-1511249534.63-46501211251197="` echo
/root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197 `" ) && sleep 0'
<localhost> PUT /tmp/tmp9f06MQ TO
/root/.ansible/tmp/ansible-tmp-1511249534.6346501211251197/command.py
<localhost> EXEC /bin/sh -c 'chmod u+x
/root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197/
/root/.ansible/tmp/ansible-tmp-1511249534.6346501211251197/command.py && sleep 0'
<localhost> EXEC /bin/sh -c '/usr/bin/python
/root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197/command.py; rm -rf
"/root/.ansible/tmp/ansibletmp-1511249534.63-46501211251197/" > /dev/null 2>&1
&& sleep 0'
changed: [server1] => {
"changed": true,
"cmd": [ "/users/demo/DEMO/bin/startup.sh" ],
"delta": "0:00:00.020024",
"end": "2017-11-21 13:02:14.741649",
"invocation": {
"module_args": {
"_raw_params": "/users/demo/DEMO/bin/startup.sh",
"_uses_shell": false,
"chdir": null,
"creates": null,
"executable": null,
"removes": null,
"warn": true
}
},
"rc": 0,
"start": "2017-11-21 13:02:14.721625",
"stderr": "",
"stderr_lines": [],
"stdout": "Tomcat started.",
"stdout_lines": [ "Tomcat started." ]
}
TASK [start-tomcat : debug] *************************************************
**********************************************************************
task path: /users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:10
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.150) 0:00:09.156 ******
ok: [server1] => {
"changed": false,
"msg": [
"Start Tomcat task ended with message: {'
stderr_lines': [], u'changed': True, u'end': u'2017-11-21 13:02:14.741649', u'stdout':
u'Tomcat started.', u'cmd': [u'/users/demo/DEMO/bin/startup.sh'], u'rc': 0, u'start':
u'2017-11-21 13:02:14.721625', u'stderr': u'', u'delta': u'0:00:00.020024',
'stdout_lines': [u'Tomcat started.']}",
"Tomcat started - True"
]
}
META: ran handlers
META: ran handlers
PLAY RECAP *******************************************************************************
*********************************************************
server1 : ok = 9 changed = 4 unreachable = 0 failed = 0
Tuesday 21 November 2017 13:02:14 +0530 (0:00:00.042) 0:00:09.198 ******
===============================================================================
install-tomcat : Install Tomcat artifacts ------------------------------- 6.76s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:5 --------------
Gathering Facts --------------------------------------------------------- 1.52s
------------------------------------------------------------------------------
install-tomcat : Copy Tomcat to user home ------------------------------- 0.26s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:37 -------------
install-tomcat : Clean DEMO environment --------------------------------- 0.26s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:19 -------------
start-tomcat : Start Tomcat --------------------------------------------- 0.15s
/users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:5 ----------------
install-tomcat : debug -------------------------------------------------- 0.06s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:11 -------------
install-tomcat : debug -------------------------------------------------- 0.06s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:29 -------------
install-tomcat : debug -------------------------------------------------- 0.04s
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:47 -------------
start-tomcat : debug ---------------------------------------------------- 0.04s
/users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:10 ---------------Acesse o seguinte URL e você será direcionado para uma página conforme mostrado abaixo - http://10.76.0.134:11677/HelloWorld/HelloWorld
A guerra implantada tem apenas um servlet que exibe “Hello World”. A saída detalhada mostra o tempo gasto por cada tarefa por causa da entrada adicionada no arquivo ansible.cfg -
[defaults]
callback_whitelist = profile_tasksVariáveis nos manuais são very similarpara usar variáveis em qualquer linguagem de programação. Ajuda você a usar e atribuir um valor a uma variável e usá-lo em qualquer lugar do manual. Pode-se colocar condições em torno do valor das variáveis e, conseqüentemente, usá-las no manual.
Exemplo
- hosts : <your hosts>
vars:
tomcat_port : 8080No exemplo acima, definimos um nome de variável tomcat_port e atribuiu o valor 8080 a essa variável e pode usar isso em seu manual sempre que necessário.
Agora, tomando uma referência do exemplo compartilhado. O código a seguir é de uma das funções (install-tomcat) -
block:
- name: Install Tomcat artifacts
action: >
yum name = "demo-tomcat-1" state = present
register: Output
always:
- debug:
msg:
- "Install Tomcat artifacts task ended with message: {{Output}}"
- "Installed Tomcat artifacts - {{Output.changed}}"Aqui, a saída é a variável usada.
Vamos examinar todas as palavras-chave usadas no código acima -
block - Sintaxe compatível para executar um determinado bloco.
name - Nome relevante do bloco - é usado no registro e ajuda na depuração de que todos os blocos foram executados com sucesso.
action- O código ao lado da tag de ação é a tarefa a ser executada. A ação novamente é uma palavra-chave Ansible usada no yaml.
register - A saída da ação é registrada usando a palavra-chave de registro e Output é o nome da variável que contém a saída da ação.
always - Novamente uma palavra-chave Ansible, ela afirma que a seguir sempre será executada.
msg - Exibe a mensagem.
Uso da variável - {{Output}} ->
Isso lerá o valor da variável Output. Além disso, como é usado na guia msg, ele imprimirá o valor da variável de saída.
Além disso, você também pode usar as subpropriedades da variável. Como no caso, verificar {{Output.changed}} se a saída foi alterada e, portanto, use-a.
Tratamento de exceções em manuais
O tratamento de exceções em Ansible é semelhante ao tratamento de exceções em qualquer linguagem de programação. Um exemplo do tratamento de exceções no manual é mostrado abaixo.
tasks:
- name: Name of the task to be executed
block:
- debug: msg = 'Just a debug message , relevant for logging'
- command: <the command to execute>
rescue:
- debug: msg = 'There was an exception.. '
- command: <Rescue mechanism for the above exception occurred)
always:
- debug: msg = "this will execute in all scenarios. Always will get logged"A seguir está a sintaxe para tratamento de exceções.
rescue e always são as palavras-chave específicas para tratamento de exceções.
Bloco é onde o código é escrito (qualquer coisa a ser executada na máquina Unix).
Se o comando escrito dentro do recurso de bloco falhar, a execução atinge o bloco de resgate e é executado. Caso não haja erro no comando do recurso de bloqueio, o resgate não será executado.
Always é executado em todos os casos.
Portanto, se compararmos o mesmo com java, é semelhante a try, catch e finally block.
Aqui, Block é similar a try block onde você escreve o código a ser executado e rescue é similar a catch block e always é similar a finally.
rotações
Abaixo está o exemplo para demonstrar o uso de Loops no Ansible.
A tarefa é copiar o conjunto de todos os arquivos war de um diretório para a pasta tomcat webapps.
A maioria dos comandos usados no exemplo abaixo já foi abordada antes. Aqui, vamos nos concentrar no uso de loops.
Inicialmente no comando 'shell' executamos ls * .war. Portanto, ele listará todos os arquivos war no diretório.
A saída desse comando é obtida em uma variável chamada output.
Para fazer um loop, a sintaxe 'with_items' está sendo usada.
with_items: "{{output.stdout_lines}}" -> output.stdout_lines nos dá a saída linha por linha e então fazemos um loop na saída com o comando with_items de Ansible.
Anexar a saída de exemplo apenas para fazer entender como usamos stdout_lines no comando with_items.
---
#Tsting
- hosts: tomcat-node
tasks:
- name: Install Apache
shell: "ls *.war"
register: output
args:
chdir: /opt/ansible/tomcat/demo/webapps
- file:
src: '/opt/ansible/tomcat/demo/webapps/{{ item }}'
dest: '/users/demo/vivek/{{ item }}'
state: link
with_items: "{{output.stdout_lines}}"
Blocos
O manual é totalmente dividido em blocos. A menor parte das etapas a serem executadas é escrita em bloco. Escrever a instrução específica em blocos ajuda a separar a funcionalidade e tratá-la com tratamento de exceções, se necessário.
O exemplo de blocos é abordado em uso de variável, tratamento de exceção e loops acima.
Condicionais
As condicionais são usadas quando é necessário executar uma etapa específica com base em uma condição.
---
#Tsting
- hosts: all
vars:
test1: "Hello Vivek"
tasks:
- name: Testing Ansible variable
debug:
msg: "Equals"
when: test1 == "Hello Vivek"Nesse caso, Equals será impresso, pois a variável test1 é igual conforme mencionado na condição when. when pode ser usado com uma condição lógica OR e AND lógica como em todas as linguagens de programação.
Basta alterar o valor da variável test1 de Hello Vivek para dizer Hello World e ver a saída.
Neste capítulo, aprenderemos o que é execução avançada com Ansible.
Como limitar a execução por tarefas
Esta é uma estratégia de execução muito importante, em que é necessário executar apenas uma execução e não todo o manual. For example, suponha que você deseja apenas parar um servidor (no caso de ocorrer um problema de produção) e, em seguida, postar a aplicação de um patch que deseja apenas iniciar o servidor.
Aqui, no manual original, parar e iniciar faziam parte de diferentes papéis no mesmo manual, mas isso pode ser resolvido com o uso de tags. Podemos fornecer tags diferentes para funções diferentes (que por sua vez terão tarefas) e, portanto, com base nas tags fornecidas pelo executor, apenas a função / tarefa especificada é executada. Portanto, para o exemplo acima fornecido, podemos adicionar tags como as seguintes -
- {role: start-tomcat, tags: ['install']}}O seguinte comando ajuda a usar tags -
ansible-playbook -i hosts <your yaml> --tags "install" -vvvCom o comando acima, apenas a função start-tomcat será chamada. A tag fornecida diferencia maiúsculas de minúsculas. Certifique-se de que a correspondência exata está sendo passada para o comando.
Como limitar a execução por hosts
Existem duas maneiras de realizar a execução de etapas específicas em hosts específicos. Para uma função específica, são definidos os hosts - em quais hosts específicos essa função específica deve ser executada.
Exemplo
- hosts: <A>
environment: "{{your env}}"
pre_tasks:
- debug: msg = "Started deployment.
Current time is {{ansible_date_time.date}} {{ansible_date_time.time}} "
roles:
- {role: <your role>, tags: ['<respective tag>']}
post_tasks:
- debug: msg = "Completed deployment.
Current time is {{ansible_date_time.date}} {{ansible_date_time.time}}"
- hosts: <B>
pre_tasks:
- debug: msg = "started....
Current time is {{ansible_date_time.date}} {{ansible_date_time.time}} "
roles:
- {role: <your role>, tags: ['<respective tag>']}
post_tasks:
- debug: msg = "Completed the task..
Current time is {{ansible_date_time.date}} {{ansible_date_time.time}}"Conforme o exemplo acima, dependendo dos hosts fornecidos, as respectivas funções serão apenas chamadas. Agora meus hosts A e B estão definidos nos hosts (arquivo de inventário).
Solução Alternativa
Uma solução diferente pode ser definir os hosts do manual usando uma variável e, em seguida, passar um endereço de host específico por meio de --extra-vars -
# file: user.yml (playbook)
---
- hosts: '{{ target }}'
user: ...
playbook contd….Executando o Playbook
ansible-playbook user.yml --extra-vars "target = "<your host variable>"Se {{target}} não for definido, o manual não fará nada. Um grupo do arquivo hosts também pode ser passado, se necessário. Isso não prejudica se o vars extra não for fornecido.
Manual direcionado a um único host
$ ansible-playbook user.yml --extra-vars "target = <your hosts variable>" --listhostsAs estratégias mais comuns para depurar manuais do Ansible estão usando os módulos fornecidos abaixo -
Depurar e registrar
Esses dois são os módulos disponíveis no Ansible. Para fins de depuração, precisamos usar os dois módulos criteriosamente. Exemplos são demonstrados a seguir.
Use verbosidade
Com o comando Ansible, pode-se fornecer o nível de detalhamento. Você pode executar os comandos com nível de detalhamento um (-v) ou dois (-vv).
Pontos importantes
Nesta seção, veremos alguns exemplos para entender alguns conceitos.
Se você não está citando um argumento que começa com uma variável. Por exemplo,
vars:
age_path: {{vivek.name}}/demo/
{{vivek.name}}Isso gerará um erro.
Solução
vars:
age_path: "{{vivek.name}}/demo/" – marked in yellow is the fix.
How to use register -> Copy this code into a yml file say test.yml and run it
---
#Tsting
- hosts: tomcat-node
tasks:
- shell: /usr/bin/uptime
register: myvar
- name: Just debugging usage
debug: var = myvarQuando executo este código por meio do comando Ansible-playbook -i hosts test.yml, obtenho a saída conforme mostrado abaixo.
Se você vir o yaml, nós registramos a saída de um comando em uma variável - myvar e apenas imprimiu a saída.
O texto marcado em amarelo nos fala sobre a propriedade da variável –myvar que pode ser usada para controle de fluxo posterior. Desta forma, podemos descobrir mais sobre as propriedades expostas de uma determinada variável. O seguinte comando debug ajuda nisso.
$ ansible-playbook -i hosts test.yml
PLAY [tomcat-node] ***************************************************************
**************** ****************************************************************
*************** ******************************
TASK [Gathering Facts] *****************************************************************
************** *****************************************************************
************** **************************
Monday 05 February 2018 17:33:14 +0530 (0:00:00.051) 0:00:00.051 *******
ok: [server1]
TASK [command] ******************************************************************
************* ******************************************************************
************* **********************************
Monday 05 February 2018 17:33:16 +0530 (0:00:01.697) 0:00:01.748 *******
changed: [server1]
TASK [Just debugging usage] ******************************************************************
************* ******************************************************************
************* *********************
Monday 05 February 2018 17:33:16 +0530 (0:00:00.226) 0:00:01.974 *******
ok: [server1] => {
"myvar": {
"changed": true,
"cmd": "/usr/bin/uptime",
"delta": "0:00:00.011306",
"end": "2018-02-05 17:33:16.424647",
"rc": 0,
"start": "2018-02-05 17:33:16.413341",
"stderr": "",
"stderr_lines": [],
"stdout": " 17:33:16 up 7 days, 35 min, 1 user, load average: 0.18, 0.15, 0.14",
"stdout_lines": [
" 17:33:16 up 7 days, 35 min, 1 user, load average: 0.18, 0.15, 0.14"
]
}
}
PLAY RECAP ****************************************************************************
**********************************************************************************
**************************************
server1 : ok = 3 changed = 1 unreachable = 0 failed = 0Problemas comuns do manual
Nesta seção, aprenderemos sobre alguns problemas comuns do manual. Os problemas são -
- Quoting
- Indentation
O manual é escrito no formato yaml e os dois acima são os problemas mais comuns no yaml / manual.
Yaml não suporta recuo baseado em tabulação e suporta recuo baseado em espaço, então é preciso ter cuidado com o mesmo.
Note - assim que terminar de escrever o yaml, abra este site (https://editor.swagger.io/) e copie e cole seu yaml no lado esquerdo para garantir que o yaml seja compilado corretamente. Esta é apenas uma dica.
O Swagger qualifica erros em avisos e também erros.