"Using Automation Tools To Deploy And Operate Applications In Real World Scenarios"

"Using Automation Tools To Deploy And Operate Applications In Real World Scenarios"

• 1.
  Using Automation ToolsTo 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 didwe 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 didwe 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 wasneeded? • 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 optionsdid 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 optionsdid 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 andwhy 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 otheroption 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 canansible 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 doesansible use? • To describe the target state ansible uses • Inventory • Variables • Roles • Playbooks • Done in yaml
• 12.
  Slide 12 How doesthis 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 doesthis 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 doesthis 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 doesthis 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 doesit look? Demo! • Example installing apache and certificates takes a few minutes • Optional: Fix a mistake easily
• 17.
  Slide 17 Summary • Makesmall 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 & SolutionsSoftware 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