Infrastructure = Code

587 views

Published on

What can sys admins and operations teams learn from software development to make their life easier?

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
587
On SlideShare
0
From Embeds
0
Number of Embeds
37
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Infrastructure = Code

  1. 1. Infrastructure = Code Georg M. Sorst CTO, FINDOLOGIC GmbH
  2. 2. What’s the challenge? Who has already setup 1 server? 2 servers? 10, 1.000, 10.000?
  3. 3. Danger zone ● Setup: Manual shell commands ● Testing: Manual ● Multiple admins: Overwrite each other’s fixes ● Updates: Different versions on every server
  4. 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. 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. 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. 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. 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. 9. Inventory https://docs.ansible.com/ansible/intro_inventory. html#groups-of-groups-and-group-variables
  10. 10. Playbook https://github.com/georgms/ansible- meetup/blob/master/apache.yml
  11. 11. Demo git clone https://github.com/georgms/ansible-meetup.git
  12. 12. Demo: Ansible + Vagrant ● vagrant up ● vagrant provision ○ Idempotent ● http://localhost:8080/
  13. 13. Demo: Ansible + Docker ● Docker image with SSH + Python ● docker build -t ansible-meetup . ● docker run -i -t -p 8080:80 ansible-meetup
  14. 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. 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. 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. 17. Ecosystem ● Ansible Galaxy: More than 5.000 roles available ● Ansible Tower: Centralized control panel, $$$ ● Works well with OpenStack (both Red Hat)
  18. 18. What are my options? ● Puppet (requires agent, Ruby DSL) ● Chef (requires agent, Ruby based configs) ● Salt (agentless,YAML config)
  19. 19. Meetup ● 11.05.
  20. 20. Thx ● @piefke_schorsch ● g.sorst@findologic.com

×