Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Ansible for Configuration Management for Lohika DevOps training 2018 @ Lohika part1
Similar to Ansible for Configuration Management for Lohika DevOps training 2018 @ Lohika part1 (20)
Recently uploaded
Recently uploaded (20)
Ansible for Configuration Management for Lohika DevOps training 2018 @ Lohika part1
- 1. Ansible for Configuration Management Ihor Banadiga for DevOps training @ Lohika Part 1
- 2. Ihor Banadiga Software Engineer at Lohika Morning@Lohika, Java Club, NodeJS Club @banadiga ibanadiga@lohika.com 2
- 3. Agenda • Configuration management • Ansible • Basic knowledge • Programming knowledge 3
- 6. Infrastructure as a code 6
- 10. Infrastructure is still growing 10
- 14. What is the problem? • Can not be run on different OS • Imperative style • Possible issues with re-runs • Not scalable • Too many words • Not human readable 14
- 15. What we need? • Write once run anywhere • Declarative style • Idempotent operation • Human readable 15
- 17. CM responsibilities • Installation • Configuration • Deployment • Support • Update and upgrade • Monitoring 17
- 18. CM Architecture
- 19. Push 19
- 20. Push pros and cons • Can select node • Can run immediately • Limit of connection • Access to all nodes 20
- 21. CM Push tools 21
- 22. Pull 22
- 23. Pull pros and cons • Limit of connection • Decrease master load • Immediately run • We should run agent • Lost connection • DDOSed master 23
- 24. CM Pull tools 24
- 25. Local run 25
- 26. Local run pros and cons • Decrease master load • Configuration without networking • Immediately run • We should run agent • Lost connection 26
- 27. CM Local run tools 27
- 28. What should we use? 28 Comparison CM
- 29. Ansible
- 30. What is Ansible • Michael DeHaan in 2012 • Python • GNU General Public License v3.0 • Red Hat acquired Ansible in October 2015. 30
- 31. What is Ansible in reality? 31
- 33. How it works 33
- 34. Benefits • YAML syntax • Push system • Supports declarative style • Idempotent operation • Human readable 34
- 36. Setup ansible • Python 2 (versions 2.6 or 2.7) or Python 3 (versions 3.5 and higher) • Ansible 2.2.3 (2017-05-09) but 2.7.0 exist • SSH agent (winrm Python module for Win) 36
- 37. Setup managed node • Python 2 (versions 2.6 or 2.7) or Python 3 (versions 3.5 and higher) • SSH server (uses native PowerShell for Win) 37
- 39. Demo Summary • Simple to install • Can be used by single command • Available 10 commands 39
- 40. Basic knowledge
- 41. Inventory File in format INI or YAML that contains: • Lists of available host • Group of hosts • Groups of groups • Host & Group variables(configuration) 41
- 42. Playbook Is a point of entry in YAML format. • Each playbook is composed of one or more plays in a list. 42
- 43. Play Mapps a group of hosts to some well defined roles • Each play starts with a name parameter, declare its targeted hosts, tasks and handlers to use. 43
- 44. Task The goal of each task is to execute a modules, with very specific arguments. 44
- 45. Module Ansible libraries that can be executed directly on a remote. 45
- 46. Handler A Handler is exactly the same as a Task, but it will run when called by another Task. A Handler runs once end the end plays. 46
- 47. Playbook summary • Playbook contains plays • Play contains tasks • Tasks run sequentially and execute modules • Handlers are triggered by tasks and runs once end the end plays 47
- 48. Let’s set up ssh connection 48
- 50. Demo Summary • Inventory in differents formats • Can run through ssh with • Can retry with failed hosts • Module is magic • Handlers - running on change 50
- 51. Modules
- 52. Modules • apt, copy, cron, ... • vmware, docker, aws, azure, gcp,... • apache, mysql, postgresql influxdb,... • zabbix, twilio, gluster,... • etc 52
- 53. Modules Built in modules: 1850 3rd party modules: ~12000 All modules 53
- 54. Idempotent Modules should be idempotent, that is, running a module multiple times in a sequence should have the same effect as running it just once. 54
- 55. But... Some module can not be idempotent. • shell - we are responsible for idempotency • ec2 - is not idempotent without special parms • etc. 55
- 57. Dynamic Inventory We can create script to create inventory file • --list - inventory file in json format • --host - host variable in yaml format We can use cli ansible-inventory 57
- 58. Host variable/Facts/Gether facts Facts is result of setup module on remote systems. Facts starts with ansible_* Information discovered from systems: Facts 58
- 59. Own variable • Defined in Inventory or playbook per play • Defined from included files • Registered variables in tasks 59
- 60. Own variable vars: variable: 'value of variable' 60
- 61. How to use variable • {{ variable }} • YAML syntax requires that if you start a value with {{ variable }} you quote 61
- 62. How to use variable tasks: - debug: msg={{variable}} 62 tasks: - debug: msg: '{{variable}}'
- 63. Filters Filters in Ansible are from Jinja2, and are used for transforming data inside a template expression Filters: mandatory, default(value), hash, checksum, min, max, unique, intersect, difference, random, etc 63
- 64. Filters tasks: - debug: msg={{variable | checksum}} - debug: msg={{othervariable | default('Default value')}} 64
- 65. Template Templates are processed by the Jinja2 templating language. We can user all ansible variable inside template. 65
- 66. Template tasks: - name: add readme to home dir template: src: mytemplates.j2 dest: ~/readme 66
- 67. Condition One way to use condition in ansible to add when in task. 67
- 68. Condition tasks: - debug: msg={{variable | checksum}} when: showchecksum 68
- 69. Loop Few ways to use loop in ansible to add • with_item, with_nested, with_* • loop or loop_control in task. 69
- 70. Loop tasks: - name: add several users user: name={{ item }} state=present loop: - testuser1 - testuser2 70
- 71. Until (retry) One ways to use until in ansible to add until in task. The default value for “retries” is 3 and “delay” is 5. 71
- 72. Until tasks: - shell: /usr/bin/foo register: result until: result.stdout.find("all systems go") != -1 retries: 5 delay: 10 72
- 73. Blocks Blocks allow for logical grouping of tasks 73
- 74. Blocks tasks: - name: test block: - debug: msg={{variable | checksum}} - debug: msg={{othervariable | default('Default value')}} 74
- 75. Error Handling The tasks in the block would execute normally, if there is any error the rescue section would get executed. The always section runs no matter what previous error did or did not occur in the block and rescue sections. 75
- 76. Error details 76 • ansible_failed_task - the task that returned ‘failed’ and triggered the rescue. • ansible_failed_result - the captured return result of the failed task that triggered the rescue.
- 79. Demo Summary • Dynamic Inventory • Switch to root mode • Retry with until • Error Handling • Jinja2 template 79
- 80. Summary 80
- 81. Summary • Write once run anywhere • Declarative & idempotent operation • User readable language 81
- 82. What's next • YAML • Roles • Advanced knowledge • Security • Use cases 82
- 84. @banadiga ibanadiga@lohika.com Thanks! Ihor Banadiga for DevOps training @ Lohika