Dieser Artikel ist der dritte Tag von OpenSaaS Studio Adventskalender 2019.
Ersteres ist eine Mono-Repo-Konfiguration mit Bazel in Golang- und Python-Microservices. Ich habe mich gefragt, ob Python mit dem Mono-Repo gemischt werden kann, wenn ich Bazel verwende, das mehrere Sprachen unterstützt, aber es war schwierig, also werde ich einen schwierigen Punkt hinterlassen.
Ich habe nur Python3-Serien im Dienst verwendet, aber ich brauchte Python2-Serien, um das erstellte Image zu pushen. Da ich Container-Registrierung als Image-Registrierung des Containers verwendet habe, benötigt Bazel das Google Cloud SDK, um das Image zu pushen, und es ist damit verknüpft. Ich denke, dass Python2-System in Form einer Fortsetzung benötigt wurde. Beschreibung des Google Cloud SDK
Neuere Versionen von macOS enthalten die entsprechende Version von Python, die für das Google Cloud SDK erforderlich ist. Das Cloud SDK erfordert Python 2 mit einer Versionsnummer von Python 2.7.9 oder höher. Wenn Sie einen zusätzlichen Python-Interpreter installieren, darf dieser die Installation des Google Cloud SDK nicht beeinträchtigen.
Bazel hat einen Mechanismus, mit dem Sie den Python-Interpreter angeben können, der beim Erstellen verwendet werden soll, also habe ich diesen verwendet.
Die Interpreterdefinition und Builddefinition sehen folgendermaßen aus.
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",
)
Bei Verwendung von Bazel Rules for Python wird beim Herunterladen der Bibliothek anscheinend der dem Befehl "python" zugeordnete "pip" ausgeführt. Wie ich oben geschrieben habe, war die Standardeinstellung "Python" 2 Serien, sodass ich die Bibliothek der Python 3-Serie herunterladen konnte. Der Code lautet hier
Geändert in python-> python3.6, sodass 3 Serien durch Gabeln verwendet werden können ..
Als ich jedoch die neueste Version überprüfte, war sie standardmäßig Pip3-kompatibel, sodass jetzt möglicherweise kein Problem mehr besteht.
Bazel hat eine Standardregel (py3_image) zum Erstellen eines Python3 Docker-Images. Als ich es in Kombination mit Python: 3.6-slim erstellt habe, konnte das erstellte Image nicht gestartet werden.
Die Build-Definition sieht folgendermaßen aus
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",
)
Eigentlich ist der Einstiegspunkt des von py3_image erstellten Bildes standardmäßig / usr / bin / python, aber in Python: 3.6-slim ist der Python-Befehl nicht in diesem Pfad festgelegt und kann nicht gestartet werden. tat.
Der Code lautet hier
Ich habe dieses Bild verwendet, weil es normalerweise mit python: 3.6 begann. (Es wird davon ausgegangen, dass die Bildoptimierung bei Bedarf später durchgeführt wird.)
Es gab drei Python-Dienste, und die von mir verwendeten Python-Versionen unterschieden sich alle von 3.5, 3.6 und 3.7. Die oben beschriebene Methode zur Verwendung des Python-Interpreters kann nur das 2. und 3. System trennen, sodass dieser Mechanismus nicht damit umgehen kann.
Ich habe beschlossen, alle im Dienst verwendeten Python-Versionen auf 3.6 zu verschieben. Die Überprüfung hat bisher lange gedauert, und ich dachte, dass eine komplizierte Konfiguration des Builds von der ursprünglichen Richtlinie abweichen würde. Daher habe ich beschlossen, die Anzahl der zu verwaltenden Dinge zu reduzieren. Wenn Sie mit mehreren Versionen von Python3 koexistieren möchten, können Sie möglicherweise WORKSPACE trennen und für jede Version den erforderlichen Python-Interpreter angeben. (unbestätigt)
├── service_for_python3.6
│ └── WORKSPACE <-Python3 hier.Richten Sie 6 Dolmetscher ein
├── service_for_python3.7
│ └── WORKSPACE <-Python3 hier.Setze 7 Dolmetscher
└── WORKSPACE
(Wahrscheinlich) Das gleiche Ereignis wie dieses Problem ist in der Bibliothek der Google-Cloud-XXX-Serie aufgetreten. Es scheint, dass das Problem durch die unterschiedliche Verzeichnisstruktur beim Installieren der Bibliothek mit "pip install" und beim Erstellen mit Bazel verursacht wurde.
Es gibt auch einen Kommentar in der Ausgabe, der jetzt durch Angabe des Attributs "Legacy_create_init" ausgeführt werden kann.
Ich verwende Tensorflow-GPU für einige Dienste und konnte die Bibliothek nicht herunterladen, da die Build-Umgebung keine GPU hatte.
Es ist ungelöst. Es ist schon eine Weile her, seit ich mit der Überprüfung begonnen habe, also habe ich sie hier aufgerundet. Bazel kann dies möglicherweise verarbeiten, indem eine der GPU zugeordnete Plattform angegeben wird (sofern vorhanden) oder indem dieser Dienst auf einer Buildfarm mit der GPU erstellt wird.
Recommended Posts