POC Ordonnanceur

Get Started. It's Free
or sign up with your email address
POC Ordonnanceur by Mind Map: POC Ordonnanceur

1. Axes à évaluer

1.1. Match avec nos uses cases Dev & Exploit Mks, Setup, Telco ...

1.1.1. Dev

1.1.1.1. * Mise en place d'une nouvelle MAJ * Ajout d'une étape à 1 MAJ existante * ....

1.1.2. S'assurer des modes opératoires d'exploitation

1.1.2.1. Cas d'exception

1.1.2.1.1. Reprise sur incident en cours de MAJ

1.1.2.1.2. Lancement manuels d'1 ou plusieurs étapes

1.1.2.2. Opération en marche normale

1.2. Retours % MAJénérique

1.2.1. Gestion du parallélisme

1.2.1.1. on doit pouvoir la gérer comme dans un diagramme de Gantt et sans perdre la visibilité sur les taches et le rapport, retour de chacune

1.2.1.2. Imbrication et dépendances entre graphs

1.2.1.3. Lancement de MAJ en parallèle

1.2.1.4. Une MAJ qui dure + de 24h ? ne pas bloquer le lancement de la suivante

1.2.2. Asynchrone

1.2.2.1. Rejoint le parallélisme

1.2.3. Des types d'étapes natifs (par exemple une étape "APPEL KYC" qui dispense de tout script ou lien symbolique dans le repo projet)

1.2.4. Gestion des scripts modèles ?

1.2.5. Passage de paramètres spécifiques à des étapes

1.2.5.1. En signature de fonctions génériques

1.2.5.2. Externalisées dans des fichiers de conf (ou bdd, ...)

1.2.6. Tester qu'Airflow est insensible au changement d'heure

1.2.7. Gérer plusieurs "types de MAJ" par des conditionnements sur les étapes

1.2.7.1. chaque jour

1.2.7.2. chaque mois le 1er et le 13, ou le dernier jours

1.2.7.3. chaque semaine par exemple dimanche, pour mardi et vendredi

1.2.7.4. imbrication de graphs

1.2.8. Récup/Chargement

1.2.8.1. Ethias, Ocm / plusieurs lancements par jour avec trt fil de l'eau fonction des arrivées

1.2.8.2. Okw / Se lancer ... et attendre que tous les fichiers soient là pour vraiment démarrer

1.2.8.2.1. Certain client envoie les données à une heure erratique, au lieu de mettre notre maj le plus tard possible, est ce qu’il faut pas ajouter par défaut la possibilité de tester (comment tester) si les données sont là, et dans ce cas lancer ou bien reessayer pour X fois ?

1.2.8.3. Multi-Sources

1.2.8.3.1. Zip / Fichiers

1.2.8.3.2. Bucket Google

1.2.8.3.3. Amazon S3

1.2.8.3.4. Sftp

1.2.8.3.5. Bases de données

1.2.8.3.6. Multi-Formats

1.2.8.3.7. pgp

1.2.8.3.8. Options post récupération

1.2.8.4. Gestion des historiques de fichiers

1.2.8.4.1. Rattrapage

1.2.8.4.2. Obligatoire/Facultatif

1.2.8.4.3. Alerte

1.2.8.4.4. Pattern de noms de fichiers (dates, périodes, ...)

1.2.8.4.5. (Nettoyages sont faits par système)

1.2.8.4.6. Ne pas récupérer/traiter plusieurs fois le même fichier

1.2.8.5. Déclenchement en juste à temps dès livraison

1.2.8.6. Pratiques de livraison

1.2.8.6.1. Pour les gros fichiers

1.2.8.6.2. ? Permettre à un client de déclencher une MAJ une fois les fichiers livrés ?

1.2.8.7. Parallélisme dans le chargement

1.2.9. Cloud-friendly & transposition processus Script php

1.2.9.1. (Jennyfer et Courir n'ont pas de Rscript, mais socle et KyC)

1.2.10. Intégration des TI

1.2.10.1. Remonter des indicateurs au monitoring

1.2.10.2. Conditions d'arrêt dans les traitements

1.2.11. Alerting

1.2.11.1. Moins d'emails

1.2.11.1.1. La responsabilité de "MAJ" est de remonter de l'info au monitoring

1.3. LE BESOIN

1.3.1. Orchestration Illustration graphique Parallélisme Taches paramétrables … Développement use case : phase setup Exploitation use case : phase running Sécurité Récup/Chargement Connectivité : cloud, BD Multi trigger On premise

1.4. Intégration des projets clients

1.4.1. * Proposer 1 mode pour les nouveaux projets * Evaluer l'effort de migration des projets existants * Particularités sectorielle : retail, telco, ... ?

1.5. Identifier une reco d'architecture cible

1.5.1. Liaison monitoring

1.5.1.1. Webhooks au niveau de Airflow

1.5.1.2. Service de scraping Airflow

1.5.1.3. Alimentation depuis les trt via "logger"

1.5.2. * Découpage fonctionnel et technique (Orchestration VS Chargements ; php vers python? ; scripts génériques ; ...) * OnPremise * Robustesse * Intégration à l'infra (? quelle instance Airflow) ...

1.5.3. Frontière avec le monito en termes de suivi d'étapes

2. Etapes

2.1. Constituer l'équipe et présenter le projet

2.1.1. Réunion de lancement le 06/05

2.1.1.1. CR (questions, attentes, ...)

2.1.2. Equipe Setup Représentants Mks : Houssem-Azmi Représentant R&D Web : Florian Représentant R&D DS : Daouda (+ Sylvain pour partage d'expérience au début) Représentant IT/Sécu : Adrien

2.2. Formuler les points d'évaluation

2.2.1. Formulation des besoins

2.2.1.1. 1ère passe réalisée, 2nde passe à prévoir

2.2.1.2. Partage des besoins recensés

2.2.2. Communiquer plus largement

2.2.2.1. Mail + quelques diapos tout inbox

2.2.2.2. 1 échange à destination Mks (dont CE)+consulting lors du prochain comité études

2.2.2.2.1. Prochain le 27/05 ! Amin en congés

2.3. Jouer 1 MAJ sur la dev d'un projet existant (? jennyfercrm-dev)

2.3.1. * En mode "commando" avec un minimum de contraintes et d'investissement technique

2.3.1.1. Installation Airflow

2.3.1.1.1. Airflow 1 instance mutualisée tous projets ou par projet ?

2.3.1.1.2. Mono instance / exécuteur

2.3.1.2. DAG minimaliste

2.3.1.2.1. Sur base de MAJ Jennyfer -> écriture du DAG

2.3.1.2.2. Récup

2.3.1.2.3. Chargement

2.3.1.2.4. Etapes

2.3.1.2.5. Rapport

2.3.1.2.6. Décisions

2.3.1.2.7. Refactoring consécutifs alignement IT

2.3.1.2.8. Questions / Points à valider par la suite

2.3.1.3. Suite des tests

2.3.1.3.1. Autres cas de test

2.3.1.3.2. Pseudo alimenter une trace pour le nouveau monitoring

2.3.1.4. Bonus de POC

2.3.1.4.1. R&D de fin de POC

2.3.1.5. Mettre 1 serveur projet actuel en position de recevoir des ordres Airflow

2.3.1.5.1. Créer 1 WS connecteur dans commun_inbox pour lancement d'un script php www-data ?

2.3.1.5.2. Créer 1 compte de service airflow sur jennyferdev + lui donner les privilèges sudo www-data pour qu'il puisse lancer les scripts php

2.3.1.5.3. => 1 échange de 30 min avec FC+AM

2.3.1.6. Faire une information sur l'architecture de test

2.3.1.6.1. -> Lancer des échanges sécu pour lever les principales questions

2.3.1.6.2. Ensuite aviser l'IT des choix d'environnement

2.3.1.7. Au moment de coder reparler de l'orga git & code

2.3.1.7.1. Se servir de ticket pour rélisation/historisation des tests & conclusions ?

2.3.2. 1ere démo de passage d'un POC minimaliste

2.3.2.1. Feedback des représentants

2.3.3. Echange avec le monitoring

2.4. Evaluer chacun des besoins identifiés

2.4.1. Approche itérative

2.4.1.1. Compléments de POC & de démo

2.4.1.2. Traitement des retours de démo au fil de l'eau

2.5. Démonstration élargie & présentation des conclusions et reco pour l'après POC

2.5.1. Inventaire des devs en préparation de l'après POC (investissement de départ pour un 1er projet en prod sur Airflow)

2.5.1.1. Transposition processus RScript

2.5.1.2. .....

3. Points importants

3.1. Implication des différentes équipes (démos, retours d'expériences, validation de la cible, préparation de l'après POC, ...)

3.1.1. 1 représentant de chaque équipe à des étapes clés de partage & démonstration

4. Objectif principal du POC

4.1. Périmètre de l'ordonnaceur

4.1.1. orchestration de toute la chaine de production

4.1.2. Liaison avec les environnements / produits / services

4.2. Démontrer qu'Airflow est une bonne solution pour satisfaire à nos enjeux d'orchestration

4.2.1. Sinon, se replier sur une recherche d'autre solution et revoir le plan