Toon posts:

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

Pagina: 1
Acties:

Vraag


  • Yariva
  • Registratie: November 2012
  • Laatst online: 21-03 17:45

Yariva

Power to the people!

Topicstarter
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.

Mensen zijn gelijk, maar sommige zijn gelijker dan andere | Humans need not apply

Alle reacties


  • sjorsjuhmaniac
  • Registratie: Februari 2009
  • Laatst online: 14:26
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
  • Registratie: Januari 2018
  • Laatst online: 14:05
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)
  • Registratie: December 2013
  • Laatst online: 12:49
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


Acties:
  • +1Henk 'm!

  • Lethalis
  • Registratie: April 2002
  • Niet online
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]

Ask yourself if you are happy and then you cease to be.


  • Ben(V)
  • Registratie: December 2013
  • Laatst online: 12:49
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • Kalentum
  • Registratie: Juni 2004
  • Nu online
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.

PV Output


  • Ben(V)
  • Registratie: December 2013
  • Laatst online: 12:49
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


Acties:
  • +1Henk 'm!

  • downtime
  • Registratie: Januari 2000
  • Niet online

downtime

Everybody lies

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)
  • Registratie: December 2013
  • Laatst online: 12:49
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.

All truth passes through three stages: First it is ridiculed, second it is violently opposed and third it is accepted as being self-evident.


  • Lethalis
  • Registratie: April 2002
  • Niet online
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.

Ask yourself if you are happy and then you cease to be.


Acties:
  • 0Henk 'm!

  • pedorus
  • Registratie: Januari 2008
  • Niet online
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/

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


Acties:
  • 0Henk 'm!

  • Yariva
  • Registratie: November 2012
  • Laatst online: 21-03 17:45

Yariva

Power to the people!

Topicstarter
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.

Mensen zijn gelijk, maar sommige zijn gelijker dan andere | Humans need not apply

Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee