Ansible coding convention (example)

edX is exposes the coding conventions of Ansible on github.

https://github.com/edx/configuration/wiki/Ansible-Coding-Conventions

This repository is GNU AGPLv3. I think that it is probably okay in the case of translation, so I will translate it here and publish it.


General

  • YAML file

    All of yaml files in the indentation of 2 spaces, .yml please with the extension.

  • variable

    Please use the format of jinja variable. $var rather than {{ var }} ` is.

  • Please put a blank before and after jinja's variable name. {{var}} ` rather than {{ var }} ` it is.

  • Variable names that need to be overwritten by your own environment should be all capital letters.

  • All variable names to be completed in the role should be all lowercase letters.

  • Be sure to add the role name to the variable name defined in the role. Example : EDXAPP_FOO

  • Please make the roll self-contained.

    Roles should not include tasks from other roles whenever possible.

  • Playbook should not do more than include the list of roles.

    However, please use it if you need pre_tasks and post_tasks. (For example, management of load balancers)

  • The Playbook to be applied to the general community, please have your on configuration / playbooks (Yakuchu : EdX own story).

  • Specific organization (edx-east, edx-west ) Playbook to be applied to create a sub-directory under the configuration / playbooks, sure to put in there (Yakuchu : edx own story).

  • test

    Automated integration test is test.yml the include Shiteku please playbook that. In addition, run_tests please so as to confirm whether or not the test by using a variable called.

  • Deploy

    Application to the update of, service stop begin with, service start including a series of tasks that end in deploy.yml the sure to include. deploy.yml to each task in the deploy please with a tag called.

  • deploy.yml addition to the tasks in, yo Una task that affect the state of the application please do not write.

  • deploy.yml all tasks in is to be able to run as a user with sudo privileges are limited, so please root authority is not required.

  • Handlers

    Each role needs to have one or more handlers for tasks in main.yml that need to restart the service.

Conditional expressions and return values

  • Always when: Please use.

    If you examine whether or not the variable is set when: my_var is defined or when: my_var is not defined use.

  • To check the return value, do this.

    Code-Block .. :: Yaml

    • Command : / Bin / False Register : My_result ignore_errors : True
    • Debug : msg = "Task Failed" When : My_result | I Failed

format

For long lines please use line continuation of YAML to break.

- debug: >
    msg={{ test }}

Alternatively, you can write this in ansible.

- debug:
    msg: "{{ test }}"

roll

Role variable

  • Group_vars / all

    Please define the variables that apply to all roles.

  • "Common" role

    Please define variables and tasks that apply to all edX proprietary roles.

  • Role variable

    Please define your own variables in /var/main.yml. All variable names should be prefixed with role names.

  • Roll defaults

    The default variable of the role should be set to run all services on a single server.

  • Define variables that are unique to the environment and that need to be overwritten with all capital letters.

  • All roles should have a single standard directory of roles. Below is an example of python and ruby virtualenv.

    Code-Block .. :: Yaml

    Edxapp_rbenv_dir : "{{Edxapp_app_dir}}" Edxapp_rbenv_root : ". {{Edxapp_rbenv_dir}} / Rbenv" Edxapp_rbenv_shims : "{{Edxapp_rbenv_root}} / Shims" Edxapp_rbenv_bin : "{{Edxapp_rbenv_root}} / Bin" Edxapp_gem_root : "{{Edxapp_rbenv_dir} } / Gem "Edxapp_gem_bin. : " {{Edxapp_gem_root}} / Bin "

Role name convention

  • Role name

    Be concise and make it as single word as possible. If necessary _ sure to use.

  • Task name of role

    Be concise and descriptive. The blank is OK. Be sure to add the role name to the beginning. (Yakuchu : Since the role name is also displayed at run time, but I think there is no need to put the name of the role ...)

  • Roll handler

    Be concise and descriptive. The blank is OK. Be sure to add the role name to the beginning. (Yakuchu : same as above)

Secure vs Secure data

As a basic policy, the following data needs to be protected.

  • username

  • Public key

    Even if the key itself is public OK, there is a possibility that the user name may be guessed

  • hostname

  • Password, API key

Directory structure of a secure repository.

ansible
├── files
├── keys
└── vars

secure_dir is group_vars/all placed, to overwrite as needed other files that use the group name in the group_vars.

There is a need to be safe, to templates and file is first_available_file use.

- name: install read-only ssh key for the content repo that is required for grading
  copy: src={{ item }} dest=/etc/git-identity force=yes owner=ubuntu group=adm mode=60
  first_available_file:
    - "{{ secure_dir }}/files/git-identity"
    - "git-identity-example"

Summary

Although this convention is not necessarily suitable, I think that it will be helpful.

In addition, since a lot of playbooks are published in the edX repository, there may be discoveries through the first visit.