1. Un grain de sel pour être
HAPI
Automatisation des déploiements et gestion
centralisée du middle-office HAPI avec SaltStack
Metin OSMAN / Octobre 2015

2. Le projet HAPI
HAPI = Homogeneous API ou une API unique pour la VOD, la catch’UP TV et le
live
Middle-Office en remplacement de la brique ATG, et à terme de middle-offices
dédiés au live actuellement
Architecture micro-services et hébergement dans le cloud AWS

3. Le projet
DROPSHIP+
Système de déploiement automatisé
et de gestion centralisée
Composé de 4 briques principales:
- Fabric : comme bibliothèque de
tâches pour le provisionning
- SaltStack : comme
bibliothèque de “recettes” pour
la spécialisation des machines
- Jenkins : pour l’orchestration
des opérations
- Git : pour la configuration des
plateformes et des applications

4. ● OpenSource et communauté réactive aux pull-requests / hotfix
● Capacité à gérer des machines Unix et Windows
● Codé en python
● Mode master et masterless
● Bonnes performances générales
● Déjà utilisé à la DTE :-)
Choix de SaltStack

5. SaltStack dans Dropship+
Un seul repo Git contenant les pillars et les states pour tous les projets utilisant
Dropship+ mutualiser au maximum le re-use des states
Les grains custom des machines sont définis dans le repo git de configuration des
plateformes (a.k.a environnements)
Utilisation en mode master et minion local (les states sont déployés sur tous les
minions)

6. Pillars vs Grains
Au départ, utilisation des pillars comme paramétrage des environnements.
Inconvénients :
- beaucoup de copier/coller entre les différents environnements
- les personnes en charge du paramétrage interviennent sur le repo Salt
Solution actuelle, les pillars servent à paramétrer les states de manière transverse pour tous les
environnements et les grains permettent de gérer les différences ponctuelles.
Avantages :
- On mutualise au maximum le paramétrage. Ex : version d’elastic-search
- les personnes en charge du paramétrage n’interviennent que sur le repo de configuration

7. Utilisation des states
3 types de states :
- commons : ensemble de states constituant le socle de toutes les machines
déployées par Dropship+ (ex : dns, ssh, users, …)
- units : states unitaires permettant d’installer un produit ou d’en paramétrer un
(ex : logstash, nginx, selinux, …)
- roles : state définissant le rôle d’une machine. Ces states incluent en
générale des states unitaires. (Ex : nginx.router, redis.server, play, …)

8. Généralisation vs spécialisation des states
Pour qu’un state puisse être utilisé par un maximum de projets, il doit être le plus
générique et le plus flexible possible.
Inconvénient :
- le nombre de combinaison à tester
- les impacts potentiels d’une modification faite pour un projet sur un autre
Solution, créer des rôles dédiés :
- permet de conserver le code dans un seul repo
- limite les impacts
- permet d’avoir des states efficaces

9. Exemple : elastic-search.hapi

10. Syndication
Un master Dropship pour
pouvoir intervenir sur toutes
les machines déployées par
Dropship+
Un master par projet pour
pouvoir intervenir sur son
projet de manière autonome

11. Quelques exemples
Redémarrage de tous les services play pour l’environnement i1 :
salt -C ‘G@roles:play and G@env:i1’ service.restart play
Mise à jour des users sur toutes les machines de tous les environnements :
salt ‘*’ state.sls commons.users
Mise à jour de bash sur toutes les machines CentOS (cf shellshock) :
salt -G ‘os:CentOS’ pkg.latest bash
...

12. Quelques chiffres
~ 20 commons, 30 units et 15 roles
26 commiters dont 8 réguliers répartis entre DTD et DMD
~ 400 machines sur Amazon gérées par 2 masters Salt
Déploiement d’HAPI avec reconstruction à 90% tous les jours en projet et
tous les quinze jours en production (à chaque fin de sprint)

13. Les sujets en cours
Automatisation des tests des rôles avec Docker
Création de branches pour QA et Dev et utilisation de GitFS
Refactor pillars vs map.jinja
Utilisation d’external pillars pour les données sensibles
Tuning de performance des states

14. Des questions ?