How is automation done in real world (and) on existing systems. This webcast shows our way from existing handmade installations to ansible playbook managed environment. Why did we choose ansible over others? A demo shows installation and how automation tools can reduce stress during incident remediation situations. Speaker: Christian Hilgers, Senior Software Engineer at ConSol Düsseldorf

1. Using Automation Tools To Deploy and
Operate Applications in Real World Scenarios
Christian Hilgers
Senior Software Consultant

2. Slide 2
Agenda
• Welcome
• Where did we came from?
• What was needed?
• Which options did we had?
• What and why was choosen?
• How does this help to make systems more robust?
• How does it look? Demo!
• Summary

3. Slide 3
Where did we came from?
• Example taken from Telco customer
• Existing environment handles 6+ mio Requests per day
• Production Environment:
• From different combinations of Solaris 10 on Sparc and x86
to Red Hat Enterprise Linux (RHEL) on x86 on Hardware
• HW was replaced 3 times since go-live
• Test Environment:
• VMs with Solaris 10 x86 and later RHEL x86
• Backend proxies are mixed VM and Hardware

4. Slide 4
Where did we came from?
• Solaris needed manual compilation of apache httpd, openssl and apache add-ons
every time a security issue was fixed
every time an updated release showed up
• Compiled code in test was not usable in prod (x86 vs. Sparc)
• Update process took hours and needed lots of scripts to compile and distribute
• All in all: error prone

5. Slide 5
What was needed?
• Proxies on Apache httpd base
• Decrypt incoming connections
• Encrypt outgoing connections
• Have all certificates at one place
• No default certificate bundles
• Rollout software, config, and certificates (+ removal)
• Reproducible
• Easy

6. Slide 6
Which options did we had?
• Option 1: do it manually
• Pro: quick the first time
• Con: easy to forget files, executing command on all systems, …
• Con: forget one system results in weird error scenarios
• Option 1.5: write scripts
• Sadly abt. 80% of code is error handling and special stuff
• Option 2: Use automation tools
• Con: takes longer the first time
• Pro: reproducible
• Pro: Works on all Environments

7. Slide 7
Which options did we test?
• Option 1: do it manually
• Been there
• Option 1.5: write scripts
• Done that
• Option 2: Use automation tools
• Seen that ;-)
Evaluation which automation tool to use, started

8. Slide 8
What and why was choosen?
• Automation tools
• Compare target state with the actual status
• Take actions to change actual state into target state
• Work idempotent, can run several times without breaking things
• Ansible was choosen due to specific contraints in that environment like
• No extra software needed, only python
• No extra port needed, just ssh
• No permanent connection needed

9. Slide 9
What other option did we had?
• Puppet
• uses extra Port, Firewall Rule needed -> KO
• Chef
• uses extra Port, Firewall Rule needed -> KO
• SaltStack
• uses extra Port, Firewall Rule needed -> KO
• Pretty fast
• Ansible
• Communicates via ssh -> OK
• Only python needed

10. Slide 10
How can ansible be used?
• With a playbook:
• Typical way of using ansible
• Combines plays and roles
• Add-hoc commands:
• ansible ts2ucipr007 -m ping
ts2ucipr007 | SUCCESS => {
"changed": false,
"ping": "pong"
}
• ansible frontendproxy -m shell -a "uname –a"
ts2ucipr007 | CHANGED | rc=0 >>
Linux ts2ucipr007 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021 x86_64 x86_64
x86_64 GNU/Linux

11. Slide 11
What does ansible use?
• To describe the target state ansible uses
• Inventory
• Variables
• Roles
• Playbooks
• Done in yaml

12. Slide 12
How does this help to make systems more robust?
• Inventory
• List of systems ansible needs to know
• Allows grouping of systems and inheritance
• Variables
• Define specific attributes for hosts and groups

13. Slide 13
How does this help to make systems more robust?
• How to create an inventory
• Manually for static environments like VMs or HW
• Automatically from eg. cloud provider API Infrastructure as code

14. Slide 14
How does this help to make systems more robust?
• Use small groups and combine them
[appserverSolaris]
appserv001
appserv002
appserv003
mickey
minnie
[appserverRedHat]
appserv011
appserv012
gustav
[appserver:children]
appserverRedHat
appserverSolaris

15. Slide 15
How does this help to make systems more robust?
• Grouping allows
• Smooth migration and steering during installation
• Changing default variables using group_vars
• We used this to migrate from Solaris to
RedHat Servers in Production
• Ansible-playbook runs can be restricted to hosts or groups

16. Slide 16
How does it look? Demo!
• Example installing apache and certificates
takes a few minutes
• Optional: Fix a mistake easily

17. Slide 17
Summary
• Make small groups and combine them
• Keep roles and playbooks generic
• Put specific information into host_vars, group_vars, inventory
• Use intrinsic ansibe_facts to eg. differentiate OS (Solaris vs. RedHat)
or versions (RHEL 7 vs. RHEL 8)
• Use tags
• Result
• Be able to run playbooks and roles on local test VMs for develpoment and debuging
• Be able to migrate fast to new target environment in case of emergency change

18. Questions?

19. Thank you!

20. ConSol
Consulting & Solutions Software GmbH
St.-Cajetan-Straße 43
D-81669 Munich
Germany
Tel.: +49-89-45841-100
info@consol.de
www.consol.com
Twitter: @consol_de

21. Slide
Krakow / Poland
Vienna / Austria
Dubai / UAE
Dusseldorf
Munich
San Francisco / USA