Je m'excuse si ce n'est pas le bon site pour cela. Si ce n'est pas le cas, merci de me le faire savoir.
Voici quelques informations générales sur ce que j'essaye. Nous travaillons sur une série de robots de discussion qui entreront en production. Chacun d'eux fonctionnera sur un environnement dans Anaconda. Cependant, notre configuration utilise tensorflow, qui utilise gcc pour être compilé, et la conformité a banni les compilateurs de la production. De plus, les règles de conformité nous désapprouvent également lorsque nous utilisons pip ou conda install en production.
Pour contourner ce problème, j'essaye de tarer le dossier Anaconda 3 et de le déplacer dans prod, avec toutes les dépendances déjà compilées et installées. Cependant, les comptes entre les environnements ont des noms différents, donc cela m'oblige à aller dans le dossier bin (à tout le moins; je suis sûr que je devrai également les modifier dans les dossiers lib et pckg) et utiliser sed -i pour renommer les chemins codés en dur pour pointer de \ home \ vers \ home \ , et bien que cela semble fonctionner, c'est aussi un bon moyen de modifier mon installation.
Mes questions sont les suivantes:
sed -i sur ces chemins? J'ai déjà lu qu'Anaconda lui-même ne le prend pas en charge, mais j'aimerais avoir votre avis. ~ . sed , y a-t-il quelque chose de critique dont je devrais être conscient? Par exemple, lorsque j'utilise grep * , je vais certains fichiers répertoriés comme correspondances de fichiers binaires . Dois-je faire quelque chose de spécial pour les changer? Et encore une fois, je suis bien conscient que je devrais simplement créer une nouvelle installation Anaconda sur la machine de production, mais ce n'est tout simplement pas une option.
Modifier: Jusqu'à présent, j'ai changé les fichiers conda.sh et conda.csh dans / etc, ainsi que les fichiers conda, activer et désactiver les fichiers dans le bac racine. En tant que tel, je suis en mesure d'activer et de désactiver mon environnement sur le nouveau compte utilisateur. De plus, j'ai changé les fichiers dans le dossier bin sous l'environnement du bot. Pour le moment, j'essaie de former le bot à tester si cela fonctionne, mais cela échoue constamment et déclare qu'une action personnalisée n'existe pas dans la liste. Je ne pense pas que cela soit lié à cela, cependant.
Edit2: J'ai confirmé que l'erreur que j'obtenais n'était pas liée à cela. Pour que le bot fonctionne correctement avec une version portée d'Anaconda, tout ce que j'avais à changer était les fichiers conda.sh et conda.csh dans / etc afin que leurs chemins vers python utilisent ~, faites de même pour activer et désactiver les fichiers dans / bin et modifier la ligne shebang dans le fichier conda dans / bin pour utiliser le nom de compte réel. Cela laisse tous les autres fichiers dans / bin et lib utilisant toujours l'ancien nom de compte dans leurs lignes shebang et d'autres variables qui utilisent le chemin, et pourtant les bots fonctionnent comme prévu. De tous les droits, je ne pense pas que cela devrait fonctionner, mais c'est le cas.
3 Réponses :
Voici probablement ce dont vous avez besoin: pip2pi .
Cela ne fonctionne que pour paquets compatibles pip.
Si je comprends bien, vous devez déplacer l'ensemble de votre configuration comme précédemment compilé sous forme de fichier .tar.gz , alors voici quelques éléments que vous pourriez essayez:
Créez un requirements.txt . Ces packages peuvent aider:
une. pipreqs
$ ls packages/ bar-0.8.tar.gz baz-0.3.tar.gz foo-1.2.tar.gz $ dir2pi packages/ $ find packages/ packages/ packages/bar-0.8.tar.gz packages/baz-0.3.tar.gz packages/foo-1.2.tar.gz packages/simple packages/simple/bar packages/simple/bar/bar-0.8.tar.gz packages/simple/baz packages/simple/baz/baz-0.3.tar.gz packages/simple/foo packages/simple/foo/foo-1.2.tar.gz
b. snakefood .
Ensuite, installez pip2pi
$ pip install pip2pi
$ cat requirements.txt foo==1.2 http://example.com/baz-0.3.tar.gz $ pip2tgz packages/ -r requirements.txt bam-2.3/ ... $ ls packages/ foo-1.2.tar.gz bar-0.8.tar.gz baz-0.3.tar.gz bam-2.3.tar.gz
pip2tgz transmet les arguments du package directement à pip, afin que les packages puissent être spécifiés dans n'importe quel format reconnu par pip:
$ pip2tgz packages/ foo==1.2 ... $ ls packages/ foo-1.2.tar.gz bar-0.8.tar.gz
Après obtenir tous les fichiers .tar.gz , les fichiers .tar.gz peuvent être transformés en index de package "simple" compatible PyPI à l'aide de la commande dir2pi :
$ pipreqs /home/project/location Successfully saved requirements file in /home/project/location/requirements.txt
Anaconda est sensible au sujet des noms de chemin. Ils sont évidemment insérés dans des scripts, mais ils peuvent également être insérés dans des binaires. Voici quelques approches qui me viennent à l'esprit:
Utilisez des images Docker en production. Lors de la création de l'image:
Installez Anaconda dans le répertoire \ home \ sur les systèmes de développement ou de construction. Même si les comptes sont différents, il devrait y avoir un moyen de créer un répertoire inscriptible par l'utilisateur au même emplacement.
\ opt \ anaconda dans tous les environnements. Ou un autre répertoire qui ne contient pas de nom d'utilisateur. Si vous ne pouvez pas obtenir un répertoire en dehors du domicile de l'utilisateur, négociez un lien symbolique ou une jonction ( mklink.exe / d ou / j ) sur un chemin fixe \ opt \ anaconda qui pointe vers le domicile de l'utilisateur.
Construisez dans un conteneur Docker en utilisant le répertoire \ home \ , puis exportez une archive et exécutez sur le système de production sans Docker.
Regroupez toute votre application sous forme de package Anaconda pré-compilé, afin qu'elle puisse être installée sans compilateurs.
conda install est mal vu en production. Mais cela pourrait simplifier la création d'images Docker sans écraser. J'ai créé des environnements Anaconda dans Docker et je les ai également exécutés sur du métal nu en production. Mais nous nous sommes toujours assurés que les chemins sont identiques dans les environnements. J'ai trouvé que les chemins déformés étaient trop effrayants pour même essayer. La vie est devenue beaucoup plus simple lorsque nous sommes passés aux images Docker partout. Mais si vous devez continuer à utiliser sed ... Bonne chance :-)
mais ils peuvent également être insérés dans des binaires
Je peux confirmer que certains paquets ont codé en dur le chemin absolu (y compris le nom d'utilisateur) dans le binaire compilé. Mais si vous limitez les noms d'utilisateur à avoir la même longueur, vous pouvez appliquer sed sur les fichiers binaires et texte pour que presque tout fonctionne aussi parfaitement.
D'un autre côté, si vous copiez le dossier entier et utilisez sed pour remplacer les noms d'utilisateur uniquement sur les fichiers texte, vous pouvez exécuter la plupart des packages installés. Cependant, les opérations impliquant la compilation au moment de l'exécution peuvent échouer, un exemple est l'installation d'un nouveau package qui nécessite une compilation lors de l'installation.
Construisez vos environnements dans un chroot ou un conteneur docker avec les mêmes chemins utilisés en production ... et parlez à votre équipe opérationnelle dans un pipeline de déploiement décent ;-)
duplication possible de l ' environnement conda portable en tant que tarball binaire