This document discusses using infrastructure as code to automate server setup and deployment using Ansible. It outlines benefits like reducing human error, allowing developers and operations teams to work seamlessly through continuous integration and testing. Specifics of the infrastructure as code stack used are covered, including Ansible for configuration management, Docker for containers, and Vagrant for local virtual machine provisioning. Challenges and lessons learned around testing, debugging, and migrating existing systems are also presented. The overall message is that infrastructure as code takes time to implement but results in major improvements to deployment speed, reliability, and ability to rapidly iterate.

1. Infrastructure = Code
1 year later
Christian Ortner
FINDOLOGIC GmbH

2. Y though?
● Automate setup / deployment
● Reduce human error
● Fail, fix, test, repeat

3. The DevOps Good
● Dev and Ops are inseparable these days
● Installing Dependencies, configuring stack
● Reduce friction and latency
● Understand deployment complexity
● No more local changes on servers

4. Our stack

5. Prod

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. Docker
FROM php:7-apache
MAINTAINER Georg M. Sorst <g.sorst@findologic.com>
COPY index.php /var/www/html/

8. Vagrant
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/xenial64"
config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.provision "ansible" do |ansible|
ansible.playbook = "playbook.yml"
end
end

9. Test 0.1

10. Dev

11. Test

12. 1 year later
● Much learning
● Server Setup from 2 days to 20 minutes
● For fun and profit

13. The Ansible good
● There’s a role for that
● Frequent updates
● Automated testing

14. Integration testing
HTTP

15. Integration testing
HTTP

16. Integration testing
HTTP

17. - name: Upload mock data
copy:
src: test/mock.json
dest: /tmp/mock.json
- name: Provide mock data using a web server container
docker_container:
image: tobilg/mini-webserver
name: mock_server
volumes:
- '/tmp:/app/public:ro'
state: started
become: yes
- name: Get IP from web server container
command: docker inspect --format '{% raw %}{{
.NetworkSettings.IPAddress }}{% endraw %}' mock_server
register: mock_server_server_ip_address
- name: Start application under test
docker_container:
image: findologic/my-app
env:
data_url: '{{ mock_server_ip_address }}:80'

18. - name: Ensure that mock data was fetched
command: docker logs mock_server
become: yes
register: mock_server_logs
failed_when: 'mock.json' not in mock_server_logs.stdout
- name: Check that app uses mock data
uri:
url: http://localhost
register: app_output
failed_when: 'something' not in app_output.content
- name: Destroy web server container
docker_container:
name: mock_server
state: absent
become: yes

19. The Bad
● Docker in Docker in Docker
● Migrating existing servers
● better start fresh
● Test, fail, fix cycle is slow
● tag tasks to speed up
● printf debugging

20. The Bad
● Yaml syntax errors
● Networking, routing, repo access, VPN, SSL

21. The awesome
● Automated builds
● Integration testing
● Mock dependencies with Docker containers
● Takes some time to figure out
● Great test harness for Ansible roles

22. The LOL
{{ string }} * 1000000 -> buffer overflow
wait_for, timeout < delay

23. Bottom line
● It’s fun
● It’s productive