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é ...
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.)
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
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! :-) )
[^] # Re: Ton organisation paraît déjà assez bonne
Posté par Michaël (site web personnel) . En réponse au message Comment synchroniser environnement de développement entre machines ?. É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! :-) )