You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

147 lines
6.4 KiB

7 years ago
7 years ago
7 years ago
  1. # Ansible-Boilerplate
  2. [![GitHub Issues](https://img.shields.io/github/issues/acch/ansible-boilerplate.svg)](https://github.com/acch/ansible-boilerplate/issues) [![GitHub Stars](https://img.shields.io/github/stars/acch/ansible-boilerplate.svg?label=github%20%E2%98%85)](https://github.com/acch/ansible-boilerplate/) [![License](https://img.shields.io/github/license/acch/ansible-boilerplate.svg)](LICENSE)
  3. [Ansible](https://www.ansible.com/) is a configuration management tool, similar to [Chef](https://www.chef.io/) and [Puppet](https://puppet.com/). It allows for performing logical configuration of infrastructure components, such as servers and network switches. The configuration files in this repository can act as a template for your own Ansible projects, in order to get you started quickly. Once you've customized the configuration files then new servers can be configured quickly — excluding their network configuration. This means that adding new servers is as simple as:
  4. - Base OS installation of new server
  5. - Network configuration of new server (including bond, bridge, DNS and routing)
  6. - Configuration of password-less (public key) SSH authentication from the Ansible host (your laptop) to the new server
  7. The remaining configuration (installing packages, configuring services, etc.) can then be achieved using Ansible. In addition, Ansible ensures that configuration of all servers is and remains consistent.
  8. ## Using this repository
  9. Simply download (clone) the repository and start modifying files according to your needs.
  10. ```
  11. git clone https://github.com/acch/ansible-boilerplate.git myAnsibleProject/
  12. ```
  13. Ideally, you'll want to use [Git](https://git-scm.com/) to manage your Ansible configuration files. For that purpose simply [fork](https://help.github.com/articles/fork-a-repo/) this repository into your own Git repository before cloning and customizing it. Alternatively, create your own repository [from the template](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-from-a-template). Git will allow you to version and roll-back changes with ease.
  14. Specifically, you'll want to customize the following files:
  15. - Add your own hosts and groups to file `hosts`. You'll want to replace `[anygroup]` with a more meaningful group name, and add your own groups as required.
  16. - Define roles by adding subdirectories underneath directory `roles/`. You'll want to rename `anyrole/` to a more meaningful role name, and add your own roles as required.
  17. - Associate your hosts (groups) with your roles by adding appropriate playbooks in the root directory. Rename `anygroup.yml` to a more meaningful playbook name.
  18. - Import all your playbooks in the main `site.yml` playbook.
  19. ## Using Ansible
  20. Install `ansible` on your laptop and link the `hosts` file from `/etc/ansible/hosts` to the file in your repository. Now you're all set.
  21. To run a single (ad-hoc) task on multiple servers:
  22. ```
  23. # Check connectivity
  24. ansible all -m ping -u root
  25. # Run single command on all servers
  26. ansible all -m command -a "cat /etc/hosts" -u root
  27. # Run single command only on servers in specific group
  28. ansible anygroup -m command -a "cat /etc/hosts" -u root
  29. # Run single command on individual server
  30. ansible server1 -m command -a "cat /etc/hosts" -u root
  31. ```
  32. As the `command` module is the default, it can also be omitted:
  33. ```
  34. ansible server1 -a "cat /etc/hosts" -u root
  35. ```
  36. To use shell variables on the remote server, use the `shell` module instead of `command`, and use single quotes for the argument:
  37. ```
  38. ansible server1 -m shell -a 'echo $HOSTNAME' -u root
  39. ```
  40. The true power of ansible comes with so called *playbooks* — think of them as scripts, but they're declarative. Playbooks allow for running multiple tasks on any number of servers, as defined in the configuration files (`*.yml`):
  41. ```
  42. # Run all tasks on all servers
  43. ansible-playbook site.yml -v
  44. # Run all tasks only on group of servers
  45. ansible-playbook anygroup.yml -v
  46. # Run all tasks only on individual server
  47. ansible-playbook site.yml -v -l server1
  48. ```
  49. Note that `-v` produces verbose output. `-vv` and `-vvv` are also available for even more (debug) output.
  50. To verify what tasks would do without changing the actual configuration, use the `--list-hosts` and `--check` parameters:
  51. ```
  52. # Show hosts that would be affected by playbook
  53. ansible-playbook site.yml --list-hosts
  54. # Perform dry-run to see what tasks would do
  55. ansible-playbook site.yml -v --check
  56. ```
  57. Running all tasks in a playbook may take a long time. *Tags* are available to organize tasks so one can only run specific tasks to configure a certain component:
  58. ```
  59. # Show list of available tags
  60. ansible-playbook site.yml --list-tags
  61. # Only run tasks required to configure DNS
  62. ansible-playbook site.yml -v -t dns
  63. ```
  64. Note that the above command requires you to have tasks defined with the `tags: dns` attribute.
  65. ## Configuration files
  66. The `hosts` file defines all hosts and groups which they belong to. Note that a single host can be member of multiple groups. Define groups for each rack, for each network, or for each environment (e.g. production vs. test).
  67. ### Playbooks
  68. Playbooks associate hosts (groups) with roles. Define a separate playbook for each of your groups, and then import all playbooks in the main `site.yml` playbook.
  69. File | Description
  70. ---- | -----------
  71. `site.yml` | Main playbook - runs all tasks on all servers
  72. `anygroup.yml` | Group playbook - runs all tasks on servers in group *anygroup*
  73. ### Roles
  74. The group playbooks (e.g. `anygroup.yml`) simply associate hosts with roles. Actual tasks are defined in these roles:
  75. ```
  76. roles/
  77. ├── common/ Applied to all servers
  78. │ ├── handlers/
  79. │ ├── tasks/
  80. │ │ └ main.yml Tasks for all servers
  81. │ └── templates/
  82. └── anyrole/ Applied to servers in specific group(s)
  83. ├── handlers/
  84. ├── tasks/
  85. │ └ main.yml Tasks for specific group(s)
  86. └── templates/
  87. ```
  88. Consider adding separate roles for different applications (e.g. webservers, dbservers, hypervisors, etc.), or for different responsibilities which servers fulfill (e.g. infra_server vs. infra_client).
  89. ### Tags
  90. Use the following command to show a list of available tags:
  91. ```
  92. ansible-playbook site.yml --list-tags
  93. ```
  94. Consider adding tags for individual components (e.g. DNS, NTP, HTTP, etc.).
  95. Role | Tags
  96. --- | ---
  97. Common | all,check
  98. ## Copyright and license
  99. Copyright 2017 Achim Christ, released under the [MIT license](LICENSE)