# Service embarqué, compte rendu ateliers

## Comptes-rendus
:calendar: Prochaine échéance: Jeudi 03 juin, CIGAL, SNSI, Dev: choix d'un scénario, alotissement

CR du point
- Rappel de l'objectif (Denis)
- proposer une nvlle offre: déployer des backend java
- prérequis debian 10, puppet 6: c'est la cible
- avantages: faciliter la vie des dévs et de l'exploitation
- Présentation de la cible (Mélanie)
- existant: compliqué, dépendance à applishare, pas de visibilité par le dev de sa configuration, gros travail des intégrateurs.
- cible:
- les properties sont fournies par le développeur dans les conf hiera ou sur manifeste noeud. Elles sont surchargées par la prod

- 1eres réactions sur la cible
- SNSI: il reste des choses à décrire sur le schéma sur ce qui est fait par CEI (exemple url exposée, FDS)
- CIGAL: le role des intégrateurs est donc réduit à la surcharge des properties. Adaptation à Majiba à apporter
- DOT/Puppet 6: de toute facon avec puppet 6 il faudra adapter majiba pour qu'il aille chercher et faire appliquer la déclaration du noeud. Le déplacement du fichier n'est plus a faire
- Dev: y aura t il du majiba en hors prod ? Non

- Quel statut pour majiba ?
- pas de majiba en Hprod
- adaptations en prod. Les FDS seraient tjrs apliquées par le Rundeck appelé par majiba
- En hors prod, pour appliquer le contrat
- ssh, rundeck, ou control repo. Le plus confortable dans un premier temps serait api Rundeck
- il y aura des contrats exemple, que les devs pourront reprendre
- emplacement du fichier de properties: CIGAL prévient qu'il y a des outils qui ont besoin qu'on leur spécifie des chemins fixes (exemple ou est la log, ou est le fichier de properties)

Décisions

RAF:
- finaliser le module cactus
- faire en puppet 6, coordiation avec l'équipe pp6 et ajouter cactus aux "pilotes" puppet 6
- adapter les normes de livraison
- adapter majiba
- adapter crapau
- décrire les possibilités exploitables avec puppet
- étudier les impacts pour l'exploitation sur la supervision, sur les emplacements standards a conserver ou non

Proposition
1ere étape: on cible la hors prod
En DV/QF:
- puppet 6 uniquement
- Control repo git, partagé entre les devs.
syncro r10k sur master, et les dev appellent puppet agent sur la machine noeud.
- inconvenient: tous les devs partagent le meme repo (pas de multi repo) et partage des mots de passe de Hors prod
- tant que pas de Rundeck, il faut aller sur la machine et lancer le service, ou installer cacus manager

Complément:
demander groupe puppet 6 de concevoir avec nous l'infrastructure puppet en prod

:calendar: Prochaine échéance: Mercredi 19 mai, entre dev (REST, DOT, pilotes)
"Rapide retour sur la "consultation" des dévs
- Quelles suggestions ont été faites ? ==> aucune préciséement,
- les dévs expriment simplement le besoin de pouvoir paramétrer le service comme ils veulent
- ils veulent pouvoir appeler le service par API
- "Spécifications" en cours https://gitlab.insee.fr/animation-developpement/etudes-techniques/embeded-tomcat/-/wikis/home suffisantes ?
- Quels 'scénario(s)' présenter à support + cigal pour le point de rerecadrage du 03/06 ?

Décision:
- **validation** du contrat tel que proposé par SNLA ("cactus")
- **en hors prod**, ils appliquent le contrat noeud soit en allant sur la machine (ssh) soit, à terme, par appel à l'API Rundeck, Rundeck étant chargé d'exécuter le puppet agent
- **en prod**: le CEI prend le manifeste noeud proposé par le dev et l'integre dans le control repo de prod.

Questions qui substistent
- comment sont passées les properties: par variables d'environnement uniquement ou avec fichier de properties ?
-

:calendar: Jeudi 06 mai
Determination de 3 scénarios sur lesquels les utilisateurs seront amenés à se prononcer
- Le ultra simple (pareil que aujourdhui avec un jar à la place du waer). On est parti sur plus que ce simple scénario
- Le scénario correspondant à l'état actuel des développement sur cactus: lancement paramétrable (SNLA à changé, il n'y a plus de .sh mais des params jvm et arguments à la ligne de commande) et properties en variables d'environnement
- le scénario "installation and launch as code'": tout est contrat puppet, les dév ont la main totale sur leur puppet en Hprod et ça constitue une base reprise par le CEI pour la mise en place de la pf de prod

Ces scénarios seront exposés aux dev via com sur les canaux tchap. Si incompréhension, alors une mini demo leur sera proposée pour leur montrer concretement de quoi il s'agit
La demo serait faite par les membres REST + Daap.

:dart:
- Communiquer
- sur le tchap InseeEmbededTomcat https://www.tchap.gouv.fr/#/room/#InseeEmbededTomcatsgfC4LnrFtu:agent.finances.tchap.gouv.fr et à destination des devs
sur ces "scénarios". Ils sont décits ici: https://gitlab.insee.fr/animation-developpement/etudes-techniques/embeded-tomcat/-/wikis/home
Leur dire qu'ils peuvent commenter/suggerer sur le codi de Fabrice https://hackmd.io/vlZHuLJ1TCywqigangGQfg
@REST: à faire Lundi 10 au plus tard pour qu'ils aient le temps de réagir d'ici le 20 mai
@Daap: à faire MArdi 11 au plus tard: picure de rappel sur Tchap support Dev, renvoyant sur le salon tchap Embedded Tomcat

Pour rappel, une offre de serveur embarqué (du type embedded tomcat en Spring Boot) est en cours d'élaboration sur le canal [InseeEmbededTomcat](https://www.tchap.gouv.fr/#/room/#InseeEmbededTomcatsgfC4LnrFtu:agent.finances.tchap.gouv.fr)

Le but du jeu: livrer et exécuter une appli java sur une plateforme sans Tomcat, le serveur est dans le jar. 
C'est également l'occasion de repenser les modes de livraison de son application, que ce soit en prod ou en dev/qf, vers plus de souplesse et vers plus de configurabité côté devs.
Plusieurs pistes sont envisagées qui concernent par exemple la récupération des properties applicatives, la personnalisation du lancement de son serveur, l'interface que l'on aimerait avoir en dv/qf pour déployer son application etc.

-
:calendar: Mardi 04/03
:dart: en intrants pour la reprise des ateliers en multilatéral

1. Besoin d'une cible plus claire: il faut repartir du besoin des dév
- @[Les devs] résument leurs besoins
- ils repartent du md ici https://hackmd.io/vlZHuLJ1TCywqigangGQfg?view
ou dans l'issue ou directement dans l'issue: https://gitlab.insee.fr/pilas/modules-puppet/cactus-puppet-module/-/issues/19
2. Besoins de simplification du processus de livraison: CIGAL a peut etre des évolutions à proposer par rapport à l'existant, en prod comme en hors prod
- @CIGAL pourra le cas échéant mettre ces éléments ici: https://gitlab.insee.fr/pilas/modules-puppet/cactus-puppet-module/-/issues/22

3. Forme du livrable
- primo livraison
- jar
- .sh
- fichier de properties
- livraison redéploiement
- jar
- .sh
- fichier de properties

@[all]: **valider ce dessin de livrable**
4. depot du livrable

- sur le nexus de prod
- validé, ne sera pas remis en cause pour l'instant

5. Contrat cactus existant
- @[Devs]:
- mettre dans les issues https://gitlab.insee.fr/pilas/modules-puppet/cactus-puppet-module/-/issues
- les points à compléter dans le contrat pour que le service soit rendu

6. mini poc Rundeck sur les pf hors prod
- Etudier un outil pour le déploiement en hprod
- @CIGAL