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

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

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

● 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

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)

Pillars vs GrainsAu 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

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, …)

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

Exemple : elastic-search.hapi

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

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

...

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)

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

Des questions ?