Bonjour,
Dans ma boîte, on développe différents logiciels pour de l'embarqué qui sont compilés sur différentes machines (station de travail, environnement d'intégration continue etc).
Entre les bouts de code en C/C++, python, JS, etc, la gestion des librairies commence à se compliquer et comme tout est fait à la main pour synchroniser les environnement de développement, c'est un peu pénible à court terme et je pense très hasardeux à long terme.
On a également plusieurs projets en parallèle, donc le besoin de basculer assez facilement de l'un à l'autre. Actuellement par chance, les dépendances sont à peut-près compatibles mais ça va pas durer.
Jusqu'à présent, on utilise une Machine Virtuelle mais c'est très gros à échanger et pratiquement jamais mis à jour correctement alors j'essaye de migrer ça vers des environnement virtuels et des containers qui pourront être archivés via git etc.
Pour les parties python, je mets en place des environnements virtuels python qui me semblent être la méthode assez classique.
Plus globalement et pour les parties C/C++, je suis parti sur des containers qui contiennent les libs et les compilos/interpréteurs. Les sources sont accessibles par l'intermédiaire d'un volume et j'ai fait quelques bidouilles pour avoir les mêmes UID/GID que l'utilisateur de l'hôte.
Ça marche assez bien pour avoir un environnement pour builder une version "officielle" (un clique et ça sort un package tout chaud) mais je suis moins convaincu pour la phase développement avec ses erreurs de compile, les phases de debug, etc. On utilise Eclipse principalement et quelques outils graphiques.
Je voyais deux options mais aucune ne me satisfait vraiment:
1. Installer Eclipse (et autres outils graphique) côté hôte pour travailler sur le code et lancer uniquement la compilation dans le container. Je trouve ça assez bien car très peut de différences par rapport au monde sans container. Là où ça me semble tordu, c'est que je vais avoir des erreurs de compile qui vont me donner des chemins correspondants au monde du container et pas de l'hôte par exemple.
2. Installer Eclipse côté container. Là, les messages d'erreur pointeront bien sur les fichiers, mais par contre il faudra lancer tous les outils en "export display" ou via une console dans le container, ce qui me semble beaucoup moins transparent à l'utilisation.
Alors voilà (enfin) ma question:
Quelles sont les bonnes pratiques et quelles autres options existent pour "dupliquer" des environnements de développement entre plusieurs machines?
Merci d'avance
# La classique
Posté par _kaos_ . Évalué à 1. Dernière modification le 02 mars 2021 à 11:20.
Salut,
Quelque chose ne va pas avec la combo
git+jira+jenkins+confluence?Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Salut,
C'est ce qu'on utilise. Une doc dans confluence pour décrire comment installer l'environnement dans la VM et les sources dans git, mais c'est très manuel et donc rarement à jour et testé.
En pratique la VM est rarement à jour et reste lourde à échanger.
Est-ce que tu as en tête un autre exemple d'utilisation de ce trio?
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2.
Salut,
Désolé, j'ai probablement édité pendant ta rédaction, et c'est devenu un quatuor.
Et on peut rajouter un petit dernier pour l'orchestration :
nexus.Bon.
Jira gère les tâches, git les branches (avec des libs éventuellement différentes), jenkins build tout seul, nexus a les bonnes versions de librairies pour les branches, confluence te permet de faire la doc une fois que c'est en cours de CI.
Manque peut-être les tests là dedans.
Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Alors pour "notre code" c'est déjà plus ou moins ce qu'on fait.
Mais si tu rajoutes une chaîne de compile un peu spécifique, des outils en plus pour pouvoir lancer les scripts d'automatisation etc … il y a besoin d'installer ces outils.
Faire un script pour gérer ça, pourquoi pas, mais quand il y a des incompatibilités entre différents projets, ça va se compliquer. C'est pour ça qu'isoler les environnements avec des VM ou des containers me semblaient une bonne option.
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2. Dernière modification le 02 mars 2021 à 12:35.
Salut,
J'ai peur de ne pas voir le problème.
jenkins+nexusça compile des branchesgitavec des environnements différents sans trop de soucis à ma connaissance.On peut évidemment rajouter aussi
sonarpar exemple, pour les tests UI.Du genre ? ;)Edit : vu ta réponse plus bas
Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Bon moi j'en suis encore à stash(git) + jira + bamboo(jenkins) + confluence dans ma petite caverne =)
Nexus je connaissais pas. J'ai regardé ça vite fait (https://fr.sonatype.com/nexus/repository-pro - j'espère que c'est le bon nexus, une recherche renvoie une tripoté de truc qui ont rien à voir) et ça m'a l'air d'avoir un intérêt pour du déploiement de container pour de la "grosse" prod.
De mon côté, on a peut être 10/15 machines à synchroniser, faire un "docker pull" pour avoir le dernier environnement me parait suffisant.
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2. Dernière modification le 02 mars 2021 à 17:01.
Salut,
Peut-être qu'on ne se comprend pas ;)
J'installe une fois (juste une) l'environnement de dev. Il permet de builder, tester, débuger, en local… bref un "truc" "normal".
Un fois prêt, ça part en "code review" (et tant mieux si A utilise eclipse et B intellij au passage).
Ensuite, ça passe à la moulinette automatique pour faire le trajet
dev>preprod>prod. Il n'y a plus d'environnement de développement là dedans, et c'est validé à chaque étape. Si ça ne passe pas, retour sur le bureau. Sinon, c'est livré.Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Ça n'en a pas l'air en effet :)
Je vais reprendre un exemple plus concret.
Mon environnement de dev c'est en gros:
- python 2, python 3, virtualenv
- une toolchain gcc avec un sysroot (c'est pour de l'embarqué)
- Eclipse
- plusieurs librairies
- des outils (git, curl, wget, unzip, cpio, zip, sudo etc)
- un user avec des droits root via sudo
- quelques variables d'environnement bien définies
C'est documenté dans un wiki confluence.
En mettant la configuration de l'environnement dans un docker, elle peut être poussée sous GIT et récupérée avec le code sur une machine ou un CI. Ça évite les mises à jour manuelle sur chaque machine.
Je pense que ça correspond à ton utilisation de jenkins+nexus.
Mon problème
estétait le côté pas pratique de bosser avec un container pour développer (ca résout une bonne partie de mon problème: https://linuxfr.org/nodes/123450/comments/1843266), mais j'ai l'impression que tu n'utilises pas de container pour développer …Voilà avec un peu de chance, tu devrais mieux comprendre ce qu'il y a dans ma tête … et m'expliquer ce que j'ai pas compris dans la tienne ;)
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2.
Salut,
Dans le cadre d'utilisation que je présente, tout est modulaire. Il y a
libA-v1,libA-v1.1,libB-v2,projetC-v2qui va utiliserlibA-v1uniquement,projetC-v2.1qui lui va avoir besoin delibA-v1.1etlibB-v2…La CI se charge de mettre à jour
libA-v1,libA-v1.1,libB-v2lorsque modification. SiprojetC-v2a besoin delibA-v1-patch42, à nouveau la CI va rebuilder tout ça. Et mettre les nouvelles versions corrigées surnexus. Du coup, construire un env de dev dans une VM ou autre, ça me semble un peu surtaillé (attention, je l'ai fait, pour une raison simple : dev avec pour cible windows alors que j'étais sous linux ; ce choix peut totalement se justifier).J'aime bien qu'on me laisse choisir mes outils, si cela est possible, et pas me les imposer de force. ;)
Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Salut,
Je pense que tu parles de bibliothèque (que tu compiles) alors que je parle d'outils de développement (gcc, python et éventuellement bibliothèques système qui sont sous forme binaire) et d'outils d'édition (Eclipse, DDD etc).
Pour les outils/bibliothèques binaires, je me repose sur la distribution pour gérer ça. C'est là où je vois l’intérêt des VM/container.
Dans le cas où tout est compilé, effectivement, ça a peu d'intérêt sauf pour du multi-plateforme.
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2.
Salut,
Oui, et désolé, je ne vois toujours pas la logique, sauf si tu ne peux vraiment pas mettre deux versions d'outils et que tu as absolument besoin de scinder.
C'est probablement là qu'on ne se comprend pas ;)
Matricule 23415
[^] # Re: La classique
Posté par ykrons . Évalué à 1.
Je pense qu'il y a des cas où je pourrais avoir des "dépendances" manquantes suivant l'OS mais c'est vrai que j'ai du mal à trouver un exemple pas trop tiré par les cheveux… :)
Je vais resté sur les VM/containers car ça me permet de cloner/réinitialiser un environnement de dev sans interférence avec l'hôte. Ça me "rassure" aussi un peu d'être indépendant de toutes les configurations potentielles du poste hôte.
[^] # Re: La classique
Posté par _kaos_ . Évalué à 2. Dernière modification le 04 mars 2021 à 16:10.
Salut,
Ah mais si ce n'est que ça, c'est super facile pour se comprendre !
Je n'ai jamais eu à le refaire, mais dans un de mes premiers boulots (je radote très certainement), y'avait du VB, codé avec les pieds. Les UAC sont arrivés et ont tout défoncé.
Panique à bord, fix vite fait (deux fois, le second améliorant le précédent ; quand on aime on ne compte pas ;) ). Et zou, un an sous la douche environ.
Je pouvais partir de presque 0 vu que le VB était à mettre à la poubelle (son rôle n'étant que d'être passe-plat entre bdd et fortran).
Là, même si je l'avais déjà la VM mais tirais pour l'avoir moins, la VM m'a servi. D'un côté le visu VB, de l'autre la ré-implémentation avec un objectif : pas perdre les utilisateurs : Les paramètres seront (presque) au même endroit. Par contre ça va prendre du temps….
Matricule 23415
# Ansible + GNU environment modules
Posté par Ronan BARZIC . Évalué à 2. Dernière modification le 02 mars 2021 à 11:42.
Pas exactement le même cas d'utilisation que le tien (je ne gère pas vraiment des librairies mais plutôt des outils) mais bon, ça peut aider
Ansible:
- pour installer la même version d'un outil sur plusieurs machines à la fois
- les outils sont installés sous
/opt/<nom de l'outil>/<version><version>peut être la version "officielle" (i.e 1.2.3) ou la date + le git hashpar exemple : /opt/iverilog/2020-07-22-5ebd08c7
GNU modules
Pour l'exemple au dessus (iverilog , compilé depuis github, version/hash 5ebd08c7), je vais créer un "module" iverilog/2020-07-22-5ebd08c7 qui definira le chemin de recherche (PATH) et tout autre variable. (j'ai même un script qui crée le fichier "module" depuis le fichier de variable Ansible)
Pour accéder à cette version, depuis le shell : module load iverilog/2020-07-22-5ebd08c7
Pour chaque project, dans le répertoire principal, on a un fichier init.sh qui "charge" les différents modules et sélectionne le bon environement virtuel pour Python.
Comme ca, on maintient une liste d'outil stables tout en permettant à chacun de changer de version d'outils en cas de bug ou de test de nouvelles fonctionnalité
Marche au poil avec Jenkins…
[^] # Re: Ansible + GNU environment modules
Posté par ykrons . Évalué à 1.
Ça parait pas mal, par contre je sais pas si ça va couvrir un de mes cas d'utilisation.
On a de vielles applis compilées avec un vieux compilo, de vieilles libs dans une vielle distribution avec pas mal de poussière dessus. Pour plusieurs raisons (effort de migration, libs plus dispo dans une nouvelle version, etc), on ne va pas mettre à jour le code pour être compatible avec un système à jour.
Dans ce cas, je ne suis pas sûr qu'on puisse toujours installer tous les outils nécessaires à un "viel environnement" sur un PC de dev à jour. Comme exemple, j'ai un outil qui veut que /bin/sh pointe sur /bin/bash, des scripts qui attendent un user particulier avec des droits root, …
C'est un peu pour ça que je cherchais plus du côté des VM/container.
Mais je connais pas Ansible, il faut que je regarde un peu pour pas dire trop de bêtises.
[^] # Re: Ansible + GNU environment modules
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 02 mars 2021 à 12:51.
Ansible est fait pour configurer et mettre à jour un parc de machines… on peut l'utiliser pour faire autre chose mais ça devient assez rapidement un choix très discutable. Je l'ai utilisé pendant 3 ans et même dans le cas d'utilisation “canonique” je trouve cet outil assez faible pas très convainquant.
Mes principaux griefs:
Au final on écrit beaucoup de shells scripts quand-même, donc hormis quelques cas d'école très particuliers Ansible n'offre pas de fonctionnalité très intéressante. (Juste le parallélisme sur les machines.)
Tout ce qui est méta-programmation / traitement de données (par exemple calculer les paramètres réseau, ajuster la taille des disques et des caches…) est juste imbitable, intestable, bref c'est sur ce point un très mauvais choix.
[^] # Re: Ansible + GNU environment modules
Posté par Ronan BARZIC . Évalué à 1.
Juste curieux: tu utilises quoi à la place d'Ansible dans ce cas ?
[^] # Re: Ansible + GNU environment modules
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 02 mars 2021 à 14:05.
Je fais exclusivement du “serveur constant” donc ansible ne sert plus à rien. :-)
Pour les containeurs j'utilise docker/kubernetes (donc en gros des shell scripts).
Pour la configuration d'instance je suis content avec des shell scripts et pour l'infrastructure comme service terraform.
[^] # Re: Ansible + GNU environment modules
Posté par Michaël (site web personnel) . Évalué à 2.
Un article d'intro sur le serveur constant (en anglais): https://martinfowler.com/bliki/ImmutableServer.html
[^] # Re: Ansible + GNU environment modules
Posté par Ronan BARZIC . Évalué à 1.
Pour info, Ansible te permet de mettre des conditions sur differents paramêtres comme l'OS, sa version,etc…
Comme ça, j'arrive à gérer des postes de travails et des serveurs sous Ubuntu (18.04,20.04) et Centos 7 sans trop de difficultée (les difficultées sont principalement due à Centos 7 qui a pas mal d'outils par default qui commencent à viellir).
Donc une fois l'OS installé sur le materiel (ou la VM), je peux réinstaller tout l'environment d'un dévelopeur via Ansible et les differentes versions d'outils (si elles étaient compatibles avec l'OS) se retrouvent installées.
[^] # Re: Ansible + GNU environment modules
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 08 avril 2021 à 04:55.
Me suis fait la même remarque qu'il avait besoin de playbooks Ansible
:-)…ou juste de dokerfiles (ce type de conteneur pouvant être plus adaptés que des vm)
…ou encore peut-être regarder du côté de Vagrant ou similaire s'il faut rester en vm.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Ton organisation paraît déjà assez bonne
Posté par Michaël (site web personnel) . Évalué à 3.
Il me semble que tu n'as que quelques points à améliorer. Si ceci est ton principal problème avec ta solution à base de containers:
tu vas être content. Tu peux très facilement exposer ton code sous le chemin dans le conteneur. Par exemple avec docker, tu peux essayer
pour voir que ton dossier courant est visible avec le même chemin dans le conteneur.
Après il me semble que si votre solution à base de machine virtuelles marche bien à ceci près que:
tout ce qu'il manque pour vivre au paradis est de construire une chaîne de livraison continue qui produit une machine virtuelle à jour à intervalles réguliers. Même si elle fait dans les 10 Go, cela ne prend normalement que quelques minutes à télécharger.
(Il me semble que Vagrant sait faire cela mais on peut s'en tirer avec quelques scripts shells et la CLI de VirtualBox, si c'est VirtualBox que vous utilisez. En plus c'est possible d'utiliser ces machines comme agents Jenkins!)
[^] # Re: Ton organisation paraît déjà assez bonne
Posté par ykrons . Évalué à 1.
C'est vrai que monter le volume au même emplacement pourrait résoudre le problème des chemins différents. C'est tout con, j'y avais pas pensé …
J'avais testé un peu Vagrant il y a qq années, ça pourrait être une solution pour avoir une VM un peu plus standardisée. Mais si les containers conviennent à tout le monde, ça peut peut-être suffire.
Après il y a des devs OS et des devs applis qui n'ont pas forcement les mêmes besoins de performances. Une VM pour certain(e)s et un container pour d'autre ça peut aussi être une solution, mais ça fera un peu double maintenance à moins d'avoir un autre truc au dessus qui génère automatiquement VM et container à partir d'une config (ansible par exemple: https://linuxfr.org/nodes/123450/comments/1843259)
[^] # Re: Ton organisation paraît déjà assez bonne
Posté par Michaël (site web personnel) . Évalué à 3.
Ce n'est pas sans piège toutefois, au niveau des permissions. Rien qui soit en principe gênant pour une compilation cependant. (Par exemple pour une clef ssh qui doit avoir une permission au plus
-rw-------pour être utilisée par le client SSH va demander plus de travail pour être utilisable.)Oui ici il y a deux approches je pense: soit on fait un joli paquet qui tire toutes les dépendances nécessaires quand on l'installe soit on s'en tire avec un simple shell-script.
Aujourd'hui un shell-script est souvent une meilleure solution que ce qu'on peut croire a priori pour configurer une machine. La raison et que, dans beaucoup de cas, le gestionnaire de paquets n'est qu'un moyen parmi d'autres d'installer des logiciels sur une machine. (Source: ouvrir une dizaine de Dockerfiles de projets libres pour faire ce constat.) Outre le gestionnaire de paquets canonique du système on a tous les gestionnaires relatifs à un langage – type npm, pip, gem, opam, quicklisp, maven, … et même la bonne vieille tarball. Avec des pratiques de type “serveur constant” la possibilité de faire une mise à jour proprement est beaucoup moins importante – en général on repart de zéro au lieu de mettre à jour l'existant.
C'est possible de faire un script qu'on copie puis exécute dans le container ou dans la vm avec vagrant ou un outillage ad-hoc. Utiliser ansible n'a ici pas grand intérêt: pour les conteneurs c'est plutôt contre nature et il va falloir se lancer dans des contorsions peu intéressantes pour effectivement utiliser ansible pour créer une image docker, et ce script ansible ne va probablement utiliser 4 modules ansibles pour installer des paquets puis appeler une dizaine de shell-scripts pour faire tout le reste… autant utiliser directement un shell-script et éliminer toute une séries de dépendances. (On a ordinairement déjà assez de risques pour casser un “build” sans s'offrir le luxe de dépendances peu utiles! :-) )
# un mix des solutions plus haut
Posté par NeoX . Évalué à 3.
-> ansible et ses playbooks, tu peux lui demander de creer un environnement, un conteneur, une VM avec certains prerequis interne
tu héberges les playbook (fichier de config) sur git,
le développeur clone les playbook et lance son fichier de config
et hop, il a la VM avec les outils qui vont bien dedans
[^] # Re: un mix des solutions plus haut
Posté par ykrons . Évalué à 2.
Ça va faire un bel empilage :)
J'aime bien l'idée, mais après ça fait pas mal d'outil à gérer et à maintenir.
bamboo/jenkins
|_ ansible
|__ vagrant
|___ VirtualBox / KVM
|__ docker
Faut trouver le bon équilibre !
# Docker ?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 02 mars 2021 à 15:27.
Pour un peu le même besoin dans la mienne j'ai créé un docker qui propose la cross compilation ARM de notre produit.
Elle embarque un script qui est capable de cloner le repo git, compiler, et préparer un réprtoire
output/avec tout dedans bien rangé. Utilisable manuellement par les devs ou en CI.EDIT : j'ai peut-être lu ton post un peu trop rapidement, toi tu parles d'embarquer Eclipse par exemple. Du coup il va te falloir plus qu'un Docker je pense.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Docker ?
Posté par ykrons . Évalué à 1.
Oui c'est à peu prêt le même besoin de mon côté et c'est aussi ce que j'ai dans mon "proto" actuel.
Par contre, on n'est pas trop "container aware" chez nous, donc j'ai un peu peur que ça perdre un peu du monde.
De ton côté, comment se passe l'utilisation par les devs?
Les devs sont plutôt à l'aise avec et ils se débrouillent pour configurer leur environnements de dev etc ?
C'est prémaché avec un script qui lance automatiquement le container de manière transparente?
C'est quoi qui est plus fort qu'un docker?
[^] # Re: Docker ?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 02 mars 2021 à 19:24.
C'est ce que j'ai fait. En tête il y a un Makefile, tout simplement (j'aime les Makefile). De la construction du docker à l'utilisation, c'est juste des commandes
make.En fait j'ai jamais utilisé Docker pour des applications graphiques, je ne sais même pas si c'est possible. Du coup je pensais à la virtualisation.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Docker ?
Posté par ykrons . Évalué à 1.
C'est vrai que c'est chouette les Makefile :) J'avais un script pour l'instant mais je vais le basculer en Makefile.
Si c'est possible mais il faut avoir toute la couche graphique donc ça alourdit forcement un peu l'image. Après un export display et c'est bon. J'imagine qu'un VNC ou un NX doivent marcher aussi.
# Vagrant a été conçu pour régler ce problème
Posté par cg . Évalué à 2. Dernière modification le 02 mars 2021 à 21:09.
(Edit: zut j'avais pas vu que c'est déjà mentionné dans les réponses, désolé !)
Est-ce vous avez essayé Vagrant ?
C'est certes basé sur des machines virtuelles, mais ça normalise et automatise leur fabrication.
# Développement distant
Posté par T_T_T . Évalué à 1.
Pour du code c++, j'utilise CLion (qui n'est pas libre) et dont le mode distant reste pas top (il y a une synchronisation +/- efficace et automatique) et je ne sais pas ce que ça vaut dans le cas où client et serveur ne sont pas homogènes (comprendre x86_64).
Il y a aussi
vscodequi propose un mode distant plus propre: tout se passe sur le serveur. Mais le support du C++ n'était pas top dans mon souvenir, et il faudra peut-être passer par un plug-in payant et pas libre de JetBrains pour avoir un truc acceptable…Dans la même veine, eclipse che. (Je n'avais pas réussi à installer…)
Sinon, bravo pour ton travail jusque là, ça va porter ses fruits, c'est sûr!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.