Cet article est le troisième jour du Calendrier de l'Avent OpenSaaS Studio 2019.
Le premier est une configuration mono-repo utilisant Bazel dans les microservices Golang et Python. Je me suis demandé si Python pouvait être mélangé dans le référentiel mono si j'utilisais Bazel, qui prend en charge plusieurs langues, mais c'était difficile, donc je vais laisser un point difficile.
docker build et pousse cette imageJ'ai utilisé uniquement la série Python3 dans le service, mais j'avais besoin de la série Python2 pour pousser l'image créée. J'ai utilisé Container Registry comme registre d'images pour le conteneur. Bazel a donc besoin du SDK Google Cloud pour pousser l'image et y est lié. Je pense que le système Python2 était nécessaire sous la forme d'une suite. Description du SDK Google Cloud
Les versions récentes de macOS incluent la version appropriée de Python requise pour le SDK Google Cloud. Le SDK Cloud nécessite Python 2 avec un numéro de version Python 2.7.9 ou version ultérieure. Si vous installez un interpréteur Python supplémentaire, il ne doit pas interférer avec l'installation du SDK Google Cloud.
Bazel a un mécanisme qui vous permet de spécifier l'interpréteur Python à utiliser lors de la construction, donc je l'ai utilisé.
La définition de l'interpréteur et la définition de construction ressemblent à ceci.
load("@rules_python//python:defs.bzl", "py_runtime_pair")
py_runtime(
name = "py2_local_bin_runtime",
interpreter_path = "/usr/local/bin/python2",
python_version = "PY2",
)
py_runtime(
name = "py3_6_local_bin_runtime",
interpreter_path = "/usr/local/bin/python3.6",
python_version = "PY3",
)
py_runtime_pair(
name = "py_local_bin_runtime_pair",
py2_runtime = ":py2_local_bin_runtime",
py3_runtime = ":py3_6_local_bin_runtime",
)
toolchain(
name = "py_mac_toolchain",
exec_compatible_with = [
"@bazel_tools//platforms:osx",
"@bazel_tools//platforms:x86_64",
],
toolchain = "py_local_bin_runtime_pair",
toolchain_type = "@rules_python//python:toolchain_type",
)
register_toolchains(
"//:py_mac_toolchain",
"//:py_linux_toolchain",
)
py_binary(
name = "mysite",
srcs = ["manage.py"],
deps = [
"//mysite/mysite:py_default_library",
"//mysite/polls:py_default_library",
],
main = "manage.py",
python_version = "PY3",
)
Lors de l'utilisation de Bazel Rules for Python, il semble que le pip associé à la commande python soit exécuté lors du téléchargement de la bibliothèque. Comme je l'ai écrit ci-dessus, le python par défaut était la série 2, donc je pouvais télécharger la bibliothèque de la série Python 3.
Le code est par ici
Changé en python-> python3.6 afin que 3 séries puissent être utilisées en forçant ..
Cependant, lorsque j'ai vérifié la dernière version, elle était compatible Pip3 par défaut, donc il n'y a peut-être plus de problème maintenant.
Bazel a une règle par défaut (py3_image) pour créer une image Docker Python3, et lorsque je l'ai construite en combinaison avec python: 3.6-slim, l'image créée n'a pas pu être démarrée.
La définition de construction ressemble à ceci
container_pull(
name = "py3_base",
registry = "index.docker.io",
repository = "library/python",
tag = "3.6-slim",
)
py3_image(
name = "mysite_image",
srcs = ["manage.py"],
deps = [
"//mysite/mysite:py_default_library",
"//mysite/polls:py_default_library",
],
main = "manage.py",
base = "@py3_base//image",
)
En fait, le point d'entrée de l'image créée par py3_image est / usr / bin / python par défaut, mais en python: 3.6-slim, la commande python n'est pas définie dans ce chemin et ne peut pas être démarrée. fait.
Le code est par ici
J'ai utilisé cette image car elle commençait normalement avec python: 3.6. (L'optimisation de l'image est supposée être effectuée plus tard si nécessaire)
Il y avait trois services Python, et les versions de Python que j'utilisais étaient toutes différentes de 3.5, 3.6 et 3.7. La méthode d'utilisation de l'interpréteur Python décrite ci-dessus ne peut séparer que les 2e et 3e systèmes, donc ce mécanisme ne peut pas le gérer.
J'ai décidé de déplacer toutes les versions de Python utilisées dans le service vers la version 3.6. La vérification a pris beaucoup de temps jusqu'à présent, et j'ai pensé que compliquer la configuration autour de la construction s'écarterait de la politique d'origine, j'ai donc décidé de réduire le nombre de choses à gérer. Si vous souhaitez coexister avec plusieurs versions de Python3, vous pourrez peut-être séparer WORKSPACE et spécifier l'interpréteur Python requis pour chacune. (non confirmé)
├── service_for_python3.6
│ └── WORKSPACE <-Python3 ici.Mettre en place 6 interprètes
├── service_for_python3.7
│ └── WORKSPACE <-Python3 ici.Set 7 interprètes
└── WORKSPACE
(Probablement) Le même événement que ce problème s'est produit dans la bibliothèque de la série google-cloud-XXX.
Il semble que le problème ait été causé par la structure de répertoires différente lors de l'installation de la bibliothèque avec pip install et lors de la construction avec Bazel.
Il y a aussi un Comment dans le problème, mais il peut maintenant être exécuté en spécifiant l'attribut legacy_create_init.
J'utilise tensorflow-gpu pour certains services et je n'ai pas pu télécharger la bibliothèque car l'environnement de construction n'avait pas de GPU.
Ce n'est pas résolu. Cela fait un moment que j'ai commencé la vérification, alors je l'ai arrondie ici. Bazel peut être en mesure de le gérer en spécifiant une plate-forme associée au GPU (si elle existe) ou en construisant ce service sur une ferme de construction qui a le GPU.
Recommended Posts