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.