Ansible. Go directly to project site 1 / 36

Transcription

1 Ansible Go directly to project site 1 / 36

2 What is it and why should I be using it? 2 / 36

3 What is it? Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy. Avoid writing scripts or custom code to deploy and update your applications Automate in a language that approaches plain English, using SSH No agents to install on remote systems 3 / 36

4 What is it? Why use it? Ansible as a project dislikes complexity Simplicity is relevant to all sizes of environments and users of all types It's not meant to be a tool you should have to obsess over, and it believes "perfect is the enemy of good" in many cases. Therefore the learning curve is really fast. No coding, instructions are plain YAML Ansible is appropriate for managing small setups as well as enterprise environments with many thousands. 4 / 36

5 Setup the control machine 5 / 36

6 Setup the control machine Ansible uses python2.7 and SSH to communicate with your remote systems Have python2.7 installed Use SSH keys for your authentication: ssh-agent bash ssk-keygen ssh-add ~/.ssh/id_rsa ssh-copy-id -i /root/.ssh/id_rsa Install required packages apt-get install python-pip apt-get install python-dev Work in a virtualenv pip install virtualenv virtualenv myproject cd myproject. bin/activate pip install ansible 6 / 36

7 Your first commands 7 / 36

8 Your first command Ansible requires an inventory file echo "localhost" > ansible_hosts Ping all hosts in your inventory file ansible all -m ping -i ansible_hosts Congratulations. You ve just contacted your nodes with Ansible: localhost success >> { "changed": false, "ping": "pong" } 8 / 36

9 Your first commands Examine the command line ansible all -m ping -i ansible_hosts all Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in Ansible s inventory file. "all" is a special word to work with all the hosts at the same time. -m will accept a correct module name (e.g., "ping"). Ansible ships with a module library but you can write your own module too. Modules are idempotent, meaning they will seek to avoid changes to the system unless a change needs to be made. The (long) list of modules can be found here. -i The name of the inventory file. 9 / 36

10 The inventory file 10 / 36

11 The inventory file The format for ansible_hosts is an INI-like format and looks like this: [webservers] localhost [dbservers] one.example.com two.example.com three.example.com The things in brackets are group names, which are used in classifying systems and deciding what systems you are controlling at what times and for what purpose. It is ok to put systems in more than one group, for instance a server could be both a webserver and a dbserver. 11 / 36

12 Modules 12 / 36

13 Modules Ansible ships with a number of modules. Users can also write their own modules. Each module supports taking arguments. Nearly all modules take key=value arguments, space delimited. Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run. Most used modules apt -- Add/Remove packages file command -- Execute any shell command service -- Start/Stop/Enable services copy -- Copy a file from source to destination on host file -- Create directories, symlinks, change permissions template -- Copy, but with variable substitution in file Example: ansible all -m apt -i ansible_hosts -a "name=apache2 state=present" ansible all -m service -i ansible_hosts -a "name=apache2 state=started" 13 / 36

14 Playbooks 14 / 36

15 Playbooks Playbooks are Ansible s configuration, deployment, and orchestration language. They can describe a set of connected actions in a general IT process. If Ansible modules are the tools in your workshop, playbooks are your design plans. Playbooks are expressed in YAML format (see YAML Syntax) and have a minimum of syntax, which intentionally tries to not be a programming language or script, but rather a model of a configuration or a process. Each playbook is composed of one or more plays in a list. While it is possible to write a playbook in one very large file, eventually you ll want to reuse files and start to organize things. 15 / 36

16 Playbook Example Write an inventory file echo localhost > ansible_hosts Open a file named playbook.yml hosts: all vars: http_port: 80 remote_user: root tasks: - name: ensure apache2 is installed apt: name=apache2 state=present Run your playbook: ansible-playbook -i ansible_hosts playbook.yml 16 / 36

17 Test passed: PLAY [test] ************************************************************ TASK: [ensure apache2 is installed] ****************************************** ok: [localhost] => {"changed": false} PLAY RECAP ************************************************************ localhost : ok=2 changed=0 unreachable=0 failed=0 17 / 36

18 Playbook Roles and Include Actions 18 / 36

19 Playbook Roles and Include Actions A playbook that includes a role: - hosts: webservers vars: http_port: 80 remote_user: root roles: - webservers Roles are ways of automatically loading certain variables, tasks, templates, handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users. Example role structure: ansible_hosts webservers.yml roles/ webservers/ files/ templates/ tasks/ handlers/ vars/ defaults/ meta/ 19 / 36

20 Playbook Roles and Include Actions Role hierarchy: If roles/x/tasks/main.yml exists, tasks listed therein will be added to the play If roles/x/handlers/main.yml exists, handlers listed therein will be added to the play If roles/x/vars/main.yml exists, variables listed therein will be added to the play If roles/x/meta/main.yml exists, any role dependencies listed therein will be added to the list of roles (1.3 and later) Any copy tasks can reference files in roles/x/files/ without having to path them relatively or absolutely Any script tasks can reference scripts in roles/x/files/ without having to path them relatively or absolutely Any template tasks can reference files in roles/x/templates/ without having to path them relatively or absolutely Any include tasks can reference files in roles/x/tasks/ without having to path them relatively or absolutely 20 / 36

21 Variables Variables should always start with a letter. foo_port is a great variable. foo5 is fine too. foo-port, foo port, foo.port and 12 are not valid variable names. Variables can be defined in many places (pros & cons..) in inventory in a playbook included files There are "facts", a type of variable that are discovered, not set by the user. Facts are returned by the module "setup", for example: The hostname as the system reports it is: {{ ansible_hostname }} registered variables (a task output) command line (--extra-vars) 21 / 36

22 Variables hierarchy extra vars (-e in the command line) always win then comes connection variables defined in inventory (ansible_ssh_user, etc) then comes "most everything else" (command line switches, vars in play, included vars, role vars, etc) then comes the rest of the variables defined in inventory then comes facts discovered about a system then "role defaults", which are the most "defaulty" and lose in priority to everything. 22 / 36

23 Ansible and AWS 23 / 36

24 Ansible and AWS Ansible contains a number of modules for controlling Amazon Web Services (AWS). All of the modules require and are tested against recent versions of boto. You ll need this Python module installed on your control machine. pip install boto Static inventory or dynamic Inventory?If you use Amazon Web Services EC2, maintaining an inventory file might not be the best approach, because hosts may come and go over time, be managed by external applications, or you might even be using AWS autoscaling. 24 / 36

25 Ansible and AWS AWS services ships with a set of credentials: ssh key acces_id secret_key Add the ssh key ssh-add keyname and set its name in aws-related playbooks (ansible will look for your ssh-key in the standard path ~/.ssh/). Set your access_id and secret_key in a "vars" file, then source it: export BOTO_CONFIG=/path/boto.conf export EC2_INI_PATH=/path/ec2.ini export AWS_ACCESS_KEY_ID=EXAMPLEKEY export AWS_SECRET_ACCESS_KEY=ThisIsAnExample export AWS_DEFAULT_REGION=region. aws-vars 25 / 36

26 Ansible and AWS Some simple checks:./plugins/inventory/ec2.py --list { "_meta": { "hostvars": {... "ec2_architecture": "x86_64",... } } "ec2": [... "ec2-name.region.compute.amazonaws.com"... ] } ansible all -i./plugins/inventory/ec2.py -m ping --user=admin ec2-name.region.compute.amazonaws.com success >> { "changed": false, "ping": "pong" } 26 / 36

27 Manage your AWS nodes with ansible 27 / 36

28 Create and start a node demo-create.yml - name: Creates aws-nodes hosts: all connection: local remote_user: root vars: image_id: image-id instance: instance-type key_name: ssh-key region: region-name tasks: - name: Create and launch instance ec2: key_name: "{{ ssh-key }}" instance_type: "{{ instance }}" image: "{{ image_id }}" region: "{{ region }}" state: present count: 1 wait: yes ansible-playbook -i aws.ini demo-create.yml 28 / 36

29 Stop a node demo-stop.yml - name: Stop aws servers connection: local remote_user: root vars: - region: region_name tasks: - name: Stop instances ec2: region: "{{ region }}" state: stopped instance_ids: "{{ec2_id}}" ansible-playbook -i plugins/inventory/ec2.py demo-stop.yml To see your instances being stopped. 29 / 36

30 Provision nodes Provision your nodes Install apache on remote AWS hosts./bin/ansible all -m apt -i plugins/inventory/ec2.py -a "name=apache2 state=present" --user=admin -become=sudo "changed": true, "stderr": "", "stdout": "Reading package lists... Building dependency tree... Reading state information Setting up apache2" 30 / 36

31 Delete nodes demo-terminate.yml - name: Delete aws servers remote_user: root vars: - region: region_name tasks: - name: Delete hosts ec2: instance_ids: "{{ ec2_id }}" region: "{{ region }}" state: absent wait: yes ansible-playbook -i plugins/inventory/ec2.py demo-terminate.yml 31 / 36

32 Some tools 32 / 36

33 Some tools ansible-galaxy It is the Ansible s official community hub for finding, downloading, rating, and sharing Ansible roles. ansible-galaxy install username.rolename You can use ansible-galaxy to start a project of your own ansible-galaxy init --offline test-role -- test-role -- defaults `-- main.yml -- files -- handlers `-- main.yml -- meta `-- main.yml -- README.md -- tasks `-- main.yml -- templates `-- vars `-- main.yml 33 / 36

34 Some tools debops Your Debian-based data center in a box. It is a framework. It can be installed through ansible-galaxy. It is a collection of Ansible playbooks, scalable from one container to an entire data center. ansible-galaxy install debops.apt ansible all -s -m apt -a 'update_cache=yes upgrade=yes' 34 / 36

35 Some tools epdb epdb or pdb? The reason to use epdb over pdb is epdb contains a remote debugging feature that can sometimes be useful for debugging processes where you don t have console access. In python module write: import epdb epdb.serve() Command line to execute module: ansible --forks 1 -i ansible_hosts --module-path path -m module_name -a '' Command line to see breakpoint: python -c "import epdb; epdb.connect()" 35 / 36

36 "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." IBM maintenance manual, 1925 Slideshow created using remark. 36 / 36