Python 3.x auf CentOS 7.x und Systemd mit Ansible

Standard

Bevor ich meine TUXERJOCH-Software auf meinen Server aufgespielt habe, lief sie nur auf meinem Desktop mit Fedora 21. Ich war überrascht, dass ich unter CentOS 7 auf Probleme gestoßen bin, mit denen ich nicht gerechnet habe.

Unter CentOS 7 stand zwar schon ein Python-3-Paket zur Verfügung, aber darüber hinaus gibt es nichts. Die meisten Libs sind noch (ausschließlich) für Python 2.x. Alles was es für Python 3 gibt ist:

  • python3-pkgversion-macros
  • python34
  • python34-debug
  • python34-devel
  • python34-libs
  • python34-test
  • python34-tkinter
  • python34-tools

So musste ich mir überlegen, wie ich an meine benötigten Python-3-Pakete komme. Ich habe keine RPM-Repos mit CentOS 7-Paketen gefunden, die ich hätte einbinden können. Also wollte ich den Weg über pip gehen. Das ist natürlich nicht so schön, weil pip ein Fremdkörper ist und die Installationen am System vorbei gehen. Ich kann nicht mit einem Befehl (yum -y update) das gesamte System aktualisieren. Aber durch meinen Einsatz von Ansible halte ich das Problem noch
für beherrschbar, da ich jetzt das System mit einem einzigen Ansible-Befehl aktualisieren kann. Ansible bedient dann seinerseits rpm und pip.

Leider musste ich feststellen, dass auch pip keine Python 3-Pakete kannte. Ich wusste aber von Fedora, dass es sie geben muss. Was mir fehlte, war also ein pip für Python 3, den es leider nicht für CentOS 7 fertig gibt. Man muss sich diesen selbst herunterladen und installieren:

curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python3.4 ./get-pip.py

Danach habe ich die gleiche pip-Version installiert, wie für den Python-Interpreter, den ich dafür benutzt habe, also in diesem Fall: pip3.4

Jetzt konnte ich endlich die passenden Libs für mein Python 3 installieren:

pip3.4 install bottle
pip3.4 install simplejson
pip3.4 install requests
pip3.4 install cherrypy

Was noch bei der Verwendung mit Ansible zu beachten ist

Damit ich den den Weblog als Service in Hintergrund laufen lassen kann, griff ich auf Systemd zurück. Damit Systemd auch tatsächlich Python 3.x verwendet und nicht 2.x, muss ich Datei /usr/lib/systemd/system/tuxerjoch.service anpassen. Und die sieht jetzt so aus:

[Unit]
Description=tuxerjoch server
After=syslog.target
After=network.target

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/usr/local/lib/tuxerjoch/
ExecStart=/usr/bin/python3.4 /usr/local/lib/tuxerjoch/tuxerjoch.py

# Give a reasonable amount of time for the server to start up/shut down
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Wie bereits erwähnt, editierte ich die Datei nicht direkt, sondern verteilte meine Konfiguration über Ansible. Bei der Konfiguration von Systemd war aber noch zu beachten, das Systemd selbst benötigt einen reload, um die veränderte Konfiguration zu berücksichtigen. Dazu habe ich mir zwei Handlers eingerichtet:

---
- name: restart systemd
  command: /usr/bin/systemctl daemon-reload

- name: restart tuxerjoch
  service:
    name: "tuxerjoch"
    state: "restarted"

Der erste veranlasste den Reload von Systemd. Der Zweite startete den Service für TUXERLOCH neu. Bei den Tasks konfigurierte ich nun, das bei jeder Änderung an der Datei /usr/lib/systemd/system/tuxerjoch.service erst systemd neu gestartet wird und dann tuxerjoch selbst:

- name: set file tuxerjoch.service
  copy:
    src: "../files/tuxerjoch.service"
    dest: "/usr/lib/systemd/system/tuxerjoch.service"
    owner: "root"
    group: "root"
    mode: 644
  notify:
    - restart systemd
    - restart tuxerjoch

Hinterlasse einen Kommentar