Go Faster with Ansible (AWS meetup)
•Télécharger en tant que PPTX, PDF•
3 j'aime•982 vues
This document discusses how Ansible can be used to configure infrastructure and deploy applications faster and more reliably. It provides an overview of key Ansible concepts like playbooks, tasks, roles, and dynamic inventories. It also summarizes how to install Ansible, write a sample Apache playbook, use roles for reusability, and find community roles on Ansible Galaxy. Advanced topics covered include testing infrastructure code, the Drupal VM project, and how to write custom Ansible modules.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Go Faster with Ansible (AWS meetup)
Similaire à Go Faster with Ansible (AWS meetup) (20)
Dernier
Dernier (20)
Go Faster with Ansible (AWS meetup)
- 1. Go Faster with Ansible AWS Bath Meetup Richard Donkin @rdonkin
- 2. $ whoami • Richard Donkin • DevOps engineer / contractor • Ansible, Packer, Vagrant, Docker, Linux, AWS, databases, … • Experience of sys admin, DevOps, backend dev, architecture, startups, … @rdonkin linkedin.com/in/rdonkin www.tempohq.net
- 3. Goal: Faster Correct Setup Servers Apps Developers • Correct configuration • No snowflake servers • Dev, Test, Production
- 4. Infrastructure As Code Software processes and tools for infrastructure configuration
- 5. What Ansible Does Configuration Management • Code that controls config App Deployment Orchestration • Sequence operations on servers, APIs, etc.
- 6. Why Ansible? • Agentless & serverless • Simple • Sequential • Declarative tasks • “Ensure nginx installed” • Enables idempotence • Easy to learn • Scales to complex cloud orchestration
- 7. Quick Install Mac: brew install ansible Debian/Ubuntu: sudo apt-add-repository ppa:ansible/ansible sudo apt-get install -y ansible RHEL/CentOS: use EPEL, then: sudo yum –y install ansible Any Linux (latest Ansible, requires Python): sudo easy_install pip sudo pip install ansible
- 9. Key Concepts Playbook = series of tasks • Targets one server or thousands • Servers defined by Inventory Task = "ensure X is done" action Play = set of tasks in playbook
- 10. Running a Playbook (1)
- 11. Running a Playbook (2) Tasks will "skip" if state already OK (Idempotence)
- 12. Writing a Playbook Play – hosts to process, become == sudo Tasks - descriptive name - invoke module (apt) with parameters Play Task
- 13. The Secret Life of Tasks Each task runs SSH commands that • Upload a Module (e.g. apt) • Run module with task's parameters • Return JSON output
- 14. Inventory and Variables Group your servers & assign parameters [web] 10.0.1.51 10.0.1.52 [db] 10.0.1.61 [web:vars] ansible_port=2222 $ ansible-playbook -i prod apache.yml --limit web Ansible conditions based on groups and vars (Typically) inventory file for dev, test, prod, ...
- 15. AWS Dynamic Inventory Generated by ec2.py from AWS API • EC2 instances, Route53, RDS, … • Many params per instance, inc. one per tag • Groups for regions, AZs, and Tags: ansible tag_KEY_VALUE -m ping
- 16. Apache Playbook (1) Vars = parameters for this playbook Can be in separate include files Or attach to hosts or host-groups in Inventory - e.g. Listening IP address should be in inventory
- 17. Apache Playbook (2) template task runs Jinja2 on local file and copies to server notify sends event to Handler - Each Handler runs just once, at end of whole playbook - Restart a service, notify Slack, ...
- 18. Apache Playbook (3) service task uses systemctl to enable start on boot - {{ apache_service }} instantiates var with Jinja2 Handler restarts apache at end if any task does a notify
- 20. Modules Over 840 modules "in the box" - Git, yum, apt, compose, pip, gem, … - Files: copy, template, edit, … - Permissions, ownership, SELinux - MySQL, PostgreSQL, MongoDB, ... Targets: - Linux, Windows, Mac, Docker, VMs - AWS, Azure, GCP, network devices Anything with an API or CLI
- 21. AWS Security Groups Define security groups as vars in YAML • Format defined by your playbook • Each has list of rules (ingress and egress)
- 22. AWS Security Groups Playbook applies all groups in a list
- 23. Roles "Modularised playbooks" - Split playbook into folder per type of content - defaults folder for "parameter vars" - vars folder for "role vars" – hard to override - meta folder for role dependencies Vars Tasks Handlers Apache + PHP playbook Apache role PHP role
- 24. Roles Use Roles for everything! Skinny playbooks + modular roles Ideal playbook only calls roles, not tasks Typical roles: • create-vpc • create-instances • base, apache, php, redis • deploy-app "Wrapper roles" to invoke third party roles
- 25. Ansible Galaxy Hub for 1000s of roles: galaxy.ansible.com Discovery: Galaxy, GitHub, blogs, … Assess quality carefully Install the roles needed by project: ansible-galaxy install –r requirements.yml Pin the role to a version or Git commit
- 26. Testing Infra Code Basic testing: - Separate test playbook using Vagrant VM - Travis CI popular for open source - Smoke test at end of playbook: Test frameworks: - Test-Kitchen, ServerSpec, InSpec, testinfra - Run whole series of tests - easier diagnosis
- 27. Drupal VM Create a VM with one command: vagrant up Ansible: 37 roles, 630 tasks, 7,200 lines of code
- 28. Resources Book: Ansible for DevOps by Jeff Geerling – regular updates Help: Stack Overflow, Ansible IRC + email lists Roles: • Geerlingguy roles – wide range – pragmatic & well maintained • Ansistrano: Deploying PHP apps demo (atomic model) Projects: • Drupal-VM – http://drupalvm.com • Trellis - https://roots.io/trellis/ - very complete WordPress setup • Use example project – requires node, bower & gulp Best practices: Ansible.com, blogs by Leucos and Nylas Podcasts: Arrested DevOps – general DevOps and Infra as Code
- 30. Infrastructure as Code Software processes for cloud resources and server configs: • Code review • Version control • Automated tests • Automated push to servers
- 31. Rapid Growth in Ansible Activity • Google Trends • 5 years to Jan 2017
- 32. One Liners Ad hoc command on single host, or group from inventory
- 33. Trellis: Modern WordPress Near Twelve Factor WordPress • Dev to Prod • PHP 7.1, A+ SSL, HTTP/2, WP-CLI, … • Example: rightsinfo.org Related roots.io projects: • Bedrock (WP boilerplate) • Sage (starter theme) • Some commercial add-ons Example project (blog post): • Install node, gulp, bower, Vagrant plugins • vagrant up • Some fixes required for Ansible 2.2
- 34. Advanced: Write a Module Much more common to write a role Required for major new features: • New API • New package tool • New container format Most modules written in Python Any language is fine: • PHP, C, Go, Perl, PowerShell, ...
Notes de l'éditeur
- Photo credit: https://www.flickr.com/photos/automobileitalia/16675249764/
- Go Faster without creating new problems... "Faster" really means more iterations per day / week Servers created much faster, without manual work Apps deployed automatically, without mistakes or omissions Deveopers on-boarded very fast, without manual installs This means: Configuration must be correct, even when moving faster Avoid snowflake servers (every one is different in detailed config) scale across dev, test, staging, production
- Capistrano style "atomic symlink" deployment involves having a single symbolic link called "current" pointing to the release that's live. Deployment means pushing the new files into a new release directory, then atomically switching the link. See Ansistrano, which enables this Capistrano model using Ansible, enabling customisation for more complex models as required. There is also f500.project-deploy, which is less powerful e.g. no before/after hooks. Rocketeer is a PHP tool that does the same thing. Fabric is a Python tool that can do anything on servers, often used for simpler deployments – requires Python coding and is lower level than Ansistrano Although Ansible can do both CM and App deployment, you normally want quite separate server configuration management and app deployment scripts (Playbooks). - "CM is a process, deployment is an event"
- – agentless - only requires SSH & Python on server simple but powerful sequential model for tasks Declarative tasks easy to learn compared to Puppet/Chef/Salt - explicit ordering visible in code, unlike Puppet/Salt easy orchestration e.g. easy to remove servers from LB during upgrade, and rollback if X% fail: Remove server from load balancer Deploy app & reboot Restore to load balancer
- Upgrades are easy with the "Any Linux" method – just do "pip install --upgrade ansible" For Windows, use a Linux VM on VirtualBox – Ubuntu is probably easiest option. Or use Windows 10's "bash shell" (Linux subsystem for Windows), which is a reasonably complete Ubuntu userland on the Windows kernel.
- Setup task = get server info (OS, hardware) – built in, can disable with "gather_facts: no" at top of play
- Parameters – single line or indented YAML The single line format (e.g. update_cache=yes) is unique to Ansible, and not part of YAML The indented format (e.g. "apt:") is YAML YAML is equivalent to JSON, using indentation. Use the "-" syntax to create a list – each new item is a list entry (equivalent to a PHP array with integer index values) Use the "foo: bar" syntax to create a key-value pair within a dictionary (equivalent to a PHP array with string index values)
- Originally known as "hosts file" – term still used in Ansible error messages Default is /etc/ansible/hosts but that's not very useful in most cases where you have different projects, environments, etc. Getting the right inventory structure, and locating variables in right place, is a key decision in Ansible projects. Generally, try to have variables in as few places as possible, e.g.: role defaults, role vars, host group vars, and use wrapper roles (mentioned later) to encapsulate vars you need for roles. Some people prefer a "group + environment" naming scheme, or moving each inventory file to a separate directory.
- This is very powerful – for example if you have a tag servertype with value prod_webserver, you can use the Ansible host group tag_servertype_prod_webserver to configure only those servers, without writing any extra code.
- - This is a simplified extract from a real-world Ansible project, the Drupal-VM role "geerlingguy.apache", combining various elements into a single playbook.
- Can target network switches and routers that don't have Python If you use Windows, you normally need a Linux VM to actually run Ansible, targetting Windows servers via WinRM and modules normally written in PowerShell, or leveraging PowerShell DSC (a basic config engine for Windows). Ansible is used to manage some large Windows deployments including over 1,000 servers on Azure at Jet.com.
- Roles are more reusable if they focus on a single logical service, or a related set of config – e.g. Apache, PHP and PHP-FPM are more re-usable if written as separate roles. Files are searched for within the current role, avoiding complex relative paths in many cases
- Look for steady development, several contributors, many commits, discussion on GitHub Always pin the role – this avoids surprises when your project changes "Vendoring" the role can help i.e. install into a "vendor/roles" folder in your project – be sure to adjust your ansible.cfg's role_path Galaxy is not that easy to browse/search, and most of the action is on GitHub I usually install directly from GitHub using Ansible Galaxy as a discovery and installation tool only.
- Goal: Test-driven infrastructure ServerSpec and InSpec provide English-like BDD testing using a DSL based on Ruby Testinfra provides simple unit tests using Python Just as with app testing, infra testing frameworks are generally more powerful than using Ansible to test itself – e.g. you can easily run just a few tests RoleSpec specifically tests Ansible roles – the others focus more on the outputs of the roles
- Fully open source
- Server config problem? Code a fix
- - can't really track "Chef" searches as Google Trends doesn't offer a software classification of term.
- Try these as well: ansible web -m setup -a 'filter=ansible_all_ip* ansible devbox -m setup -a 'filter=ansible_mem*'
- Requires node, bower and gulp and some Vagrant plugins Should work with Ansible 2.0.2.0 as specified in the docs (run "pip install --upgrade ansible==2.0.2.0" as long as you're already using the "pip install ansible" method to install Ansible). Some fixes needed for Ansible 2.2 (mailhog and logrotate roles, php-fpm pool from wordpress-setup role, and composer role) Trellis clone gives you trellis tree (ansible), then Bedrock clone gives you WP site tree, and Sage clone populates WP theme inside that Includes Nginx "micro caching" for 5 sec to Reddit-proof your site