Introducing Ansible

Introducing Ansible
Introducing Ansible Francesco Pantano francesco.pantano@opmbx.org March 7, 2016
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation A day in the life of a sysadmin 2/32
The timeline ”We have the misfortune to be living in the present. In the future, of course, computers will be smart enough to just figure out what we want, and do it. Until then, we have to spend a lot of time telling the computer things it should already know.” A day in the life of a sysadmin 3/32
Keeping the configuration synchronized A day in the life of a sysadmin 4/32
Repeating changes across many servers The command to create a new user account is slightly different for Red Hat Linux from the equivalent command for Ubuntu, for example. Solaris is a little different again. Each command is doing basically the same job, but has differences in syntax, arguments, and default values. A day in the life of a sysadmin 5/32
Self-updating documentation A new sysadmin joins your organization, and he needs to know where all the servers are, and what they do. Even if you keep scrupulous documentation, it can’t always be relied on. The only accurate documentation, in fact, is the servers themselves. You can look at a server to see how it’s configured, but that only applies while you still have the machine. If something goes wrong and you can’t access the machine, or the data on it, your only option is to reconstruct the lost configuration from scratch. Wouldn’t it be nice if you had a configuration document which was guaranteed to be up to date? A day in the life of a sysadmin 6/32
Version control, history, continuous integration A day in the life of a sysadmin 7/32
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation Automation 8/32
Why Automation? Fast deployment time It’s cheap and flexible Scalability and support Standard environments Automation as a standardized approach IT automation is a standard approach that combines multi-node software deployment, ad-hoc task execution and configuration management. Automation 9/32
The Automation environment Automation 10/32
IT Automation: Terminology Idempotence: the ability to run an operation which produces the same result whether run once or multiple times Inventory: hosts file that defines: the description of the nodes that can be accessed the IP address or hostname of each node nodes group to run a different set of tasks nodes parameters such as username, password or ssh keys Playbooks: they express configurations, deployment and orchestration in Ansible. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible call tasks. Automation 11/32
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation Introducing Ansible 12/32
Quick Start Linux - run natively e.g. on a Fedora/RHEL/CentOS: yum -y install ansible Debian or Ubuntu sudo apt-add-repository -y ppa:ansible/ansible sudo apt-get update sudo apt-get install -y ansible Verify your installation $ ansible –version ansible 2.0.1.0 config file = /etc/ansible/ansible.cfg configured module search path = Default w/o overrides Introducing Ansible 13/32
The inventory file Where it is located /etc/ansible/hosts What is the format [mailservers] mail.example.com [webservers] foo.example.com ansible ssh user = user001 bar.example.com ansible ssh private key file = /.ssh/ansible key001 [dbservers] one.example.com two.example.com db-[a:f].example.com Introducing Ansible 14/32
The inventory file I can define a group of machines # Group ’multi’ with all servers [multi:children] vm01 vm02 # Variables that will be applied to all servers [multi:vars] ansible ssh user=user001 ansible ssh private key file = /.ssh/pkey ..available parameters https://docs.ansible.com/ansible/intro inventory.html Introducing Ansible 15/32
The Ansible command line ansible-playbook Execute a playbook ansible-galaxy Roles management ansible example -a ”free -m” -u [username] Run the free command on the example domain ansible example -m ping -u [username] Run the ping command on the example domain ansible atlanta -m copy -a ”src=/etc/hosts dest=/tmp/hosts” File copy using the copy module ansible all -m user -a ”name=foo password=’crypted password here’” User and group management Introducing Ansible 16/32
Your first Ansible playbook Host section It is related to a section of the inventory file described above --- - hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/ srv/httpd.j2 dest =/etc/httpd.conf notify: - restart apache - name: ensure apache is running (and enable it at boot) service: name=httpd state=started enabled=yes handlers: - name: restart apache service: name=httpd state=restarted Vars Section Variables used to the tasks in order to parametrize something Introducing Ansible 17/32
Your first Ansible playbook Task section Groups of tasks that are performed on a certain set of hosts to allow them to fulfill the function you want to assign to them. Notify section This is not an internal Ansible command, it is a reference to a handler, which can perform certain functions when it is called from within a task. Handlers section Handlers are just like tasks, but they only run when they have been told by a task that changes have occurred on the client system. Run the playbook ansible-playbook playbook.yml Introducing Ansible 18/32
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation Ansible Playbooks: beyond the Basics 19/32
Playing with variables --- - hosts: example vars: foo: bar tasks: # Prints "Variable ’foo’ is set to bar". - debug: msg="’foo’ is set to {{ foo }}" Variables always begin with a letter ([A-Za-z]), and can include any number of underscores ( ) or numbers ([0-9]). Variables can be passed in via the command line, when calling ansible-playbook, with the –extra-vars option: ansible-playbook example.yml –extra-vars ”foo=bar” Ansible Playbooks: beyond the Basics 20/32
Registering/Accessing variables Send a command and register the result... name: Get the value of the environment variable we just added. shell: ”source /.bash profile && echo $ENV VAR” register: foo ..and then use it as before - name: Print the value of the environment variable. debug: msg = ”The variable is {{ foo.stdout }}” Ansible Playbooks: beyond the Basics 21/32
Per-play environment variables # Set to ’absent ’ to disable proxy: proxy_state: present # In the ’tasks ’ section of the playbook: - name: Configure the proxy. lineinfile: dest: /etc/ environment regexp: "{{ item.regexp }}" line: "{{ item.line }}" state: "{{ proxy_state }}" with_items: - {regexp:"^http_proxy=",line:"http_proxy=http :// example -proxy :80/"} - {regexp:"^https_proxy=",line:" https_proxy =https :// example -proxy :443/"} - {regexp:"^ftp_proxy=",line:"ftp_proxy=http :// example -proxy :80/"} Doing it this way allows me to configure whether the proxy is enabled per-server, and with one play, set the http, https, and ftp proxies. You can use a similar kind of play for any other types of environment variables you need to set system-wide. Ansible Playbooks: beyond the Basics 22/32
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation Roles and Includes 23/32
Roles and Includes Ansible is very flexible when it comes to organizing your tasks in more efficient ways so you can make your playbooks more maintainable, reusable, and powerful. We are talking about: Includes Roles Includes examples handlers: - include: included-handlers.yml tasks: - include: tasks/common.yml - include: tasks/apache.yml - include: tasks/mysql.yml Roles and Includes 24/32
More about roles Including playbooks inside other playbooks makes your playbook organization a little more sane, but once you start wrapping up your entire infrastructures configuration in playbooks, you might end up with something resembling Russian nesting dolls. The solution comes with the keyword: roles. Roles provides a way to take bits of configuration and packages and make them flexible so we can use them throughout our infrastructure and we can include them in this way: roles: - yum-repo-setup - firewall - nodejs - app-deploy Roles and Includes 25/32
Role essentials Instead of requiring you to explicitly include certain files and playbooks in a role, Ansible automatically includes any main.yml files inside specific directories that make up the role. Roles structure There are only two directories required to make a working role: role name/ meta/main.yml tasks/main.yml Ansible will run all the tasks defined in tasks/main.yml, you just need to include the created role using following syntax: - - - - hosts: all roles: - role name Your roles can live in a couple different placesin the default global Ansible role path configurable in /etc/ansible/ansible.cfg. Roles and Includes 26/32
Enter Ansible Galaxy: Be social Wouldnt it be better if people could share roles for commonly-installed applications and services? Helpful Galaxy commands Some other helpful ansible-galaxy commands you might use from time to time: ansible-galaxy list displays a list of installed roles, with version numbers ansible-galaxy remove [role] removes an installed role ansible-galaxy init can be used to create a role template suitable for submission to Ansible Galaxy Roles and Includes 27/32
#Outline 1 A day in the life of a sysadmin 2 Automation 3 Introducing Ansible 4 Ansible Playbooks: beyond the Basics 5 Roles and Includes 6 Automating Your Automation Automating Your Automation 28/32
Ansible tower Continuous integration It’s always a good practise use a continuous integration model inside your infrastructure Go Over the CLI The business needs detailed reporting of infrastructure deployments and failures, especially for audit purposes. Team-based infrastructure management requires varying levels of involvement in playbook management, inventory management, and key and password access. A through visual overview of the current and historical playbook runs and server health helps identify potential issues before they affect the bottom line. Playbook scheduling can help ensure infrastructure remains in a known state. Automating Your Automation 29/32
Ansible tower Automating Your Automation 30/32
Thank you! Questions? More examples at https://github.com/ansible/ Automating Your Automation 31/32
References Ansible for DevOps https://leanpub.com/ansible-for-devops Ansible in Real Life https://www.reinteractive.net/posts/167-ansible-real-life- good-practices Ansible Tower https://docs.ansible.com/ansible-tower/ Official doc https://docs.ansible.com/ Automating Your Automation 32/32

Check these out next

Introducing Ansible

Recommended

More Related Content

Slideshows for you(20)

Viewers also liked(20)

Similar to Introducing Ansible(20)

Recently uploaded(20)

Introducing Ansible