Ansible Playbooks vs Roles

De acordo com os docs ansible, um Playbook é:

... a base para um gerenciamento de configuração realmente simples e sistema de implantação de várias máquinas, diferente de qualquer um que já existe, e que é muito adequado para implantar aplicativos complexos.

E, novamente, de acordo com esses mesmos documentos, as funções são:

... maneiras de carregar automaticamente certos vars_files, tarefas e manipuladores com base em uma estrutura de arquivo conhecida. O agrupamento de conteúdo por funções também permite o fácil compartilhamento de funções com outros usuários.

No entanto, a distinção entre esses e seus diferentes casos de uso não é imediatamente óbvia para mim. Por exemplo, se eu configurar meu /etc/ansible/hostsarquivo para se parecer com:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

... então o que é esta [databases]entrada " " ... uma função ? Ou o nome de um arquivo YAML de playbook em algum lugar? Ou alguma outra coisa?!?

Se alguém pudesse me explicar as diferenças entre eles, minha compreensão de Ansible seria muito aprimorada!

• Manual vs Papel vs [databases]e entradas semelhantes em/etc/ansible/hosts
• Se Playbooks são definidos dentro de arquivos YAML, então onde as funções são definidas?
• Além de ansible.cfgmorar no servidor Ansible, como faço para adicionar / configurar o Ansible com Playbooks / funções disponíveis? Por exemplo, quando corro ansible-playbook someplaybook.yaml, como Ansible sabe onde encontrar aquele manual?

Playbook vs função vs [bancos de dados] e entradas semelhantes em / etc / ansible / hosts

[databases]é um único nome para um grupo de hosts. Ele permite que você faça referência a vários hosts por um único nome.

Função é um conjunto de tarefas e arquivos adicionais para configurar o host para servir a uma determinada função .

Playbook é um mapeamento entre hosts e funções.

O exemplo da documentação descreve o projeto de exemplo. Ele contém duas coisas:

• Playbooks. site.yml, webservers.yml, fooservers.ymlSão playbooks.
• Funções: roles/common/e roles/webservers/contêm definições commone webserversfunções de acordo.

Dentro do manual ( webservers.yml) você tem algo como:

---
- hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question
  roles: <- this is list of roles to assign to these hosts
     - common
     - webservers

Se Playbooks são definidos dentro de arquivos YAML, então onde as funções são definidas?

Eles são definidos dentro de roles/*diretórios. As funções são definidas principalmente usando arquivos YAML, mas também podem conter recursos de qualquer tipo ( files/, templates/). De acordo com a documentação, a definição da função é estruturada desta forma:

• Se roles / x / tasks / main.yml existir, as tarefas listadas ali serão adicionadas à peça
• Se roles / x / handlers / main.yml existir, os manipuladores listados nele serão adicionados à peça
• Se roles / x / vars / main.yml existir, as variáveis ​​listadas ali serão adicionadas à peça
• Se roles / x / meta / main.yml existir, quaisquer dependências de funções listadas nele serão adicionadas à lista de funções (1.3 e posterior)
• Qualquer tarefa de cópia pode fazer referência a arquivos em roles / x / files / sem ter que direcioná-los de forma relativa ou absoluta
• Qualquer tarefa de script pode fazer referência a scripts em roles / x / files / sem ter que direcioná-los de forma relativa ou absoluta
• Qualquer tarefa de modelo pode fazer referência a arquivos em roles / x / templates / sem ter que direcioná-los de forma relativa ou absoluta
• Qualquer tarefa de inclusão pode fazer referência a arquivos em roles / x / tasks / sem ter que direcioná-los de forma relativa ou absoluta

O arquivo mais importante é roles/x/tasks/main.yml, aqui você define as tarefas, que serão executadas, quando a função for executada.

Além do ansible.cfg residente no servidor Ansible, como faço para adicionar / configurar o Ansible com Playbooks / funções disponíveis? Por exemplo, quando executo o ansible-playbook someplaybook.yaml, como Ansible sabe onde encontrar esse playbook?

$ ansible-playbook someplaybook.yaml

Procurará um manual dentro do diretório atual.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Irá procurar um manual dentro do somedir/somedir/diretório.

É sua responsabilidade colocar seu projeto com todos os manuais e funções no servidor. Ansible não tem nada a ver com isso.

Playbook vs função vs [bancos de dados] e entradas semelhantes em / etc / ansible / hosts

As funções são uma forma de agrupar tarefas em um contêiner. Você pode ter uma função para configurar o MySQL, outra para configurar o Postfix etc.

Um manual define o que está acontecendo e onde . Este é o lugar onde você define os hosts (grupos de hosts, veja abaixo) e as funções que serão aplicadas a esses hosts.

[databases]e as outras entradas em seu inventário são grupos de hosts. Os grupos de hosts definem um conjunto de hosts nos quais uma peça será executada.

Uma peça é um conjunto de tarefas ou papéis (ou ambos) dentro de um manual. Na maioria dos casos (e exemplos), um manual conterá apenas uma única jogada. Mas você pode ter quantos quiser. Isso significa que você pode ter um manual que executará a função postfixno grupo de hosts mail_serverse a função mysqlno grupo de hosts databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Se Playbooks são definidos dentro de arquivos YAML, então onde as funções são definidas?

Em Ansible, quase tudo é definido em YAML, o que conta para papéis e manuais.

Além do ansible.cfg residente no servidor Ansible, como faço para adicionar / configurar o Ansible com Playbooks / funções disponíveis? Por exemplo, quando executo o ansible-playbook someplaybook.yaml, como Ansible sabe onde encontrar esse playbook?

AFAIK, você deve fornecer o caminho para o manual ao invocar ansible-playbook. Portanto ansible-playbook someplaybook.yaml, esperaria someplaybook.yamlestar em seu diretório atual. Mas você pode fornecer o caminho completo:ansible-playbook /path/to/someplaybook.yaml

É uma questão terminológica / semântica. Pode ser subjetivo, embora haja uma definição básica.

Minha visão é a seguinte:

Qualquer sistema de gerenciamento / implantação de configuração tem:

1. source data - dados usados ​​para criar a configuração do host de destino
2. target data - dados usados ​​para identificar hosts de destino
3. config changes- lista / conjunto de regras / ações que aplicamos com source datao host de destino com base emtarget data

Em termos Ansible:

1. source data- são os vários lugares onde podemos colocar dados - group_vars, playbookvars, rolevars, etc., Esses lugares afetam a precedência (se uma variável com o mesmo nome for redefinida em locais diferentes, existem regras muito específicas de qual seria o valor do variável durante ansible/ ansible-playbookexecução
2. target data - é o inventário (e também é possível definir as variáveis ​​de inventário / hostgroup dentro do inventário!)
3. config changes - ansible tem 4 níveis de abstração para ele:
   1. tarefa - ação única
   2. lista de tarefas - lista de ações
   3. função - lista de ações (ou lista de listas) agrupadas pelo mesmo 'assunto', geralmente todos os alvos estão operando no mesmo host / grupo de hosts
   4. playbook - lista de jogadas, cada uma operando em um grupo de host possivelmente diferente, aplicando várias listas de tarefas role/ tasks / s (e tarefas especiais como handlers)

Do ponto de vista de 'software' - a função deve ser genérica o suficiente para ser reutilizada .

Também em algumas organizações (bastante grandes), as 'funções' são enviadas pelo grupo A, embora sejam usadas em manuais mantidos pelo grupo B.

resumo

Todos os itens acima permitem o agrupamento de configurações semelhantes - em a role. agrupando subsistemas / componentes relacionados em um playbook. Além disso, vale a pena mencionar, 1 artigo YAML em um playbook (incluindo hosts:e um ou tasks, pre_tasks, post_tasks, roles) é chamado deplay

Agora, para sua pergunta:

Sim, é confuso no início.

Você normalmente conecta seu source dataà semântica da sua função, então quando você vê que a função setup_dbé aplicada em uma peça no grupo de host relacionado (por exemplo db_hosts), mas um playpode estar executando uma união de vários grupos de host. É apenas uma questão de convenção versus flexibilidade.

PS

Por favor, escreva-me de volta se isso adicionou à confusão ou esclareceu. Obrigado.

Além disso, tenha em mente que um manual pode chamar mais de uma função se um metarquivo for usado com o objetivo de afetar as diferentes funções.

Exemplo de manual: dual_role-playbook.yml

- name: Some Action for two roles
  hosts: localhost

  vars_files:
    - roles/dual_role/meta/main.yml

  roles:
    - dual_role/container-1
    - dual_role/container-2

A pasta de papéis e o esquema de arquivos serão semelhantes a este:

dual_role-playbook.yml
  -- roles
     -- dual_role
        -- meta/main.yml
        -- container-1
           -- tasks/main.yml
           -- templates/template.j2
        -- container-2
           -- tasks/main.yml
           -- templates/template.j2

Basta colocar:

Um playbook é como o programa principal, contém instruções completas para concluir o trabalho. No entanto, para grandes projetos, não é desejável realmente incluir todos os detalhes. Então você precisa de um papel.

Uma função é uma sub-rotina e geralmente atinge um objetivo, por exemplo, configurar um servidor de banco de dados. Você pode colocá-lo no roles/diretório ou baixar funções de terceiros, fornecendo URIs rolesfile.ymle pedir ao ansible-galaxy para baixá-los para você.

O [database]é um grupo de hosts definido no arquivo de inventário que lista os hosts que pertencem ao databasegrupo. Você também pode especificar um grupo de servidores da web, especificando algo como

[web]
web1.example.com
web2.example.com

Grupo webou databasepode então ser usado em manuais ou funções para especificar os hosts a serem aplicados.

Os grupos também podem ser usados ​​em comandos ansiblepara executar comandos ad-hoc.