Instalação no Linux Debian/Ubuntu

2024-01-01T00:00:00+00:00

Instalação no Linux Debian/Ubuntu</h1>

O que você vai aprender</strong></p>

Reproduzir o que a página mostra sobre Método 1: APT (Recomendado para Produção)</strong></li>
Reproduzir o que a página mostra sobre Método 2: pip (Recomendado para Desenvolvimento)</strong></li>
Reproduzir o que a página mostra sobre Método 3: pip com Requirements</strong></li>
Reproduzir o que a página mostra sobre Configuração Pós-Instalação</strong></li>
Reconhecer, em um playbook alheio, onde cada um desses recursos foi usado</li> </ul> </div>

Antes de começar</strong></p>

Uma máquina Linux ou macOS com acesso a terminal</li> </ul> </div>
Método 1: APT (Recomendado para Produção)</h2>
Passo 1: Atualizar Repositórios</h3>
sudo apt update </code></pre> Passo 2: Instalar Software Properties</h3> sudo apt install -y software-properties-common </code></pre> Passo 3: Adicionar Repositório Ansible (versão mais recente)</h3> sudo apt-add-repository --yes --update ppa:ansible/ansible </code></pre> Passo 4: Instalar Ansible</h3> sudo apt install -y ansible </code></pre> Passo 5: Verificar Instalação</h3> ansible --version </code></pre> Saída esperada:</strong></p> ansible [core 2.16.x] config file = /etc/ansible/ansible.cfg configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3/dist-packages/ansible ansible collection location = /home/user/.ansible/collections/ansible_collections executable location = /usr/bin/ansible python version = 3.12.x </code></pre> Método 2: pip (Recomendado para Desenvolvimento)</h2> Instalar pip e dependências</h3> sudo apt update sudo apt install -y python3-pip python3-venv python3-full </code></pre> Criar ambiente virtual (recomendado)</h3> # Criar ambiente virtual python3 -m venv ~/.venv/ansible # Ativar ambiente source ~/.venv/ansible/bin/activate # Instalar Ansible pip install ansible </code></pre> Sem ambiente virtual (descontinuado)</h3> pip3 install ansible --user </code></pre> Desativar ambiente virtual</h3> deactivate </code></pre> Método 3: pip com Requirements</h2> Criar arquivo de requirements</h3> # requirements.txt ansible==2.16.3 ansible-core==2.16.3 </code></pre> Instalar</h3> pip install -r requirements.txt </code></pre> Configuração Pós-Instalação</h2> 1. Criar diretório de projetos</h3> mkdir -p ~/ansible-projects cd ~/ansible-projects </code></pre> 2. Configurar ansible.cfg (opcional)</h3> # Criar configuração local cat > ansible.cfg << 'EOF' [defaults] inventory = ./inventory host_key_checking = False retry_files_enabled = False interpreter_python = auto_silent [privilege_escalation] become = True become_method = sudo become_user = root become_ask_pass = False EOF </code></pre> 3. Criar inventário inicial</h3> cat > inventory << 'EOF' [local] localhost ansible_connection=local [webservers] web1.example.com web2.example.com [dbservers] db1.example.com EOF </code></pre> 4. Testar conectividade</h3> # Ping localhost ansible localhost -m ping # Listar hosts ansible all --list-hosts </code></pre> Atualização</h2> via APT</h3> sudo apt update sudo apt upgrade ansible -y </code></pre> via pip</h3> pip install --upgrade ansible </code></pre> Desinstalação</h2> via APT</h3> sudo apt remove ansible -y sudo apt autoremove -y </code></pre> via pip</h3> pip uninstall ansible -y </code></pre> Problemas Comuns</h2> "apt-add-repository: command not found"</h3> sudo apt install -y software-properties-common </code></pre> "sudo: apt-add-repository: command not found"</h3> Mesmo erro, o pacote software-properties-common</code> não está instalado.</p> Conflito de versões</h3> Se tiver múltiplas versões:</p> # Remover versão do sistema sudo apt remove ansible -y # Usar apenas pip pip install ansible </code></pre> Verificação Final</h2> # Ver todas as tasks disponíveis ansible-doc -l | head -20 # Testar módulo ping ansible localhost -m ping # Ver configuração ansible-config dump </code></pre> Dica:</strong> Para ambientes de produção, use o método APT com repositório oficial. Para desenvolvimento, pip com venv oferece mais flexibilidade.</p> Exercício</h2> Instalar Ansible no Ubuntu/Debian</strong></p> Atualize os repositórios: sudo apt update</code></li> Instale o Ansible: sudo apt install -y ansible</code></li> Verifique a versão: ansible --version</code></li> Teste com ansible localhost -m ping</code></li> Execute ansible-doc -l | wc -l</code> para contar módulos disponíveis</li> </ol> </blockquote> Você aprendeu</strong></p> Método 1: APT (Recomendado para Produção)</strong> — com exemplo pronto para copiar</li> Método 2: pip (Recomendado para Desenvolvimento)</strong> — com exemplo pronto para copiar</li> Método 3: pip com Requirements</strong> — com exemplo pronto para copiar</li> Configuração Pós-Instalação</strong> — com exemplo pronto para copiar</li> Todo exemplo desta página deve ser idempotente: rodar duas vezes não pode relatar changed</code> na segunda</li> </ul> </div> Perguntas para reflexão</strong></p> Que problema Método 1: APT (Recomendado para Produção)</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Método 2: pip (Recomendado para Desenvolvimento)</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Método 3: pip com Requirements</strong> resolve, e em que situação você recorreria a isso?</li> Qual dos exemplos desta página você reescreveria de memória, sem consultar?</li> Rodando duas vezes, algum exemplo desta página relataria changed</code> na segunda?</li> </ul> </div> Desafio: rode duas vezes</strong></p> Rode os exemplos desta página numa máquina de teste e depois rode de novo, sem alterar nada.</p> Se a segunda execução relatar changed</code>, alguma task não é idempotente — e descobrir qual, com o exemplo pequeno desta página, é bem mais barato do que descobrir num playbook de produção.</p> </div> Leia também</strong></p> Config Files</a> — O arquivo ansible.cfg: onde ele pode estar, quais seções importam e a…</li> Instalação Debian Ubuntu</a> — instalar o Ansible no Debian e no Ubuntu: apt, PPA, pip em ambiente…</li> Instalação RHEL Fedora</a> — instalando Ansible no RHEL/Fedora</li> Instalação macOS</a> — instalar o Ansible no macOS com Homebrew ou pip, e os detalhes de fork e…</li> </ul> </div> Referências</h2> Ansible — Installing Ansible</a></li> </ol>

Verificação da Instalação

2024-01-01T00:00:00+00:00

Verificação da Instalação</h1>

O que você vai aprender</strong></p>

Reproduzir o que a página mostra sobre Testes Básicos</strong></li>
Reproduzir o que a página mostra sobre Testes de Configuração</strong></li>
Reproduzir o que a página mostra sobre Verificar Conectividade SSH</strong></li>
Reproduzir o que a página mostra sobre Verificar Collections</strong></li>
Reconhecer, em um playbook alheio, onde cada um desses recursos foi usado</li> </ul> </div>

Antes de começar</strong></p>

Uma máquina Linux ou macOS com acesso a terminal</li> </ul> </div>
Testes Básicos</h2>
1. Verificar Versão</h3>
ansible --version </code></pre> Saída esperada:</strong></p> ansible [core 2.16.3] config file = /home/user/.ansible/ansible.cfg configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3/dist-packages/ansible ansible collection location = /home/user/.ansible/collections/ansible_collections executable location = /usr/bin/ansible python version = 3.12.2 </code></pre> 2. Verificar Módulos</h3> # Listar módulos disponíveis ansible-doc -l | head -20 # Contar total de módulos ansible-doc -l | wc -l </code></pre> 3. Testar Ping Local</h3> # Com connection=local ansible localhost -m ping </code></pre> Saída de sucesso:</strong></p> localhost | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "changed": false, "ping": "pong" } </code></pre> Testes de Configuração</h2> Ver Arquivo de Configuração</h3> # Mostrar configuração atual ansible-config dump # Ver configuração apenas do inventario ansible-inventory --list </code></pre> Criar Projeto de Teste</h3> mkdir -p ~/ansible-test cd ~/ansible-test cat > inventory << 'EOF' [local] localhost ansible_connection=local [webservers] web1 ansible_host=127.0.0.1 web2 ansible_host=127.0.0.2 EOF cat > test.yml << 'EOF' --- - name: Teste de instalação hosts: localhost tasks: - name: Verificar Python debug: msg: "Python {{ ansible_facts['python_version'] }}" - name: Testar variável set_fact: test_var: "Instalação OK" - name: Mostrar resultado debug: var: test_var EOF </code></pre> Executar Playbook de Teste</h3> ansible-playbook -i inventory test.yml </code></pre> Verificar Conectividade SSH</h2> Testar SSH Local</h3> ssh localhost "echo 'SSH funciona'" </code></pre> Verificar SSH Key</h3> ls -la ~/.ssh/ cat ~/.ssh/id_rsa.pub </code></pre> Verificar Collections</h2> # Listar collections instaladas ansible-galaxy collection list # Ver collections no path padrão ls -la ~/.ansible/collections/ansible_collections/ </code></pre> Problemas Comuns e Soluções</h2> "ansible: command not found"</h3> Causa</strong>: Ansible não está no PATH</p> Solução</strong>:</p> # Encontrar onde está which ansible # Adicionar ao PATH (adicione ao ~/.bashrc) export PATH="$HOME/.local/bin:$PATH" # Ou usar python3 -m ansible python3 -m ansible --version </code></pre> "python3: command not found"</h3> Solução</strong>:</p> # Linux sudo apt install python3 # Debian/Ubuntu sudo dnf install python3 # RHEL/Fedora # macOS brew install python@3.12 </code></pre> "Authentication or permission failure"</h3> Solução</strong>:</p> # Verificar SSH ssh -v user@host # Gerar/copiar chave ssh-keygen -t ed25519 ssh-copy-id user@host </code></pre> "Module Not Found"</h3> Solução</strong>:</p> # Reinstalar pip install --force-reinstall ansible # Ou com venv source ~/.venv/ansible/bin/activate pip install --force-reinstall ansible </code></pre> Checklist de Verificação</h2> Item</th> Comando</th> Sucesso se</th></tr></thead> Ansible instalado</td> ansible --version</code></td> Mostra versão</td></tr> Python OK</td> python3 --version</code></td> Python 3.9+</td></tr> Módulos OK</td> ansible-doc -l | head -5</code></td> Lista módulos</td></tr> Ping local</td> ansible localhost -m ping</code></td> SUCCESS</td></tr> Config dump</td> ansible-config dump</code></td> Mostra config</td></tr> Inventory</td> ansible-inventory --list</code></td> Mostra JSON</td></tr> Playbook syntax</td> ansible-playbook --syntax-check test.yml</code></td> CHECK SUCCEEDED</td></tr> </tbody></table> Próximos Passos</h2> Após verificar a instalação:</p> Configure seu inventário</a></li> Execute seu primeiro playbook</a></li> Aprenda sobre módulos</a></li> </ol> Sucesso!</strong> Se todos os testes passaram, sua instalação está funcionando. Continue para a próxima seção.</p> Você aprendeu</strong></p> Testes Básicos</strong> — com exemplo pronto para copiar</li> Testes de Configuração</strong> — com exemplo pronto para copiar</li> Verificar Conectividade SSH</strong> — com exemplo pronto para copiar</li> Verificar Collections</strong> — com exemplo pronto para copiar</li> Todo exemplo desta página deve ser idempotente: rodar duas vezes não pode relatar changed</code> na segunda</li> </ul> </div> Perguntas para reflexão</strong></p> Que problema Testes Básicos</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Testes de Configuração</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Verificar Conectividade SSH</strong> resolve, e em que situação você recorreria a isso?</li> Qual dos exemplos desta página você reescreveria de memória, sem consultar?</li> Rodando duas vezes, algum exemplo desta página relataria changed</code> na segunda?</li> </ul> </div> Desafio: rode duas vezes</strong></p> Rode os exemplos desta página numa máquina de teste e depois rode de novo, sem alterar nada.</p> Se a segunda execução relatar changed</code>, alguma task não é idempotente — e descobrir qual, com o exemplo pequeno desta página, é bem mais barato do que descobrir num playbook de produção.</p> </div> Leia também</strong></p> Config Files</a> — O arquivo ansible.cfg: onde ele pode estar, quais seções importam e a…</li> Instalação Debian Ubuntu</a> — instalar o Ansible no Debian e no Ubuntu: apt, PPA, pip em ambiente…</li> Instalação RHEL Fedora</a> — instalando Ansible no RHEL/Fedora</li> Instalação macOS</a> — instalar o Ansible no macOS com Homebrew ou pip, e os detalhes de fork e…</li> </ul> </div> Referências</h2> Ansible — Installing Ansible</a></li> </ol> Arquitetura do Ansible 2024-01-01T00:00:00+00:00 Arquitetura do Ansible</h1> O que você vai aprender</strong></p> Reproduzir o que a página mostra sobre Visão Geral</strong></li> Reproduzir o que a página mostra sobre Componentes Principais</strong></li> Reproduzir o que a página mostra sobre Fluxo de Execução</strong></li> Reproduzir o que a página mostra sobre Authentication e Conectividade</strong></li> Reconhecer, em um playbook alheio, onde cada um desses recursos foi usado</li> </ul> </div> Visão Geral</h2> O Ansible possui uma arquitetura simples mas poderosa composta por:</p> ┌─────────────────────────────────────────────────────────────┐ │ CONTROL NODE │ │ │ │ ┌─────────┐ ┌─────────────┐ ┌──────────────────────┐ │ │ │ Playbook│ │ Modules │ │ Plugins │ │ │ │ (YAML) │ │ (Executors) │ │ (Extensions) │ │ │ └────┬────┘ └──────┬──────┘ └──────────┬───────────┘ │ │ │ │ │ │ │ └──────────────┼─────────────────────┘ │ │ ▼ │ │ ┌─────────────────┐ │ │ │ Ansible Core │ │ │ │ (Engine/CLI) │ │ │ └────────┬────────┘ │ │ │ │ │ ┌────────▼────────┐ │ │ │ Inventory │ │ │ │ (Hosts List) │ │ │ └────────┬────────┘ │ └─────────────────────┼───────────────────────────────────────┘ │ SSH/WinRM ┌───────────┼───────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Node 1 │ │ Node 2 │ │ Node N │ │(Managed) │ │(Managed) │ │(Managed) │ └──────────┘ └──────────┘ └──────────┘ </code></pre> Componentes Principais</h2> 1. Control Node</h3> O Control Node</strong> (ou nó de controle) é a máquina onde o Ansible está instalado e de onde a automação é executada.</p> Requisitos:</strong></p> Sistema operacional: Linux, macOS, ou WSL (Windows Subsystem for Linux)</li> Python 3.9+ instalado</li> Acesso SSH aos nodes gerenciados</li> Não pode ser Windows (nativamente)</li> </ul> # Verificar requirements do control node python3 --version ssh -V </code></pre> 2. Managed Nodes</h3> São os servidores-alvo</strong> que serão configurados pelo Ansible. Podem ser:</p> Linux/Unix servers</strong> - Comunicados via SSH</li> Windows servers</strong> - Comunicados via WinRM</li> Dispositivos de rede</strong> - Comunicados via API ou SSH</li> Serviços cloud</strong> - AWS, GCP, Azure via módulos específicos</li> </ul> Requisitos mínimos nos managed nodes:</strong></p> Python 2.7+ (ou Python 3.5+) - exceto para módulos raw</code> ou script</code></li> SSH server rodando</li> Credenciais de acesso válidas</li> </ul> 3. Inventário (Inventory)</h3> O Inventário</strong> é uma lista de hosts (máquinas gerenciadas) organizados em grupos.</p> # Formato INI tradicional [webservers] web1.example.com web2.example.com 192.168.1.10 [dbservers] db1.example.com db2.example.com [datacenter:children] webservers dbservers </code></pre> # Formato YAML all: hosts: web1.example.com: web2.example.com: children: webservers: hosts: web1.example.com: web2.example.com: </code></pre> 4. Playbooks</h3> Playbooks são arquivos YAML</strong> que contêm a automação desejada em formato declarativo.</p> --- - name: Playbook de configuração de webserver hosts: webservers become: yes tasks: - name: Instalar Nginx apt: name: nginx state: present - name: Iniciar serviço Nginx service: name: nginx state: started enabled: yes </code></pre> 5. Módulos (Modules)</h3> Módulos</strong> são unidades atômicas de trabalho. Cada módulo executa uma tarefa específica.</p> Categorias de Módulos:</strong></p> Categoria</th> Exemplos</th> Descrição</th></tr></thead> System</strong></td> user, group, service, mount</td> Gerenciamento de SO</td></tr> Commands</strong></td> command, shell, script, raw</td> Execução de comandos</td></tr> Files</strong></td> copy, file, template, lineinfile</td> Manipulação de arquivos</td></tr> Packages</strong></td> apt, yum, dnf, pip</td> Gerenciamento de pacotes</td></tr> Cloud</strong></td> ec2, azure_rm, gce</td> Provedores cloud</td></tr> Network</strong></td> ios_config, nxos, eos</td> Equipamentos de rede</td></tr> </tbody></table> 6. Plugins</h3> Plugins</strong> estendem a funcionalidade core do Ansible.</p> Tipos de Plugins:</strong></p> Connection Plugins</strong> - Como conectar aos hosts (SSH, WinRM, local)</li> Lookup Plugins</strong> - Buscar dados de fontes externas (file, env, API)</li> Filter Plugins</strong> - Transformar dados Jinja2</li> Callback Plugins</strong> - Hooks para eventos (log, notificação)</li> Strategy Plugins</strong> - Controlar ordem de execução de tasks</li> </ul> 7. Collections</h3> Collections</strong> (a partir do Ansible 2.9) são o formato de distribuição de conteúdo.</p> namespace/ └── collection_name/ ├── plugins/ │ ├── modules/ │ ├── lookup/ │ └── filter/ ├── roles/ ├── playbooks/ └── README.md </code></pre> Fluxo de Execução</h2> 1. Parse do Playbook (YAML → AST) ↓ 2. Leitura do Inventário (hosts + grupos) ↓ 3. Build do grafo de dependências ↓ 4. Para cada Play: a. Filtrar hosts pelo pattern b. Para cada Host: - Coletar facts (se gather_facts: yes) - Para cada Task: - Selecionar módulo - Passar parâmetros - Executar via conexão - Coletar resultado - Notificar handlers se necessário ↓ 5. Executar Handlers (se notificados) ↓ 6. Resumo (PLAY RECAP) </code></pre> Authentication e Conectividade</h2> Linux/Unix</h3> Método</th> Configuração</th></tr></thead> SSH Key</strong></td> ssh-copy-id user@host</code></td></tr> SSH Agent</strong></td> ssh-agent bash && ssh-add</code></td></tr> Password</strong></td> Prompt interativo ou ansible-vault</code></td></tr> Become</strong></td> sudo</code>, su</code>, pfexec</code>, doas</code></td></tr> </tbody></table> Windows</h3> Método</th> Requisitos</th></tr></thead> WinRM</strong></td> PowerShell 3+, pywinrm</td></tr> SSH</strong></td> OpenSSH instalado</td></tr> NTLM/Kerberos</strong></td> Para domínios AD</td></tr> </tbody></table> Exemplo de Fluxo Completo</h2> # 1. Criar inventário cat > inventory.ini << 'EOF' [webservers] server1 ansible_host=192.168.1.10 ansible_user=ubuntu server2 ansible_host=192.168.1.11 ansible_user=ubuntu EOF # 2. Criar playbook cat > site.yml << 'EOF' --- - name: Configurar Webservers hosts: webservers become: yes tasks: - name: Instalar Nginx apt: name: nginx state: present EOF # 3. Executar ansible-playbook -i inventory.ini site.yml </code></pre> Dica:</strong> O fluxo é sempre: Inventário → Playbook → Módulos → Nodes. Entenda cada peça para dominar o Ansible.</p> Exercício</h2> Exercício</h2> Mapeie a arquitetura</strong></p> Identifique o Control Node no seu ambiente</li> Liste 3 managed nodes (reais ou fictícios)</li> Crie um inventário com pelo menos 2 grupos</li> Execute ansible all -i inventory.ini -m ping</code> para testar conectividade</li> </ol> </blockquote> Você aprendeu</strong></p> Visão Geral</strong> — com exemplo pronto para copiar</li> Componentes Principais</strong> — com exemplo pronto para copiar</li> Fluxo de Execução</strong> — com exemplo pronto para copiar</li> Authentication e Conectividade</strong> — com exemplo pronto para copiar</li> Todo exemplo desta página deve ser idempotente: rodar duas vezes não pode relatar changed</code> na segunda</li> </ul> </div> Perguntas para reflexão</strong></p> Que problema Visão Geral</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Componentes Principais</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Fluxo de Execução</strong> resolve, e em que situação você recorreria a isso?</li> Qual dos exemplos desta página você reescreveria de memória, sem consultar?</li> Rodando duas vezes, algum exemplo desta página relataria changed</code> na segunda?</li> </ul> </div> Desafio: rode duas vezes</strong></p> Rode os exemplos desta página numa máquina de teste e depois rode de novo, sem alterar nada.</p> Se a segunda execução relatar changed</code>, alguma task não é idempotente — e descobrir qual, com o exemplo pequeno desta página, é bem mais barato do que descobrir num playbook de produção.</p> </div> Leia também</strong></p> Ad-hoc vs Playbook</a> — quando usar um comando ad-hoc e quando escrever um playbook: as duas…</li> Cases de Uso</a> — casos de uso Ansible</li> Comparativo Ferramentas</a> — comparando Ansible com outras ferramentas</li> Comparativo: Ansible vs outras ferramentas</a> — comparação do Ansible com Puppet, Chef, SaltStack, Terraform e Pulumi</li> </ul> </div> Referências</h2> Ansible — Getting started</a></li> Ansible — Glossary</a></li> </ol> Comparativo: Ansible vs outras ferramentas 2024-01-01T00:00:00+00:00 Comparativo: Ansible vs Outras Ferramentas</h1> O que você vai aprender</strong></p> Reproduzir o que a página mostra sobre Visão Geral das Ferramentas</strong></li> Reproduzir o que a página mostra sobre Ansible vs Puppet</strong></li> Reproduzir o que a página mostra sobre Ansible vs Chef</strong></li> Reproduzir o que a página mostra sobre Ansible vs SaltStack</strong></li> Reconhecer, em um playbook alheio, onde cada um desses recursos foi usado</li> </ul> </div> Visão Geral das Ferramentas</h2> Ferramenta</th> Tipo</th> Modelo</th> Paradigma</th></tr></thead> Ansible</strong></td> Configuração + Orquestração</td> Push</td> Declarativo</td></tr> Puppet</strong></td> Configuração</td> Pull</td> Declarativo</td></tr> Chef</strong></td> Configuração</td> Pull</td> Procedural</td></tr> SaltStack</strong></td> Configuração + Orquestração</td> Push/Pull</td> Declarativo</td></tr> Terraform</strong></td> Infrastructure as Code</td> Push</td> Declarativo</td></tr> Pulumi</strong></td> Infrastructure as Code</td> Push</td> Imperativo/Declarativo</td></tr> </tbody></table> Ansible vs Puppet</h2> Sem Agente vs Com Agente</h3> Aspecto</th> Ansible</th> Puppet</th></tr></thead> Agent</strong></td> Não requer (SSH)</td> Requer instalar puppet-agent</td></tr> Porta</strong></td> 22 (SSH)</td> 8140 (Puppet Master)</td></tr> Latência</strong></td> Maior (SSH overhead)</td> Menor (agente local)</td></tr> Setup</strong></td> Mais simples</td> Mais complexo</td></tr> </tbody></table> DSL e Legibilidade</h3> Ansible (YAML)</strong> - Mais legível:</p> - name: Instalar Nginx apt: name: nginx state: present </code></pre> Puppet (PP DSL)</strong>:</p> package { 'nginx': ensure => present, } </code></pre> Casos de Uso</h3> Situação</th> Recomendação</th></tr></thead> Configuração de servidores novos</td> Ansible</td></tr> Gerenciamento contínuo de estado</td> Puppet</td></tr> Infraestrutura como código</td> Terraform</td></tr> Orquestração de containers</td> Ansible + Kubernetes</td></tr> Ambientes híbriddos Linux/Windows</td> Ansible</td></tr> </tbody></table> Ansible vs Chef</h2> Modelo de Execução</h3> Aspecto</th> Ansible</th> Chef</th></tr></thead> Modelo</strong></td> Push (controla quando executa)</td> Pull (agentes puxam código)</td></tr> Execução</strong></td> sob demanda</td> contínua (a cada 30min por padrão)</td></tr> Idempotência</strong></td> inerente nos módulos</td> garantida por recursos</td></tr> </tbody></table> Abordagem</h3> Ansible</strong> - Declarativo:</p> - name: Garantir diretório existe file: path: /opt/myapp state: directory mode: '0755' </code></pre> Chef</strong> - Procedural (você descreve como):</p> directory '/opt/myapp' do owner 'root' group 'root' mode '0755' action :create end </code></pre> Ansible vs SaltStack</h2> Similaridades</h3> Ambos suportam SSH como transporte</li> Ambos usam YAML para configuração</li> Ambos têm arquitetura master/agent (Salt) ou pure push (Ansible)</li> </ul> Diferenças</h3> Aspecto</th> Ansible</th> SaltStack</th></tr></thead> Agente</strong></td> Opcional (requer se usar pull mode)</td> Recomendado (always-on)</td></tr> Performance</strong></td> Lento para pequenas tasks</td> Muito rápido (ZeroMQ)</td></tr> Curva de aprendizado</strong></td> Menor</td> Maior</td></tr> Comunidade</strong></td> Maior</td> Menor</td></tr> </tbody></table> Ansible vs Terraform</h2> Diferença Fundamental</h3> Aspecto</th> Ansible</th> Terraform</th></tr></thead> Propósito</strong></td> Configuração de SO e apps</td> Infraestrutura (IaaS)</td></tr> Estado</strong></td> Stateless (idempotente)</td> Statefull (mantém estado)</td></tr> Ordem</strong></td> Tasks/Plays</td> Plan/Apply</td></tr> Recursos</strong></td> Módulos (~2500)</td> Providers (~1000)</td></tr> </tbody></table> Quando Usar Cada Um</h3> # Terraform - Criar infraestrutura terraform apply -var="environment=prod" # Ansible - Configurar após criar ansible-playbook -i inventory.py site.yml </code></pre> Integração Ansible + Terraform</h3> # Terraform chama Ansible após criar VMs resource "null_resource" "ansible" { provisioner "local-exec" { command = "ansible-playbook -i '${aws_instance.web.public_ip},' site.yml" } } </code></pre> Ansible vs Pulumi</h2> Abordagem</h3> Aspecto</th> Ansible</th> Pulumi</th></tr></thead> Linguagem</strong></td> YAML</td> Python, TypeScript, Go, C#</td></tr> Paradigma</strong></td> Declarativo YAML</td> Imperativo/Declarativo com linguagem</td></tr> Estado</strong></td> Não mantém</td> Mantém estado</td></tr> Debugging</strong></td> Limitado</td> Full IDE support</td></tr> </tbody></table> Matriz de Decisão</h2> ┌─────────────────────┐ │ O QUE VOCÊ PRECISA? │ └──────────┬──────────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌──────────────┐ ┌─────────────┐ ┌────────────┐ │ Infraestrutura│ │ Configuração│ │Orquestração│ │ (VMs, Redes) │ │ (SO, App) │ │ (Containers│ │ │ │ │ │ , Deploy) │ └──────┬───────┘ └──────┬──────┘ └─────┬──────┘ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │Terraform │ │ Ansible │ │ Ansible │ │Pulumi │ │ Puppet │ │ K8s │ │ │ │ Chef │ │ Docker │ │ │ │ Salt │ │ Swarm │ └──────────┘ └──────────┘ └──────────┘ </code></pre> Tabela Comparativa Técnica</h2> Característica</th> Ansible</th> Puppet</th> Chef</th> Salt</th> Terraform</th></tr></thead> Linguagem</strong></td> YAML</td> Ruby PP</td> Ruby</td> YAML</td> HCL</td></tr> Agentless</strong></td> Sim</td> Não</td> Não</td> Opcional</td> Sim</td></tr> Licença</strong></td> GPLv3</td> Apache</td> Apache</td> Apache</td> BSL</td></tr> Comunidade</strong></td> Muito Grande</td> Grande</td> Média</td> Média</td> Muito Grande</td></tr> Curva de Aprendizado</strong></td> Baixa</td> Média</td> Média</td> Alta</td> Baixa</td></tr> Idempotência</strong></td> Sim</td> Sim</td> Sim</td> Sim</td> Sim</td></tr> Suporte Windows</strong></td> Bom</td> Bom</td> Bom</td> Bom</td> Médio</td></tr> Suporte Network</strong></td> Bom</td> Limitado</td> Limitado</td> Limitado</td> Médio</td></tr> Execução Paralela</strong></td> Sim</td> Sim</td> Sim</td> Sim</td> Paralelo</td></tr> Dry Run</strong></td> Sim</td> Sim</td> Sim</td> Sim</td> Plan</td></tr> </tbody></table> Resumo</h2> Use Ansible quando:</strong></p> Precisa de configuração de servidores sem agente</li> Já conhece YAML</li> Precisa de orquestração (multi-tier apps)</li> Quer simplicidade de uso</li> Tem ambiente híbrido Linux/Windows</li> </ul> Use Terraform quando:</strong></p> Foco em infraestrutura como código (IaaS)</li> Precisa criar/destruuir infraestrutura completa</li> Usa múltiplos provedores cloud</li> Precisa manter estado de infraestrutura</li> </ul> Use Puppet/Chef quando:</strong></p> Tem ambiente enterprise consolidado</li> Precisa de compliance contínuo</li> Tem equipe dedicada de DevOps</li> Prefere arquitetura pull-established</li> </ul> Nota:</strong> Muitos times usam Terraform + Ansible juntos: Terraform cria infraestrutura, Ansible configura os sistemas.</p> Você aprendeu</strong></p> Visão Geral das Ferramentas</strong> — com exemplo pronto para copiar</li> Ansible vs Puppet</strong> — com exemplo pronto para copiar</li> Ansible vs Chef</strong> — com exemplo pronto para copiar</li> Ansible vs SaltStack</strong> — com exemplo pronto para copiar</li> Todo exemplo desta página deve ser idempotente: rodar duas vezes não pode relatar changed</code> na segunda</li> </ul> </div> Perguntas para reflexão</strong></p> Que problema Visão Geral das Ferramentas</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Ansible vs Puppet</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Ansible vs Chef</strong> resolve, e em que situação você recorreria a isso?</li> Qual dos exemplos desta página você reescreveria de memória, sem consultar?</li> Rodando duas vezes, algum exemplo desta página relataria changed</code> na segunda?</li> </ul> </div> Desafio: rode duas vezes</strong></p> Rode os exemplos desta página numa máquina de teste e depois rode de novo, sem alterar nada.</p> Se a segunda execução relatar changed</code>, alguma task não é idempotente — e descobrir qual, com o exemplo pequeno desta página, é bem mais barato do que descobrir num playbook de produção.</p> </div> Leia também</strong></p> Ad-hoc vs Playbook</a> — quando usar um comando ad-hoc e quando escrever um playbook: as duas…</li> Arquitetura do Ansible</a> — arquitetura do Ansible - Control Node, Managed Nodes, Módulos, Inventário…</li> Cases de Uso</a> — casos de uso Ansible</li> Comparativo Ferramentas</a> — comparando Ansible com outras ferramentas</li> </ul> </div> Referências</h2> Ansible — Getting started</a></li> Ansible — Glossary</a></li> </ol> O que é Ansible? 2024-01-01T00:00:00+00:00 O que é Ansible?</h1> O que você vai aprender</strong></p> Reproduzir o que a página mostra sobre Definição</strong></li> Reproduzir o que a página mostra sobre Filosofia</strong></li> Reproduzir o que a página mostra sobre Características Principais</strong></li> Reproduzir o que a página mostra sobre História e Evolução</strong></li> Reconhecer, em um playbook alheio, onde cada um desses recursos foi usado</li> </ul> </div> Definição</h2> Ansible</strong> é uma ferramenta de automatização de TI</strong> open-source que permite configurar sistemas, implementar software e orquestrar tarefas complexas de infraestrutura. Foi criada por Michael DeHaan em 2012 e adquirida pela Red Hat em 2015.</p> Filosofia</h2> O Ansible segue princípios fundamentais:</p> Simplicidade</strong> - YAML legível por humanos para automação</li> Agentless</strong> - Não requer agente instalado nos nodes gerenciados</li> Idempotência</strong> - Executar múltiplas vezes produz o mesmo resultado</li> Push-based</strong> - Control node envia configurações para nodes</li> </ol> Características Principais</h2> Sem Agentes para Instalar</h3> Diferente de outras ferramentas como Puppet ou Chef, o Ansible não requer software-agent instalado nos servidores gerenciados. A comunicação acontece via SSH</strong> (Linux/Unix) ou WinRM</strong> (Windows).</p> Linguagem Declarativa</h3> Playbooks Ansible usam YAML</strong>, uma linguagem legível que descreve o estado desejado da infraestrutura:</p> # Exemplo: Garantir que Nginx está instalado - name: Instalar Nginx apt: name: nginx state: present </code></pre> Push vs Pull</h3> Modelo</th> Ferramentas</th> Como Funciona</th></tr></thead> Push</strong></td> Ansible</td> Control node envia comandos para nodes</td></tr> Pull</strong></td> Puppet, Chef</td> Nodes puxam configuração de servidor central</td></tr> </tbody></table> História e Evolução</h2> Ano</th> Evento</th></tr></thead> 2012</td> Michael DeHaan cria Ansible</td></tr> 2013</td> Lançamento público no GitHub</td></tr> 2015</td> Red Hat adquire Ansible</td></tr> 2019</td> Ansible AWX lançado (versão open source do Tower)</td></tr> 2022</td> Ansible 2.10+ com Collections</td></tr> </tbody></table> Casos de Uso</h2> O Ansible pode ser usado para:</p> Provisionamento</strong> - Criar VMs, containers, recursos cloud</li> Gerenciamento de Configuração</strong> - Manter estado consistente de sistemas</li> Deploy de Aplicações</strong> - Automatizar pipelines de release</li> Orquestração</strong> - Coordenar múltiplas tarefas em múltiplos servidores</li> Segurança e Compliance</strong> - Aplicar políticas de segurança</li> </ul> Quando NÃO Usar Ansible</h2> Necessidade de execução em tempo real</strong> (Ansible não é contínuo)</li> Processamento de dados</strong> massivo (não é um framework de processamento)</li> Infraestrutura Windows muito complexa (há limitações)</li> </ul> Próximos Passos</h2> Nota:</strong> Agora que você entende o que é Ansible, prossiga para a página de Arquitetura</a> para entender como os componentes funcionam juntos.</p> Exercício</h2> Explore a instalação do Ansible</strong></p> Verifique se o Ansible está instalado no seu sistema</li> Execute ansible --version</code></li> Observe a versão do Python utilizada</li> Liste os módulos disponíveis com ansible-doc -l | head -20</code></li> </ol> </blockquote> Você aprendeu</strong></p> Definição</strong> — com exemplo pronto para copiar</li> Filosofia</strong> — com exemplo pronto para copiar</li> Características Principais</strong> — com exemplo pronto para copiar</li> História e Evolução</strong> — com exemplo pronto para copiar</li> Todo exemplo desta página deve ser idempotente: rodar duas vezes não pode relatar changed</code> na segunda</li> </ul> </div> Perguntas para reflexão</strong></p> Que problema Definição</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Filosofia</strong> resolve, e em que situação você recorreria a isso?</li> Que problema Características Principais</strong> resolve, e em que situação você recorreria a isso?</li> Qual dos exemplos desta página você reescreveria de memória, sem consultar?</li> Rodando duas vezes, algum exemplo desta página relataria changed</code> na segunda?</li> </ul> </div> Desafio: rode duas vezes</strong></p> Rode os exemplos desta página numa máquina de teste e depois rode de novo, sem alterar nada.</p> Se a segunda execução relatar changed</code>, alguma task não é idempotente — e descobrir qual, com o exemplo pequeno desta página, é bem mais barato do que descobrir num playbook de produção.</p> </div> Leia também</strong></p> Ad-hoc vs Playbook</a> — quando usar um comando ad-hoc e quando escrever um playbook: as duas…</li> Arquitetura do Ansible</a> — arquitetura do Ansible - Control Node, Managed Nodes, Módulos, Inventário…</li> Cases de Uso</a> — casos de uso Ansible</li> Comparativo Ferramentas</a> — comparando Ansible com outras ferramentas</li> </ul> </div> Referências</h2> Ansible — Getting started</a></li> Ansible — Glossary</a></li> </ol> Terminologia Ansible 2024-01-01T00:00:00+00:00 Terminologia Ansible</h1> Conceitos Fundamentais</h2> Playbook</h3> Playbook</strong> é um arquivo YAML que descreve a automação desejada. Contém uma ou mais plays</strong> (peças).</p> --- - name: Meu primeiro playbook hosts: webservers tasks: - name: Instalar Nginx apt: name: nginx state: present </code></pre> Play</h3> Play</strong> é um bloco dentro do playbook que mapeia hosts para tasks.</p> - name: Configurar webservers # Nome do play hosts: webservers # Quais hosts become: yes # Executar como root tasks: # Lista de tasks - name: Instalar nginx apt: name: nginx state: present </code></pre> Task</h3> Task</strong> é a unidade mínima de trabalho, combina um módulo com argumentos.</p> tasks: - name: Copiar configuração # Nome descritivo template: # Módulo src: nginx.conf.j2 # Argumento dest: /etc/nginx/nginx.conf # Argumento notify: Restart Nginx # Handler trigger </code></pre> Module (Módulo)</h3> Módulo</strong> é o código executável que realiza a ação. Ansible vem com +2500 módulos embutidos.</p> Módulo</th> Função</th> Exemplo</th></tr></thead> apt</code> / yum</code></td> Instalar pacotes</td> apt: name=vim state=present</code></td></tr> copy</code></td> Copiar arquivos</td> copy: src=file dest=/tmp/</code></td></tr> file</code></td> Criar arquivos/dirs</td> file: path=/tmp mode=0755 state=directory</code></td></tr> service</code></td> Gerenciar serviços</td> service: name=nginx state=started</code></td></tr> command</code></td> Executar comando</td> command: /usr/bin/uptime</code></td></tr> shell</code></td> Executar shell</td> shell: cat /etc/os-release</code></td></tr> </tbody></table> Handler</h3> Handler</strong> é uma task especial executada apenas quando notificada.</p> handlers: - name: Restart Nginx service: name: nginx state: restarted tasks: - name: Copiar config template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf notify: Restart Nginx # Dispara o handler </code></pre> Role</h3> Role</strong> é uma estrutura de diretórios autocontida para organizar playbooks.</p> roles/ └── nginx/ ├── tasks/ │ └── main.yml ├── handlers/ │ └── main.yml ├── templates/ │ └── nginx.conf.j2 ├── vars/ │ └── main.yml └── defaults/ └── main.yml </code></pre> Collection</h3> Collection</strong> é o formato de distribuição do Ansible 2.9+.</p> namespace/ └── collection_name/ ├── plugins/ │ └── modules/ ├── roles/ ├── playbooks/ └── README.md </code></pre> Inventory (Inventário)</h3> Inventário</strong> lista os hosts gerenciados.</p> # INI format [webservers] web1.example.com web2.example.com [dbservers] db1.example.com [datacenter:children] webservers dbservers </code></pre> # YAML format all: children: webservers: hosts: web1.example.com: web2.example.com: </code></pre> Facts (Fatos)</h3> Facts</strong> são informações coletadas automaticamente sobre cada host.</p> # Coletar facts ansible all -m setup </code></pre> # Acessar facts - debug: var: ansible_facts['distribution'] - debug: var: ansible_facts['default_ipv4']['address'] </code></pre> Variables (Variáveis)</h3> Variáveis</strong> armazenam valores para usar nos playbooks.</p> # Definição vars: http_port: 80 app_name: myapp # Uso - name: Configurar Nginx template: src: "{{ app_name }}.conf.j2" dest: /etc/nginx/conf.d/{{ http_port }}.conf </code></pre> Jinja2 Template</h3> Template Jinja2</strong> permite interpolação de variáveis.</p> # template.conf.j2 server { listen {{ http_port }}; server_name {{ domain_name }}; {% if enable_ssl %} ssl_certificate {{ ssl_cert_path }}; ssl_certificate_key {{ ssl_key_path }}; {% endif %} } </code></pre> Idempotência</h3> Idempotência</strong> significa que executar a mesma task múltiplas vezes produz o mesmo resultado.</p> # Idempotente - resultado sempre o mesmo - name: Garantir Nginx instalado apt: name: nginx state: present # NÃO idempotente - pode mudar algo toda vez - name: Instalar versão específica apt: name: nginx=1.18.0 state: present </code></pre> Ansible Vault</h3> Ansible Vault</strong> criptografa dados sensíveis.</p> # Criar arquivo criptografado ansible-vault create secrets.yml # Editar ansible-vault edit secrets.yml # Executar playbook com vault ansible-playbook site.yml --ask-vault-pass </code></pre> Strategy (Estratégia)</h3> Strategy</strong> controla como tasks são executadas entre hosts.</p> Estratégia</th> Comportamento</th></tr></thead> linear</code> (padrão)</td> Todos os hosts executam a mesma task antes de avançar</td></tr> free</code></td> Cada host executa o mais rápido possível</td></tr> debug</code></td> Executa task por task para debug</td></tr> </tbody></table> - name: Exemplo com strategy free hosts: all strategy: free tasks: - name: Long running task command: /usr/bin/long-operation </code></pre> Tags (Etiquetas)</h3> Tags</strong> permitem selecionar subset de tasks para executar.</p> tasks: - name: Instalar dependências apt: name: "{{ packages }}" tags: [install, packages] - name: Configurar aplicação template: src: app.conf.j2 dest: /etc/app.conf tags: [config] </code></pre> # Executar apenas tasks com tag 'install' ansible-playbook site.yml --tags install # Pular tasks com tag 'config' ansible-playbook site.yml --skip-tags config </code></pre> Condition (Condição)</h3> When</strong> executa task apenas se condição for verdadeira.</p> - name: Instalar Nginx apenas no Debian/Ubuntu apt: name: nginx state: present when: ansible_facts['os_family'] == "Debian" - name: Instalar HTTPD apenas no RHEL/CentOS yum: name: httpd state: present when: ansible_facts['os_family'] == "RedHat" </code></pre> Loop (Laço)</h3> Loop</strong> executa task múltiplas vezes com valores diferentes.</p> # with_items (sintaxe antiga) - name: Instalar múltiplos pacotes apt: name: "{{ item }}" state: present with_items: - nginx - vim - curl # loop (sintaxe moderna) - name: Criar usuários user: name: "{{ item }}" state: present loop: - john - jane - admin </code></pre> Block</h3> Block</strong> agrupa tasks para tratamento de erros.</p> tasks: - name: Bloco principal block: - name: Tentar instalar pacote apt: name: "{{ package_name }}" state: present rescue: - name: Se falhar, instalar dependências apt: name: "{{ package_name }}-dev" state: present always: - name: Sempre limpar cache file: path: /tmp/cache state: absent </code></pre> Become (Escalação de Privilégio)</h3> Become</strong> executa como outro usuário (sudo/su).</p> # Nível de playbook - name: Play que requer root hosts: webservers become: yes # Ativar become become_user: www-data # Como qual usuário become_method: sudo # Método de escalação tasks: - name: Criar arquivo no diretório web file: path: /var/www/html/file state: touch </code></pre> Delegate_to</h3> Delegate_to</strong> executa task em outro host.</p> - name: Adicionar host ao load balancer hosts: webservers tasks: - name: Registrar no HAProxy haproxy: backend: app host: "{{ inventory_hostname }}" state: present delegate_to: lb01.example.com </code></pre> Run Once</h3> Run Once</strong> executa task apenas no primeiro host.</p> - name: Executar apenas uma vez hosts: webservers tasks: - name: Criar banco de dados postgresql_db: name: myapp state: present run_once: true </code></pre> Dica:</strong> Consulte o Glossário</a> completo para referência de todos os termos Ansible.</p> Leia também</strong></p> Ad-hoc vs Playbook</a> — quando usar um comando ad-hoc e quando escrever um playbook: as duas…</li> Arquitetura do Ansible</a> — arquitetura do Ansible - Control Node, Managed Nodes, Módulos, Inventário…</li> Cases de Uso</a> — casos de uso Ansible</li> Comparativo Ferramentas</a> — comparando Ansible com outras ferramentas</li> </ul> </div> Referências</h2> Ansible — Getting started</a></li> Ansible — Glossary</a></li> </ol>

Ansible — Do Básico ao Avançado

Instalação no Linux Debian/Ubuntu

Método 1: APT (Recomendado para Produção)</h2>

Método 2: pip (Recomendado para Desenvolvimento)</h2>

Método 3: pip com Requirements</h2>

Configuração Pós-Instalação</h2>

Atualização</h2>

Desinstalação</h2>

Problemas Comuns</h2>

"sudo: apt-add-repository: command not found"</h3> Mesmo erro, o pacote software-properties-common</code> não está instalado.</p>

Referências</h2> Ansible — Installing Ansible</a></li> </ol>

Instalação no Linux RHEL/Fedora/CentOS

Instalação no Linux RHEL/Fedora/CentOS</h1> O que você vai aprender</strong></p>

Método 1: DNF/YUM (RHEL 8+/CentOS 8+/Fedora)</h2>

Método 2: Repositório Ansible oficial (Todas versões)</h2>

Método 3: pip (Universal)</h2>

Configuração</h2>

Atualização</h2>

Referências</h2> Ansible — Installing Ansible</a></li> </ol>

Requisitos

Control Node (onde o Ansible roda)</h2>

Managed Nodes (servidores que serão gerenciados)</h2>

Conectividade</h2>

Recursos Recomendados</h2>

Próximos Passos</h2> Nota:</strong> Escolha o método de instalação adequado para seu SO na barra de navegação.</p>

Verificação da Instalação

Testes Básicos</h2>

Testes de Configuração</h2>

Verificar Conectividade SSH</h2>

Problemas Comuns e Soluções</h2>

Arquitetura do Ansible

Componentes Principais</h2>

Authentication e Conectividade</h2>

Comparativo: Ansible vs outras ferramentas

Ansible vs Puppet</h2>

Ansible vs Chef</h2>

Ansible vs SaltStack</h2>

Ansible vs Terraform</h2>

Ansible vs Pulumi</h2>

O que é Ansible?

Definição</h2> Ansible</strong> é uma ferramenta de automatização de TI</strong> open-source que permite configurar sistemas, implementar software e orquestrar tarefas complexas de infraestrutura. Foi criada por Michael DeHaan em 2012 e adquirida pela Red Hat em 2015.</p>

Características Principais</h2>

Sem Agentes para Instalar</h3> Diferente de outras ferramentas como Puppet ou Chef, o Ansible não requer software-agent instalado nos servidores gerenciados. A comunicação acontece via SSH</strong> (Linux/Unix) ou WinRM</strong> (Windows).</p>

"sudo: apt-add-repository: command not found"</h3>
Mesmo erro, o pacote `software-properties-common</code> não está instalado.</p>`

Referências</h2>

Ansible — Installing Ansible</a></li> </ol>

Referências</h2>

Ansible — Installing Ansible</a></li> </ol>

Próximos Passos</h2>
Nota:</strong> Escolha o método de instalação adequado para seu SO na barra de navegação.</p>

Definição</h2>
Ansible</strong> é uma ferramenta de automatização de TI</strong> open-source que permite configurar sistemas, implementar software e orquestrar tarefas complexas de infraestrutura. Foi criada por Michael DeHaan em 2012 e adquirida pela Red Hat em 2015.</p>

Sem Agentes para Instalar</h3>
Diferente de outras ferramentas como Puppet ou Chef, o Ansible não requer software-agent instalado nos servidores gerenciados. A comunicação acontece via SSH</strong> (Linux/Unix) ou WinRM</strong> (Windows).</p>