bignose's questions

Como posso definir uma variável Ansible cujo valor é outra variável na mesma estrutura de mapeamento ?

Para permitir um namespace sensato de variáveis, estou definindo estruturas de mapeamento como esta, onde alguns valores dependem de outras variáveis ​​na mesma estrutura:

acme:
  directory:
    hostname: "acme-staging-v02.api.letsencrypt.org"
letsencrypt:
  config_dir: "/etc/letsencrypt"
  keys_dir: "{{ letsencrypt.config_dir }}/keys"
  csrs_dir: "{{ letsencrypt.config_dir }}/csr"
  certs_dir: "{{ letsencrypt.config_dir }}/certs"
  accounts_dir: "{{ letsencrypt.config_dir }}/accounts"
  csr_file: "{{ letsencrypt.csrs_dir }}/{{ site_domain }}.csr"
  account_key_file: "{{ letsencrypt.csrs_dir }}/{{ acme.directory.hostname }}"
  email_address: "certificate-reminders@{{ site_domain }}"

Isso falha porque o Ansible não pode resolver os valores que fazem referência a outros na mesma estrutura de dados:

loop recursivo detectado na string do modelo: {{ letsencrypt.config_dir }}/keys

Então eu pensei que a pesquisavars permitiria adiar essa resolução:

acme:
  directory:
    hostname: "acme-staging-v02.api.letsencrypt.org"
letsencrypt:
  config_dir: "/etc/letsencrypt"
  keys_dir: "{{ lookup('vars', 'letsencrypt.config_dir') }}/keys"
  csrs_dir: "{{ lookup('vars', 'letsencrypt.config_dir') }}/csr"
  certs_dir: "{{ lookup('vars', 'letsencrypt.config_dir') }}/certs"
  accounts_dir: "{{ lookup('vars', 'letsencrypt.config_dir') }}/accounts"
  csr_file: "{{ lookup('vars', 'letsencrypt.csrs_dir') }}/{{ site_domain }}.csr"
  account_key_file: >-
    {{ lookup('vars', 'letsencrypt.csrs_dir') }}/{{ acme.directory.hostname }}
  email_address: "certificate-reminders@{{ site_domain }}"

Isso falha porque o Ansible está tentando resolver essa pesquisa imediatamente:

Nenhuma variável encontrada com este nome: letsencrypt.config_dir

Claro que eu poderia dividi-los para que sejam variáveis ​​separadas. Isso anula meu propósito, porém, de manter todas as variáveis ​​fortemente relacionadas agrupadas no mesmo namespace.

Então, o que me permitirá definir a estrutura de dados para que alguns valores possam depender de outras variáveis ​​na mesma estrutura ?

Como posso definir diretivas compartilhadas entre todas as tarefas no arquivo, em um arquivo de fragmento de playbook Ansible que contém apenas tarefas ?

# ansible/inventory/roles/os_packages/tasks/main.yaml

- name: "APT: Update available packages from Debian repositories"
  gather_facts: false
  become: true
  become_user: root
  apt:
    update_cache: true
- name: "APT: Install required packages"
  gather_facts: false
  become: true
  become_user: root
  apt:
    name:
      - foo
      - bar

Essas diretivas repetidas — gather_facts, become, etc. — devem ser declaradas uma vez nesse arquivo. Mas onde, já que não existe (atualmente?) nenhum arquivo representando o papel ou peça?

# ansible/inventory/roles/os_packages/tasks/main.yaml

# This doesn't work because Ansible is expecting only tasks.
gather_facts: false
become: true
become_user: root

- name: "APT: Update available packages from Debian repositories"
  apt:
    update_cache: true
- name: "APT: Install required packages"
  apt:
    name:
      - foo
      - bar

O arquivo precisa consistir apenas em uma sequência de tarefas; o nível "role" ou "play" não parece ter um lugar apropriado nesta estrutura de diretórios recomendada .

Se o playbook inteiro estivesse em um arquivo, cada play teria seu próprio nome separado e eu definiria as diretivas no play. Mas esses arquivos de tarefas estão sendo reunidos e compilados, e não há lugar onde o jogo exista para eu escrever essas diretivas.

Onde as diretivas que se aplicam a todas as tarefas em uma função devem ser definidas?

Como faço para escrever uma tarefa Ansible para executar um script PHP como um terceiro usuário ; não o usuário root e não o usuário de conexão, mas o usuário “servidor da web”?

O programa de administração NextCloud occ, de acordo com a documentação, deve ser executado como usuário do servidor web :

sudo -u www-data php occ

Para se tornar um usuário diferente para executar um comando, o Ansible fornece o becomerecurso. A documentação do Ansible recomenda severamente não tentar executar comandos como um usuário diferente e não root :

Tudo está bem se o arquivo do módulo for executado sem usar become, quando o become_userfor root, ou quando a conexão com a máquina remota for feita como root. Nesses casos, o Ansible cria o arquivo do módulo com permissões que permitem apenas a leitura pelo usuário e root, ou apenas permitem a leitura pelo usuário sem privilégios para o qual está sendo alternado.

No entanto, quando o usuário de conexão e o become_usernão têm privilégios, o arquivo do módulo é gravado como o usuário que o Ansible se conecta (o remote_user), mas o arquivo precisa ser legível pelo usuário que o Ansible está configurado para se tornar.

Usando become_userpara esse usuário

O usuário de conexão tem sudopermissão para executar comandos como terceiro usuário:

$ sudo -u www-data whoami
www-data

Quando eu uso become_userna tarefa, para executar o comando como esse usuário:

- name: "NextCloud: Instance configuration"
  become_user: "{{ web_process_user }}"
  command:
    cmd: >-
        php "{{ apache_nextcloud_dir }}/occ" maintenance:install
            --no-interaction
            …

ATUALIZAÇÃO : hum, funciona. Não sei o que mudou, mas ao tentar reproduzir o problema, parou.

Usando com uma invocação shellexplícita como esse usuáriosudo

Quando configuro a tarefa do Ansible com um shellcomando:

shell: >-
    su '{{ web_process_user }}' --shell '/bin/bash' -c ' \
        php "{{ apache_nextcloud_dir }}/occ" …

Ansible reclama:

[AVISO]: Considere usar 'become', 'become_method' e 'become_user' em vez de executar su

Eu adoraria fazer isso. O Ansible becomeseria uma maneira muito mais graciosa do que esse shell: suhack.

Mas ao usar become, ocorrem os problemas descritos na documentação do Ansible: o módulo de tarefa enviado pela conexão para executar esse comando não consegue obter o privilégio de criar seus arquivos temporários.

A documentação do Ansible aconselha:

• “use pipelining”: Isso perde as vantagens do sistema de módulo de tarefa padrão.
• “evitar se tornar um usuário sem privilégios”: Não é uma opção, porque o usuário do servidor web sem privilégios é necessário para executar este comando corretamente.

Como devo fazer uma tarefa do Ansible que seja executada php "{{ apache_nextcloud_dir }}/occ" como o terceiro usuário sem privilégios {{ web_process_user }} ?

UPDATE : a becomefuncionalidade parece funcionar corretamente agora.

Qual configuração é necessária para formatar corretamente a saída de fluxo padrão das tarefas em uma ansible-playbookexecução do Ansible?

O que eu executo ansible-playbook foo.yamla saída das tarefas inclui o conteúdo de fluxo padrão ( stdout, stderr). Mas a exibição deles está em um grande blob JSON de linha única e não é impresso como as linhas formatadas que foram enviadas para o fluxo.

TASK [Django: Collect media fixture files] ******************************************************************************
ok: [lorem]

TASK [Django: Create superuser] ******************************************************************************
fatal: [lorem]: FAILED! => {"changed": false, "cmd": "python3 -m django createsuperuser\n  --noinput\n  --username \"admin\"\n  --email \"[email protected]\"", "msg": "\n:stderr: CommandError: You must use --full_name with --noinput.\n", "path": "/var/local/dolor/virtualenv/rectory/venv.py3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/games", "syspath": ["/tmp/ansible_django_manage_payload_uj9f3le8/ansible_django_manage_payload.zip", "/usr/lib/python37.zip", "/usr/lib/python3.7", "/usr/lib/python3.7/lib-dynload", "/usr/local/lib/python3.7/dist-packages", "/usr/lib/python3/dist-packages"]}

O que está causando essa formatação indesejada da saída? Como posso dizer ao Ansible para sempre formatar a saída do fluxo corretamente para exibição na ansible-playbooksaída?

Que tipo de sistema de arquivos Linux posso usar para não tentar a recuperação de inconsistências na inicialização, mas descartá-las (liberar espaço) e montar rapidamente?

Eu tenho um aplicativo que usa muito espaço para armazenar em cache seus resultados. O cache não é precioso; quando há inconsistências detectadas na inicialização, prefiro que o kernel libere rapidamente o espaço e continue montando o volume.

Este é um dos recursos de um volume 'tmpfs', mas o tamanho do volume é muito grande para consumir RAM para isso. A velocidade (depois de montar o volume) não é um critério principal, portanto, é preferível um armazenamento mais lento e maior.

O cache está atualmente no tipo de sistema de arquivos padrão 'ext4'. A demora para resolver inconsistências na hora da montagem não é onerosa, mas é desnecessária (o espaço pode simplesmente ser liberado), então prefiro evitá-la.

Em vez de explorar por que fazer isso, gostaria de saber qual tipo de sistema de arquivos possui essas propriedades para saber se essa opção é viável.

Que tipo de sistema de arquivos suportado pelo Linux posso usar para isso?