Infrastructure as code is an approach to managing servers where their configuration is defined using code and version control rather than manual shell commands. Ansible is a tool that allows defining servers' desired state in YAML files checked into version control. It can automatically install software, configure systems, and ensure consistency across multiple servers using SSH without requiring an agent. Playbooks declare tasks to run that are idempotent, allowing Ansible to safely deploy changes. This approach improves on manual configuration by enabling testing, collaboration, and rolling back changes if needed.

1. Infrastructure = Code
Georg M. Sorst
CTO, FINDOLOGIC GmbH

2. What’s the challenge?
Who has already setup 1 server?
2 servers?
10, 1.000, 10.000?

3. Danger zone
● Setup: Manual shell commands
● Testing: Manual
● Multiple admins: Overwrite each other’s fixes
● Updates: Different versions on every server

4. Develop like it’s 1999
● Software Development has solved these issues:
● Installation: Deployment Scripts
● Testing: Unit Tests
● Multiple developers: git merge
● Updates: Version tagging

5. Infrastructure = Code?
● Define the desired state of the servers
● In human readable form
● Commit to VCS
● Automatically run tests
● Setup / Update server with single command
● Fail, fix and deploy

6. Ansible!
---
- hosts: webservers
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

7. What?
● “Ansible” = fictional instantaneous hyperspace communication system
● Michael DeHaan 2012 / Red Hat
● Python
● Declare desired state, not how to get there
○ name=apache state=present
○ Idempotent
● Agentless
○ Just needs SSH access
● Plain YAML
○ Can be versioned

8. Structure
● Inventory: Which hosts / hostgroups are available?
● Hosts: Which hosts to run on?
● Vars: Use in config files, tasks etc.
● Tasks: What to do?
● Handlers: Restart service on config change

9. Inventory
https://docs.ansible.com/ansible/intro_inventory.
html#groups-of-groups-and-group-variables

10. Playbook
https://github.com/georgms/ansible-
meetup/blob/master/apache.yml

11. Demo
git clone https://github.com/georgms/ansible-meetup.git

12. Demo: Ansible + Vagrant
● vagrant up
● vagrant provision
○ Idempotent
● http://localhost:8080/

13. Demo: Ansible + Docker
● Docker image with SSH + Python
● docker build -t ansible-meetup .
● docker run -i -t -p 8080:80 ansible-meetup

14. Testing, 1 2, Testing
● Use Ansible test modules
○ Get response from port
○ Check log file contents
● Jenkins: vagrant up
● Travis CI
○ https://github.com/georgms/ansible-meetup/blob/master/.travis.yml
● Automatically build Docker image / Vagrant box

15. What else
● Ad-hoc tasks: Reboot multiple servers
● Roles: This is a Web-Server, DB-Server, SSH
● Templates: Replace value in config file
● Conditionals: Run only on Ubuntu
● Loops: Install packages, create users
● Vault: Encrypt passwords, private keys

16. Lessons learned
● Use .d files, eg. /etc/apache2/conf.d/
● Takes a while to have really robust playbooks
○ Absolutely requires automated testing
● Don’t make local changes on servers
○ Commit to repo, run tests, deploy (just like code)
● < cowsay >
--------
^__^
(oo)_______
(__) )/
||----w |
|| ||

17. Ecosystem
● Ansible Galaxy: More than 5.000 roles available
● Ansible Tower: Centralized control panel, $$$
● Works well with OpenStack (both Red Hat)

18. What are my options?
● Puppet (requires agent, Ruby DSL)
● Chef (requires agent, Ruby based configs)
● Salt (agentless,YAML config)

19. Meetup
● 11.05.

20. Thx
● @piefke_schorsch
● g.sorst@findologic.com