Como é a política de formatação desde o Ansible 2.0?

Question

Eu tenho visto vários exemplos Ansible no github e nos documentos ansible , por exemplo:

---
# this might be in a file like handlers/handlers.yml
- name: restart apache
  service: name=apache state=restarted

Exemplo do Github

O exemplo a seguir contém um comentário como name .

# Make sure Jenkins starts, then configure Jenkins.
- name: Ensure Jenkins is started and runs on startup.
  service: name=jenkins state=started enabled=yes

Discussão

Um name seria um direito suficiente ou um comentário deveria ser usado?

Deverá ser:

- name: Symlink RabbitMQ bin to sbin
  file: state=link src=/usr/lib/rabbitmq/bin dest=/usr/lib/rabbitmq/sbin

ou:

#Symlink RabbitMQ bin to sbin
file: 
  state: link
  src: /usr/lib/rabbitmq/binhttp://docs.ansible.com/ansible/YAMLSyntax.html
  dest: /usr/lib/rabbitmq/sbin

Quando o YAML Lint é consultado conforme recomendado por o documento de sintaxe Ansible YAML , ambos os fragmentos parecem ser YAML válido. Embora ambos os fragmentos pareçam ser válidos em YAML, a estrutura visual é diferente.

Perguntas

1. O nome ( name ) deve ser usado ou um comentário ( # )?
2. Deve ser file: state=link src=/usr/lib/rabbitmq/bin dest=/usr/lib/rabbitmq/sbin ou deve ser dividido por elementos, por exemplo %código%

Answer 1

Por favor, entenda que acredito que minha resposta seja altamente subjetiva. Internamente, minha equipe concorda com minhas opiniões sobre isso. Mas não elaboramos nenhuma "política de formatação" para livros didáticos.

1. Should name (name) be used or a comment (#)?

Nós só incluímos comentários se for útil para explicar o "por quê?" da tarefa específica. name é sempre presente. O valor de name será exibido durante a execução do playbook. Nos casos em que uma função é usada como dependência, eu frequentemente parametrizava name . Alguns exemplos.

Parametrizado name example, de roles / some_container / meta / main.yml

...
dependencies:
  - { role: remove_container, container_name: some_container }
...

roles / remove_container / tasks / main.yml

...
- name: Remove containers - {{ container_name }}
  docker_container:
    name: "{{ container_name }}"
    state: absent
    force_kill: true
...

Comentários como cortesia para name . roles / remove_image / tasks / main.yml

# The 'docker_image' module, as of EPEL build 2.1.0.0, does not correctly handle 'tag: *' for removing all image tags.
# Below is not pretty but works on systems where you know all the image names.
- name: Remove images - {{ image_name }}
  shell: docker rmi -f $(docker images | grep {{ image_name }} | awk '{print $3}')
  register: result
  changed_when: "'requires a minimum of 1 argument' not in result.stderr"
  failed_when:
    - "'requires a minimum of 1 argument' not in result.stderr"
    - "result.rc != 0"

2. Should it be [k=v] or [k: v]?

Eu sempre uso a sintaxe 'k: v'. Além disso, divido valores separados com uma nova linha. Ao ler uma peça em que alguém colocou muitos 'k = v' em uma única linha, meu cérebro fica distorcido. Eu acho muito difícil conciliar todas as chaves / valores enquanto eu leio para aqueles que me interessam.

Qual é mais fácil de ler? Eu acho que o segundo exemplo.

# 1. Launch container k=v
- name: Start A container
  docker_container:
name=containerA image=imageA published_ports='443:8443' exposed_ports=8443 volumes='/some/path:/some/path' links='b:b' env='/some/local.fact' pull=false restart_policy=always state=started

# 2. Launch container k: v
- name: Start api container
  docker_container:
    name: containerA
    image: imageB
    published_ports:
      - "443:8443"
    exposed_ports:
      - 8443
    volumes:
      - /some/path:/some/path
    links:
      - db:db
    env: /some/local.fact
    pull: false
    restart_policy: always
    state: started

Eu também uso criteriosamente o espaço em branco às vezes.

...

# Containers a, b, c comprise 'app d' and can be updated independently.
roles:
    - { role: bootstrap_common,   tags: bootstrap  }
    - { role: bootstrap_a,        tags: bootstrap  }
    - { role: bootstrap_b,        tags: bootstrap  }
    - { role: deploy_container_a, tags: a          }
    - { role: deploy_container_b, tags: b          }
    - { role: deploy_container_c, tags: c          }
...

    

Answer 2

Isso é da sua preferência.

Comentários como # Make sure Jenkins starts, then configure Jenkins. não fazem muito sentido, pois não adicionam mais informações.

A sintaxe

Inline é suportada por YAML para ser compatível com JSON . No entanto, a sintaxe Outline deve ser preferida porque o código é mais legível e as alterações de código podem ser melhor revisadas com o diff.