Puppet, Salt oder Ansible Welches Tool ist das Richtige? Andy Wirtz, Dr. Jonas Trüstedt 27. November 2018
Puppet, Salt oder AnsibleWelches Tool ist das Richtige?
Andy Wirtz, Dr. Jonas Trüstedt
27. November 2018
Tätigkeiten im Rechenzentrum
Typische Aufgaben desSystemadministrators:
I einen Host erstellen
I Host mit Applikationenprovisionieren
I Applikationen updaten
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Konfigurationsmanagement
Eine Applikation muss:
I installiert werden
I konfiguriert werden
I gestartet werden
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Beispiel ntp
Verwendung imperativer Shell-Befehle fürunterschiedliche Betriebssysteme:
yum|apt|zypper install -y ntp
vi /etc/ntp.conf
systemctl start ntpd|ntp|ntpdsystemctl enable ntpd|ntp|ntpd
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Manuelle Konfiguration
Imperative einzelne Konfiguration:
I zu aufwändig
I zu zeitintensiv
I zu fehleranfällig
Die Anzahl Instanzen steigt mit derZeit, die Anzahl Mitarbeiter nicht
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Automatisches Konfigurationsmanagement
Verwendung einesKonfigurationsmanagement-Tools:
I Deklarative Formulierung derInfrastruktur
I Abstraktion der einzelnenRessourcen
I Infrastruktur einfach skalierbarund reproduzierbar
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Kernpunkte
I Idempotenz:
→ Mehrmaliges Ausführen möglich
→ Nur bei Änderungen wird angepasst
I Code als Dokumentation:
→ Code lesbar
→ Dokumentation als Code/Parameterset
I Trennung von Parametern und Code:
→ Code mehrfach verwendbar
→ Parameter als spezifische Konfiguration
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Vorteile von Konfigurationsmanagement
”Infrastructure as Code”:
I Standardisierung
I Automatisierung
I Änderungen an vielen/allenHosts einfacher
I zentrale Versionskontrolle
I Effizientere Verwaltung derInfrastruktur
Parameters Code
Targethost
Config
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Tools
I von Red Hat seit 2015, IBM seit 2018:
I Release: 2012I Basis: Python
I von puppetlabs:
I Release: 2005I Basis: Ruby
I von Saltstack:
I Release: 2011I Basis: Python
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Terminologie
Ansible
FactsModules
TasksRoles
Playbook
Inventory
Salt
GrainsModules
StatesFormulas
Roles
Top-file + Pillar
Puppet
FactsResources
ClassesModules
Roles/Profiles
Hiera
System
Code
Parameters
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Ansible - allgemein
I SSH Verbindung zu Hosts(sshkeys)
I Kein Client nötig
I Abbildung der Infrastruktur ineinem Inventar
I Community-roles in AnsibleGalaxy
Inventory Playbook
Host1 Host2 Host3
Host+
Vars
Role
Role
Ansible-Host
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Ansible - Beispiel
ntp.yaml:
tasks:- name: install ntp
package:name: ntpstate: present
- name: Generate ntp.conftemplate:
src: ntp.conf.j2dest: /etc/ntp.conf
- name: Ensure NTP isrunning
service:name: ntpdstate: startedenabled: yes
Ausschnitt aus ntp.conf.j2:
[...]{% for item in ntp_servers
%}server {{ item }}{% endfor %}[...]
Inventory.yaml (ini-file or yaml):
base:hosts:
host1.example.comhost2.example.com
vars:ntp_servers:
- ntp1.server.org- ntp2.server.org
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Puppet - allgemein
I Clientbasiert
I Periodische Durchläufe(Standard: alle 30 min)
I Community-Module auf PuppetForge
I Hiera zur Verwaltung vonParametern
Hiera (Profiles)
Host1 Host2 Host3
Module
Module
Master
Module
Module
common
os
host1
Puppet-Agents
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Puppet - Beispiel
ntp: init.pp:
package{ ntp:ensure => latest,
}
file { /etc/ntp.conf:ensure => present,content => epp('ntp/ntp.
conf.epp'),}
service{ 'ntpd':ensure => running,enable => true
}
Ausschnitt aus ntp.conf.epp:
[...]<% $ntp::servers.each |
$server| {-%>server <%= $server %><% } -%>[...]
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Puppet - Beispiel
common.yaml:
classes:- ntp
ntp::servers:- ntp1.server.org- ntp2.server.org
host5.example.com.yaml:
ntp::servers:- ntp1.test.server.com- ntp2.test.server.com
Hiera-config hiera.yaml:
hierarchy:- name: "Per-node_data"
path: "nodes/%{trusted.certname}.yaml"
- name: "Per-OS_defaults"path: "os/%{facts.os.
family}.yaml"
- name: "Common_data"path: "common.yaml"
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Salt - allgemein
I Clientbasiert & SSH-Variante
I Eventbasierte Auslöser (Reactor)
I Periodische Durchläufe möglich
I Infrastruktur aufgeteilt in:
I Top.sls (wie Inventory)I Pillars (ausgelagerte
Parameter)
I Wenig Community-Formulas
Host1 Host2 Host3
State
Master
State
top.sls
Pillars
Minions
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Salt - Beispiel
ntp.sls:
ntp:pkg.installed:
- name: ntp
ntp_conf:file.managed:
- name: /etc/ntp.conf- template: jinja- source: salt://ntp/ntp
-client.conf
ntp_running:service.running:
- name: ntpd- enable: True
Ausschnitt aus ntp-client.conf:
[...]{% set ntpservers = salt['
pillar.get']('ntp:servers ') %}
{% for ntpserver inntpservers -%}
server {{ ntpserver }}{% endfor %}[...]
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Salt - Beispiel
top.sls:
base:'*':
- ntp'webserver ':
- httpd
Salt-SSH mit Roster-File für Targets:
Minion1:host: host1.example.com
Minion2:host: host2.example.com
Ausschnitt aus pillar ntp:
[...]ntp:
servers: ['ntp1.example.com','ntp2.example.com','ntp3.example.com']
[...]
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
AdHoc-Befehle/Community
Einzelne Befehle direkt auf Hosts ausführen:
I Puppet: Bolt/Tasks
I Ansible: AdHoc-Commands
I Salt: AdHoc-Commands
Fertige Bausteine aus der Community:
I Puppet Forge: ~5800 Module
I Ansible Galaxy: ~17000 Roles
I Salt Formulas (Github): ~300 Formulas
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Integration in anderen Produkten
Beispiele:
Als Installer:
I Red Hat Openshift → Ansible
I Suse CaaSP → Salt
I Foreman-Installer → Puppet
Foreman/orcharhino/Satellite:
I Puppet
I Ansible
I Salt
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Einsatzmöglichkeiten
I Basiskonfiguration für Infrastruktur:
I Spezielle KonfigurationenI Admin-User inkl. ssh-keysI Anbinden an Logging/Monitoring
I Installer für Software/Umgebungen:
I Serverspezifische KonfigurationenI Spezielle AnwendungenI Clusterumgebungen wie Kubernetes/Openshift
I Orchestrierung:
I ContainerhostsI Anwendungen mit mehreren Instanzen
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Welches Tool ist das Richtige?
Allgemeine Antwort:
⇒ ”Kommt drauf an”
⇒ Fast alles kann mit jedem Tool irgendwieumgesetzt werden
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Welches Tool ist das Richtige?
Basiskonfiguration
User mit Systemzugriff
nur Anfangskonfiguration User dürfen Konfiguration ändern
ssh-basiert (Ansible, Salt) Client-basiert (Puppet, Salt)
Nein Ja
Ja
Ja Nein
Alle Varianten
Nein
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Welches Tool ist das Richtige?
Installer/Orchestrierung
Konfiguration statisch
ssh-basiert (Ansible, Salt) Client-basiert (Puppet, Salt)
Nein Ja
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Welches Tool ist das Richtige?
Einführen von Configmgmt
Standardanwendungen
Puppet oder Ansible Trigger auf Monitorparameter
Salt (Reactor) Alle Varianten
NeinJa
Ja Nein
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Client-based vs ssh-based
Client-basiert:
I Fokus auf Stabilität/Persistenz
I Infrastructure as Code
I Zentrale Verwaltung
I Höhere Abstraktion
→ Heterogene Systeme
→ Stärken bei persistentenKonfigurationen
ssh-basiert:
I Fokus auf Flexibilität
I Verwaltung jeAnwendung/Umgebung
I Verwendung mit Userrechten
I Einfache Remote-Ausführung
→ Stärken bei Orchestrierung/Deployment
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Kombination von Tools
I Kombination unterschiedlicher Tools möglich
I Mehrfache Verwendung von gleichen Client-based Tools
→ Mehrere Puppet-/Saltmaster technisch schwierig
→ Workflows für die zentrale Verwaltung nötig
I Mehrfache Verwendung von gleichen ssh-based Tools
→ In eigenen Inventories möglich
→ Verwaltung pro Abteilung möglich
→ Geeignete Wahl der Tools pro Abteilung/Anwendung möglich
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Zusammenfassung
I Arbeitserleichterung durch Configurationmanagement
I Zentrale Verwaltung von Servern/Anwendungen
I Reproduzierbarkeit
I 3 Tools mit vielen Gemeinsamkeiten:
I AnsibleI PuppetI Saltstack
I Häufig Kombination der Tools
I Wahl des Tools je nach Einsatzzweck
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack
Training/Schulung @ ATIX
I
I
www.atix.de
#ATIX #linuxstammtisch #configmgmt #puppet #ansible #saltstack