#TECH / Devops - Automatisation : déploiements systèmes et applicatifs

1. Migration de FUN-MOOC et ses marques
blanches vers un cloud public OpenStack :
retour d’expérience
POSS Décembre 2017, PARIS
Brice Trinel
Consultant avant vente, Objectif Libre

2. Les MOOC et la plateforme FUN
Ø Technologie
• Open source : Open edX
• Plateforme hébergée en France
Ø Usage des données
• Confidentialité des données des apprenants
• Accès aux données anonymisées à des fins de
recherche
2

3. FUN : Bilan chiffré
3

4. FUN : Bilan chiffré

5. Hébergement
diffusion de MOOC &
SPOC
Animer la communauté
FUN
Favoriser les
partenariats
Accompagner les
nouveaux usages
§ Un réseau de 1300 correspondants /concepteurs
§ Une équipe d’appui aux concepteurs de MOOC
§ Un programme de formation
§ Des outils méthodologiques
§ Des évènements participatifs
§ La délivrance de certificats
§ Une offre de collections et de parcours
§ L’utilisation revisitée des MOOC (classe inversée, SPOC)
§ Le développement de la formation continue
§ Avec le secteur industriel (OPCALIM, ITII)
§ Avec des structures publiques (ADEME, CNFPT)
§ Avec des startups (projet EIFFELa)
§ Avec des universités étrangères (Maroc, Sénégal, Chine).
①
② ③
Les missions de FUN

6. FUN : Nouvelles pratiques
n Sur les campus
• Classes inversées, Formation hybrides (blended
learning)
• Cours ouverts sous forme de SPOC pour permettre :
- un suivi approfondi des étudiants
- une adaptation / contextualisation aux besoins
académiques
n En formation continue
• Au sein des entreprises
• Au profit des demandeurs d’emplois ou de salariés
d’une branche professionnelle (via un OPCA)
6

7. FUN : Nouvelles pratiques
n Des membres et partenaires avec des besoins spécifiques
• Développement d’une offre de plateformes en marque blanche
MOOC Bâtiment Durable
(ADEME)
CNFPT Centrale Pékin

8. Premier projet :
La migration de la plateforme FUN

9. Le contexte du projet
n Migration de la plateforme de MOOC vers un cloud public
• Disponibilité des ressources à la demande
• Elasticité de la plateforme
• Localisation des données en France
n Enjeux
• Migration vers un SI stable, sécurisé, pérenne et évolutif
• Assurer la continuité du service lors de la transition
• Conserver les mêmes fonctionnalités, y compris les
développements FUN
9

10. Le déroulement du projet
Phase 1 : Etude des composants Open edX
• Livrable : points de vigilance du passage AWS vers Cloudwatt
Phase 2 : Adaptation des playbooks Ansible/AWS de l’éditeur
• Déploiement multi-instances
• Livrable : les playbooks pour OpenStack
Phase 3 : Analyse des différences entre Open edX standard et
l’Open edX de FUN
Phase 4 : Identification du chemin critique de la migration
• Industrialisation finale de plateforme cible
• Livrable : le code pour « builder » la nouvelle infrastructure

11. Schéma d’architecture

12. La stratégie de migration
Enjeux : migration de la plateforme FUN avec interruption de
service < 4h
Solutions proposées :
• Cluster MySQL master/slave
Réplication de 200 Go de données. Jour J sans delta
• Sauvegarde incrémentale pour le MongoDB
Import de masse (40 Go) ; jour J → traitement du
différentiel.
• Synchronisation de fichiers GlusterFS
Utilisation de rsync - petite volumétrie (4 à 5 Go)
>> Migration maîtrisée et contrôlée

13. Enjeux : MEP sans interruption & rollback instantané
• Particularité : travail sur 2 versions de prod
• Possibilité de rejouer une stack heat en relançant le
job Jenkins de la version N-1 de l’image
• Prérequis : pas de changement de schéma de la DB
entre la version N & N+1
>> MEP automatisée & contrôlée
La stratégie pour les MEP : Blue / Green

14. Principes de fonctionnement :
• Nouveau code sur le GIT avec tag spécifique
• Playbook Ansible pour le Build image packer
• Lancement manuel de la nouvelle image depuis Jenkins
• Au lancement du RUN, volonté de garder le contrôle des MEP
• Déploiement d’une nouvelle stack via heat avec la nouvelle
image buildée
• Rollback manuel en rejouant le playbook Ansible
Bonnes pratiques :
• Départ d’une image vierge Ubuntu 12/16 → même
environnement prod & pré-prod
• Définition des politiques de gestion des versions N-1
La stratégie pour les MEP : Blue / Green

15. Principes de fonctionnement :
• Packer réalise le build image
• Il lance le build depuis une Ubuntu 12 ou 16
• Il démarre une VM et run le playbook Ansible
• Il installe les services et déploie le nouveau code mais pas la
configuration de la VM.
• L’intérêt : Il réalise un déploiement identique de la prod et de
la pré-prod
• Après le run Ansible, Packer réalise les actions suivantes
• Il éteint la VM
• Il fait une image au format qcow2
• Nouvelle image prête : lancement du Blue/Green dans Jenkins
>> Maîtrise dans la construction des images
La construction des images via Packer

16. Principes de fonctionnement :
• A l’aide des playbooks Ansible
• Générer les images via Packer
• Gérer le setup des backends
• Gérer la configuration des services via cloud init
(@IP, DNS, Supervision, Log…)
>> Gain de temps et + facile à rejouer
Le choix de l’automatisation : Ansible

17. Principes de fonctionnement :
• Heat déploie l’infrastructure complète de 6 stacks
• Stack base (groupe de sécurité & réseau)
• Stack backend
• Stack edxapp & worker (LMS/CMS)
• Stack front (HAProxy et LBaaS)
• Stack e-commerce
• Stack forum
>> + rapide à déployer et + facile à updater
Le choix de l’automatisation : Heat

18. Enjeu : Comment transmettre de manière sécurisée les
mots de passe des DB aux instances ?
Solutions :
• Dans les user/data à l’aide de cloud init.
• Problème : les données transitent en clair
• En utilisant Vault de Hashicorp
• Système de coffre-fort pour générer un token temporaire
d’accès aux mots de passe
• Si le secret n’est pas découvert dans le temps imparti, le
token est détruit (au boot via cloud init et les VM
récupèrent les secrets)
>> Sécurisation pour l’envoi des mots de passe
L’outil de sécurisation : Vault Hashicorp

19. Deuxième projet :
Le déploiement des marques blanches

20. Les enjeux
§ Autonomie : Déploiement automatique d’une nouvelle
marques blanche pour les équipes de FUN
§ Avantages : réduction du temps de déploiement à
l’aide des conteneurs. (1 min VS 15 min)
§ Coût : Utilisation efficiente de la plateforme OpenStack
20

21. L’architecture
§ Conteneurisation : « Dockerisation » des briques de
l’application Open edX « dockerisable »
• Application stateless ou application sans état (ex : protocole
http)
• Frontaux web dockerisés (simplification de l’auto-scalling)
• Base de données non dockerisée car + complexe dans
l’exploitation (ROI < coût de l’exploitation)
§ Orchestration : Mise en place de l’orchestrateur
Rancher pour la gestion des conteneurs et leur cycle de
vie
§ Socle: VM parent sur un OpenStack
21

22. Principes de fonctionnement :
• Nouveau code sur le GIT avec tag spécifique
• MEP sans interruption & rollback instantané
• Remplacer les composants conteneurisés
successivement jusqu’à la MEP complète
Ø 1 par 1 ou par petits groupes
>> MEP automatisée & contrôlée
La stratégie pour les MEP : Rolling release

23. Conclusion
23
§ Une infrastructure automatisée et semi-auto pour des MEP
>> moins de 15min !
§ Blue/Green et Rolling release : des mécanismes qui offrent
des MEP régulières sans interruption de services et
maîtrisées
§ Une infrastructure facilement évolutive en fonction des pics
de charge
§ Economie en terme de coûts

24. Merci de votre attention !
24