Как выглядит политика форматирования со времен Ansible 2.0?

Я видел несколько примеров Ansible на github и в документах ansible, например:

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

Пример Github

Следующий пример содержит оба комментария в виде name,

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

обсуждение

name будет достаточно прав или комментарий должен быть использован?

Должно ли это быть:

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

или же:

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

При обращении к YAML Lint в соответствии с рекомендациями синтаксического документа Ansible YAML оба фрагмента кажутся действительными YAML. Хотя оба фрагмента являются допустимыми YAML, визуальная структура отличается.

Вопросы

  1. Следует назвать (name) быть использованы или комментарий (#)?
  2. Должно ли это быть file: state=link src=/usr/lib/rabbitmq/bin dest=/usr/lib/rabbitmq/sbin или следует разделить, например, state:
Источник

2 ответа

Решение

Пожалуйста, поймите, я считаю, что мой ответ очень субъективен. Внутренне моя команда слабо согласна с моим мнением по этому поводу. Но мы не разработали никакой "политики форматирования" для playbooks.

  1. Следует назвать (name) быть использованы или комментарий (#)?

Мы включаем комментарии, только если полезно объяснить "почему?" конкретной задачи. name всегда присутствует. Значение name будет отображаться во время запуска playbook. В тех случаях, когда роль используется как зависимость, я часто параметризировал name, Пара примеров.

параметризованных name пример из ролей /some_container/meta/main.yml

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

Роли /remove_container/ задачи / main.yml

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

Комментарии как дополнение к name, Роли /remove_image/ задачи / 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"
  1. Это должно быть [k=v] или [k: v]?

Я всегда использую синтаксис "k: v". Дополнительно я разбиваю отдельные значения новой строкой. Когда я читаю пьесу, где кто-то набил много k = v в одной строке, мой мозг искажается. Мне очень трудно манипулировать всеми ключами / значениями, пока я читаю, для тех, которые меня интересуют.

Что легче читать? Я думаю, что второй пример.

# 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

Я также время от времени разумно использую пустое пространство.

...

# 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          }
...
Источник

Это зависит от ваших собственных предпочтений.

Комментарии как # Make sure Jenkins starts, then configure Jenkins. не имеет особого смысла, так как они не добавляют больше информации.

Inline синтаксис поддерживается YAML быть совместимым с JSON, Outline однако синтаксис должен быть предпочтительным, потому что код лучше читается, а изменения кода можно лучше просматривать с помощью diff.

Источник
Другие вопросы по тегам