Puppet, Salt oder Ansible - Welches Tool ist das Richtige? · Puppet-allgemein I Clientbasiert I PeriodischeDurchläufe (Standard:alle30min) I Community-ModuleaufPuppet Forge I HierazurVerwaltungvon

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


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


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


Automatisches Konfigurationsmanagement

Verwendung einesKonfigurationsmanagement-Tools:

I Deklarative Formulierung derInfrastruktur

I Abstraktion der einzelnenRessourcen

I Infrastruktur einfach skalierbarund reproduzierbar


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


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


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


Terminologie

Ansible

FactsModules

TasksRoles

Playbook

Inventory

Salt

GrainsModules

StatesFormulas

Roles

Top-file + Pillar

Puppet

FactsResources

ClassesModules

Roles/Profiles

Hiera

System

Code

Parameters


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


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


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


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 %><% } -%>[...]


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"


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


Salt - Beispiel

ntp.sls:

ntp:pkg.installed:

- name: ntp

ntp_conf:file.managed:

- name: /etc/ntp.conftemplate: 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 %}[...]


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']

[...]


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


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


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


Welches Tool ist das Richtige?

Allgemeine Antwort:

⇒ ”Kommt drauf an”

⇒ Fast alles kann mit jedem Tool irgendwieumgesetzt werden



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



Installer/Orchestrierung

Konfiguration statisch

ssh-basiert (Ansible, Salt) Client-basiert (Puppet, Salt)

Nein Ja



Einführen von Configmgmt

Standardanwendungen

Puppet oder Ansible Trigger auf Monitorparameter

Salt (Reactor) Alle Varianten

NeinJa

Ja Nein


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


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


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


Training/Schulung @ ATIX

I

I

www.atix.de


www.atix.de

Documents

Puppet, Salt oder Ansible - Welches Tool ist das Richtige? · Puppet-allgemein I Clientbasiert I PeriodischeDurchläufe (Standard:alle30min) I Community-ModuleaufPuppet Forge I HierazurVerwaltungvon