Un grain de sel pour être
HAPI
Automatisation des déploiements et gestion
centralisée du middle-office HAPI avec SaltStack...
Le projet HAPI
HAPI = Homogeneous API ou une API unique pour la VOD, la catch’UP TV et le
live
Middle-Office en remplaceme...
Le projet
DROPSHIP+
Système de déploiement automatisé
et de gestion centralisée
Composé de 4 briques principales:
- Fabric...
● OpenSource et communauté réactive aux pull-requests / hotfix
● Capacité à gérer des machines Unix et Windows
● Codé en p...
SaltStack dans Dropship+
Un seul repo Git contenant les pillars et les states pour tous les projets utilisant
Dropship+ mu...
Pillars vs Grains
Au départ, utilisation des pillars comme paramétrage des environnements.
Inconvénients :
- beaucoup de c...
Utilisation des states
3 types de states :
- commons : ensemble de states constituant le socle de toutes les machines
dépl...
Généralisation vs spécialisation des states
Pour qu’un state puisse être utilisé par un maximum de projets, il doit être l...
Exemple : elastic-search.hapi
Syndication
Un master Dropship pour
pouvoir intervenir sur toutes
les machines déployées par
Dropship+
Un master par proje...
Quelques exemples
Redémarrage de tous les services play pour l’environnement i1 :
salt -C ‘G@roles:play and G@env:i1’ serv...
Quelques chiffres
~ 20 commons, 30 units et 15 roles
26 commiters dont 8 réguliers répartis entre DTD et DMD
~ 400 machine...
Les sujets en cours
Automatisation des tests des rôles avec Docker
Création de branches pour QA et Dev et utilisation de G...
Des questions ?
Prochain SlideShare
Chargement dans…5
×

Un peu de sel pour être HAPI

804 vues

Publié le

Automatisation des déploiements et gestion centralisée du middle-office HAPI avec SaltStack

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
804
Sur SlideShare
0
Issues des intégrations
0
Intégrations
240
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Un peu de sel pour être HAPI

  1. 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. 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. 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. 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. 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. 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. 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. 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. 9. Exemple : elastic-search.hapi
  10. 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. 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. 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. 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. 14. Des questions ?

×