Configuration Managment met Ansible

Door Heli0s op vrijdag 27 februari 2015 07:43 - Reacties (5)
Categorie: -, Views: 3.063

De eerste keer dat ik Ansible gebruikte, was om een update te doen aan onze servers waar nog geen Puppet draait. Ik vind het altijd verschrikkelijk als ik iets meer dan 2 keer moet doen en probeer het dan onmiddellijk te automatiseren. Het werkte erg simpel en het was de investering van tijd meer dan waard.
Wat is Ansible?
Volgens Ansible zelf: "Ansible is the simplest way to automate.". Ansible is software om de configuratie van een Server (Of client) te beheren. Het voordeel van dit soort software is dat je alles vanaf een plek kan beheren. Dit zorgt er voor dat je makkelijker, sneller en met minder fouten meer server kan beheren.
Er is een hele Waslijst aan verschillende pakketten om uit te kiezen, dus waarom Ansible?

Voor mij is het aller grootse voordeel van Ansible dat het zonder client werkt. Dit doet Ansible door gebruik te maken van OpenSSH en een aantal standaard tools. De enige vereiste voor de client is Python 2.4 of later en als je een Python versie eerder dan 2.5 draait heb je python-simplejson nodig. Heb je dit en kan je naar de machine ssh'en dan kan je met Ansible werken.

Ansible zelf adviseert om het via je package managment te installeren (Op de machine vanaf waar je wilt beheeren) of via pip.
Maar hoe werkt het dan?
Als je Ansible hebt geinstallerd op je beheer machine kan je testen of het werk met:


code:
1
ansible server_naam -m ping -u root



Als je op deze machine geen ssh-key hebt, moet je de optie --ask-pass mee geven. Mocht je voor een commando sudo rechten nodig hebben moet je de optie --ask-sudo-pass mee geven. Als alles goed is zou je de volgende response terug moeten krijgen:


code:
1
2
3
4
server_naam | success >> {
    "changed": false,
    "ping": "pong"
}



Top, het werk! Alleen moet ik nu nogsteeds elke server apart een commando geven, dat is nog steeds een hoop hand werk. Om dit op te lossen heeft Ansible een hosts file. Deze word geschreven in een INI formaat:


code:
1
2
3
4
5
[servers]
192.168.0.1
192.168.0.3
server1
server2



Dit is dus een lijst met een kopje voor de groeps naam, en dan een lijst met DNS namen of IP adressen. Je kan nu door de file mee te geven het commando op een groep of op alle servers uit de lijst:


code:
1
2
3
4
5
# Alle hosts:
ansible all -m ping -u root -i hosts_file_naam

# Een groep:
ansible groep_naam -m ping -u root -i hosts_file_naam

Playbooks
De echte kracht van Ansible zit hem in wat ze Playbooks noemen. Een playbook is een YAML config file die beschrijft wat er moet gebeuren. Playbooks worden stap voor stap uitgevoerd en kunnen dus een workflow uit voeren. Denk bijvoorbeeld aan het volgende:
  • zet server in maintenence mode
  • haal de server uit de load balancer
  • doe een software update
  • draai de tests
  • zet de server terug in de load balancer
  • haal de server weer uit maintenece mode
Door de structuur van een playbook is als volgt:


YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
---
# Welke hosts
- hosts: all
  # Als welke user moet ik inloggen
  remote_user: root
  # Moet ik sudo gebruiken
  sudo: yes
  #Welke taak moet ik uitvoeren
  tasks:
    - name: Test connection
      ping:
    - name: Setup key
      authorized_key: user=root
                      key="{{ lookup('file', '/home/heli0s/.ssh/id_rsa.pub') }}"



In dit geval doe ik de eerder gedraaide ping test en maak ik gebruik van de ingebouwde system module om mijn ssh key toe te voegen aan de authorized_key file van de user root. Deze module controleert ook of de key al in de file staat. Dit brengt mij bij het volgende punt.
Idempotentie
Idempotentie betekend volgens wikipedia:
Idempotentie is de eigenschap van een object (of systeem) en/of een operatie daarop dat het object niet meer verandert als de operatie nogmaals wordt uitgevoerd.
Of als ik mijn Playbook een 2de keer uitvoer zouden er geen wijzigingen moeten plaats vinden op de machine. Als je er voor zorgt dat je playbooks idempotent zijn kan je bijvoorbeeld elke 30 minuten een run doen en er zo voor zorgen dat je servers geen configuration drift vertonen. Een ander voordeel is dat je (net als alle andere Configuration Managment pakketen) je config in een version managment pakket kan bij houden.

Zoals je ziet, is Ansible een mooie tool. Voor mij is het vooral handig dat ik op afstand een commando kan uitvoeren zonder al te veel instellingen. Ansible heeft ook een aantal modules die het leven makkelijk kunnen maken. Een playbook is ook snel gemaakt om wat complexere taken uit te voeren op meerdere servers.
Links

Volgende: MySQL slave maken of repareren met innobackupex 06-'16 MySQL slave maken of repareren met innobackupex
Volgende: SSH proxy met FireFox 12-'14 SSH proxy met FireFox

Reacties


Door Tweakers user Blokker_1999, vrijdag 27 februari 2015 13:35

Ansible gebruiken om puppet te installeren? Waarom niet direct alles met Ansible doen?

Door Tweakers user Heli0s, vrijdag 27 februari 2015 13:49

Blokker_1999 schreef op vrijdag 27 februari 2015 @ 13:35:
Ansible gebruiken om puppet te installeren? Waarom niet direct alles met Ansible doen?
Wij gebruiken standaard puppet om onze servers te beheren. Er zijn echter nog servers die naar puppet gemigreerd moeten worden. Om op deze servers een aanpassing te doen is Ansible erg handig, er is immers geen install nodig.

Daarnaast is het handig om de Macs op kantoor mee te beheeren.

Door Tweakers user sfranken, zondag 1 maart 2015 13:59

Misschien is het puur ter demo maar sudo icm een root account? Lijkt me niet het toppunt van correct usermanagement ;-)

Door Tweakers user johnkeates, zondag 1 maart 2015 16:20

Waarom ansible en puppet als je ook gewoon alles met Salt kan doen :p je kan ook Salt installeren met Salt en dat via salt-ssh doen voor dat je je master opgezet!

Door Tweakers user Heli0s, maandag 2 maart 2015 09:53

sfranken schreef op zondag 01 maart 2015 @ 13:59:
Misschien is het puur ter demo maar sudo icm een root account? Lijkt me niet het toppunt van correct usermanagement ;-)
Het is gedeeltelijk ter demo en gedeeltelijk omdat ik de voorbeelden vanaf een Mac doe, en daar heb ik sudo nodig :)
johnkeates schreef op zondag 01 maart 2015 @ 16:20:
Waarom ansible en puppet als je ook gewoon alles met Salt kan doen :p je kan ook Salt installeren met Salt en dat via salt-ssh doen voor dat je je master opgezet!
Puppet was al gedeeltelijk in gebruik toen ik hier kwam werken, als ik had kunnen kiezen was ik misschien voor salt gegeaan. Maar zoals het nu is werkt puppet prima voor ons.

Reageren is niet meer mogelijk