Comment mettre son grain de sel partout

Comment mettre son grain de sel partout
Aurélien Minet, ENS Cachan
Agenda
Introduction
Qu'est ce que SaltStack
Fonctionnement (& vocabulaire)
Utilisation
Cas pratiques & possibilités
Introduction
Disponibilité
software defined
update
Services
API
VM
Configuration
Cloud
manage
résilience
SLA
tests
Agile
orchestration
event driven containers
Deploy
CI
Ops
Microservices
automation
security
infrastructure
code
SSH
scalable
conformité
Qu'est ce que SaltStack : le pitch
SaltStack delivers a dynamic infrastructure
communication bus used for orchestration,
remote execution, configuration management
and much more
Qu'est ce que SaltStack :
- un logiciel libre (Apache version 2.0)
- création février 2011
- une société éponyme
- une communauté importante
- un des plus gros projets basé sur Python
Qu'est ce que SaltStack :
- un framework d’exécution distante (asynchrone)
- un gestionnaire de configuration (centralisé)
- un outil de provisionning VM & Cloud
- un système d'orchestration
- un logiciel extensible & flexible
Qu'est ce que SaltStack :
une boîte à outils
avec une documentation conséquente
avec une communauté réactive (GitHub, mailing list)
qui est « jeune » et qui bouge beaucoup
Fonctionnement : les composants
le master : le serveur qui gère le tout
les minions : les agents contrôlés par le master
les syndics : des minions servant d'intermédiaire
entre des minions et un master
les proxy-minions : « agents » spécifiques servant
d'interface entre le master et un équipement
sans possibilité d'y avoir un minion, ni ssh.
Fonctionnement : topologie
Fonctionnement : les composants
Les minions se connectent au master
→ ils doivent être acceptés (PKI)
→ la connexion est chiffrée AES
→ connectés ils sont sur un bus ZeroMQ
(PUB/SUB et REQ/REP)
Les minions peuvent être seuls : masterless (salt-call)
Fonctionnement : les composants
Fonctionnement : les éléments
- les states : déclaration de l'état d'un système
(fichiers .sls, par défaut YAML+Jinja)
- les grains : variables statiques d'un minion
- les pillars : variables pour des minions
Fonctionnement : les éléments
- la mine : collections de données générées par les
minions (ip…)
- les formulas : « super states » prêt à l'emploi
- les returners : ils permettent aux minions de retourner
la sortie vers un service externe (db, ...)
- les beacons : triggers sur les minions pour envoyer des
événements au master
Fonctionnement : les éléments
- les reactors : permet de définir des actions sur le
master en réaction à un événement
- les modules : pour l'exécution (~330)
pour les états (~190)
- les runners : modules (manage, job, orchestrate …)
s'exécutant sur le master (salt-run)
- la salt-api : interface REST
Utilisation : exécution
Comme SSH :
salt bob cmd.run "rm -rf /tmp/*"
Ou plus spécifique :
salt '*' disk.percent /var
(et plus pratique qu'un df avec cssh)
Utilisation : configuration
Pour appliquer toute la configuration d'un
système:
salt kevin state.highstate [test=True]
Pour n'appliquer qu'un état de la configuration :
salt stuart state.apply monfichier (sans .sls)
Utilisation : ciblage
salt '*.ens-cachan.fr' test.ping
salt -G 'cpuarch:x86_64' system.reboot
salt -C '[email protected]/24 and G@os:MacOS' \
desktop.say "Bonjour"
Utilisation : top.sls
Base:
'*' :
- commun
'^www.(prod|test).ens-cachan.fr$' :
- match: pcre
- php.fpm55
- apache.server24
'os:(RedHat|CentOS)':
- match: grain_pcre
- repos.epel
Fonctionnement : les éléments
Utilisation : fichier sls simple
installer apache:
pkg.installed:
- name: httpd
file.manage:
- name: /etc/apache2/httpd.conf
- source: salt://files/apache/httpd.conf.jinja
Utilisation : fichier sls avec jinja
vim:
pkg.installed
# fixme on Centos
Utilisation : fichier sls avec jinja
vim:
pkg.installed:
{% if grains['os_family'] == 'RedHat' %}
- name: vim-enhanced
{% elif grains['os_family'] == 'Debian' %}
- name: vim
{% endif %}
Utilisation : fichier sls plus complexe
Fichier /srv/pillar/users.sls
users:
bob:
uid: 1001
fullname: "Bob"
password: '...'
kevin:
uid: 1002
fullname: "Kevin"
key.pub: True
Utilisation : fichier sls plus complexe
{% for user, args in salt['pillar.get']('users', {}).iteritems() %}
{{ user }}:
user.present:
- uid: {{ args['uid'] }}
{% if 'password' in args %}
- password: {{ args['password'] }}
{% endif %}
{% if 'key.pub' in args and args['key.pub'] == True %}
{{ user }}_key.pub:
ssh_auth:
- present
- user: {{ user }}
- source: salt://files/users/{{ user }}/keys/key.pub
{% endif %}
{% endfor %}
Cas pratiques
Installer Oracle Database
→ pkg.installed pkg.pkgs
→ file.append file.manage file.directory
→ user.present group.present
→ cmd.run
+ cmd.wait & watch, require, unless & onlyif
Cas pratiques : formulas
Les formulas :
- installer et configurer HAProxy
- installer, configurer et gérer OpenSSH
(authorized_keys, known_hosts …)
Réalisation de modules :
- Kaspersky (exécution)
- « osxrepo »
Cas pratiques : salt-ssh
Gestion des bornes WiFi sous OpenWRT
→ fichier /etc/salt/roster (dns+jinja)
→ clé ssh
⇒ salt-ssh 'mc4-ap*.wifi.ens-*.fr' -r 'wifi reload'
Cas pratiques
Gestion de parc : script de bootstrap du minion
- Windows : utilisateurs, connexion au domaine,
GPO, logiciels (winrepo), base de registre …
- Mac OS : utilisateurs, modification de fichiers,
logiciels (cmd.run avec Homebrew & Cask)
Possibilités / « much more »
- Cloud : salt-cloud (et modules pour lxc, docker …)
- Interface Web : Saltpad (salt-api)
- Approche « validation continue » / mesure de la
conformité: salt-highstate-stats
- Monitoring par les minions : Saltmon
SaltStack : automatiser est un investissement
Data Defined Infrastructure :
→ versions
→ documentation
Event Driven :
→ orchestration
→ scalabilité
→ résilience
Test Driven :
→ mêmes méthodes (agiles) que pour le développement
Un dernier exemple
salt -C '*.attendees.2015.jres.org and
G@location:berlioz' ask.questions