Veuillez comprendre que je pense que ma réponse est très subjective. En interne, mon équipe est plus ou moins d'accord avec mes opinions à ce sujet. Mais nous n'avons pas élaboré de "politique de formatage" pour les playbooks.
- Le nom doit être (
name ) ou un commentaire ( # ) ?
Nous n'incluons des commentaires que s'il est utile d'expliquer le "pourquoi" d'une tâche particulière. name es toujours présent. La valeur de name s'affichera lors de l'exécution du cahier de jeu. Dans les cas où un rôle est utilisé comme dépendance, j'ai souvent paramétré name . Quelques exemples.
Paramétré name exemple, à partir 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
...
Commentaires à titre complémentaire 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"
- Faut-il dire [k=v] ou [k : v] ?
J'utilise toujours la syntaxe "k : v". En outre, je sépare les valeurs par une nouvelle ligne. Lorsque je lis une pièce dans laquelle quelqu'un a inséré plusieurs "k=v" sur une seule ligne, mon cerveau s'embrouille. Je trouve qu'il est très difficile de jongler avec toutes les clés/valeurs pendant que je lis pour trouver celles qui m'intéressent.
Lequel est le plus facile à lire ? Je pense que c'est le deuxième exemple.
# 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
J'utilise aussi parfois judicieusement les espaces blancs.
...
# 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 }
...
