Python scripts werken... Hoe maak ik deze productie waardig?

[Yariva]

Mijn vraag
Ik ben nu een tijdje aan het coden in Python, voornamelijk om een netwerk te ondersteunen. Maar de kennis en scripts worden steeds breder getrokken. Om te voorkomen dat ik troep ga opleveren / in productie plaats wil ik een mooi stukje software schrijven welke tegen een stootje kan en collega's zonder programmeer kennis (ja die zijn er genoeg in de netwerk business ) de code ook kunnen gebruiken.

Ik neem als voorbeeld een script welke ik redelijk netjes heb gemaakt, een synchronisatie script om tegen een IPAM aan te praten en deze hosts automatisch in ons monitoring pakket te plaatsen. Onderhuids maakt het gebruik van de requests library.

Een aantal dingen welke ik nu probeer vast te houden:
- Gebruik logging module voor strout logging als voor extern loggen naar een .log bestandje.
- Gebruik custom error classes. Handig voor latere module import en om de code simpel te houden.
- Maak gebruik van classes / methods etc.
- Externe credentials / IP adressen etc in een apart .cfg bestand of als enviroment variable.
- Gebruik cronjob's om het script bijv. om het uur af te schieten.

Volgens mij is dit niet al te slecht. Maar met bijvoorbeeld die cronjob vind ik het lastig om in te schatten of iets werkt ja / nee. Natuurlijk kan je het log bestand een tail geven en zoeken naar error codes maar met de gedachte dat ik dit werk ook aan mijn collega's moet kunnen geven word ik hier niet heel warm van.

Wat ik vaker zie met de python projecten welke wat ingewikkelder in elkaar zitten is bijv. aanroepen middels systemctl. Waarin je precies kan zien wat de status van het script is, laatste paar log entries etc. Maar ook bijvoorbeeld de log locatie vind ik lastig. Is het handig om deze in /var/log te plaatsen en zo ja wat komt hier bij kijken etc.

Wat heb ik al gevonden
Ik heb al even rond gekeken op Google naar deze vragen. Al snel kom ik op pagina's met "how to package your application" etc. Maar is dat niet een beetje overkill voor een simpel synchronisatie scriptje denk ik dan...

Mogelijk zijn er Tweakers met iets meer ervaring die een kijkje in hun keuken kunnen geven. Ik kom er niet snel meer uit, iedere site lijkt nu wel een andere oplossing te vinden en ik ben erg benieuwd wat er benodigd is in mijn situatie.

[sjorsjuhmaniac]

Blijft toch ook altijd iets persoonlijks.

Wat ik prettig vind
- zorg dat je duidelijk versioning gebruikt, zodat snel/eenvoudig te zien is met welke versie er gewerkt wordt. Ik gebuik vaak zelfs een clone van de gehele git repo als het om kleine projecten/script gaat. Schijfruimte is tegenwoordig haast nooit een probleem en je kan super eenvoudig versies switchen/updaten.
- include alle non-python libraries in je distributie en import die ipv de op de systeem geinstalleerde versie. Dit werkt alleen voor kleinere projecten. Ik gooi ze meestal in een de submap modules (./modules/<module1>)
- zorg dat je errors duidelijk zijn en waar mogelijk uniek. De error zou een duidelijk 'hint' moeten zijn voor wat ze kunnen aanpassen. Gebruik bv dezelfde terminologie als de opties die aan je script worden meegegeven. Noem bv een hostname niet ineens een host of machine. Als je dan alsnog met vragen komen kun je eenvoudiger helpen.
- voeg een goede help text toe (./script.py --help)
- cronjobs zijn slecht maar hebben haken en ogen omdat de environment vaak net anders is dan voor de normale user. Let hierop bij gebruik van cron.
- kijk of je het voor je collega's niet kan vereenvoudigen door ze bv alleen maar een sshkey te geven en met die key. Dit kan dmv de 'command' optie in authorized_keys. Dit voorkomt dat collega's commandos moeten leren

[martyw]

De punten die je noemt zijn allemaal prima, ook de tips van @sjorsjuhmaniac zijn behulpzaam, m.n. version control kan een life saver zijn. Daarnaast kun je nog denken aan

• Voeg unit tests toe, dan kunnen eventuele opvolgers makkelijker veranderingen aanbrengen in je code zonder de functionaliteit te slopen - zie hier voor meer info
• Gebruik statische code analyse tools om je code te verbeteren zoals flake8 - zie hier voor meer info

[ Voor 3% gewijzigd door martyw op 04-03-2021 13:04 ]

[Ben(V)]

Cron jobs zou ik persoonlijk niet doen.
Dan is systemd in combinatie met stytemctl een beter oplossing.

Je kunt ook gewoon in python een deamon process gebruiken met de bekende dubbele os.fork() en dan via een timer thread de code op regelmatige basis uitvoeren.

En voor logging nooit var/log gebruiken maar netjes een applicatie log locatie, ergens waar de applicatie zelf ook staat.
var/log is voor het Os en niet voor applicaties.

[Lethalis]

Ben(V) schreef op zaterdag 6 maart 2021 @ 00:06:
En voor logging nooit var/log gebruiken maar netjes een applicatie log locatie, ergens waar de applicatie zelf ook staat.
var/log is voor het Os en niet voor applicaties.

Maar als je centrale logging wil, is het toch juist handig om naar syslog te loggen? Dan kan rsyslog het bijvoorbeeld sturen naar een centrale logserver en kun je daar in 1 keer alle logfiles monitoren? Ook al heb je die applicaties / scripts op 100 servers draaien?

[ Voor 3% gewijzigd door Lethalis op 06-03-2021 09:04 ]

[Ben(V)]

Tja alles is een keuze, maar je kunt ook voor een centrale applicatie log kiezen.
Persoonlijk vind ik dat OS zaken van applicatie zaken moet scheiden, maar dat is ook maar een mening.

[Kalentum]

Ben(V) schreef op zaterdag 6 maart 2021 @ 09:17:
Tja alles is een keuze, maar je kunt ook voor een centrale applicatie log kiezen.
Persoonlijk vind ik dat OS zaken van applicatie zaken moet scheiden, maar dat is ook maar een mening.

Uit nieuwsgierigheid ben ik dan benieuwd wat jij vindt van /var/log/mail.log of /var/log/nginx/access.log of /var/log/postgresql.

Het is juist handig ivm beheer (centrale logserver, logrotatie) als je logs op 1 plek staan.

[Ben(V)]

Is al beter dan alles in var/log te gooien, maar ik blijf erbij dat je applicatie en OS moet scheiden ook in de logging.
Het doorpluizen van de logging wordt wel heel onoverzichtelijk en algemene tooling is meestal gemaakt om logfilters op OS gerelateerde zaken te doen.
En dan heb ik het nog niet eens over dat je meestal systeembeheerders en applicatiebeheerders hebt en dat je vaak ook nog voor verschillende applicaties verschillende beheerders hebt.

Je kunt dan beter de boel bij de bron scheiden dan alles in een grote bak te gooien en je weer tooling nodig hebt om de juiste filters te maken en de juiste toegang te geven.
Meestal wil je applicatiebeheerders geen toegang geven tot OS zaken.

[downtime]

Ben(V) schreef op zaterdag 6 maart 2021 @ 10:29:

Meestal wil je applicatiebeheerders geen toegang geven tot OS zaken.

Als applicatiebeheerder vind ik dit een rare opmerking. Het OS bepaalt de gezondheid van mijn applicatie en het is lastig beheren als je moedwillig blind wordt gemaakt omdat je niet in OS logs mag kijken.

[Ben(V)]

Tja we noemen dat functiescheiding en zo is het in de meeste bedrijven geregeld.
En uiteraard bepaalt het OS niet de gezondheid van een applicatie.

Systeem beheer is er voor het OS en applicatie beheer voor de applicaties anders gaat applicatie beheer onherroepelijk zoeken naar systeem problemen en dat kan niet de bedoeling zijn.
Als de applicatie iets logt dan op een systeemfout wijst schakel je daarna systeembeheer in.

Maar als jij zoals je zegt applicaties schrijft ter ondersteuning van het netwerk ligt het natuurlijk op het grensvlak en moet er gewoon een keuze gemaakt worden.

[Lethalis]

Ben(V) schreef op zaterdag 6 maart 2021 @ 13:07:
Als de applicatie iets logt dan op een systeemfout wijst schakel je daarna systeembeheer in.

Tsja dan denk ik eigenlijk meteen aan de keren dat de applicatie weinig bijzonders meldt, maar vooral heel traag is.

Dan is het wel handig om te weten dat er iets met het RAID volume is en dat er geen spreekwoordelijke muur tussen zit waar je iets overheen moet gooien, nadat je eerst hebt zitten ploeteren om problemen op applicatieniveau op te lossen.

Ik ben juist gewend dat systeem- en applicatiebeheer nauw samenwerken.

[pedorus]

Yariva schreef op zondag 28 februari 2021 @ 14:19:
Ik neem als voorbeeld een script welke ik redelijk netjes heb gemaakt, een synchronisatie script om tegen een IPAM aan te praten en deze hosts automatisch in ons monitoring pakket te plaatsen.

Ik heb eigenlijk geen flauw idee wat dit op een host doet, in plaats van iets dat door iets buiten de host wordt geregeld (zeg een ansible scriptje alhoewel ik de context niet weet).

Op je vraag over logging: Moderne logging gaat veelal gewoon naar stderr / stdout. Met zeg kubernetes/docker containers is dat gelijk goed, onder systemd kun je die stromen in een service ook prima configureren. En ook iets als apache airflow verwacht logging daar. Een logging framework is prima, maar loggen naar een bestand is veelal geen taak van een script/applicatie meer.

Zie daarvoor ook:
https://12factor.net/logs
12factor zijn 12 zaken die je voor python applicaties zou kunnen toepassen. Zie ook https://12factor.net/config dat gaat met environment variabelen.
https://kubernetes.io/doc...r-administration/logging/

[Yariva]

pedorus schreef op zondag 7 maart 2021 @ 11:36:
[...]

Ik heb eigenlijk geen flauw idee wat dit op een host doet, in plaats van iets dat door iets buiten de host wordt geregeld (zeg een ansible scriptje alhoewel ik de context niet weet).

Op je vraag over logging: Moderne logging gaat veelal gewoon naar stderr / stdout. Met zeg kubernetes/docker containers is dat gelijk goed, onder systemd kun je die stromen in een service ook prima configureren. En ook iets als apache airflow verwacht logging daar. Een logging framework is prima, maar loggen naar een bestand is veelal geen taak van een script/applicatie meer.

Zie daarvoor ook:
https://12factor.net/logs
12factor zijn 12 zaken die je voor python applicaties zou kunnen toepassen. Zie ook https://12factor.net/config dat gaat met environment variabelen.
https://kubernetes.io/doc...r-administration/logging/

Thanks ik ga hier later vandaag nog even naar kijken.

Wat betreft het host verhaal: dit doelt niet de applicatie host maar een data object in de DCIM.