Aanleveren van een Python applicatie

Applicaties kunt u zelf plaatsen door ze op de upload-server in de juiste web-app directory neer te zetten. Het is ook mogelijk dit door NPO ICT te laten doen. Wij gaan er dan vanuit dat er 1 complete tar file aangeleverd wordt (bv dmv een url waarvan wij de tar file kunnen downloaden). Vervolgens zullen wij de tar file plaatsen. Wij verwachten dat naast de tar file installatie instructies aangeleverd worden.

Het configureren van de passenger/nginx wordt altijd door NPO ICT gedaan. Idem voor databases.

Het configureren van de applicatie zal meestal in samenspraak tussen NPO ICT en de sitebouwer gebeuren. Zaken waar NPO ICT zich mee bemoeit zijn:

  • Database parameters config/settings.yml; de database wordt door NPO ICT aangemaakt. login namen en database passwords zijn daar eventueel op te vragen)
  • Applicatie logfiles; Een python applicatie wordt geacht te loggen onder /e/ap/X/log houd er rekening mee dat er altijd meerdere python instanties hierin schrijven, maak een apart logfile voor elke instantie, neem bijvoorbeeld de uid op in de bestandnaam.
  • tmpdir; De applicatie tmpdir van een applicatie X wordt geacht te zijn:· /e/ap/X/tmp
  • packages (modules); Binaire (gecompileerde) packages willen wij graag compileren om makkelijk software en OS upgrades uit te kunnen voeren. Overige modules worden geacht in de applicatie geïnstalleerd te worden
  • current; De applicatie wordt geacht te staan in /e/ap/X/pages/current/passenger_wsgi.py waarbij current meestal een symlink zal zijn naar de meest recente deployments.

Bij initiële oplevering plaatst NPO ICT een hello world applicatie om een werkende set-up te kunnen tonen. Deze kunt u uiteraard naar believen overschrijven of verwijderen.

Per applicatie wordt een bijbehorende python 'binary' opgeleverd Voor een applicatie X is dat

/e/ap/X/bin/python

deze sourced z'n environment variabelen uit:

/e/ap/X/bin/env

Gebruik dit ook in je eigen shell om altijd de juiste python te gebruiken voor command-line werk.

source /e/ap/X/bin/env
python --version

Indien gewenst kunnen wij hier meer environment variabelen in opnemen zoals PYTHONPATH of DJANGO_SETTINGS_MODULE.

pip install

Zo maak je je eigen python packages repository:

source /e/ap/X/bin/env
pip install --prefix=/e/ap/X/pages/env SomePackage

Zie hier voor meer details.

Vervolgens kan via PYTHONPATH aangegeven worden waar deze packages gevonden kunnen worden:

export PYTHONPATH=/e/ap/X/pages/env/lib/python2.7/site-packages

of in geval van python3.6

export PYTHONPATH=/e/ap/X/pages/env/lib/python3.6/site-packages

LET OP: niet alle packages kunnen via “pip install” geïnstalleerd worden, namelijk als er software gecompiled moet worden kan dat vaak niet. In zo'n geval kan NPO:ICT een module samenstellen waar de gewenste packages in zitten. Deze wordt dan beschikbaar gesteld via /local/python-poilib-<iets>/… en middels het zetten van PYTHONPATH gerefereerd via /e/ap/X/bin/env.

virtualenv / pyvenv

De python-wereld kent zoiets als een virtualenv welke kan worden opgebouwd met 'virtualenv' of met 'pyvenv'. Voor python-3 geldt dat dit probleemloos kan.

Voor python-2[.7] is het zo dat virtualenv een kopie van de python binary maakt. Dat is op zich geen probleem, totdat er een upgrade van python langskomt. In zo'n geval kan het voorkomen dat de virtualenv na de upgrade niet meer werkt. Voor python-2 omgevingen adviseren we om als er vanuit NPO:ICT python upgrades aangekondigd worden na de upgrade de virtualenv opnieuw aan te maken, om er zeker van te zijn dat deze goed blijft samenwerken met de ge-upgrade python versie.

python versies op het systeem

Zoals hierboven uitgelegd koppelen we meestal een python binary 1-op-1 aan een website. Deze staat voor website X dan in

/e/ap/X/bin/python

Als je in beter kijkt zie je dat die niet een echte binary is, maar een shellscript waar /e/ap/X/bin/env ingelezen wordt en vervolgens de echte python binary geëxecuteerd wordt. In /e/ap/X/bin/env staat de locatie van de eigenlijke python binary en eventueel de locatie van extra packages die nodig zijn voor website X.

De locatie van de eigenlijke python binary is voor python-2 installaties is meestal

/local/Python27-minimal/bin/python

of

/local/Python36-minimal/bin/python

voor python-3.

Waarbij /local/Python27-minimal (en /local/Python36-minimal) symlinks zijn naar een zeer kale standaard python installatie, waar eigenlijk alleen pip en virtualenv aan zijn toegevoegd.

Op die manier kan men zelf middels pip install extra packages installeren en kan NPO:ICT onderhoud op python uitvoeren door /local/Python27-minimal van tijd tot tijd naar een nieuwere python versie te laten wijzen (b.v. van Python-2.7.13 naar Python-2.7.14) zonder dat de bestaande pip install packages hiervoor aanpassingen behoeven.

Naast /local/Python[XY]-minimal is er ook een python binary in /usr/bin/python. Dit is de python versie zoals die standaard met het OS meekomt en door componenten in het OS gebruikt wordt. Deze is niet geschikt om webhosting mee te doen en kan hier dus beter niet voor gebruikt worden. Om te voorkomen dat deze versie per ongeluk toch gebruikt wordt is het zaak om altijd

source /e/ap/X/bin/env

te doen zodat de juiste versie van python op het systeem gebruikt wordt.

Herstarten applicatie

Het herstarten van de applicatie kunt u zelf veroorzaken door een touch van /e/ap/X/pages/restart.txt uit te voeren.

  • sterretje-cluster/appcluster-hosting_python.txt
  • Last modified: 2019/04/26 10:34
  • (external edit)